- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 22 Aug 2012 10:30:29 +0200
- 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 exception." 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