Last Comment Bug 661961 - Get 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-o...
Status: RESOLVED FIXED
[needs Mozmill test update]
:
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: unspecified
: All All
: -- normal with 3 votes (vote)
: mozilla22
Assigned To: AWAY Tom Schuster [:evilpie]
:
:
Mentors:
: 835969 870590 (view as bug list)
Depends on:
Blocks: 883671
  Show dependency treegraph
 
Reported: 2011-06-03 15:40 PDT by Dave Garrett
Modified: 2014-11-10 01:59 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
wip (4.53 KB, patch)
2013-02-17 05:16 PST, AWAY Tom Schuster [:evilpie]
benjamin: feedback+
Details | Diff | Splinter Review
v1 (4.20 KB, patch)
2013-02-25 12:39 PST, AWAY Tom Schuster [:evilpie]
benjamin: review+
Details | Diff | Splinter Review

Description Dave Garrett 2011-06-03 15:40:19 PDT
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).
Comment 1 AWAY Tom Schuster [:evilpie] 2013-02-17 05:16:15 PST
Created attachment 714896 [details] [diff] [review]
wip
Comment 2 AWAY Tom Schuster [:evilpie] 2013-02-17 05:17:41 PST
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.
Comment 3 AWAY Tom Schuster [:evilpie] 2013-02-17 05:19:24 PST
Please ignore the change to getHSTSPreloadList.js. :)
Comment 4 WildcatRay 2013-02-17 05:39:18 PST
By the way, is the title supposed to be "Get rid of..." instead of "Gid rid of..."
Comment 5 Dave Garrett 2013-02-17 06:39:47 PST
(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... :/
Comment 6 Georg Fritzsche [:gfritzsche] 2013-02-18 08:37:28 PST
(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.
Comment 7 Chris Peterson [:cpeterson] 2013-02-19 23:47:29 PST
*** Bug 835969 has been marked as a duplicate of this bug. ***
Comment 8 Benjamin Smedberg [:bsmedberg] 2013-02-21 11:32:45 PST
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?
Comment 9 AWAY Tom Schuster [:evilpie] 2013-02-25 12:39:45 PST
Created attachment 718023 [details] [diff] [review]
v1

Great, let's do this.
Comment 10 Mike de Boer [:mikedeboer] 2013-02-26 09:39:11 PST
Tom,
Comment 11 Mike de Boer [:mikedeboer] 2013-02-26 09:40:18 PST
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?
Comment 12 AWAY Tom Schuster [:evilpie] 2013-03-01 08:15:38 PST
I removed the changes to the title, because they were not actually effective.
https://hg.mozilla.org/integration/mozilla-inbound/rev/abeabcfe18fb
Comment 13 Ryan VanderMeulen [:RyanVM] 2013-03-01 15:49:51 PST
https://hg.mozilla.org/mozilla-central/rev/abeabcfe18fb
Comment 14 Dave Garrett 2013-05-09 17:36:43 PDT
*** Bug 870590 has been marked as a duplicate of this bug. ***
Comment 15 Dave Garrett 2013-05-09 18:13:12 PDT
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.
Comment 16 Benjamin Smedberg [:bsmedberg] 2013-05-09 18:35:55 PDT
No, this will not be uplifted (21 final is already built).
Comment 17 byzod 2013-05-22 02:33:42 PDT
(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?
Comment 18 Georg Fritzsche [:gfritzsche] 2013-05-22 02:37:14 PDT
(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).

Note You need to log in before you can comment on or make changes to this bug.