The plugin.expose_full_path pref was added in bug 88183 to allow navigator.plugins to expose the full path to the plugin file in the filesystem. Basically a privacy and security hole was fixed but a pref was added to allow you to manually re-open that hole. A better route would have been to only allow about:plugins access to the path, but it's just a page with normal privileges so a fair bit of a rewrite would've been required. So, the quick and simple hack won the day. There is no real reason for a website to have access to this information and flipping this pref on can greatly increase fingerprintability and possibly expose your username in your OS if the path includes it. A much better option would be to add the plugin path to either about:addons or about:support. As this information is only really needed in a few support-related situations, the later makes more sense. The most logical route would be to scrap about:plugins entirely and just add a new plugins section to about:support (see bug 638769) potentially also adding the paths there by amending nsIPluginHost or AddonManager instead of using navigator.plugins (which would also have the added benefit of showing disabled plugins, whereas the current method of using navigator.plugins does not).
This adds an extra row "Path:" to about:plugins. Maybe this should just be combined with "File:"? I tried to make the same change to the about:addons details view, but I had problems with actually finding that code.
Please ignore the change to getHSTSPreloadList.js. :)
By the way, is the title supposed to be "Get rid of..." instead of "Gid rid of..."
(In reply to Ray Murphy (WildcatRay) from comment #4) > By the way, is the title supposed to be "Get rid of..." instead of "Gid rid > of..." Of course it is. That's a dumb typing fail on my part... :/
Summary: Gid rid of plugin.expose_full_path pref and expose plugin paths in a chrome-only interface → Get rid of plugin.expose_full_path pref and expose plugin paths in a chrome-only interface
(In reply to Tom Schuster [:evilpie] from comment #2) > This adds an extra row "Path:" to about:plugins. Maybe this should just be > combined with "File:"? I think it's probably better to have a separate row for the path, both for testability and readability. Apropos testability: this probably also needs a Mozmill update like bug 831533.
Whiteboard: [needs Mozmill test update]
Assignee: nobody → evilpies
Status: NEW → ASSIGNED
Comment on attachment 714896 [details] [diff] [review] wip While you're touching this code: the current title of "about:plugins" is "Enabled Plugins" but that's no longer accurate; we include all plugins. Can you fix that? The getHSTSPreloadList.js change isn't related to this patch, right?
Attachment #714896 - Flags: feedback?(benjamin) → feedback+
Great, let's do this.
See Also: → 845022
Ahum. What I wanted to say is that I attached a patch to the bug report I added here as 'See also'. Does this interfere with your work at all?
I removed the changes to the title, because they were not actually effective. https://hg.mozilla.org/integration/mozilla-inbound/rev/abeabcfe18fb
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
Can this get uplifted to Firefox 21 beta? There's currently no way for a user to look up a plugin's path without this as the pref is broken there.
No, this will not be uplifted (21 final is already built).
(In reply to Benjamin Smedberg [:bsmedberg] from comment #16) > No, this will not be uplifted (21 final is already built). Will this patch land on 22 beta?
(In reply to byzod from comment #17) > Will this patch land on 22 beta? It already is in 22 (and hence in the current beta).
You need to log in before you can comment on or make changes to this bug.