navigator.plugins and browser fingerprinting protection

Talk about code development, features, specific bugs, enhancements, patches, and similar things.
Forum rules
Please keep everything here strictly on-topic.
This board is meant for Pale Moon source code development related subjects only like code snippets, patches, specific bugs, git, the repositories, etc.

This is not for tech support! Please do not post tech support questions in the "Development" board!
Please make sure not to use this board for support questions. Please post issues with specific websites, extensions, etc. in the relevant boards for those topics.

Please keep things on-topic as this forum will be used for reference for Pale Moon development. Expect topics that aren't relevant as such to be moved or deleted.
User avatar
noellarkin
Fanatic
Fanatic
Posts: 120
Joined: 2021-07-27, 04:20

navigator.plugins and browser fingerprinting protection

Unread post by noellarkin » 2024-06-23, 13:48

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.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37685
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: navigator.plugins and browser fingerprinting protection

Unread post by Moonchild » 2024-06-23, 13:58

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.

User avatar
noellarkin
Fanatic
Fanatic
Posts: 120
Joined: 2021-07-27, 04:20

Re: navigator.plugins and browser fingerprinting protection

Unread post by noellarkin » 2024-06-23, 14:15

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.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37685
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: navigator.plugins and browser fingerprinting protection

Unread post by Moonchild » 2024-06-23, 14:33

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.

User avatar
moonbat
Knows the dark side
Knows the dark side
Posts: 5592
Joined: 2015-12-09, 15:45

Re: navigator.plugins and browser fingerprinting protection

Unread post by moonbat » 2024-06-23, 22:55

Moonchild wrote:
2024-06-23, 13:58
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 :(

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37685
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: navigator.plugins and browser fingerprinting protection

Unread post by Moonchild » 2024-06-23, 23:35

moonbat wrote:
2024-06-23, 22:55
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.

User avatar
noellarkin
Fanatic
Fanatic
Posts: 120
Joined: 2021-07-27, 04:20

Re: navigator.plugins and browser fingerprinting protection

Unread post by noellarkin » 2024-06-24, 02:09

Moonchild wrote:
2024-06-23, 23:35
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.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37685
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: navigator.plugins and browser fingerprinting protection

Unread post by Moonchild » 2024-06-24, 09:37

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).

User avatar
adoxa
Lunatic
Lunatic
Posts: 429
Joined: 2019-03-16, 13:26
Location: Qld, Aus.

Re: navigator.plugins and browser fingerprinting protection

Unread post by adoxa » 2024-06-24, 11:12

Off-topic:
Moonchild wrote:
2024-06-24, 09:37
courser granularity
Of course, that should be "coarser" (it annoyed me in the release notes, so this time I'm going to speak up :) ).

User avatar
noellarkin
Fanatic
Fanatic
Posts: 120
Joined: 2021-07-27, 04:20

Re: navigator.plugins and browser fingerprinting protection

Unread post by noellarkin » 2024-06-24, 11:49

Moonchild wrote:
2024-06-24, 09:37
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.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37685
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: navigator.plugins and browser fingerprinting protection

Unread post by Moonchild » 2024-06-24, 14:09

adoxa wrote:
2024-06-24, 11:12
Off-topic:
Moonchild wrote:
2024-06-24, 09:37
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

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37685
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: navigator.plugins and browser fingerprinting protection

Unread post by Moonchild » 2024-06-24, 14:14

noellarkin wrote:
2024-06-24, 11:49
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.

User avatar
noellarkin
Fanatic
Fanatic
Posts: 120
Joined: 2021-07-27, 04:20

Re: navigator.plugins and browser fingerprinting protection

Unread post by noellarkin » 2024-06-29, 17:36

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;
}

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37685
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: navigator.plugins and browser fingerprinting protection

Unread post by Moonchild » 2024-06-29, 19:28

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

Kris_88
Board Warrior
Board Warrior
Posts: 1101
Joined: 2021-01-26, 11:18

Re: navigator.plugins and browser fingerprinting protection

Unread post by Kris_88 » 2024-06-30, 02:45

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

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 37685
Joined: 2011-08-28, 17:27
Location: Motala, SE

Re: navigator.plugins and browser fingerprinting protection

Unread post by Moonchild » 2024-06-30, 08:34

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.

User avatar
noellarkin
Fanatic
Fanatic
Posts: 120
Joined: 2021-07-27, 04:20

Re: navigator.plugins and browser fingerprinting protection

Unread post by noellarkin » 2024-07-01, 12:09

Moonchild wrote:
2024-06-23, 14:33
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?