Confirm
717
edits
Changes
no edit summary
}}
{{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 casesUse Cases".
* What determines if a plugin is click-to-play vs always disabled vs always enabled? See "Use Cases" below.
* 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.
* Differentiating plugins by type - should enabling (or clicking) Flash enable Javaon a given page, for example?
* 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 they content differentiate between "click to play" and "hard-disabled for security reasons"?
* 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.
Optional requirements
* Manage plugin run settings on a per-site basis
* Control plugins on a per-plugin per-basis for a given site basis
* Mitigate attacks where user chooses to interact with site (clickjacking, or simply wants to run vulnerable plugin)
|Feature non-goals=We can't prevent users getting owned up by vulnerable plugins if they choose to activate a plugin on a site hosting malicious payloads. That is why driving plugin updates is important.
