Test navigator.pdfViewerEnabled/plugins/mimeTypes #29559
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
3 tasks
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Jul 13, 2021
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 [2], and involves the hard-coding of a list of PDF viewers and mime types. The list will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. 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] #29559 Bug: 1164635 Change-Id: I7c52af5b918768d8b4c4a9faa409fb4e6b72ecc2
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Jul 16, 2021
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 [2], and involves the hard-coding of a list of PDF viewers and mime types. The list will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. 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] #29559 Bug: 1164635 Change-Id: I7c52af5b918768d8b4c4a9faa409fb4e6b72ecc2
annevk
approved these changes
Jul 20, 2021
|
This is subsumed into #29652 (Chromium export) so I'll close it, but I'll keep an eye on that Chromium CL to make sure it lands! |
Thanks! So will I. I'm just waiting for the approvals on the I2S and I'll land it. |
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Jul 21, 2021
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 [2], and involves the hard-coding of a list of PDF viewers and mime types. The list will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. 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] #29559 Bug: 1164635 Change-Id: I7c52af5b918768d8b4c4a9faa409fb4e6b72ecc2
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Jul 23, 2021
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 [2], and involves the hard-coding of a list of PDF viewers and mime types. The list will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. 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] #29559 Bug: 1164635 Change-Id: I7c52af5b918768d8b4c4a9faa409fb4e6b72ecc2
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Aug 3, 2021
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 [2], and involves the hard-coding of a list of PDF viewers and mime types. The list will be empty if the user setting to download PDFs instead of viewing them (chrome://settings/content/pdfDocuments) is enabled. 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] #29559 Bug: 1164635 Change-Id: I7c52af5b918768d8b4c4a9faa409fb4e6b72ecc2
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Aug 3, 2021
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] #29559 Bug: 1164635 Change-Id: I7c52af5b918768d8b4c4a9faa409fb4e6b72ecc2
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Aug 6, 2021
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] #29559 Bug: 1164635 Change-Id: I7c52af5b918768d8b4c4a9faa409fb4e6b72ecc2
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Aug 6, 2021
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] #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}
chromium-wpt-export-bot
pushed a commit
that referenced
this pull request
Aug 6, 2021
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] #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}
blueboxd
pushed a commit
to blueboxd/chromium-legacy
that referenced
this pull request
Aug 7, 2021
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}
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 12, 2021
…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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 13, 2021
…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
moz-v2v-gh
pushed a commit
to mozilla/gecko-dev
that referenced
this pull request
Aug 14, 2021
…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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 16, 2021
…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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 16, 2021
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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 16, 2021
…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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 17, 2021
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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 18, 2021
…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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 18, 2021
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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 19, 2021
…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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 19, 2021
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
jamienicol
pushed a commit
to jamienicol/gecko
that referenced
this pull request
Aug 20, 2021
…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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 20, 2021
…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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 20, 2021
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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 20, 2021
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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 20, 2021
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
mkarolin
pushed a commit
to brave/brave-core
that referenced
this pull request
Aug 26, 2021
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
mkarolin
pushed a commit
to brave/brave-core
that referenced
this pull request
Aug 26, 2021
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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 31, 2021
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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Aug 31, 2021
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
mkarolin
pushed a commit
to brave/brave-core
that referenced
this pull request
Sep 1, 2021
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
mkarolin
pushed a commit
to brave/brave-core
that referenced
this pull request
Sep 1, 2021
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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Sep 2, 2021
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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Sep 2, 2021
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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Sep 2, 2021
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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Sep 2, 2021
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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Sep 3, 2021
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
mariospr
added a commit
to brave/brave-core
that referenced
this pull request
Sep 3, 2021
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
mkarolin
pushed a commit
to brave/brave-core
that referenced
this pull request
Sep 7, 2021
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
mkarolin
pushed a commit
to brave/brave-core
that referenced
this pull request
Sep 7, 2021
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
mkarolin
pushed a commit
to brave/brave-core
that referenced
this pull request
Sep 11, 2021
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
mkarolin
pushed a commit
to brave/brave-core
that referenced
this pull request
Sep 11, 2021
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
mkarolin
pushed a commit
to brave/brave-core
that referenced
this pull request
Sep 13, 2021
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
mkarolin
pushed a commit
to brave/brave-core
that referenced
this pull request
Sep 13, 2021
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
mjfroman
pushed a commit
to mjfroman/moz-libwebrtc-third-party
that referenced
this pull request
Oct 14, 2022
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
i3roly
pushed a commit
to i3roly/firefox-dynasty
that referenced
this pull request
Jun 1, 2024
…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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follows whatwg/html#6738.
/cc @annevk @mfreed7 . Mason might want to take over these tests and move them into a Chromium CL since I just wrote them blind and there might be bugs.