Remove deprecation for navigator.vendor and navigator.platform

[Pomax]

Summary

The WhatWG spec for the navigator object does not list these properties as deprecated, but does call them out as being useful rather than to be avoided.

While for security reasons the amount of information provided by browsers through navigator properties has been reduced from what the older standard allowed for (as highlighted by the warning in the spec that "user agent implementers are strongly urged to include as little information in this API as possible", which all browsers have indeed taken to heart by only providing summary information rather than detailed information), the properties themselves have not been deprecated, and the use of navigator has in no way been marked as bad. As per the text for the navigator object itself, rather the opposite:

In certain cases, despite the best efforts of the entire industry, web browsers have bugs and limitations that web authors are forced to work around.

This section defines a collection of attributes that can be used to determine, from script, the kind of user agent in use, in order to work around these issues.

Test results and supporting details

• https://html.spec.whatwg.org/multipage/system-state.html#the-navigator-object
• https://html.spec.whatwg.org/multipage/system-state.html#dom-navigator-vendor-dev
• https://html.spec.whatwg.org/multipage/system-state.html#dom-navigator-platform-dev

Related issues

• Mark navigator 'platform' and 'vendor' deprecated #17322 (which incorrectly marked them as deprecated in 2022, when the spec already read what it reads today)
• Issue with "Navigator.platform": Cross-browser API marked deprecated and Chromium-only alternative suggested content#14429 (comment) (link to a summary comment that tracks how this change happened, and how it probably shouldn't have)

[github-actions]

Tip: Review these changes grouped by change (recommended for most PRs), or grouped by feature (for large PRs).

[OnkarRuikar]

I asked about this in the MDN chat rooms. Here is the conversation for future references:

Onkar:
In HTML specs, what are "non-normative" features? Are they non-standard, deprecated, or even experimental?
The navigator.platform and the new navigator.userAgentData.platform both serve a similar purpose.

• How should we treat "non-normative" features on MDN in general? As they are not norm shouldn't they be non-standard?
• Or, is the old one non-normative because it is to be treated as deprecated?
  Recently raised concern: Issue with "Navigator.platform": Cross-browser API marked deprecated and Chromium-only alternative suggested content#14429 (comment)
  One thread in the past: Mark navigator 'platform' and 'vendor' deprecated #17322 (comment)

Sideshowbarker:
The features listed in https://html.spec.whatwg.org/multipage/system-state.html#dom-navigator-platform-dev aren’t non-normative. Instead, the (green) block in the spec that describes those features is non-normative — which means that block is providing information about those features, rather than stating requirements.

The -dev part of the https://html.spec.whatwg.org/multipage/system-state.html#dom-navigator-platform-dev link is short for developer , and the purpose of those green blocks is to provide documentation of those features, targeted at web developers — rather than targeted at browser implementors, which is what the actual requirements in the spec are for (and really the entire rest of the spec other than those green blocks)
👍

So for the navigator.platform, the normative requirements are at https://html.spec.whatwg.org/multipage/system-state.html#dom-navigator-platform (which is what clicking on the self.navigator.platform link in that green block will take you to). (edited)

So at least as far as the specs are concerned, there’s actually no such thing as a “non-normative feature”.

Onkar:
I see. So should we remove deprecated from navigator.platform' in BCD?\ Why does userAgentData.platform` exist that does the same thing?

Sideshowbarker:
The userAgentData properties were created because many of the corresponding ones on navigator have essentially become useless.
👍

That said, I don’t know what the MDN position should be on navigator.platform. One the one hand, it’s not strictly deprecated as far as the spec is concerned. But on the other hand, we have an obligation to warn web developers away from expecting it to return anything accurate.
…because the normative spec requirements are this:

The platform getter steps are to return a string representing the platform on which the browser is executing (e.g. “MacIntel”, “Win32", “Linux x86_64”, “Linux armv81") or, for privacy and compatibility, a string that is commonly returned on another platform.

The part in bold there is what creates the problem for us.
Since that text is saying (in so many words), that implementations can intentionally return something incorrect for it, if they want to.

Sideshowbarker:
Personally I think showing the trashcan icon next to those is exactly what we should be doing if we want to make things as clear as possible to web developers. And the “Not for use in new websites” language that the tooltip text for the trashcan shows is what we want to be saying.

The only problem is, using the term “deprecated” — since the spec doesn’t strictly say the feature is deprecated.
But if we wanted to, we could just change all our machinery to display “Not recommended” or “Discouraged” (or some such) in place of everywhere we currently display “Deprecated”.

[Pomax]

Given that platform just gives you a value that is also found in the user agent string, I see no reason for MDN to have a strong stance on whether to discourage using this poperty or not. it is fully supported in all browsers right now, and has been since the "concern" was raised back in 2019. Six years is a long time to care about security but not enough for literally anyone to actually do anything =)

It's fine, this value doesn't aid in fingerprinting beyond repeating what is already available in "this thing is never going away" properties (and the user agent string is a heck of lot more fingerprinty). MDN doesn't need to "have a stronger opinion" about compat here than the spec defines, and right now that deprecation warning is both unwarranted (there is no security implication), and effectively a lie (it's not deprecated in principle according to the spec, nor in practice in any browser including Firefox)

[SyntaxColoring]

I support "deprecated": false.

I agree that these properties are usually to be avoided. I would support some kind of soft "discouraged by the community" designator, if this repo had one. But this repo's data guidelines state that the deprecated designator that it has today is for authoritative deprecation (e.g. deprecation by the spec), and these properties have not been authoritatively deprecated.

@sideshowbarker is right that we have a responsibility to warn people away from these. I think a good balance is:

• Set "deprecated": false, following the data guidelines.
• Add copy to https://github.com/mdn/content to describe why we don't like these APIs.
  • For navigator.platform, spell out @sideshowbarker's point above.
  • For navigator.vendor, describe the spec's "navigator compatibility mode" concept.
• Remove the trashcan icon.
  • I actually don't mind having it or not having it. But as I understand it, removing it follows from setting "deprecated": false?
• Remove the "not for use in new websites" tooltip.
  • Again, I think this follows from setting "deprecated": false.
  • But even if this didn't follow from setting "deprecated": false, I would want this removed. At least for navigator.platform. There are legitimate uses for it, and the API that would replace it is not broadly supported, so how can we say it's not for use in new code? This was brought up a while ago in #14429.
• Remove the boilerplate deprecation notice at the top of the page.
  • Again, I think this follows from setting "deprecated": false, but again, I would want this removed even it it didn't.
  • It overstates a lot of scary things ("may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes"; "be aware that this feature may cease to work at any time"), and it does not state the actual problems with these APIs.

This is spiritually what the outcome of mdn/content#14429 + mdn/content#14452 was, before it got undone.

I'm happy to work on the https://github.com/mdn/content copy if that's where we go with this.

[Pomax]

For the first point in that list, was that supposed to say false instead of true?

[SyntaxColoring]

Yes, thank you, edited.