This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
public-html-comments posting from: Philippe De Ryck <philippe.deryck@cs.kuleuven.be> http://www.w3.org/mid/1312393604.16132.5.camel@maverick The following comment contains detailed information about a few issues that were identified during a recent security analysis of 13 W3C standards, organized by ENISA (European Network and Information Security Agency), and performed by the DistriNet Research Group (K.U. Leuven, Belgium). The complete report is available at http://www.enisa.europa.eu/html5 (*), and contains information about the process, the discovered vulnerabilities and recommendations towards improving overall security in the studied specifications. Issues -------- HTML5EL-SECURE-2.Menu Integration: A web application can define contextual and toolbar menus. The specification does not mention many implementation details. A user agent may implement integrate these menus with its own user interface, especially on small displays such as smartphones. This may confuse a user and may present malicious or erroneous menu items. HTML5EL-SECURE-3.Keygen Scenarios: The specification does not provide enough details about the keygen element. No concrete usage scenarios (from keygen to actual use of the key) or implementation requirements (e.g. storage of private keys) are provided. HTML5EL-USER-1.Overriding Sandbox: Sandboxed content is not allowed to load plugin content. The specification of the embed element however states that a user agent may allow the user to override this for a specific content item, but the user agent should warn the user that this could be dangerous. The override option is only briefly mentioned as part of the description of the embed element, but is also an important aspect of the sandbox attribute. The spec should either mention this with the sandbox attribute or refer to the embed element. (*) HTML version of the report is available as well: https://distrinet.cs.kuleuven.be/projects/HTML5-security/ -- Philippe De Ryck K.U.Leuven, Dept. of Computer Science Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
This should be split into three bugs. Looking at them quickly: the first one could get resolved by some clarifying non-normative text, if implementation advice really is necessary here (are browsers likely to screw this up? how?); the second one is an implementation detail as far as I can tell, so it's not clear what should happen there; and the third I don't really understand.
this bug is waiting on more active involvement from Philippe De Ryck <philippe.deryck@cs.kuleuven.be> -- in particular, response to the last part of comment #1
sent Philippe De Ryck a message asking him to follow up here - http://lists.w3.org/Archives/Public/public-html-comments/2011Nov/0059.html
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: insufficient information