info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Plugin whitelist
87 views
Skip to first unread message
Benjamin Smedberg
Mar 3, 2014, 2:43:05 PM3/3/14
to dev-tech-plugins, Firefox Dev, Chad Weiner, mozilla.dev.planning group, dev-pl...@lists.mozilla.org
On Friday Chad posted and blogged about our proposed plugin whitelisting
policy.
https://wiki.mozilla.org/Plugins/Firefox_Whitelist
https://blog.mozilla.org/security/2014/02/28/update-on-plugin-activation/
The primary goal of this policy is to give plugin vendors who are
working on moving towards HTML5 solution some additional time to make
the transition, as well as providing feedback from plugin vendors to our
web API teams about features missing from the web platform. We will
continue to preserve user security by keeping engineering and QA
contacts for each plugin vendor.
Please ask questions/provide feedback by replying to
mozilla.dev.tech.plugins.
--BDS
policy.
https://wiki.mozilla.org/Plugins/Firefox_Whitelist
https://blog.mozilla.org/security/2014/02/28/update-on-plugin-activation/
The primary goal of this policy is to give plugin vendors who are
working on moving towards HTML5 solution some additional time to make
the transition, as well as providing feedback from plugin vendors to our
web API teams about features missing from the web platform. We will
continue to preserve user security by keeping engineering and QA
contacts for each plugin vendor.
Please ask questions/provide feedback by replying to
mozilla.dev.tech.plugins.
--BDS
Chris Peterson
Mar 3, 2014, 3:39:02 PM3/3/14
to
On 3/3/14, 11:43 AM, Benjamin Smedberg wrote:
> The primary goal of this policy is to give plugin vendors who are
> working on moving towards HTML5 solution some additional time to make
> the transition, as well as providing feedback from plugin vendors to our
> web API teams about features missing from the web platform. We will
> continue to preserve user security by keeping engineering and QA
> contacts for each plugin vendor.
Which version of Firefox do you plan to enable click-to-play by default?
> The primary goal of this policy is to give plugin vendors who are
> working on moving towards HTML5 solution some additional time to make
> the transition, as well as providing feedback from plugin vendors to our
> web API teams about features missing from the web platform. We will
> continue to preserve user security by keeping engineering and QA
> contacts for each plugin vendor.
I use Nightly so I had forgotten that click-to-play had not landed on
the general release of Firefox. :)
chris
Benjamin Smedberg
Mar 3, 2014, 3:58:23 PM3/3/14
to Chris Peterson, dev-tech...@lists.mozilla.org
On 3/3/2014 3:39 PM, Chris Peterson wrote:
>
> Which version of Firefox do you plan to enable click-to-play by
> default? I use Nightly so I had forgotten that click-to-play had not
> landed on the general release of Firefox. :)
We didn't commit to a release, but we're planning on doing this in
>
> Which version of Firefox do you plan to enable click-to-play by
> default? I use Nightly so I had forgotten that click-to-play had not
> landed on the general release of Firefox. :)
Firefox 30 unless there are hiccups in the process.
--BDS
Benjamin Smedberg
Mar 4, 2014, 1:36:10 PM3/4/14
to Andrew Joakimsen, dev-tech-plugins
On 3/3/2014 10:02 PM, Andrew Joakimsen wrote:
> Will it be possible for users and system administrators to fully disable the new "feature" of blocking all plugins through about:config options or will the users that require plugins be forced to cease upgrading their installations?
You will be able to change the defaults for all sites by changing
preferences. You can also add per-domain defaults using administration
deployment tools, which is the recommended way to approach this problem:
most enterprise plugins are used on a limited and well-known set of
sites, and using a per-domain rule reduces exposure to potential
security issues.
--BDS
> Will it be possible for users and system administrators to fully disable the new "feature" of blocking all plugins through about:config options or will the users that require plugins be forced to cease upgrading their installations?
You will be able to change the defaults for all sites by changing
preferences. You can also add per-domain defaults using administration
deployment tools, which is the recommended way to approach this problem:
most enterprise plugins are used on a limited and well-known set of
sites, and using a per-domain rule reduces exposure to potential
security issues.
--BDS
Benjamin Smedberg
Mar 4, 2014, 2:51:33 PM3/4/14
to Bill Selman, dev-tech-plugins
On 3/4/2014 2:18 PM, Bill Selman wrote:
> Is there a plan to onboard users with this change to the user
> experience? We conducted user tests last fall for Flash CTP and the
> overwhelming majority of users we tested were frustrated that they
> were required to complete additional step to reach their desired
> content. Further, participants were confused by the security
> implications of CTP.
We significantly redesigned the UI as a result of that experiment, and
we've already deployed the new UI for Java without significant negative
feedback via SUMO/input. So I'm fairly confident in the current design
and no plans for a special onboarding step.
--BDS
> Is there a plan to onboard users with this change to the user
> experience? We conducted user tests last fall for Flash CTP and the
> overwhelming majority of users we tested were frustrated that they
> were required to complete additional step to reach their desired
> content. Further, participants were confused by the security
> implications of CTP.
We significantly redesigned the UI as a result of that experiment, and
we've already deployed the new UI for Java without significant negative
feedback via SUMO/input. So I'm fairly confident in the current design
and no plans for a special onboarding step.
--BDS
Benjamin Smedberg
Mar 4, 2014, 3:25:31 PM3/4/14
to Bill Selman, dev-tech-plugins
On 3/4/2014 3:05 PM, Bill Selman wrote:
> Java has a different reach than other plugins and is used for
> different kinds of functionality. Can you share how your confidence
> for this design translates to other plugins and their uses?
Top plugins by reach are:
* Flash (unaffected by any of this)
* Java (already affected, sometimes used invisibly)
* Silverlight (almost always visible, works fine)
* Unity (always visible, works fine)
very small minorities
The primary pain points in the original study were that nobody could
understand why they had to click twice on videos (once to enable the
plugin and once to play the video) and they really wanted a way to just
say "yes always for this site" which was present but not discoverable.
By switching things to be per-domain by default, the default interaction
model is now the one users expect which is "yes please allow this plugin
and stop asking me".
--BDS
> Java has a different reach than other plugins and is used for
> different kinds of functionality. Can you share how your confidence
> for this design translates to other plugins and their uses?
Top plugins by reach are:
* Flash (unaffected by any of this)
* Java (already affected, sometimes used invisibly)
* Silverlight (almost always visible, works fine)
* Unity (always visible, works fine)
very small minorities
The primary pain points in the original study were that nobody could
understand why they had to click twice on videos (once to enable the
plugin and once to play the video) and they really wanted a way to just
say "yes always for this site" which was present but not discoverable.
By switching things to be per-domain by default, the default interaction
model is now the one users expect which is "yes please allow this plugin
and stop asking me".
--BDS
David E. Ross
Mar 6, 2014, 6:14:05 PM3/6/14
to
Applications list? Will this be automated?
Can I whitelist plugins globally instead of for specified URIs? I have
some plugins that are used by a large number of Web sites. It appears
that the AVG SiteSafety plugin (npsitesafety.dll) operates on ALL Web
sites.
My concern is about non-Mozilla developers who do not want to bother
with applying for whitelisting but whose products are quite useful.
--
David E. Ross
<http://www.rossde.com/>
On occasion, I filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam, flames, and trolling from that source.
Benjamin Smedberg
Mar 6, 2014, 6:29:45 PM3/6/14
to dev-tech...@lists.mozilla.org
On 3/6/14 6:14 PM, David E. Ross wrote:
> Can users whitelist plugins that are identified in the user's Helper
> Applications list?
If they are actually plugins and show up in the addon manager, yes.
> Can users whitelist plugins that are identified in the user's Helper
> Applications list?
> Will this be automated?
I'm not sure exactly what this means, but I'm guessing the answer is
"no, probably not".
>
> Can I whitelist plugins globally instead of for specified URIs?
Yes, unless the plugin is "known insecure" in the blocklist. The user
> Can I whitelist plugins globally instead of for specified URIs?
can go into the addon manager and switch any plugin from "Ask to
Activate" to "Always Activate".
> I have
> some plugins that are used by a large number of Web sites. It appears
> that the AVG SiteSafety plugin (npsitesafety.dll) operates on ALL Web
> sites.
That is surprising and probably indicates that AVG is injecting content
> some plugins that are used by a large number of Web sites. It appears
> that the AVG SiteSafety plugin (npsitesafety.dll) operates on ALL Web
> sites.
into the page, which I would say is a compatibility and security hazard.
In any case the above answer still applies.
--BDS
David E. Ross
Mar 6, 2014, 8:22:57 PM3/6/14
to
On 3/6/2014 3:29 PM, Benjamin Smedberg wrote [in part]:
> On 3/6/14 6:14 PM, I previously wrote [also in part]:
attempt to view a hazardous Web site. AVG calls this "Link Protection",
which involves scans of Web, Twitter, & Facebook links.
> On 3/6/14 6:14 PM, I previously wrote [also in part]:
>> It appears
>> that the AVG SiteSafety plugin (npsitesafety.dll) operates on ALL Web
>> sites.
> That is surprising and probably indicates that AVG is injecting content
> into the page, which I would say is a compatibility and security hazard.
> In any case the above answer still applies.
Actually, the AVG SiteSafety plugin is supposed to alert me when I
>> that the AVG SiteSafety plugin (npsitesafety.dll) operates on ALL Web
>> sites.
> That is surprising and probably indicates that AVG is injecting content
> into the page, which I would say is a compatibility and security hazard.
> In any case the above answer still applies.
attempt to view a hazardous Web site. AVG calls this "Link Protection",
which involves scans of Web, Twitter, & Facebook links.
0 new messages