Restore navigator.plugins and navigator.mimeTypes as PDF-focused #6738

domenic · 2021-06-04T17:09:58Z

This is an attempt at addressing the discussion starting at #6003 (comment).

It ensures browsers only vary on a single boolean, "PDF viewer supported". Then, it:

Standardizes a new navigator.pdfSupported property which exposes that boolean directly.
Makes the legacy navigator.plugins and navigator.mimeType interfaces expose a uniform set of Plugin and MimeType objects, across every browser, in one of two configurations (depending on the PDF viewer supported boolean).

For PDF viewer supported UAs, the resulting structure is:

5 Plugin objects, named (in order) "PDF Viewer", "Chrome PDF Viewer", "Chromium PDF Viewer", "Microsoft Edge PDF Viewer", "WebKit built-in PDF".
- description: "Portable Document Format" (like Chrome. Safari is the empty string.)
- filename: "internal-pdf-viewer" (like one of Chrome's two possibilities. Safari is the empty string.)
- All 5 point to both of the following MimeType objects via their named/indexed properties.
2 MimeType objects, for the types "application/pdf" and "text/pdf".
- description: "Portable Document Format" (like both Safari and Chrome)
- suffixes: "pdf" (like both Safari and Chrome)
- Both point to the 0th "PDF Viewer" Plugin object via their enabledPlugin getter.
- application/x-google-chrome-pdf is not included

At least two implementers are interested (and none opposed):
- Chrome
- Firefox
- Safari has been supportive of this general direction per comments in Removing plugins? #6003 but has not reviewed this specific spec text.
Tests are written and can be reviewed and commented upon at:
- Test navigator.pdfViewerEnabled/plugins/mimeTypes web-platform-tests/wpt#29559
- I'd also like to write tests based on PDF loading examples web-platform-tests/wpt#27129 to see about PDF loading support being synced...
Implementation bugs are filed:

(See WHATWG Working Mode: Changes for more details.)

Original change description

This is an attempt at addressing the discussion starting at https://github.com//issues/6003#issuecomment-805389170. There is another approach, discussed in https://github.com//issues/6003#issuecomment-854887958, which might supersede this one.

It also includes navigator.pdfSupported as a modern way of doing detection so that web developers have a bit of an easier time, and maybe in five years we can revisit removing navigator.plugins and navigator.mimeTypes.

This approach (for PDF-supporting UAs) is:

Such UAs have a single Plugin with the following properties:
- name: implementation-defined, but must contain the string "PDF".
- description: "Portable Document Format" (like Chrome. Safari is the empty string.)
- filename: "internal-pdf-viewer" (like one of Chrome's two possibilities. Safari is the empty string.)
Such UAs have two MimeTypes with the following properties:
- type: application/pdf for the 0th, and text/pdf for the 1st. (Like Safari. Chrome has application/x-google-chrome-pdf for the 0th, and application/pdf for the 1st.)
- description: "Portable Document Format" (like both Safari and Chrome)
- suffixes: "pdf" (like both Safari and Chrome)
These objects are related in the following manner: the Plugin maps to both MimeTypes (via named/indexed properties), and each MimeType maps to the single Plugin (via its enabledPlugin getter).

Notable differences in object structure:

Safari also has a third MimeType for application/postscript, mapping to the same Plugin. Per Removing plugins? #6003 (comment) I left that out (although you can see an earlier commit that supported it).
Chrome has two MimeTypes and two corresponding Plugins which map to each other. I went with the single-plugin-two-MimeType approach from Safari because it's simpler.

Potential variants:

We could try to cut out text/pdf. It's somewhat harmless but while we're simplifying it might be nice to get rid of...
This leaves one bit of implementation-defined behavior, the name of the plugin. Could we clean that up? See the discussion in Removing plugins? #6003 (comment).

/browsing-the-web.html ( diff )
/common-dom-interfaces.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/obsolete.html ( diff )
/system-state.html ( diff )
/window-object.html ( diff )

- Adds window.pdfSupported - Either 0, 2, or 3 MIME types (the third is PostScript) - 1 Plugin, with implementation-defined name

Nice simplification

annevk

This looks good editorially, but is everyone on the same page with regards to the PDF boolean? Does this match what implementations do today when the user disables inline viewing support? And also, does this allow for an implementation to say that it's not supported, but still support it? (I think that's what mobile Safari does.)

cc @rniwa @smaug----

domenic · 2021-06-17T17:24:01Z

Does this match what implementations do today when the user disables inline viewing support?

Quite probably not, but I think there was general interest in aligning on this model to reduce fingerprinting.

And also, does this allow for an implementation to say that it's not supported, but still support it? (I think that's what mobile Safari does.)

