Confirm
717
edits
Changes
m
no edit summary
|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".
* Whether What determines if a plugin is click-to differentiate between an SSL site containing plugin content loaded over SSL and an HTTP site containing plugin content loaded over HTTP-play vs always disabled vs always enabled? See "Use Cases" below. * How do we manage these click to play settings? Trusting content served over HTTPS is not the same as trusting content over HTTPIt would bad to hard-code them, which is why they are usually treated as separate origins for security purposesand much better to deliver via our existing blocklist mechanism.
* Risk of clickjacking Differentiating plugins by type - should enabling (or clicking) Flash enable Java, for example?
* Adverse reactions between content plugin sniffing and click-to-play
** Can they differentiate between "click to play" and "hard-disabled for security reasons"?
* What determines if a Whether to differentiate between an SSL site containing plugin content loaded over SSL and an HTTP site containing plugin is click-to-play vs always disabled vs always enabled? See "Use Cases" belowcontent loaded over HTTP. * How do we manage these click to play settings? It would bad to hard-code themTrusting content served over HTTPS is not the same as trusting content over HTTP, and much better to deliver via our existing blocklist mechanismwhich is why they are usually treated as separate origins for security purposes. * Differentiating plugins by type - should enabling (or clicking) Flash enable Java, for example?
* Risk of clickjacking - is this something we should try to mitigate
|Feature overview=Unknown, slow or insecure plugins shouldn't be allowed to run without user interaction.
