Confirm
197
edits
Changes
no edit summary
#* '''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 chooses to opt in to click to play for all plugins or some subset of their installed plugins
# * Plugins are 'click to play' based on the settings the user chooses in the Add On Manager and any permissions the user has granted to particular domains
# User goes to a site that uses a plugin that requires click to play, but it is not visible on the page.
#* '''Info bar / door hanger will show up asking if the user wants to enable the plugin, showing user-friendly name of plugin if possible.'''
(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. When Phase 3 lands, User & Use Cases 1-7 will all have been implemented.
Phase 4: Explore Future Research User and Use Cases 8-10. This needs more research. Can we leverage user behavior to define a heuristic of when a plugin should be click to play?
|Feature implementation notes=Meta bug for the work is {{bug|738698}}