Yes, this is allowed. There is no connection between the boolean and the navigation processing model, so they can vary independently.

annevk · 2021-06-17T18:16:34Z

Given web-platform-tests/wpt#27129 it seems more useful if this is aligned with the processing model (and thus user preferences) at no additional fingerprinting cost (unless you take into account how quickly you can acquire the bit). Although that would argue that mobile Safari changes what they do. Hmm, I guess I'm curious what others think.

mfreed7 · 2021-06-17T22:48:12Z

source

+   <dd>
+    <p>Returns true if the user agent supports inline viewing of PDF files, or false otherwise.</p>
+
+    <p>Note that this does not reflect user preferences, but instead the basic capabilities of the user agent. If the user agent supports PDF viewing, but a user has disabled that ability through a browser preference, this property still returns true.</p>


Hmm, I do think this should reflect the user preference. The code that was incompatible with the original "empty" plugins list was just trying to figure out if that setting was on/off, so they could take appropriate action. And from an author point of view, I do see the need. If PDFs are supported, show the PDF. If not, take a different course of action which may or may not involve downloading the PDF or showing something alternative. Or just not giving them the option to see a PDF in the first place.

mfreed7 · 2021-06-17T22:51:01Z

source

+  false, to reflect the inherent capabilities of these different browser builds. But if the user
+  disables inline PDF viewing on the desktop browser, the user agent has to keep the <span>PDF
+  viewer supported</span> value of true, so as to avoid identifying users which have changed that
+  setting.</p>


I do understand that this exposes one bit of entropy. But the original list already exposed that same bit, and we're hopefully reducing the remaining (>1 bit) entropy leak from the previously variable plugin lists. And I believe developers do need a way to tell whether PDFs are viewable, no?

mfreed7 · 2021-06-17T22:56:30Z

Nice work on this PR - it looks very clean and makes sense to me. I think with one exception (see below), it should be web compatible for at least the previously-identified breakages from the empty plugins array.

Given web-platform-tests/wpt#27129 it seems more useful if this is aligned with the processing model (and thus user preferences) at no additional fingerprinting cost (unless you take into account how quickly you can acquire the bit). Although that would argue that mobile Safari changes what they do. Hmm, I guess I'm curious what others think.

I put some comments in to this effect as well, but I think the bit needs to reflect the user preference, for web compat as well as general developer capabilities.

domenic · 2021-06-22T16:37:13Z

I'm working on such a change now, including updates to the navigate processing model.

I wrote a quick test to see how text/pdf should play into things and I found out that in Chrome and Firefox at least, if the server sets text/pdf, the result is not treated as a PDF:

https://selective-heliotrope-dumpling.glitch.me/text-pdf

However in Safari it is.

Probably we should align on Safari behavior, since it doesn't hurt anything and keeps things in sync with navigator.mimeTypes? Or we could remove text/pdf from navigator.mimeTypes and ask Safari to remove this...

domenic · 2021-06-22T17:00:21Z

I've pushed a commit that makes pdf viewer support respect user preferences and be tied to the processing model (although the navigation processing model is a bit shaky around plugins/"inline content").

mfreed7 · 2021-06-22T22:26:54Z

I'm working on such a change now, including updates to the navigate processing model.

Thanks for working on the change to respect user preferences!

I wrote a quick test to see how text/pdf should play into things and I found out that in Chrome and Firefox at least, if the server sets text/pdf, the result is not treated as a PDF:

https://selective-heliotrope-dumpling.glitch.me/text-pdf

However in Safari it is.

Probably we should align on Safari behavior, since it doesn't hurt anything and keeps things in sync with navigator.mimeTypes? Or we could remove text/pdf from navigator.mimeTypes and ask Safari to remove this...

I agree that this sounds like a bug in Chromium to me - I would think text/pdf should invoke the PDF viewer. Do you know if that's already been reported as a bug? If not, I can file it.

domenic · 2021-06-22T22:29:37Z

