Canmove, confirm
285
edits
Changes
no edit summary
#* '''User is prompted to open plugin-check/update page, but can run plugin after scary warning instead'''
# User is tired of always clicking to play a given plugin (i.e. outdated flash on YouTube) and for whatever reason cannot or will not update (outdated version of a plugin is required for their job, for example):
#* '''User can right click on the overlay and check an option to always allow this specific out-of-date version on the specific domain.(UX: How do you right click on tablets and phones?)'''
#* Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking. Could provide "Now/Always/Never" choices.
# User goes to a site that uses a plugin that requires click to play, but it is not visible on the page.
Mozilla can remotely configure the user's browser to require click to play for specific plugins that are out-of-date and/or vulnerable.
(Note that we may allow vendors a few days or a week to update their users before remotely requiring click to play on a plugin. This will depend on the severity of the vulnerabilities in the plugin.). The plugin blocklist may also be used in some cases, as it recently was to block widespread exploitation of Java.
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.
|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).
