Re: web+ and registerProtocolHandler

On Sun, Sep 16, 2012 at 1:32 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
> So I've seen a bunch of uniformly negative mail on this
> and nothing positive fwiw.

That's because the folks who are in favor of doing this aren't
participating in this discussion.

> Maybe it'd be good to get an appsarea presentation on it
> at an IETF meeting (assuming that's not happened) so the
> broader community get to know about it?
>
> I don't really know enough to be against it myself but
> it does sound like a bad security idea from the mails I've
> seen pass by so count me amongst those concerned about
> this.

I'd caution you about forming an opinion after having heard only one
side of the issue.

Adam


> On 09/14/2012 08:20 PM, Larry Masinter wrote:
>> 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:
>> 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/>
>>
>>
>>>
>>>

Received on Sunday, 16 September 2012 20:56:15 UTC