navigator.plugins and browser fingerprinting protection

[noellarkin]

By default, Pale moon lists NPAPI plugins for navigator.plugins and a list of corresponding mime types for navigator.mimeTypes. When about:config is used to disable plugin enumeration, it returns empty arrays for both navigator.plugins and navigator.mimeTypes.
A fingerprint protection method I've come across in other browsers like Brave is returning a generic list of plugin names, instead of zero arrays:
https://github.com/brave/brave-browser/issues/9435

Would this be implementable in Pale Moon in the following manner:
- when plugin enumeration is enabled in about:config, the default list of NPAPI plugins is returned.
- when plugin enumeration is disabled in about:config, instead of returning empty arrays, to return an array of very generic plugins and mimeTypes.
IMO this would be useful for fingerprint protection, whilst allowing those who are using NPAPI plugins to report them.

[Moonchild]

I don't think this is a good idea, which is why it has not been considered for Pale Moon. The whole point of plugin enumeration is to provide websites with an accurate list of capabilities provided by plugins. It's easy to work around not getting that list (using e.g. a try/fail fallback) but it is not possible for a website to properly respond to a fake, minimal list of plugins and knowing whether the capability is there or not. Defaulting to try/fail as the only solution (for a fake list) would make the whole point of enumeration capabilities moot, making it equal to not providing the list to begin with.

[noellarkin]

Understood. You're right, that makes sense.
I'd still like to play around with this, though - - I did a git clone of the pale moon and uxp repos last night, so I could learn a little more about it. If I were to try implementing this, what would I have to tweak?
I suppose its in /platform/dom/plugins or something - - just did a "search for string in file" using notepad++ for "navigator.plugins" but most of what it found was tests.

[Moonchild]

Looking into the fingerprinting around this because of your question, I realized something is amiss:
I noticed that the shuffling implementation I put in early in Pale Moon's development to combat plugin enumeration fingerprinting was dropped along the way when rebasing for Pale Moon 27 - one more to chalk up, I guess. I'll re-implement this.

[moonbat]

The whole point of plugin enumeration is to provide websites with an accurate list of capabilities provided by plugins.

How many non legacy sites even care about plugins anymore

[Moonchild]

How many non legacy sites even care about plugins anymore

Not many, and as such they are also less likely to check plugins for tracking/fingerprinting.
Still, for those that do, being as robust as possible is a good thing.

[noellarkin]

Not many, and as such they are also less likely to check plugins for tracking/fingerprinting.
Still, for those that do, being as robust as possible is a good thing.

An excerpt from https://fingerprint.com/blog/browser-an ... echniques/:

Another good example of the uniformity approach to minimize fingerprint-able browser surface is the recent changes made to the deprecated navigator.plugins and navigator.mimeTypes features. The WHATWG HTML Standard was updated to reflect Flash deprecation and specified that browsers should always return a fixed list of supported plugins and mime types (depending on a new read-only navigator.pdfViewerEnabled property). Gecko and Chromium have already adopted the change.

From https://incolumitas.com/2021/03/01/7-co ... -scraping/

Furthermore, scrapers don't have any plugin information (navigator.plugins) associated with them. This is very uncommon for legit chrome browses. Usually, every chrome browser has standard plugin information such as

"plugins": [
{
"name": "Chrome PDF Plugin",
"description": "Portable Document Format",
"mimeType": {
"type": "application/x-google-chrome-pdf",
"suffixes": "pdf"
}
},
{
"name": "Chrome PDF Viewer",
"description": "",
"mimeType": {
"type": "application/pdf",
"suffixes": "pdf"
}
},
{
"name": "Native Client",
"description": "",
"mimeType": {
"type": "application/x-nacl",
"suffixes": ""
}
}
]

With scrapingrobot.com, this information looks like this:

"plugins": [
{
"mimeType": null
},
{
"mimeType": null
}
]

It seems to me there are two issues here:
1. when plugins are disabled in Pale Moon (default state set to 0) then it returns navigator.plugins values that makes it look more like a bot scraper.
2. when plugins are enabled in Pale Moon, it returns a highly identifiable, fingerprintable list of plugins.

IMO it would be nice to at least have the option to return a generic plugin list, even though I agree that from a feature reporting perspective, @Moonchild is right about Pale Moon's approach.
Perhaps some kind of about:config switch like plugin.return_generic_values that is set to false by default, and if set to true, returns a fixed list of generic plugins and MIME types.

[Moonchild]

