13267 2011-07-15 08:14:20 +0000 sandboxing implication for plugins should be rephrased 2011-09-26 22:28:37 +0000 1 1 1 Unclassified HTML WG LC1 HTML5 spec unspecified All All RESOLVED NEEDSINFO http://www.w3.org/TR/2011/WD-html5-20110525/Overview.html#attr-iframe-sandbox P2 normal --- 1 julian.reschke ian ayg ian lrosenth mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 51094 0 julian.reschke 2011-07-15 08:14:20 +0000 "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>. 51133 1 ayg 2011-07-15 19:04:46 +0000 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). 51141 2 julian.reschke 2011-07-15 20:02:40 +0000 (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 53453 3 mike 2011-08-04 05:14:00 +0000 mass-move component to LC1 57256 4 ian 2011-09-23 19:40:15 +0000 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. 57257 5 contributor 2011-09-23 19:43:16 +0000 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 57265 6 lrosenth 2011-09-23 19:53:00 +0000 (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. 57275 7 ian 2011-09-23 22:35:27 +0000 I don't understand. What has communicating with insecure data sources got to do with the sandbox="" attribute? 57382 8 ian 2011-09-26 22:28:37 +0000 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