Opt-in activation for plugins: Difference between revisions

Jump to navigation Jump to search

Opt-in activation for plugins (view source)

Revision as of 21:08, 17 April 2012

178 bytes removed ,  17 April 2012
no edit summary
No edit summary
No edit summary
Line 18: Line 18:
}}
}}
{{FeaturePageBody
{{FeaturePageBody
|Feature open issues and risks=* What type of UX to have for allowing users to opt in (or out) of enabling plugins on a (semi)persistent basis?  See below in "Use Cases".
|Feature open issues and risks=* How do we manage Mozilla-controlled click to play settings?  Deliver via our existing blocklist mechanism? (Potentially leverage severity 0 "warning-only" blocklist entries"?) A new system?
** Requires more research


* How do we manage Mozilla-controlled click to play settings?  Deliver via our existing blocklist mechanism? (Potentially leverage severity 0 "warning-only" blocklist entries"?) A new system?  
 
* Adverse reactions between content plugin sniffing and click-to-play
** Bsmedberg asks in bug 711552: "Are we exposing to the DOM that a particular plugin element (<object> or <embed> is user-disabled?) This seems important for websites that rely primarily on plugins (e.g. Pandora) so that they can show alternate UI (plugins are disabled, please click to play) instead of timing out and showing a generic "please install Flash" or "Song initialization timed out, please hit refresh" UI."
** Can content differentiate between "click to play" and "hard-disabled for security reasons"?
** This will be determined later on, after some of the phases land.
 
<b>Questions for UX</b>
* What type of UX to have for allowing users to opt in (or out) of enabling plugins on a (semi)persistent basis? See below in "Use Cases".


* Where are the preferences to require click to play for all or specific plugins?  Where are the preferences to have separate plugin permissions per-site?
* Where are the preferences to require click to play for all or specific plugins?  Where are the preferences to have separate plugin permissions per-site?
Line 28: Line 36:
* UX - Invisible (or barely visible) plugins will cause an infobar to appear to enable all plugins on the page - how do we handle multiple invisible (or barely visible) plugins on a page ? (stacking infobars ?)  
* UX - Invisible (or barely visible) plugins will cause an infobar to appear to enable all plugins on the page - how do we handle multiple invisible (or barely visible) plugins on a page ? (stacking infobars ?)  


* Adverse reactions between content plugin sniffing and click-to-play
** Bsmedberg asks in bug 711552: "Are we exposing to the DOM that a particular plugin element (<object> or <embed> is user-disabled?) This seems important for websites that rely primarily on plugins (e.g. Pandora) so that they can show alternate UI (plugins are disabled, please click to play) instead of timing out and showing a generic "please install Flash" or "Song initialization timed out, please hit refresh" UI."
** Can content differentiate between "click to play" and "hard-disabled for security reasons"?
* Risk of clickjacking - is this something we should try to mitigate ?
*  Whether to differentiate between an SSL site containing plugin content and an HTTP site containing plugin content. Trusting content served over HTTPS is not the same as trusting content over HTTP, which is why they are usually treated as separate origins for security purposes. For example, if a user goes to https://foo.com, encounters plugins which are click to play, and chooses some method of always enabling plugins for this site does that always enable for foo.com regardless of scheme or for https://foo.com and NOT http://foo.com ?
|Feature overview=Out of date (and hence, likely vulnerable) plugins shouldn't be allowed to run without user interaction.
|Feature overview=Out of date (and hence, likely vulnerable) plugins shouldn't be allowed to run without user interaction.


Line 84: Line 85:


Warning the user of a newly installed plugin - this is part of another feature : https://wiki.mozilla.org/Features/Firefox/Improved_plugin_installation_and_management_experience
Warning the user of a newly installed plugin - this is part of another feature : https://wiki.mozilla.org/Features/Firefox/Improved_plugin_installation_and_management_experience
We are currently not going to protect against clickjacking for click to play plugins.
We are not currently differentiating between an SSL site containing plugin content and an HTTP site containing plugin content.  We are differentiating per domain and not per scheme or port.
|Feature functional spec=Phase 1:
|Feature functional spec=Phase 1:
Users can turn on a preference to require click to play for all plugins globally
Users can turn on a preference to require click to play for all plugins globally


Phase 2:
Phase 2:
Users can turn on preferences to require click to play for specific plugins
Users can turn on preferences to require click to play for specific plugins.  And potentially per site preferences.


Phase 3:
Phase 3:
Line 96: Line 101:
This will implement User & Uses Cases 4-9.
This will implement User & Uses Cases 4-9.


Phase 4: Explore User and Use Cases 1-3.  This needs more research.  Can we leverage user behavior to define a heuristic of when a plugin should be click to play.
Phase 4: Explore User and Use Cases 1-3.  This needs more research.  Can we leverage user behavior to define a heuristic of when a plugin should be click to play?
|Feature ux design=When "click to play" plugins are found on a page, their start up will be delayed until a user performs interaction with the browser to enable the running of the plugin (as much as possible).  
|Feature ux design=When "click to play" plugins are found on a page, their start up will be delayed until a user performs interaction with the browser to enable the running of the plugin (as much as possible).  


Tanvi
canmove, Confirmed users
285

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/421135"

Navigation menu