Not going to consider it for the reasons I already explained. Also, I disagree with the uniformity approach to minimize fingerprint-able browser surfaces. Instead, we use the poisoning approach as it is more effective. Unique is good, when that uniqueness never returns later from the same browser. It makes tracking data useless, while the uniformity approach does not (it just makes it more generic/grouped, still easily identifying/tracking users based on coarser granularity).

[adoxa]

Off-topic:

courser granularity

Of course, that should be "coarser" (it annoyed me in the release notes, so this time I'm going to speak up ).

[noellarkin]

Not going to consider it for the reasons I already explained. Also, I disagree with the uniformity approach to minimize fingerprint-able browser surfaces. Instead, we use the poisoning approach as it is more effective. Unique is good, when that uniqueness never returns later from the same browser. It makes tracking data useless, while the uniformity approach does not (it just makes it more generic/grouped, still easily identifying/tracking users based on courser granularity).

Okay, I see your point - - the uniqueness approach makes sense, too, if it is implementable. You have a system that shuffles the order of NPAPI plugins array, which is great, but in my computer, for example, there's only one NPAPI plugin (SumatraPDF), so shuffling the PluginArray wouldn't really do anything. I'm not sure how many people use NPAPI plugins any more so they may not have the plugins on their computers to make the array shuffle poisoning method work.
Can the implementation be something more like:
- plugin enumeration gives an array of the existing (real) NPAPI plugins, as well as a randomized list of 2-3 randomly named fake plugins
- the real NPAPI plugins will be untouched, fake plugin names can be constructed by randomly combining 2 words from a list followed by the words Plugin/Viewer/Renderer
This way, the existing real plugins will be accurately reported, and there'll be some randomized plugins with nonsense names that can add some noise to the plugins fingerprint hash. The noise/poisoning can be made constant in the same manner that it is done for the canvas poisoning timer.

[Moonchild]

Off-topic:

courser granularity

Of course, that should be "coarser" (it annoyed me in the release notes, so this time I'm going to speak up ).

Yes, dumb mistake. sorry

[Moonchild]

plugin enumeration gives an array of the existing (real) NPAPI plugins, as well as a randomized list of 2-3 randomly named fake plugins

No, equally pointless. Truly fake names are easily flagged and filtered out. Using non-fake names (and adding fake entries with real plugin names) gives the issue of claiming a plugin exists when it does not, breaking content.

[noellarkin]

Okay, understood.

I want to try this out myself, though, would love some pointers.
I'm checking out the PM source code, and have git cloned it to my local system. I want to test compile a version for myself that will return something like this:

Code: Select all

"plugins": [
{
"name": "Chrome PDF Plugin",
"description": "Portable Document Format",
"mimeType": {
"type": "application/x-google-chrome-pdf",
"suffixes": "pdf"
}
},
{
"name": "Chrome PDF Viewer",
"description": "",
"mimeType": {
"type": "application/pdf",
"suffixes": "pdf"
}
},
{
"name": "Native Client",
"description": "",
"mimeType": {
"type": "application/x-nacl",
"suffixes": ""
}
}
]

where in the source code will I have to make changes? This is what the Navigator.cpp looks like right now:

Code: Select all

nsPluginArray*
Navigator::GetPlugins(ErrorResult& aRv)
{
  if (!mPlugins) {
    if (!mWindow) {
      aRv.Throw(NS_ERROR_UNEXPECTED);
      return nullptr;
    }
    mPlugins = new nsPluginArray(mWindow);
    mPlugins->Init();
  }

  return mPlugins;
}

[Moonchild]

You'd want to make a special case in mPlugins->Init().

[Kris_88]

Navigator.mimeTypes and Navigator.plugins are now deprecated.
https://developer.mozilla.org/en-US/doc ... /Navigator

Return empty for navigator.plugins and navigator.mimeTypes
https://developer.chrome.com/blog/deps- ... rmimetypes

[Moonchild]

No.
You're not seeing this in context. It's only "deprecated" because PP/NPAPI plugins are no longer supported by the products published by the companies writing the specs. Just because they no longer support it doesn't mean we should also remove the property/interface. Removing enumeration of plugins would be bad. It's there for a reason.

[noellarkin]

Looking into the fingerprinting around this because of your question, I realized something is amiss:
I noticed that the shuffling implementation I put in early in Pale Moon's development to combat plugin enumeration fingerprinting was dropped along the way when rebasing for Pale Moon 27 - one more to chalk up, I guess. I'll re-implement this.

Will this be re-implemented in the next update release?