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 6.5.1.2 Custom scheme and content handlers features of registerProtocolHandler and registerContentHandler open huge security and privacy holes which are not described in the specification and for which there is no reliable mitigation such that users of these features could count on. It's understandable that these are attractive features from the point of view of the power they put in the hands of developers of new protocols and content-types. The bug is that these features are inadequately specified and the security of them inadequately analyzed and mitigated. Here is an incomplete analysis: These features expand the attack surface for introduction of malware, for leakage of private information in unanticipated and undisclosed ways. While the security section alludes to a few of the problems, the mitigations given are not implementable in a way that a browser-independent web application that wished to use the features could do so reliably. For one small example, registerContentHandler for a new image type might merely prompt the user for permission to install a new content-type handler, without clearly identifying that now, all images of that type will be sent to the handler site as soon as the image is received. This gives the site that registers the content handler far more information about the user's activities. It exacerbates the current difficulties of multiple applications overwriting the default content handler for various media types, provides for no 'undo' mechanism for putting back pointers to local interpreters, etc. As these are intended to be permanent changes to the underlying systems and not bounded by interpretation within the browser, a web site is now allowed to affect the permanent operation of the receiver's system. While this might be thought of as no different from typical installation dialogs, installing new software on a system usually involves virus and malware scanning, checking digital signatures of the the installed code and so forth. After a new handler has been installed, the server of the handler is now part of an attack surface. Attempting to strengthen the mechanism for preventing malicious overwriting of legitimate handlers could merely encourage malicious preemptive registration of handlers.
Also: The current specification attempts to mitigate some of the risks of registerProtocolHandler by maintaining a "white list" of protocols for which handlers are "safe" and disallowing registering all other handlers except those starting with "web+". However, this mechanism doesn't help with most of the security and privacy problems that arise when allowing dynamically assigned and overwritten handlers. There is another bug and decision which focused on "web+" prefix and the authority under which such schemes are registered, but this was a distraction from the more fundamental problems. For example, even if registerProtocolHandler only allowed registering "mailto" and nothing else, the risks of web sites trying to steal "mailto" from each other, or the information leakage that the handler's site now can learn whenever a user STARTS to type a message, even when the user abandons the interaction, has not been disclosed or mitigated. For example, one mitigation might be that handlers not be URI patterns of remote services but rather pages or content bodies or previously downloaded Javascript libraries.
See also threads on public-ietf-w3c starting http://lists.w3.org/Archives/Public/public-ietf-w3c/2012Aug/0000.html "web+: enabling websites to expose services with custom URI schemes to registerProtocolHandler." and http://lists.w3.org/Archives/Public/public-ietf-w3c/2012Sep/0004.html "web+ and registerProtocolHandler" and Chris Weber's blog post http://web.lookout.net/2012/01/testing-registerprotocolhandler-and-web.html
Note: registerContentHandler and registerProtocolHandler are currently at-risk features for HTML 5.0 http://www.w3.org/html/wg/wiki/index.php?title=HTML5.0AtRiskFeatures
Given that these two features are at-risk, are you against leaving their definition in the CR spec? If so, then we can probably resolve this bug and if need be, pull the definitions out later (preparatory to the spec transitioning to PR). If not, then we can remove the features entirely from the 5.0 draft. Note, however, that these APIs will still exist in 5.1, so it may also be prudent to just move this bug to the 5.1--not let it block 5.0--and address the root of the security problems with these APIs.
Per W3C process, at risk features in a CR document can be removed at any point without resetting the status of the document in its advancement toward REC. This topic needs further refinement and clarification on how to make the specified APIs more secure, and this refinement can be done in the HTML5.1 draft--it is not blocking for 5.0 at this point. Removing the CR keyword from this bug.
HTML5.1 Bugzilla Bug Triage: Moved to https://github.com/w3c/html/issues/233 If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!