This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"The sandbox attribute, when specified, enables a set of extra restrictions on any content hosted by the iframe. Its value must be an unordered set of unique space-separated tokens that are ASCII case-insensitive. The allowed values are allow-same-origin, allow-top-navigation, allow-forms, and allow-scripts. When the attribute is set, the content is treated as being from a unique origin, forms and scripts are disabled, links are prevented from targeting other browsing contexts, and plugins are disabled." This doesn't cover the case where a UI might be able to negotiate these restrictions with a plugin. See context around <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-July/032429.html>.
Specifically, it would make the most sense to remove "plugins are disabled", and add a sentence saying that the UA has to only allow plugins to run if it knows they'll meet these requirements. E.g., NPAPI might be extended to have flags to signal this sort of thing, or maybe the browsers authors control the plugin themselves (like the Chrome PDF viewer).
(In reply to comment #1) > Specifically, it would make the most sense to remove "plugins are disabled", > and add a sentence saying that the UA has to only allow plugins to run if it > knows they'll meet these requirements. E.g., NPAPI might be extended to have > flags to signal this sort of thing, or maybe the browsers authors control the > plugin themselves (like the Chrome PDF viewer). +1
mass-move component to LC1
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Concurred with reporter's comments.
Checked in as WHATWG revision r6573. Check-in comment: Define how sandboxing works with plugins in a hypothetical world where plugins honour the sandbox. http://html5.org/tools/web-apps-tracker?from=6572&to=6573
(In reply to comment #4) > EDITOR'S RESPONSE: This is an Editor's Response to your comment. I would recommend removing or changing the example for a secure-aware plugin, since "pop-up windows" has nothing to do with security. A better example might be communicating with insecure data sources.
I don't understand. What has communicating with insecure data sources got to do with the sandbox="" attribute?
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Did Not Understand Request Change Description: no spec change Rationale: see comment 7