- From: Ojan Vafai <ojan@chromium.org>
- Date: Tue, 19 Apr 2011 10:39:35 -0700
On Tue, Apr 19, 2011 at 10:33 AM, Ian Hickson <ian at hixie.ch> 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
Received on Tuesday, 19 April 2011 10:39:35 UTC