W3C home > Mailing lists > Public > public-ietf-w3c@w3.org > August 2012

Re: web+: enabling websites to expose services with custom URI schemes to registerProtocolHandler.

From: Julian Reschke <julian.reschke@gmx.de>
Date: Wed, 22 Aug 2012 10:30:29 +0200
Message-ID: <503498A5.2010607@gmx.de>
To: Larry Masinter <masinter@adobe.com>
CC: Peter Saint-Andre <stpeter@stpeter.im>, Philippe Le Hegaret <plh@w3.org>, Barry Leiba <barryleiba@computer.org>, Mark Nottingham <mnot@mnot.net>, "public-ietf-w3c@w3.org" <public-ietf-w3c@w3.org>, Edward O'Connor <eoconnor@apple.com>
On 2012-08-21 21:40, Larry Masinter wrote:
> That and the security considerations, but I suppose that the security concerns are about RegisterProtocolHandler. I don't understand or see how the 'origin' sandboxing can work, since the protocol handler registry is a shared global resource.

I don't think there's an attempt to sandbox here. As a matter of fact, I 
would expect the protocol handler to be registered *globally*, so that 
links would work when followed from a MUA as well.

> And what does the "web+" buy, anyway? It prevents "Web+mailto" from stepping on "mailto", but it doesn't prevent "web+mailto" 1 from stepping on "web+mailto" 2.

It's not about name collisions; it's about implicit white-listing a set 
of URI scheme.

> Whenever there's a naming convention, there needs to be some invariant that is true for things that match, otherwise the naming convention is meaningless. So what is it that you know about "web+foo:" that you don't know about "foo:" ?

"If the registerProtocolHandler() method is invoked with a scheme that 
is neither a whitelisted scheme nor a scheme whose value starts with the 
substring "web+" and otherwise contains only characters in the range 
lowercase ASCII letters, the user agent must throw a SecurityError 

So by default, most current and future URI schemes can not be 
registered, *unless* they start with "web+", *or* they are added to the 
exception list.

Best regards, Julian
Received on Wednesday, 22 August 2012 08:31:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:56:35 UTC