info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Helping ensure privacy + security
684 views
Skip to first unread message
Chris Antaki
Oct 21, 2015, 11:06:22 PM10/21/15
to
Have you heard of EFF's Panopticlick project? It uses various methods to identify your browser, then shows you how unique its footprint is.
It turns out that the ability to enumerate plugins and mimetypes is actually one of the largest sources of uniquely identifiable information it collects. Of course, every piece of information adds up.
Inspired by the Panopticlick project, I built a Firefox addon that currently has 2,199 users (https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-plugins-mimety/). By preventing enumeration of plugins and mimetypes, it made fingerprinting browsers more difficult.
Sadly the addon was broken with Firefox 41, due to this update https://bugzilla.mozilla.org/show_bug.cgi?id=1169945.
Now I understand how the plugins.enumerable_names was broken for certain uses. However, when using it in a Binary way, that is either setting the default value or setting "" for an empty whitelist, it actually worked great.
I'm wondering if we could bring back a simplified version of the feature. And furthermore, what other steps can we take to empower privacy-conscious Firefox users?
It turns out that the ability to enumerate plugins and mimetypes is actually one of the largest sources of uniquely identifiable information it collects. Of course, every piece of information adds up.
Inspired by the Panopticlick project, I built a Firefox addon that currently has 2,199 users (https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-plugins-mimety/). By preventing enumeration of plugins and mimetypes, it made fingerprinting browsers more difficult.
Sadly the addon was broken with Firefox 41, due to this update https://bugzilla.mozilla.org/show_bug.cgi?id=1169945.
Now I understand how the plugins.enumerable_names was broken for certain uses. However, when using it in a Binary way, that is either setting the default value or setting "" for an empty whitelist, it actually worked great.
I'm wondering if we could bring back a simplified version of the feature. And furthermore, what other steps can we take to empower privacy-conscious Firefox users?
Chris Peterson
Oct 22, 2015, 2:46:12 PM10/22/15
to
our discussion in bug 1169945:
I wrote the plugins.enumerable_names feature (in bug 757726) and removed
it (in bug 1169945).
The plugins.enumerable_names whitelist was incomplete fingerprinting
protection and broke a lot of websites. The whitelist breaks on nearly
all websites that depend on a plugin not exposed in the
plugins.enumerable_names pref. Tech evangelism bug 934107 has some
examples of sites that were broken, contacted by Mozilla, and still have
not fixed their plugin detection. For every website reported, there are
likely 100x more broken but not reported.
But the big hole is that "hidden" plugins are still visible to tracking
websites because they can query navigator.plugins using a long list of
known plugin names. A better solution is to configure your plugins to
"Never Activate" by default and them allow individual plugins on on the
websites that use them. That will protect you from both plugin
fingerprinting and plugin vulnerability exploits on random websites or
ad networks.
We could make that per-site UI easier. Bug 1186948 would make per-site
enumeration opt-in easier by hiding click-to-play ("Ask to Activate")
plugins from websites enumerating navigator.plugins until the user
clicks the click-to-play button.
Chris Antaki
Oct 23, 2015, 1:18:03 AM10/23/15
to
> We could make that per-site UI easier. Bug 1186948 would make per-site
> enumeration opt-in easier by hiding click-to-play ("Ask to Activate")
> plugins from websites enumerating navigator.plugins until the user
> clicks the click-to-play button.
If the plugin was hidden on pageload, prior to click-to-play, is it possible many sites would still break in the same way?
> enumeration opt-in easier by hiding click-to-play ("Ask to Activate")
> plugins from websites enumerating navigator.plugins until the user
> clicks the click-to-play button.
Also, to take a step back, I have some questions about the 'plugins.enumerable_names' feature. For the 2,199+ people who were using my plugin, which prevented plugin & mimetype enumeration entirely by setting the value to "", do you think their decision to accept poorly written JavaScript to break, as it does, was valid? Do you think they should be able to make that decision, assuming they might value their privacy over the functionality of some websites?
Chris Antaki
Oct 23, 2015, 1:24:45 AM10/23/15
to
Also, do you think disabling plugin enumeration makes generating unique browser footprints more expensive/difficult? For instance, someone might be using a rare plugin, one that wouldn't be on even a well kept list of plugins to specifically search for. Perhaps it's something they made for themselves and a small group of their friends, team members, etc. In a situation like that, wouldn't disabling plugin enumeration add value?
I like your Click-to-play idea too! I think it could coexist with an option to disable plugin enumeration entirely too.
I like your Click-to-play idea too! I think it could coexist with an option to disable plugin enumeration entirely too.
Chris Peterson
Oct 23, 2015, 2:57:01 AM10/23/15
to
On 10/22/15 10:18 PM, Chris Antaki wrote:
>> We could make that per-site UI easier. Bug 1186948 would make per-site
>> enumeration opt-in easier by hiding click-to-play ("Ask to Activate")
>> plugins from websites enumerating navigator.plugins until the user
>> clicks the click-to-play button.
>
> If the plugin was hidden on pageload, prior to click-to-play, is it possible many sites would still break in the same way?
Sites would break, but the patch in bug 1186948 would show Firefox's
>> We could make that per-site UI easier. Bug 1186948 would make per-site
>> enumeration opt-in easier by hiding click-to-play ("Ask to Activate")
>> plugins from websites enumerating navigator.plugins until the user
>> clicks the click-to-play button.
>
> If the plugin was hidden on pageload, prior to click-to-play, is it possible many sites would still break in the same way?
click-to-play notification. If the user allowed the plugin, Firefox
would refresh the page and then expose the plugin in navigator.plugins
so the site could properly detect it.
> Also, to take a step back, I have some questions about the 'plugins.enumerable_names' feature. For the 2,199+ people who were using my plugin, which prevented plugin & mimetype enumeration entirely by setting the value to "", do you think their decision to accept poorly written JavaScript to break, as it does, was valid? Do you think they should be able to make that decision, assuming they might value their privacy over the functionality of some websites?
other than Flash or Silverlight (which were whitelisted in
plugins.enumerable_names). Your add-on would effectively make all other
plugins undetectable, as if they had been disabled in the Add-ons
Manager. Actually, installing your add-on is easier than manually
disabling each plugin one by one. :-)
Chris Peterson
Oct 23, 2015, 3:05:48 AM10/23/15
to
On 10/22/15 10:24 PM, Chris Antaki wrote:
> Also, do you think disabling plugin enumeration makes generating unique browser footprints more expensive/difficult? For instance, someone might be using a rare plugin, one that wouldn't be on even a well kept list of plugins to specifically search for. Perhaps it's something they made for themselves and a small group of their friends, team members, etc. In a situation like that, wouldn't disabling plugin enumeration add value?
Yes, hiding unique plugins definitely reduces browser fingerprinting.
> Also, do you think disabling plugin enumeration makes generating unique browser footprints more expensive/difficult? For instance, someone might be using a rare plugin, one that wouldn't be on even a well kept list of plugins to specifically search for. Perhaps it's something they made for themselves and a small group of their friends, team members, etc. In a situation like that, wouldn't disabling plugin enumeration add value?
That's why I was motivated to write the plugin-hiding feature in the
first place. :-)
However, there are much easier ways to track users than fingerprinting
uncommon plugins. For example, supercookies use multiple tracking
methods to make deleting a cookie very difficult. And, as shown on
Panopticlick, Flash allows trackers to fingerprint all your system fonts
(which may be hundreds), which exposes at least as much user entropy as
the fingerprinting a dozen common and uncommon plugins.
Hiding plugins does reduce the amount of fingerprinting information
available to trackers, but it is a small hole in a big bucket. And the
C++ code to hide plugins added extra complexity to Firefox's already
ugly plugin handling code.
Chris Antaki
Oct 23, 2015, 3:11:23 PM10/23/15
to
> Sites would break, but the patch in bug 1186948 would show Firefox's click-to-play notification. If the user allowed the plugin, Firefox would refresh the page and then expose the plugin in navigator.plugins so the site could properly detect it.
That sounds awesome, actually.
> I suspect that many of your users didn't use sites that required plugins other than Flash or Silverlight (which were whitelisted in plugins.enumerable_names).
> Your add-on would effectively make all other plugins undetectable, as if they had been disabled in the Add-ons Manager.
> Actually, installing your add-on is easier than manually disabling each plugin one by one. :-)
> Yes, hiding unique plugins definitely reduces browser fingerprinting. That's why I was motivated to write the plugin-hiding feature in the first place. :-)
> However, there are much easier ways to track users than fingerprinting uncommon plugins. For example, supercookies use multiple tracking methods to make deleting a cookie very difficult. And, as shown on Panopticlick, Flash allows trackers to fingerprint all your system fonts (which may be hundreds), which exposes at least as much user entropy as the fingerprinting a dozen common and uncommon plugins.
> Hiding plugins does reduce the amount of fingerprinting information available to trackers, but it is a small hole in a big bucket. And the C++ code to hide plugins added extra complexity to Firefox's already ugly plugin handling code.
I understand there's asymmetry when we discuss this issue. It's easy for me to ask for more security features, when I don't have to write the C++. I'd just hope that you, and other developers involved in this, keep in mind that security is one of Firefox's key advantages over Chrome. If not the most important one. While it might be challenging, maybe it's a challenge that only a company like Firefox, a non-profit whose business model isn't based around surveillance, can take on?
Chris Peterson
Oct 23, 2015, 3:32:38 PM10/23/15
to
On 10/23/15 12:11 PM, Chris Antaki wrote:
>> >Your add-on would effectively make all other plugins undetectable, as if they had been disabled in the Add-ons Manager.
> Well, wasn't my plugin just preventing enumeration of the `navigator.mimeTypes` and `navigator.plugins` objects? My understanding was that the plugins could still be queried for directly, which would be a more efficient method O(1), and more respectful of user privacy.
The plugins can still be queried directly, but convincing each and every
>> >Your add-on would effectively make all other plugins undetectable, as if they had been disabled in the Add-ons Manager.
> Well, wasn't my plugin just preventing enumeration of the `navigator.mimeTypes` and `navigator.plugins` objects? My understanding was that the plugins could still be queried for directly, which would be a more efficient method O(1), and more respectful of user privacy.
website to rewrite their plugin detection code is a "boil the ocean"
problem. It's never going to be complete and there will always be
unmaintained websites that expect a plugin but won't work in Firefox.
Support for all NPAPI plugins (except Flash) will be removed next year,
so plugin fingerprinting will no longer be a problem. (However,
fingerprinting system fonts using Flash will still be a problem.)
https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Chris Antaki
Oct 23, 2015, 3:38:45 PM10/23/15
to
Regarding the big change next year, that's great news!
> The plugins can still be queried directly, but convincing each and every website to rewrite their plugin detection code is a "boil the ocean" problem. It's never going to be complete and there will always be unmaintained websites that expect a plugin but won't work in Firefox.
I agree, convincing every website to rewrite their detection would be like boiling the ocean. Perhaps a little easier, and better for the environment, but essentially impossible.
As a user though, I would love the option, just the option that existed until very recently, to prevent a website from enumerating plugins. If that causes a website's code to break, it's fine. I see it as a protest of sorts. And of course, more importantly, it makes mass surveillance more expensive. And I mean, protesting and making mass surveillance more expensive, isn't that really all we can do, much of the time?
> The plugins can still be queried directly, but convincing each and every website to rewrite their plugin detection code is a "boil the ocean" problem. It's never going to be complete and there will always be unmaintained websites that expect a plugin but won't work in Firefox.
As a user though, I would love the option, just the option that existed until very recently, to prevent a website from enumerating plugins. If that causes a website's code to break, it's fine. I see it as a protest of sorts. And of course, more importantly, it makes mass surveillance more expensive. And I mean, protesting and making mass surveillance more expensive, isn't that really all we can do, much of the time?
Chris Antaki
Oct 23, 2015, 3:41:15 PM10/23/15
to
Is there any way we could just revert the recent change, until the big change next year? :)
Chris Peterson
Oct 23, 2015, 5:58:34 PM10/23/15
to
On 10/23/15 12:41 PM, Chris Antaki wrote:
> Is there any way we could just revert the recent change, until the big change next year? :)
I think a better solution would be an add-on that disabled all plugins
> Is there any way we could just revert the recent change, until the big change next year? :)
by default and then provided an easy user interface to configure the
per-site settings for each plugin. All these per-site settings are
available in the about:permissions page, but it is not user-friendly. A
simple tab with a list of sites and their allowed plugins would be much
easier to use.
Chris Antaki
Oct 24, 2015, 4:27:21 AM10/24/15
to
Thanks for sharing your knowledge, Chris. I really like your suggestion to disable all plugins by default. As an added bonus, it also works in Chrome.
Chris Peterson
Oct 25, 2015, 3:29:33 AM10/25/15
to
On 10/24/15 1:27 AM, Chris Antaki wrote:
> Thanks for sharing your knowledge, Chris. I really like your suggestion to disable all plugins by default. As an added bonus, it also works in Chrome.
I really like that idea. The best UI is no UI: your add-on could disable
> Thanks for sharing your knowledge, Chris. I really like your suggestion to disable all plugins by default. As an added bonus, it also works in Chrome.
all plugins by default, but instead of including UI to maintain a plugin
whitelist, the add-on could include its own curated whitelist of which
plugins should be allowed on which websites. For example:
* Silverlight could be disabled by default but whitelisted to be allowed
on netflix.com and amazon.com (and some of the other video-on-demand
sites that use Silverlight).
* QuickTime could be disabled by default but whitelisted to be allowed
on for apple.com (where it is used for movie trailers and product demos).
Flash is so ubiquitous, you would probably need to allow it everywhere.
To expand the add-on's plugin/website whitelist, users could send you
lists of plugin websites they use. Or the whitelist could be maintained
on GitHub so users can submit pull requests to update list more easily.
chris
PluginUser
Nov 5, 2015, 8:18:08 PM11/5/15
to
As a user of the plugin and supporter of the concept that I do not want to expose information, the logic of this thread puzzles me.
The root scenario for me is this: I do not want websites to be able to query information about my browser, what plugins I have running, or anything else - except when I approve that information. This is not "disable the plugin" but have the plugin run and yet not be reported.
What I see is that a valid plugin that provided exactly this feature has been disabled by recent design changes. Not because it was problematic, but just because. (If there was a technical reason that I failed to see, please do point it out.)
When called on this de-featuring, what I see as a response is basically: all of this is going away in a future release, when we also expect to alienate most of our users, so we won't bother reverting this.
The other argument I see raised is this: there are thousands of other points of attack, why bother with this one? The obvious answer is that you have to start somewhere, and this was a vector that was closed, until a code change took away this ability to close the vector. The underlying argument here boils down to this: we might as well all go back to FTP and Telnet, because the Internet is insecure, and it's too hard to fix all the holes.
Asking users to manually enable/disable plugins per-website is not likely to scale - particularly as more sites use third-parties to provide key content and infrastructure, so the "active" list will have to keep evolving even for established websites. It also doesn't address my desired outcome: no website should have the right to ask me for information I do not want to provide. The default answer should be null, not everything under the sun.
Could this conversation be turned back around to the original purpose?
* Why was the feature removed on technical grounds?
* Why do you not want to re-introduce the feature on technical grounds?
The root scenario for me is this: I do not want websites to be able to query information about my browser, what plugins I have running, or anything else - except when I approve that information. This is not "disable the plugin" but have the plugin run and yet not be reported.
What I see is that a valid plugin that provided exactly this feature has been disabled by recent design changes. Not because it was problematic, but just because. (If there was a technical reason that I failed to see, please do point it out.)
When called on this de-featuring, what I see as a response is basically: all of this is going away in a future release, when we also expect to alienate most of our users, so we won't bother reverting this.
The other argument I see raised is this: there are thousands of other points of attack, why bother with this one? The obvious answer is that you have to start somewhere, and this was a vector that was closed, until a code change took away this ability to close the vector. The underlying argument here boils down to this: we might as well all go back to FTP and Telnet, because the Internet is insecure, and it's too hard to fix all the holes.
Asking users to manually enable/disable plugins per-website is not likely to scale - particularly as more sites use third-parties to provide key content and infrastructure, so the "active" list will have to keep evolving even for established websites. It also doesn't address my desired outcome: no website should have the right to ask me for information I do not want to provide. The default answer should be null, not everything under the sun.
Could this conversation be turned back around to the original purpose?
* Why was the feature removed on technical grounds?
* Why do you not want to re-introduce the feature on technical grounds?
Chris Peterson
Nov 6, 2015, 12:08:42 AM11/6/15
to
On 11/5/15 5:18 PM, PluginUser wrote:
> The root scenario for me is this: I do not want websites to be able to query information about my browser, what plugins I have running, or anything else - except when I approve that information. This is not "disable the plugin" but have the plugin run and yet not be reported.
Do you have examples of websites that use NPAPI plugins successfully
> The root scenario for me is this: I do not want websites to be able to query information about my browser, what plugins I have running, or anything else - except when I approve that information. This is not "disable the plugin" but have the plugin run and yet not be reported.
even when the plugin names are hidden? Which plugins do the websites
use? We had lots of broken websites reported and only a couple websites
actually fixed their plugin detection.
chris
Chris Antaki
Nov 6, 2015, 12:11:27 AM11/6/15
to
Disabling plugin enumeration made it more difficult to grab every enabled plugin in one fell loop. In my opinion, it made Firefox more secure, even if it wasn't perfect. It still made mass surveillance more difficult and expensive, which is realistically one of the strongest courses of action we have as privacy activists.
I wish Firefox had kept the setting. It was removed because it caused poorly coded sites to break, and wasn't a perfect feature. I worry that the *exact* same logic could be used to remove the ability to disable cookies and WebRTC in Firefox.
Chris P's suggestion to disable all plugins works in both Chrome and Firefox though, which is kind of amazing.
Without the differentiation in privacy standards, I've switched to using Chrome in the past few weeks. There's definitely a difference in performance! I think Firefox still offers a lot of value, but perhaps in a modified form, like how it's being extended in the Tor browser-bundle.
I wish Firefox had kept the setting. It was removed because it caused poorly coded sites to break, and wasn't a perfect feature. I worry that the *exact* same logic could be used to remove the ability to disable cookies and WebRTC in Firefox.
Chris P's suggestion to disable all plugins works in both Chrome and Firefox though, which is kind of amazing.
Without the differentiation in privacy standards, I've switched to using Chrome in the past few weeks. There's definitely a difference in performance! I think Firefox still offers a lot of value, but perhaps in a modified form, like how it's being extended in the Tor browser-bundle.
Chris Antaki
Nov 6, 2015, 12:35:04 AM11/6/15
to
If you can live without plugins, I think disabling them all is the way to go. Like Chris P pointed out, it prevents them from even being queried directly, which was possible even when the enumeration was disabled.
Disabling Flash and Java in-browser is a huge privacy and security win too. Flash allows for font-harvesting and supercookies. Both plugins are popular channels for 0-day exploits.
Disabling Flash and Java in-browser is a huge privacy and security win too. Flash allows for font-harvesting and supercookies. Both plugins are popular channels for 0-day exploits.
Chris Peterson
Nov 6, 2015, 12:39:42 AM11/6/15
to
On 11/5/15 9:11 PM, Chris Antaki wrote:
> Disabling plugin enumeration made it more difficult to grab every enabled plugin in one fell loop. In my opinion, it made Firefox more secure, even if it wasn't perfect. It still made mass surveillance more difficult and expensive, which is realistically one of the strongest courses of action we have as privacy activists.
>
> I wish Firefox had kept the setting. It was removed because it caused poorly coded sites to break, and wasn't a perfect feature. I worry that the*exact* same logic could be used to remove the ability to disable cookies and WebRTC in Firefox.
> Disabling plugin enumeration made it more difficult to grab every enabled plugin in one fell loop. In my opinion, it made Firefox more secure, even if it wasn't perfect. It still made mass surveillance more difficult and expensive, which is realistically one of the strongest courses of action we have as privacy activists.
>
>
> Chris P's suggestion to disable all plugins works in both Chrome and Firefox though, which is kind of amazing.
I still feel that hiding the plugin names is untenable because you can't
> Chris P's suggestion to disable all plugins works in both Chrome and Firefox though, which is kind of amazing.
fix all the websites and the plugin names are still visible to trackers
that query them using a list of known plugin names. In contrast,
disabling plugins by default and selectively allow plugins on the
websites you care about is more private and doesn't break websites.
For example, assume you want to use the Google Earth plugin. If plugin
enumeration is disabled, then you must whitelist the Google Earth
plugin, thus exposing the plugin to ALL websites and trackers. If you
instead selectively plugins only on the websites that need them, then
you only need to expose Google Earth plugin to google.com.
chris p.
Chris Antaki
Nov 6, 2015, 1:08:53 AM11/6/15
to
On Thursday, November 5, 2015 at 9:39:42 PM UTC-8, Chris Peterson wrote:
> I still feel that hiding the plugin names is untenable because you can't
> fix all the websites and the plugin names are still visible to trackers
> that query them using a list of known plugin names. In contrast,
> disabling plugins by default and selectively allow plugins on the
> websites you care about is more private and doesn't break websites.
Totally! It sounds like we agree that disabling plugins is a safer solution. We just disagree in our value assessments of disabling plugin enumeration and whether users should be empowered to make that choice.
> I still feel that hiding the plugin names is untenable because you can't
> fix all the websites and the plugin names are still visible to trackers
> that query them using a list of known plugin names. In contrast,
> disabling plugins by default and selectively allow plugins on the
> websites you care about is more private and doesn't break websites.
Josh
Nov 6, 2015, 1:53:05 AM11/6/15
to
So . . . the argument is basically that "some websites might break with this field changed" regardless of how it is changed.
So we can expect the next release of Firefox to prevent users from altering the User Agent string, then? After all, changing that to a different value (or null) can and will break many websites.
I use this example as an extreme case to show the logically inconsistent stance taken. Users want the ability to limit information or otherwise alter the behavior of their browser. Chris' plugin, the "FireGloves" plugin, and many others do this.
What I am seeing is a lack of a technical argument for why the defeaturing took place. It's simply because one person doesn't think people should do this . . . really? There are thousands of plugin users that disagree.
As for sites breaking - as with the User Agent string - that's between the user and the extension developer. Maybe something else will need to be added. But this is such a niche area at the moment, the "nanny mode" mindset should be thrown out, and users should be expected as competent and aware of the risks.
This kind of behavior is what led to Gnome 3 having such a massive fork and split of the userbase.
So we can expect the next release of Firefox to prevent users from altering the User Agent string, then? After all, changing that to a different value (or null) can and will break many websites.
I use this example as an extreme case to show the logically inconsistent stance taken. Users want the ability to limit information or otherwise alter the behavior of their browser. Chris' plugin, the "FireGloves" plugin, and many others do this.
What I am seeing is a lack of a technical argument for why the defeaturing took place. It's simply because one person doesn't think people should do this . . . really? There are thousands of plugin users that disagree.
As for sites breaking - as with the User Agent string - that's between the user and the extension developer. Maybe something else will need to be added. But this is such a niche area at the moment, the "nanny mode" mindset should be thrown out, and users should be expected as competent and aware of the risks.
This kind of behavior is what led to Gnome 3 having such a massive fork and split of the userbase.
Chris Peterson
Nov 6, 2015, 1:35:37 PM11/6/15
to
On 11/5/15 10:53 PM, Josh wrote:
> So . . . the argument is basically that "some websites might break with this field changed" regardless of how it is changed.
>
> So we can expect the next release of Firefox to prevent users from altering the User Agent string, then? After all, changing that to a different value (or null) can and will break many websites.
Customization of the User Agent string will not be removed because it is
> So . . . the argument is basically that "some websites might break with this field changed" regardless of how it is changed.
>
> So we can expect the next release of Firefox to prevent users from altering the User Agent string, then? After all, changing that to a different value (or null) can and will break many websites.
useful for improving compatibility with some websites and for testing.
> I use this example as an extreme case to show the logically inconsistent stance taken. Users want the ability to limit information or otherwise alter the behavior of their browser. Chris' plugin, the "FireGloves" plugin, and many others do this.
>
> What I am seeing is a lack of a technical argument for why the defeaturing took place. It's simply because one person doesn't think people should do this . . . really? There are thousands of plugin users that disagree.
clearly sympathetic to the privacy aspects. I am also the "one person"
who removed it. It is an all-around worse solution than disabling
plugins by default and selectively enabling them for websites you need.
This feature could never be enabled by default because it broke too many
websites. And there was no value in leaving this code dormant because,
if someone enabled the pref on their machine, it would break websites.
I have asked for, and no one has yet provided, one example of a website
that uses an NPAPI plugin successfully when plugin names are hidden.
Chris Antaki
Nov 6, 2015, 2:48:51 PM11/6/15
to
On Thursday, November 5, 2015 at 10:53:05 PM UTC-8, Josh wrote:
> As for sites breaking - as with the User Agent string - that's between the user and the extension developer. Maybe something else will need to be added. But this is such a niche area at the moment, the "nanny mode" mindset should be thrown out, and users should be expected as competent and aware of the risks.
Well said!
> As for sites breaking - as with the User Agent string - that's between the user and the extension developer. Maybe something else will need to be added. But this is such a niche area at the moment, the "nanny mode" mindset should be thrown out, and users should be expected as competent and aware of the risks.
tsqs...@gmail.com
Dec 4, 2015, 9:22:13 AM12/4/15
to
i need add-on Disables enumeration of mimeTypes & plugins. for my work..pls share me file addon..i can add for firefox Manual
Chris Peterson
Dec 4, 2015, 1:12:46 PM12/4/15
to
On 12/4/15 6:22 AM, tsqs...@gmail.com wrote:
> i need add-on Disables enumeration of mimeTypes & plugins. for my work..pls share me file addon..i can add for firefox Manual
If you are concerned about websites knowing which plugins you have
> i need add-on Disables enumeration of mimeTypes & plugins. for my work..pls share me file addon..i can add for firefox Manual
installed, the safest method is to disable all the plugins in the
Add-ons Manager ("Never Activate" setting) and then manually allow the
each plugin you need when you visit a website.
Chris Antaki
Dec 4, 2015, 1:47:47 PM12/4/15
to
The more I've thought about your decision to remove the enumerable option, the more it makes sense. The method you just outlined is solid.
Chris Peterson
Dec 4, 2015, 2:30:35 PM12/4/15
to
On 12/4/15 10:47 AM, Chris Antaki wrote:
> The more I've thought about your decision to remove the enumerable option, the more it makes sense. The method you just outlined is solid.
There is a missing piece in my recommendation, though: the UI for
> The more I've thought about your decision to remove the enumerable option, the more it makes sense. The method you just outlined is solid.
whitelisting a disabled plugin for individual websites you trust is not
easy to use (i.e. a checkbox buried in the Page Info dialog box). A
browser extension (hint hint ;) could add a toolbar button that can
allow or block plugins from a simple dropdown menu with check boxes.
That extension functionality would be useful in both Firefox and Chrome.
labob...@gmail.com
Dec 5, 2015, 1:25:21 PM12/5/15
to
This thread is chasing its tail and not getting anywhere.
The suggestion of manually enable and disable plugins is micro-management. You can see it as a form of nagging.
I've seen this sort of technique used to annoy users in to not doing it at all because for some reason the company don't want users to do it. Usually it boils don't to money.
Basically it's a form of manipulation technique.
One form of this is Chrome's nagging message when you have custom extensions enabled. Google say it's for "security reasons" but that's just bullshit. They want to control extensions development via their web store. Whatever their hidden reason for it, it's bad.
Excuse the half-rant.
Lets avoid more circular argumentation and wasting of time.
Let me blunt. It's simple, either you revert the change or say you will refuse to do it. So we can move on.
To say you removed it because of "extra complexity" is a weak excuse. After all will not the code be removed anyway when the big change happens, if I understand it correctly. So why the hurry of removing that code now?
I fail to see a valid point here based on this thread.
Excuse my maybe somewhat harsh direct tone.
The suggestion of manually enable and disable plugins is micro-management. You can see it as a form of nagging.
I've seen this sort of technique used to annoy users in to not doing it at all because for some reason the company don't want users to do it. Usually it boils don't to money.
Basically it's a form of manipulation technique.
One form of this is Chrome's nagging message when you have custom extensions enabled. Google say it's for "security reasons" but that's just bullshit. They want to control extensions development via their web store. Whatever their hidden reason for it, it's bad.
Excuse the half-rant.
Lets avoid more circular argumentation and wasting of time.
Let me blunt. It's simple, either you revert the change or say you will refuse to do it. So we can move on.
To say you removed it because of "extra complexity" is a weak excuse. After all will not the code be removed anyway when the big change happens, if I understand it correctly. So why the hurry of removing that code now?
I fail to see a valid point here based on this thread.
Excuse my maybe somewhat harsh direct tone.
Chris Peterson
Dec 5, 2015, 3:26:16 PM12/5/15
to
On 12/5/15 10:25 AM, labob...@gmail.com wrote:
> To say you removed it because of "extra complexity" is a weak excuse. After all will not the code be removed anyway when the big change happens, if I understand it correctly. So why the hurry of removing that code now?
> I fail to see a valid point here based on this thread.
I removed the feature (which I originally implemented) because:
> To say you removed it because of "extra complexity" is a weak excuse. After all will not the code be removed anyway when the big change happens, if I understand it correctly. So why the hurry of removing that code now?
> I fail to see a valid point here based on this thread.
1. It broke real websites.
2. It provided very little privacy benefit.
3. It provided zero security benefit against plugin vulnerabilities
(because the hidden plugins are still enabled and accessible to any
website).
4. The code added extra complexity required to manage multiple lists of
plugins (hidden and visible) even though the feature was disabled (see
#1) and could not be re-enabled.
Yes, Firefox's NPAPI code will eventually be removed, but that's more
than a year away. Even after NPAPI support is removed, Firefox must
retain some of that code to continue supporting Flash.
I do not plan to spend any more time on this feature. It is a dead end.
But you are welcome to submit patches for someone else to review. My
original patches are still accessible in Bugzilla.
chris
0 new messages