Re: web+ and registerProtocolHandler

On 2012/09/12 23:47, Peter Saint-Andre wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> In the context of whitelisting vs. blacklisting, the concern I have
> with the prefixing idea is that it implicitly whitelists any URI
> scheme that starts with the string "web+",

I'd buy the "implicitly whitelists" argument if there were any schemes 
starting with web+ now, or if there were a big chance that such schemes 
would be introduced independent of the purpose of "web+" (e.g. "I need a 
new scheme, "web+" really looks cool, I want my scheme to have that as a 
prefix so that I'm part of the club.").


> yet the proponents of this
> idea have not specified any criteria for review of such prefixed URI
> schemes (or even answered the questions raised here and elsewhere
> about whether additional review is needed for such schemes by the
> designated experts or the IANA).

Having such criteria would indeed be a good thing. But I guess that in 
the limit, it's difficult to come up with some. ssh: quite easily 
provides an example. [The following is simplified and so I think it's 
not too difficult to poke holes in it, but I hope it shows that it's 
difficult to come up with any but very basic criteria.]

It's easy to assume that quite a bit of ssh use is security relevant. On 
the other hand, it's not impossible to imagine to use ssh out of a 
browser. I have to trust my web browser (which I have to do anyway), and 
I have to trust the Web application that provides the ssh facilities. 
But that's not much different from having to trust the ssh application 
that I downloaded. If I entrust a web mail service with all my email 
communications, I may as well entrust a trustworthy ssh Web service with 
all my ssh communications.


Even for http/https, which is now blacklisted, who says that in the 
future we won't see browsers that are written as Web apps inside another 
browser? To some extent, that's a crazy idea involving lots of overheads,...

But proxies and things such as Amazon Silk and some of what Opera does 
for mobiles already essentially move part of the browsing facilities 
away from the client machine. Google Chrome Frame also implemented a 
"browser in a browser", although as a plugin.

Who's to say that a "browser in a browser" (implemented as a Web app) 
doesn't make sense? It's the browser makers that have blacklisted 
http/https, and maybe (just a wild guess) that's just because they think 
they are doing a decent-enough job so that nobody needs a "browser in a 
browser".


Which brings me to another problem, and what I think is the main 
problem, with the "web+" prefix: When email, and mailto:, were created, 
who was thinking about Webmail? Of course nobody. So when the next 
interesting killer app for the Internet is created, who will think about 
doing a Web version? In many if not most cases, it will either be 
Web-based from the start (which means it uses http(s) and doesn't need 
to think about a new URI/IRI scheme or a prefix), or it will be 
standalone because it's way too hard and does not seem appropriate to do 
the same thing in a browser. So the creators of this new technology will 
just register a scheme without "web+". At a later date, when somebody 
comes up with a cool way to do the same thing over the Web, it's already 
way too late to add the "web+" prefix.

In other words, I think the problem is not with having (or not) a list 
of criteria, it's with being able to judge whether these criteria will 
apply somewhen in the future.


Regards,    Martin.

> I agree that blacklisting doesn't scale and isn't secure. I disagree
> that implicit whitelisting is the answer.
>
> Peter
>
> On 9/10/12 9:56 AM, Adam Barth wrote:
>> It's just a practical issue.  Many folks have URI schemes
>> registered on their computers that are not safe for web sites to
>> hijack (i.e., register).  It's not practical to create an blacklist
>> that effectively mitigates that risk.  As it happens, we not aware
>> of any folks who have such registrations for URI schemes that begin
>> with "web+".
>>
>> Adam
>>
>>
>> On Mon, Sep 10, 2012 at 1:01 AM, Larry Masinter
>> <masinter@adobe.com>  wrote:
>>> since this affects ietf and w3c, and public-ietf-w3c is publicly
>>> archived, could someone explain why allowing registering
>>> arbitrary web+xxx scheme handlers is any better than allowing
>>> arbitrary (unblacklisted) xxx scheme handlers?
>>>
>>>
>>> -----Original message-----
>>>
>>> From: Adam Barth<w3c@adambarth.com>  To: Larry Masinter
>>> <masinter@adobe.com>  Cc: "michel@suignard.com"
>>> <michel@suignard.com>, Tony Hansen<tony@att.com>, Philippe Le
>>> Hegaret<plh@w3.org>, Peter Saint-Andre<stpeter@stpeter.im>,
>>> Adil Allawi<adil@diwan.com>, Robin Berjon<robin@berjon.com>,
>>> Ted Hardie<ted.ietf@gmail.com>, John O'Conner
>>> <jooconne@adobe.com>, Pete Resnick<presnick@qualcomm.com>,
>>> "Martin J. Dürst"<duerst@it.aoyama.ac.jp>, Chris Weber
>>> <chris@lookout.net>  Sent: Sun, Sep 9, 2012 19:09:22 GMT+00:00
>>> Subject: RE: 85th IETF - Working Group/BOF/IRTF Scheduling -
>>> REMINDER
>>>
>>> We should discuss further on a publicly archived mailing list.
>>>
>>> Adam
>>>
>>> On Sep 9, 2012 12:00 PM, "Larry Masinter"<masinter@adobe.com>
>>> wrote:
>>>>
>>>> Why doesn't "web+"  introduce all the same problems a blacklist
>>>> approach (where everything is allowed unless explicitly
>>>> disallowed) introduces? That's kind of what Chris' tests are
>>>> showing.
>>>>
>>>> And what's the point, anyway, of a precise specification but
>>>> leaving out the necessary steps to implement the spec
>>>> securely?
>>>>
>>>>
>>>>
>>>> -----Original Message----- From: Adam Barth
>>>> [mailto:w3c@adambarth.com] Sent: Sunday, September 09, 2012
>>>> 10:20 AM To: Chris Weber Cc: Larry Masinter; "Martin J. Dürst";
>>>> Peter Saint-Andre; Philippe Le Hegaret; John O'Conner; Tony
>>>> Hansen; Ted Hardie; michel@suignard.com; Adil Allawi; Pete
>>>> Resnick; Robin Berjon Subject: Re: 85th IETF - Working
>>>> Group/BOF/IRTF Scheduling - REMINDER
>>>>
>>>> Folks can be unhappy with a whitelist all they want.  A
>>>> blacklist isn't secure and we won't implement it.
>>>>
>>>> Adam
>>>>
>>>>
>>>> On Sun, Sep 9, 2012 at 12:11 AM, Chris Weber
>>>> <chris@lookout.net>  wrote:
>>>>> Thanks for the message Martin and Larry.  I will not be in
>>>>> Atlanta unfortunately,  I'm guessing Peter will..?  I'd be
>>>>> happy to schedule some design meeting time for next week
>>>>> after the expiring drafts have been re-submitted.
>>>>>
>>>>> As far as web+xxx, I'm still afraid that a user
>>>>> fingerprinting and tracking risk exists - though I didn't
>>>>> test the isProtocolHandlerRegistered() method for
>>>>> exploitability because it didn't exist, I see Safari has
>>>>> implemented it now and Chrome and Firefox have some active
>>>>> bugs for tracking.
>>>>>
>>>>> Also, I notice that some developers are not happy with the
>>>>> whitelist vs blacklist approach:
>>>>> https://github.com/jquery/standards/issues/12
>>>>>
>>>>> -Chris
>>>>>
>>>>> On 9/8/2012 9:32 AM, Larry Masinter wrote:
>>>>>> I'm planning to go to IETF Atlanta (direct from W3C TPAC in
>>>>>> Lyon)
>>>>>>
>>>>>> I'd like to better coordinate the IETF and W3C specs on
>>>>>> URLs, IRIs, etc. Doing so was my original motivation for
>>>>>> revising these specs in the first place. I'd like to also
>>>>>> see if we can make progress on "web+xxx" and (if it's still
>>>>>> in W3C specs) "http+aes".
>>>>>>
>>>>>> I see Chris is doing testing. Making progress on open
>>>>>> issues was stymied by lack of testing, so perhaps now that
>>>>>> we have some testing capabilities we can make more rapid
>>>>>> progress.
>>>>>>
>>>>>> Larry
>
> <snip/>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
>
> iEYEARECAAYFAlBQoGQACgkQNL8k5A2w/vxCAgCfXencuCpjpoP1OqvSvgCb2m/B
> OwcAnR7QcQGgy5ZGuuUS60Rcfu1ylNJk
> =T5l0
> -----END PGP SIGNATURE-----
>
>

Received on Thursday, 13 September 2012 04:33:17 UTC