On Tue, Apr 19, 2011 at 10:33 AM, Ian Hickson <[email protected]> wrote: > On Tue, 12 Apr 2011, Lachlan Hunt wrote: > > > > We are investigating registerProtocolHandler and have been discussing > > the need for a blacklist of protocols to forbid. > > > > [...] > > > > We'd like to know if we've missed any important schemes that must be > > blocked, and we think it might be useful if the spec listed most of > > those, except for the vendor specific schemes, which should probably be > > left up to each vendor to worry about. > > I haven't updated the spec yet, but it strikes me that maybe what we > should do instead is have a whitelist of protocols we definitely want to > allow (e.g. mailto:), and define a common prefix for protocols that are > used with this feature, in a similar way to how with XHR we've added Sec-* > as a list of headers _not_ to support. > > So e.g. we could whitelist any protocol starting with "web+" and then > register that as a common extension point for people inventing protocols > for use with this feature, so that people writing OS-native apps would > know that if they used a protocol with that prefix it's something that any > web site could try to take over. > > I'd be curious about people's opinions on that matter. > > (If we did this, the whitelist may have to be updated occasionally to add > new protocols that people invented that we think are fine to be > overridden, but that are not "web+"-prefixed.)
This seems like the right approach. Even if we blacklist correctly now, needing to remember to blacklist each new protocol is too risky. A whitelist somewhat limits the potential for people using registerProtocolHandler in unexpected useful ways, but it still meets the primary use cases. Ojan