I'm not aware of such a bug. Arguably it's more correct to not support text/pdf, since the official MIME type is application/pdf. But since this whole business is an exercise in maximal compatibility anyway, that's why I was leaning toward supporting it in Chrome.

mfreed7 · 2021-06-23T01:18:01Z

I'm not aware of such a bug. Arguably it's more correct to not support text/pdf, since the official MIME type is application/pdf. But since this whole business is an exercise in maximal compatibility anyway, that's why I was leaning toward supporting it in Chrome.

I agree with the last part of what you said - let's try to maximize compatibility. It doesn't seem like there should be any potential issues with starting to run the PDF viewer on text/pdf files, when they currently just show the user garbage. But you never know, I guess?

Side-note, Gecko puts up a "What should Firefox do with this file?" dialog for text/pdf, and doesn't display it.

I filed this Chromium bug.

source

domenic · 2021-07-01T20:17:04Z

@rniwa, ping to give your review on the choices we've made here. What do you think?

Follows whatwg/html#6738.

mfreed7 · 2021-07-09T20:00:38Z

@smaug---- also ping. We discussed this overall change at the last spec triage meeting, and I believe you were supportive, but this was not captured in the notes. Could you please confirm your support here?

domenic · 2021-07-13T16:33:35Z

I'd like to merge and file bugs on this now, since we had supportive comments from Mozilla and Apple at the triage meeting and in #6003. Normally I'd prefer to get more explicit support for the exact proposal, but we have a bit of an unusual situation here, where the current spec (post-#6296) does not have the support of the implementer community. So moving from the current empty-lists spec to this spec is a strict improvement, I think.

I still do need a green checkmark from someone with write privileges, though. @foolip perhaps? (I believe @annevk is out of office.)

mfreed7 · 2021-07-13T16:43:23Z

I'd like to merge and file bugs on this now, since we had supportive comments from Mozilla and Apple at the triage meeting and in #6003. Normally I'd prefer to get more explicit support for the exact proposal, but we have a bit of an unusual situation here, where the current spec (post-#6296) does not have the support of the implementer community. So moving from the current empty-lists spec to this spec is a strict improvement, I think.

I still do need a green checkmark from someone with write privileges, though. @foolip perhaps? (I believe @annevk is out of office.)

Thank you - I agree that it would be good to merge this. I'm working through the Intent to Ship for Chromium, but this was an immediate question. As I mentioned above, I do believe there was agreement on this direction from (at least) @smaug---- at the last meeting, but that isn't documented, unfortunately.

foolip

Green check mark with nits.

foolip · 2021-07-13T16:47:57Z

source

+
+  <div w-nodev>
+
+  <p>Although these days detecting PDF viewer support can be done via <code


Great note!

foolip · 2021-07-13T16:49:58Z

source

+
+  <p class="note">These names were chosen based on evidence of what websites historically search
+  for, and thus what is necessary for user agents to expose in order to maintain compatibility with
+  existing content. They are ordered alphabetically The "<code data-x="">PDF Viewer</code>" name was


Suggested change

existing content. They are ordered alphabetically The "<code data-x="">PDF Viewer</code>" name was

existing content. They are ordered alphabetically. The "<code data-x="">PDF Viewer</code>" name was

foolip · 2021-07-13T16:53:19Z

source

+   <li><p>Return null.</p></li>
+  </ol>
+
+  <p>The <code>PluginArray</code> interface <span data-x="support named properties">support indexed


Suggested change

<p>The <code>PluginArray</code> interface <span data-x="support named properties">support indexed

<p>The <code>PluginArray</code> interface <span data-x="support named properties">supports indexed

foolip · 2021-07-13T16:55:27Z

source

+  </ol>
+
+  <p>The <code>PluginArray</code> interface's <dfn attribute for="PluginArray"><code
+  data-x="dom-PluginArray-length">length</code></dfn> getter steps are to return 5 if the user


Optional nit: the hardcoded 5 here is kind of fun, but could this instead be defined in terms of the "PDF viewer plugin objects", with less words overall?

Yeah, good point, the 5 could be nicer since we can just look at the size of the list. The « 0, 1, 2, 3, 4 » is a bit trickier to make generic, just in terms of wording... I might try anyway.

I'll punt on fixing the indices for now but can do an editorial followup once whatwg/infra#386 is merged.

@domenic

…ssInfo MimeClassInfo now requires to pass a list of extensions to the constructor, so we need to generate at least a random one to create the fake MimeClassInfo used for farbling purposes. FIXME: 3 browser tests failing likely because of this patch being wrong: BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPlugins BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsBuiltin BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsReset Chromium change: https://source.chromium.org/chromium/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

The CL below made a change to make fingerprinting more difficult in Chromium without breaking existing sites by returning a fixed list of PDF plugins, regardless of the actual ones available, which broke our farbling of the navigator.plugins array. Since farbling in Brave works in a different way (i.e. differently depending on the selected "farbling level"), we're just disabling this runtime feature to get back to the original code we had before, which would make sure the actual list of plugins is only returned if the used has explicitly disabled fingerprinting protections, otherwise a farbled, randomly generated and always different list of plugins will be returned (which is better than a fixed list anyway). Last, we add some new chromium_src overrides here to avoid the need of a C++ patch to disable this runtime feature via WebRuntimeFeatures. Chromium change: https://chromium.googlesource.com/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

…pes in navigator, a=testonly Automatic update from web-platform-tests Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635 Change-Id: I7c52af5b918768d8b4c4a9faa409fb4e6b72ecc2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3017890 Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Cr-Commit-Position: refs/heads/master@{#909443} -- wpt-commits: 7be5ecfd72f0e95257f435a101b88e5ad277206f wpt-pr: 29652

@domenic

…ssInfo MimeClassInfo now requires to pass a list of extensions to the constructor, so we need to generate at least a random one to create the fake MimeClassInfo used for farbling purposes. FIXME: 3 browser tests failing likely because of this patch being wrong: BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPlugins BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsBuiltin BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsReset Chromium change: https://source.chromium.org/chromium/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

The CL below made a change to make fingerprinting more difficult in Chromium without breaking existing sites by returning a fixed list of PDF plugins, regardless of the actual ones available, which broke our farbling of the navigator.plugins array. Since farbling in Brave works in a different way (i.e. differently depending on the selected "farbling level"), we're just disabling this runtime feature to get back to the original code we had before, which would make sure the actual list of plugins is only returned if the used has explicitly disabled fingerprinting protections, otherwise a farbled, randomly generated and always different list of plugins will be returned (which is better than a fixed list anyway). Last, we add some new chromium_src overrides here to avoid the need of a C++ patch to disable this runtime feature via WebRuntimeFeatures. Chromium change: https://chromium.googlesource.com/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

MimeClassInfo now requires to pass a list of extensions to the constructor, so we need to generate at least a random one to create the fake MimeClassInfo used for farbling purposes. Note that 3 browser tests failing likely because of this patch: BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPlugins BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsBuiltin BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsReset This is because of Chromium now enabling a feature that will return a hardcoded list via navigator.plugins which is incompatible with Brave's farbling code. That will be addressed in the next patch. Chromium change: https://source.chromium.org/chromium/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

The CL below made a change to make fingerprinting more difficult in Chromium without breaking existing sites by returning a fixed list of PDF plugins, regardless of the actual ones available, which broke our farbling of the navigator.plugins array. Since farbling in Brave works in a different way (i.e. differently depending on the selected "farbling level"), we're just disabling this runtime feature to get back to the original code we had before, which would make sure the actual list of plugins is only returned if the used has explicitly disabled fingerprinting protections, otherwise a farbled, randomly generated and always different list of plugins will be returned (which is better than a fixed list anyway). Last, we add some new chromium_src overrides here to avoid the need of a C++ patch to disable this runtime feature via WebRuntimeFeatures. Chromium change: https://chromium.googlesource.com/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

MimeClassInfo now requires to pass a list of extensions to the constructor, so we need to generate at least a random one to create the fake MimeClassInfo used for farbling purposes. Note that 3 browser tests failing likely because of this patch: BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPlugins BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsBuiltin BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsReset This is because of Chromium now enabling a feature that will return a hardcoded list via navigator.plugins which is incompatible with Brave's farbling code. That will be addressed in the next patch. Chromium change: https://source.chromium.org/chromium/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

The CL below made a change to make fingerprinting more difficult in Chromium without breaking existing sites by returning a fixed list of PDF plugins, regardless of the actual ones available, which broke our farbling of the navigator.plugins array. Since farbling in Brave works in a different way (i.e. differently depending on the selected "farbling level"), we're just disabling this runtime feature to get back to the original code we had before, which would make sure the actual list of plugins is only returned if the used has explicitly disabled fingerprinting protections, otherwise a farbled, randomly generated and always different list of plugins will be returned (which is better than a fixed list anyway). Last, we add some new chromium_src overrides here to avoid the need of a C++ patch to disable this runtime feature via WebRuntimeFeatures. Chromium change: https://chromium.googlesource.com/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

MimeClassInfo now requires to pass a list of extensions to the constructor, so we need to generate at least a random one to create the fake MimeClassInfo used for farbling purposes. Note that 3 browser tests failing likely because of this patch: BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPlugins BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsBuiltin BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsReset This is because of Chromium now enabling a feature that will return a hardcoded list via navigator.plugins which is incompatible with Brave's farbling code. That will be addressed in the next patch. Chromium change: https://source.chromium.org/chromium/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

The CL below made a change to make fingerprinting more difficult in Chromium without breaking existing sites by returning a fixed list of PDF plugins, regardless of the actual ones available, which broke our farbling of the navigator.plugins array. Since farbling in Brave works in a different way (i.e. differently depending on the selected "farbling level"), we're just disabling this runtime feature to get back to the original code we had before, which would make sure the actual list of plugins is only returned if the used has explicitly disabled fingerprinting protections, otherwise a farbled, randomly generated and always different list of plugins will be returned (which is better than a fixed list anyway). Last, we add some new chromium_src overrides here to avoid the need of a C++ patch to disable this runtime feature via WebRuntimeFeatures. Chromium change: https://chromium.googlesource.com/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

MimeClassInfo now requires to pass a list of extensions to the constructor, so we need to generate at least a random one to create the fake MimeClassInfo used for farbling purposes. Note that 3 browser tests failing likely because of this patch: BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPlugins BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsBuiltin BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsReset This is because of Chromium now enabling a feature that will return a hardcoded list via navigator.plugins which is incompatible with Brave's farbling code. That will be addressed in the next patch. Chromium change: https://source.chromium.org/chromium/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

The CL below made a change to make fingerprinting more difficult in Chromium without breaking existing sites by returning a fixed list of PDF plugins, regardless of the actual ones available, which broke our farbling of the navigator.plugins array. Since farbling in Brave works in a different way (i.e. differently depending on the selected "farbling level"), we're just disabling this runtime feature to get back to the original code we had before, which would make sure the actual list of plugins is only returned if the used has explicitly disabled fingerprinting protections, otherwise a farbled, randomly generated and always different list of plugins will be returned (which is better than a fixed list anyway). Last, we add some new chromium_src overrides here to avoid the need of a C++ patch to disable this runtime feature via WebRuntimeFeatures. Chromium change: https://chromium.googlesource.com/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

MimeClassInfo now requires to pass a list of extensions to the constructor, so we need to generate at least a random one to create the fake MimeClassInfo used for farbling purposes. Note that 3 browser tests failing likely because of this patch: BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPlugins BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsBuiltin BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsReset This is because of Chromium now enabling a feature that will return a hardcoded list via navigator.plugins which is incompatible with Brave's farbling code. That will be addressed in the next patch. Chromium change: https://source.chromium.org/chromium/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

The CL below made a change to make fingerprinting more difficult in Chromium without breaking existing sites by returning a fixed list of PDF plugins, regardless of the actual ones available, which broke our farbling of the navigator.plugins array. Since farbling in Brave works in a different way (i.e. differently depending on the selected "farbling level"), we're just disabling this runtime feature to get back to the original code we had before, which would make sure the actual list of plugins is only returned if the used has explicitly disabled fingerprinting protections, otherwise a farbled, randomly generated and always different list of plugins will be returned (which is better than a fixed list anyway). Last, we add some new chromium_src overrides here to avoid the need of a C++ patch to disable this runtime feature via WebRuntimeFeatures. Chromium change: https://chromium.googlesource.com/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

MimeClassInfo now requires to pass a list of extensions to the constructor, so we need to generate at least a random one to create the fake MimeClassInfo used for farbling purposes. Note that 3 browser tests failing likely because of this patch: BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPlugins BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsBuiltin BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsReset This is because of Chromium now enabling a feature that will return a hardcoded list via navigator.plugins which is incompatible with Brave's farbling code. That will be addressed in the next patch. Chromium change: https://source.chromium.org/chromium/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

The CL below made a change to make fingerprinting more difficult in Chromium without breaking existing sites by returning a fixed list of PDF plugins, regardless of the actual ones available, which broke our farbling of the navigator.plugins array. Since farbling in Brave works in a different way (i.e. differently depending on the selected "farbling level"), we're just disabling this runtime feature to get back to the original code we had before, which would make sure the actual list of plugins is only returned if the used has explicitly disabled fingerprinting protections, otherwise a farbled, randomly generated and always different list of plugins will be returned (which is better than a fixed list anyway). Last, we add some new chromium_src overrides here to avoid the need of a C++ patch to disable this runtime feature via WebRuntimeFeatures. Chromium change: https://chromium.googlesource.com/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

MimeClassInfo now requires to pass a list of extensions to the constructor, so we need to generate at least a random one to create the fake MimeClassInfo used for farbling purposes. Note that 3 browser tests failing likely because of this patch: BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPlugins BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsBuiltin BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsReset This is because of Chromium now enabling a feature that will return a hardcoded list via navigator.plugins which is incompatible with Brave's farbling code. That will be addressed in the next patch. Chromium change: https://source.chromium.org/chromium/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

The CL below made a change to make fingerprinting more difficult in Chromium without breaking existing sites by returning a fixed list of PDF plugins, regardless of the actual ones available, which broke our farbling of the navigator.plugins array. Since farbling in Brave works in a different way (i.e. differently depending on the selected "farbling level"), we're just disabling this runtime feature to get back to the original code we had before, which would make sure the actual list of plugins is only returned if the used has explicitly disabled fingerprinting protections, otherwise a farbled, randomly generated and always different list of plugins will be returned (which is better than a fixed list anyway). Last, we add some new chromium_src overrides here to avoid the need of a C++ patch to disable this runtime feature via WebRuntimeFeatures. Chromium change: https://chromium.googlesource.com/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

MimeClassInfo now requires to pass a list of extensions to the constructor, so we need to generate at least a random one to create the fake MimeClassInfo used for farbling purposes. Note that 3 browser tests failing likely because of this patch: BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPlugins BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsBuiltin BraveNavigatorPluginsFarblingBrowserTest.FarbleNavigatorPluginsReset This is because of Chromium now enabling a feature that will return a hardcoded list via navigator.plugins which is incompatible with Brave's farbling code. That will be addressed in the next patch. Chromium change: https://source.chromium.org/chromium/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

The CL below made a change to make fingerprinting more difficult in Chromium without breaking existing sites by returning a fixed list of PDF plugins, regardless of the actual ones available, which broke our farbling of the navigator.plugins array. Since farbling in Brave works in a different way (i.e. differently depending on the selected "farbling level"), we're just disabling this runtime feature to get back to the original code we had before, which would make sure the actual list of plugins is only returned if the used has explicitly disabled fingerprinting protections, otherwise a farbled, randomly generated and always different list of plugins will be returned (which is better than a fixed list anyway). Chromium change: https://chromium.googlesource.com/chromium/src/+/fb96360c18b517bcc487c0de7235eec27e3adf5e commit fb96360c18b517bcc487c0de7235eec27e3adf5e Author: Mason Freed <masonf@chromium.org> Date: Fri Aug 6 20:20:17 2021 +0000 Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635

@domenic

See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635 Change-Id: I7c52af5b918768d8b4c4a9faa409fb4e6b72ecc2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3017890 Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Cr-Commit-Position: refs/heads/master@{#909443} NOKEYCHECK=True GitOrigin-RevId: fb96360c18b517bcc487c0de7235eec27e3adf5e

@domenic

…pes in navigator, a=testonly Automatic update from web-platform-tests Hard-code the list of plugins and mimetypes in navigator See [1] for a previous attempt to completely empty the navigator.plugins and navigator.mimeTypes APIs. That caused site breakage due to sites scanning for a PDF reader. This new attempt is discussed in significant detail in [2], and involves the hard-coding of a list of PDF viewers and mime types. The plugins/mimetypes lists will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. This is to ensure compat with sites that scan the plugins list for specific PDF plugins to decide on behavior. Prior to this CL, when the PDF viewer is disabled, the PDF viewer plugins are unloaded. Tests were copied mostly verbatim from [3], thanks @domenic. I2S: https://groups.google.com/a/chromium.org/g/blink-dev/c/bbxAGu90LgM [1] https://chromium-review.googlesource.com/c/chromium/src/+/2783393 [2] whatwg/html#6738 [3] web-platform-tests/wpt#29559 Bug: 1164635 Change-Id: I7c52af5b918768d8b4c4a9faa409fb4e6b72ecc2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3017890 Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Cr-Commit-Position: refs/heads/master@{#909443} -- wpt-commits: 7be5ecfd72f0e95257f435a101b88e5ad277206f wpt-pr: 29652

domenic added 2 commits June 4, 2021 12:39

Take 1

4042477

- Adds window.pdfSupported - Either 0, 2, or 3 MIME types (the third is PostScript) - 1 Plugin, with implementation-defined name

Remove optional PostScript support

f47fe2d

Nice simplification

domenic mentioned this pull request Jun 4, 2021

Removing plugins? #6003

Open

domenic added 2 commits June 10, 2021 16:51

Add all the Plugin objects

08b39bf

Merge branch 'main' into plugins-restored

74e9543

domenic requested a review from annevk June 10, 2021 21:01

domenic added the interop Implementations are not interoperable with each other label Jun 15, 2021

annevk reviewed Jun 17, 2021

View reviewed changes

mfreed7 reviewed Jun 17, 2021

View reviewed changes

Tie to processing model and user preferences

f98c3de

zcorpan reviewed Jul 1, 2021

View reviewed changes

source Outdated Show resolved Hide resolved

domenic added 2 commits July 1, 2021 14:24

pdfSupported -> pdfViewerEnabled

3f223dd

Merge branch 'main' into plugins-restored

89d35db

domenic added a commit to web-platform-tests/wpt that referenced this pull request Jul 1, 2021

Test navigator.pdfViewerEnabled/plugins/mimeTypes

946c36d

Follows whatwg/html#6738.

domenic mentioned this pull request Jul 1, 2021

Test navigator.pdfViewerEnabled/plugins/mimeTypes web-platform-tests/wpt#29559

Closed

foolip added the impacts documentation Used by documentation communities, such as MDN, to track changes that impact documentation label Jul 13, 2021

foolip approved these changes Jul 13, 2021

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Restore navigator.plugins and navigator.mimeTypes as PDF-focused #6738

Restore navigator.plugins and navigator.mimeTypes as PDF-focused #6738

domenic commented Jun 4, 2021 •

edited

Loading

annevk left a comment

domenic commented Jun 17, 2021

annevk commented Jun 17, 2021

mfreed7 Jun 17, 2021

mfreed7 Jun 17, 2021

mfreed7 commented Jun 17, 2021

domenic commented Jun 22, 2021

domenic commented Jun 22, 2021

mfreed7 commented Jun 22, 2021

domenic commented Jun 22, 2021

mfreed7 commented Jun 23, 2021

domenic commented Jul 1, 2021

mfreed7 commented Jul 9, 2021

domenic commented Jul 13, 2021

mfreed7 commented Jul 13, 2021

foolip left a comment

foolip Jul 13, 2021

foolip Jul 13, 2021

foolip Jul 13, 2021

foolip Jul 13, 2021

domenic Jul 13, 2021

domenic Jul 13, 2021


		<div w-nodev>

		<p>Although these days detecting PDF viewer support can be done via <code

	existing content. They are ordered alphabetically The "<code data-x="">PDF Viewer</code>" name was
	existing content. They are ordered alphabetically. The "<code data-x="">PDF Viewer</code>" name was

	<p>The <code>PluginArray</code> interface <span data-x="support named properties">support indexed
	<p>The <code>PluginArray</code> interface <span data-x="support named properties">supports indexed

Restore navigator.plugins and navigator.mimeTypes as PDF-focused #6738

Restore navigator.plugins and navigator.mimeTypes as PDF-focused #6738

Conversation

domenic commented Jun 4, 2021 • edited Loading

annevk left a comment

Choose a reason for hiding this comment

domenic commented Jun 17, 2021

annevk commented Jun 17, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mfreed7 commented Jun 17, 2021

domenic commented Jun 22, 2021

domenic commented Jun 22, 2021

mfreed7 commented Jun 22, 2021

domenic commented Jun 22, 2021

mfreed7 commented Jun 23, 2021

domenic commented Jul 1, 2021

mfreed7 commented Jul 9, 2021

domenic commented Jul 13, 2021

mfreed7 commented Jul 13, 2021

foolip left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic commented Jun 4, 2021 •

edited

Loading