RE: web+ and registerProtocolHandler

I think we should be more careful with terminology.
"Whitelist" -- all values are forbidden except ones explicitly in a (fininte, enumerated) "white list", so a whitelist allows a small subset, and disallows everything in an arbitrarily large set.
"blacklist" -- all values are allowed except ones explicitly in a (finite, enumerated) "black list", so a blacklist disallows a small subset, and allows everything else in an arbitrarily large set.

The pros and cons of the two approaches have to do with what is deployed and what is known to be deployed and has been evaluated as "safe to override",
 as well as what we imagine might be useful to allow.

The "web+" convention is hybrid, it's not a "blacklist" and it's not really a "whitelist" either. While it's like a whitelist explicitly allows one small, enumerated, known-in-advance set (which seems pretty arbitrary and without justification), but it also allows another arbitrarily large set. 

The notion is that anything using "web+" should be, by definition, safe to override with registerProtocolHandler. 

Part of the question is whether anyone defining a web+ scheme will actually register it, or will look at the registry to determine if anyone is using it.
Right now, browsers (Chrome, Safari) define URI schemes and use them without any significant effort to register them. Why is there any expectation that this will change?   So the notion that the registration process can somehow enforce invariants for security reasons is suspect. 

Probably the disagreement about the the value of and venue for registration is the more important "elephant in the room".

Larry


-----Original Message-----
From: "Martin J. Dürst" [mailto:duerst@it.aoyama.ac.jp] 
Sent: Wednesday, September 12, 2012 9:32 PM
To: Peter Saint-Andre
Cc: Adam Barth; Larry Masinter; michel@suignard.com; tony@att.com; plh@w3.org; adil@diwan.com; robin@berjon.com; ted.ietf@gmail.com; John O'Conner; presnick@qualcomm.com; chris@lookout.net; public-ietf-w3c@w3.org
Subject: 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 Friday, 14 September 2012 19:22:00 UTC