There are a bunch of different teams working on the current
click-to-play (CtP) plugins effort, and there are a bunch of small-group
email threads going around. I would like to consolidate all of this work
to a single discussion forum, and I've asked everyone I know who is part
of this effort to carry on their design discussions here in
dev-apps-firefox.
Note: please reply/follow up to mozilla.dev.apps.firefox only!
For information on the teams, as well as some summary information and
bug queries, see this wiki page:
https://wiki.mozilla.org/Firefox/Click_To_Play
Talking about click-to-play has been complicated, because we have
several parallel goals and efforts:
* Make users more secure by blocking known-unsafe version of plugins
* Give users control by having them opt in to "new" plugins that are
found on their machine
* Make Firefox faster and less crashy by reducing the number of plugin
instances that users see
SECURITY-BLOCKED PLUGINS
Up to now, we have been focusing primarily on the first of these goals,
"security click-to-play". We have long wanted to be able to block
known-insecure versions of common plugins. This has been hard because
some users (especially those in enterprise and education settings)
cannot upgrade, and in other cases there are poorly constructed sites
that only work with specific versions of plugins (especially Java).
click-to-play blocking of plugins allows us to strike a balance between
protecting users from "drive by" plugin exploits and allowing them to
accomplish work that requires plugins.
Another issue with the current UI is that because the click-to-play UI
is in-content, it is relatively easy to construct a website which
"clickjacks" the user into activating a plugin even if they didn't mean
to. The security team has proposed that when a plugin is known to be
insecure, we should not simply accept a single click on a plugin
instance, but instead the user should activate the plugin from the
doorhanger UI instead (which is not clickjackable). This is covered in
bug 832481. Larissa Co from UX is currently in the process of
understanding the interaction model here and coming up with the best design.
One goal of the UI is allowing users to enable a plugin "always for this
site". We've discovered that in the current UI, it's hard to discover
that you *can* whitelist a plugin to always activate for a particular
site, even though that is the desired solution for sites that a user
visits regularly. We are not yet certain how to solve this problem, but
are going to test one possible solution in bug 834749. This problem may
be moot for "security blocked" plugins if the doorhanger solution above
is implemented. The security team has also raised concerns that "always
for this site" should not be *forever* when a plugin is insecure, but
should only last for a period of time, so that the user is reminded that
they have an insecure plugin.
Some websites are poorly written; they try to use plugins immediately
after they are created, and even if the user clicks to display the
plugin later, the website will not work correctly. One potential
solution is to choose "always for this site" and reload; this should
cause plugins to behave normally. We are also considering a less
"permanent" solution like "reload with plugins enabled" which would
enable plugins either for only one reload, or only for the current
session, or some intermediate period of time.
In enterprise and education deployments, there has been significant
desire to be able to automatically deploy per-site whitelists for
plugins even if they are known to be insecure. This allows
administrators to keep intranet sites from breaking for users. We are
currently investigating writing a small addon which would use a
preconfigured whitelist to bypass the normal protections for specific
domains.
The last issue that has come up is how we deal with small or hidden
plugin instances. This is mostly a problem with Flash, because invisible
Flash instances are commonly used by websites for various reasons,
including playing music (Pandora), playing noises (Chat), fancy
file-upload controls (facebook/wordpress), and advertising trackers
(many big news sites). Striking the right UI balance here has been very
difficult. Users always have the option of enabling all Flash on a page
by clicking the plugin icon in the location bar. But most users don't
notice this UI, and even if they do they don't know what it's for. For a
while, we tried popping up the plugin doorhanger on every page that had
a hidden plugin. But we quickly discovered that this totally annoys
users because many pages with advertising trackers have hidden Flash,
and they didn't understand why Firefox was interrupting their web
browsing on news sites. Our current compromise solution in Firefox 18 is
that each time you run Firefox, we will show the doorhanger notification
*once*, and after that we won't show it again; the theory is that if we
show the relationship between the doorhanger and the plugin icon in the
location bar, that users will know where to look. But comments from
users in our support site show that this solution is still unpopular
with many users who don't understand when the doorhanger will show and
when it won't. Other options that were considered include a notification
bar (the yellow bar at the top of the window), but that solution has
additional problems as duplicating the doorhanger UI, and not
reinforcing the plugin icon in the location bar. I believe that our
current solution is only barely good enough, and we will need to
continue experimentation and design to find the correct balance in this UI.
USER CONTROL (or click-to-play by default)
The next step that my team is focusing on is making most plugins
click-to-play by default. Many users do not realize that they have
plugins installed, often plugins which are installed into the system by
other software which is entirely unrelated to web browsing. We are
trying to make it possible to not enable most plugins automatically, but
rather to make them CtP by default and give the user the option to
always enable them, enable them per-site, or completely disable them.
In general, the UI issues with making plugins CtP by default are very
similar to a known-insecure plugin. However, we are planning on making
the in-content UI much less "threatening" looking, and we want to allow
single-click activation and do not plan to solve the "clickjacking"
problem for this class of plugins. This work is covered in bug 831921,
and the most recent visual design can be found at this screenshot:
http://cl.ly/image/0N2y1C3B0R2G/o
In addition, we need to change the addon manager to expose a tri-state
enabled/disabled/click-to-play setting switch for plugins (bug 549697).
We also need to change the backend system for storing the
enabled/disabled state of plugins: this state is currently stored by
plugin name and path in pluginreg.dat, and because both plugin names and
paths can change when they are upgraded, we need to switch to storing
plugin state by MIME type. This work is covered in bug 832085. There is
a lot of secondary UI which is still being completed. For example, there
is currently no way to view or reset your choice after you have chosen
"Always for this site". This is being added to the page info dialog, and
we may also expose this information via options in the addons manager.
In this timeframe, we don't believe that we can make the most recent
version of Flash click-to-play by default. Too many websites and users
rely on Flash content for videos, games, and other features. We are
continuing to work hard to make it possible to write websites that don't
require Flash.
I am hopeful that we will have all this work completed in time for the
Firefox 22 trains. I am tracking the set of bugs needed for this work
with the "CtPDefault" whiteboard tag and this bugzilla query:
https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr;status_whiteboard=CtpDefault%3AP;resolution=---;resolution=DUPLICATE;query_format=advanced
STABILITY
Plugins are the #1 cause of both crashes and pauses in Firefox. While we
continue to work with Adobe to improve Flash stability, we would also
like to investigate the possibility of making all plugins, including
Flash, click-to-play by default. In order to see how this would affect
users, we are going to be running a user research study later this
month. In the custom build for this study, we are including the visual
design enhancements, as well as some basic UX improvements to make
"always for this site" more prominent. We are also aggressively
instrumenting the build to see which pieces of UI are used, as well as
what plugins users choose to activate. The study participants will be
asked to write journal entries about their experience; whether Firefox
felt faster, whether they were able to use all their websites, and their
feelings about the new behavior. Mary Trombley has helped me design and
implement this study along with the rest of the UR team.
I am tracking the set of bugs needed for the custom build using the
"CtPUR" whiteboard tag and this bugzilla query:
https://bugzilla.mozilla.org/buglist.cgi?status_whiteboard_type=allwordssubstr;status_whiteboard=CtPUR%3A%2B;resolution=---;resolution=DUPLICATE;query_format=advanced
Finally, although this is not directly related to click-to-play, we are
planning on removing the Plugin Finder Service (PFS) from Firefox.
Previously when Firefox encountered web content which needed a plugin,
it would prompt the user to install the plugin. Instead, we are now
discouraging users from using browser plugins, and want to avoid this
prompt.
HOW CAN I HELP?
For now, the best way you can help is by turning on the hidden pref
"plugins.click_to_play". If you have specific websites that don't work,
you should feel free to file bugs in the "Core:Plug-ins" component.
Please be as specific as possible, including the following information:
* The exact URL of the page
* The plugin information from about:plugins
* Whether "always for this site" causes the site to work correctly
If you are capable, I'd love to have volunteers to help take these
reports and create minimal testcases from them. It is possible that some
websites are "unfixable" in normal conditions and require a feature like
"reload with plugins enabled" to work properly, but in many cases we've
found ways to fix common javascript or actionscript libraries to better
support click-to-play, as well as making changes in Firefox itself to
allow these websites to work. Bugmasters wanted!
Finally, if you have a suggestion for improving the user experience,
especially the experience for hidden Flash plugins or the design of the
doorhanger notification, please forward them to this list. It is
probably not worth filing a bug until the design has been discussed.
--BDS
_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security
