Confirm
717
edits
Changes
m
* How do we manage these click to play settings? It would bad to hard-code them, and much better to deliver via our existing blocklist mechanism.
no edit summary
}}
{{FeaturePageBody
|Feature open issues and risks=* Differentiating plugins by type - should enabling (or clicking) Flash enable Java, for example? * What type of UX to have for allowing users to opt in (or out) of enabling plugins more than once. on a (semi)persistent basis? See below in "use cases".
* Whether to differentiate between an SSL site containing plugin content loaded over SSL and an HTTP site containing plugin content loaded over HTTP. 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.
* Risk of clickjacking
* Adverse reactions between content plugin sniffing and click-to- bsmedberg 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 they differentiate between "click to play" and "hard-disabled for security reasons"? * What determines if a plugin is click-to-play vs always disabled vs always enabled? See "Use Cases" below.
* Along the lines of the above, when a plugin ISN'T disabled explicitly but hasn't been clicked, it seems important that content know that the plugin is availableHow do we manage these click to play settings? It would bad to hard-code them, and much better to avoid wrongfully showing the alternate 'you have no plugin' UI deliver via our existing blocklist mechanism.
* What determines if a plugin is clickDifferentiating plugins by type -to-play vs always disabled vs always enabledshould enabling (or clicking) Flash enable Java, for example? See use cases below
|Feature overview=Unknown, slow or insecure plugins shouldn't be allowed to run without user interaction.
** A user has clicked on this four times in X days, so automatically enable this plugin on this site until user revokes this decision (about:permissions?) and/or remember decision for Y days after last click
** Jruderman has suggested a context menu instead of a click - this is a mitigation against click jacking. Could provide "Now/Always/Never" choices.
|Feature dependencies=* UX design/review
* Revisions to blocklisting (or at least re-purposing of existing mechanisms)
