Re: HTML5 proposes introduction of new family of URI schemes

Martin,

I still do not understand, from your explanations, what value the 'web+' 
prefix brings to the table over the status quo. 

I get that it would be bad for a malicious web service to try to trick the 
user into associating all http traffic with it. However, 
'web+' doesn't really fix that, instead it creates more problems that it 
intends to solve.

The authors of a protocol are likely not the same individuals who might 
conceive of the idea of a web-based handler. Seems as if the scheme will 
simply encourage
all protocol designers to register their URI scheme with the 'web+' prefix 
simply to leave open the prospect of a web-based handler. This defeats the 
intended
purpose of the 'web+' prefix.

Further, I notice the whitelist omits xmpp. Is there no hope for web-based 
IM, absent a formal change in the spec? Someone better alert Meebo.

It seems to me that a blacklist might better serve to address the security 
concerns. Specifically, blacklist those protocols for 
which there is a known security threat profile should that protocol be 
usurped by a web-based handler. I imagine that list will be fairly short.

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Industry and Cloud Standards
Member, IBM Academy of Technology
IBM Software Group, Standards Strategy
email: chrisfer@us.ibm.com
blog: 
https://www.ibm.com/developerworks/mydeveloperworks/blogs/chrisferris/
phone: +1 508 234 2986



From:   "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
To:     Noah Mendelsohn <nrm@arcanedomain.com>, 
Cc:     Jonathan A Rees <rees@mumble.net>, Julian Reschke 
<julian.reschke@gmx.de>, "www-tag@w3.org" <www-tag@w3.org>, Paul Cotton 
<Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby 
<rubys@intertwingly.net>
Date:   01/19/2012 06:08 AM
Subject:        Re: HTML5 proposes introduction of new family of URI 
schemes



Hello Noah,

On 2012/01/19 12:10, Noah Mendelsohn wrote:
> Martin,
>
> There's something about your example that confuses me. Let's say I
> author a Web page, and to make it easy for you to email me, I include a
> link to mailto:nrm@arcanedomain.com. You read my page, and click on the
> link, and you've explained why as a (hypothetical) Webmail user you'd
> want your new, smart HTML5 Web browser to invoke the Webmail Web app to
> compose the e-mail. If someone else clicks the link, then they might
> want that same link to open Outlook or Thunderbird. So far, no problem.
> We've got an existing scheme, it's in the whitelist, and each client can
> be configured to do what its user needs.
>
> What strikes me as important, though, is that I in composing the Web
> page don't want to know how you want your particular client to handle
> the links. I want to use a URI that's independent of the implementation
> technology of, in this case, the e-mail reader, which may in some cases
> be Web-based and in others a native client app.

Yes indeed. As a page author, you just use the 'mailto' scheme, and 
that's it.

> So my question is: why would the story be any different for other links?
> Don't we want to continue to use URI schemes that are independent of the
> implementation technology of the application? Don't we want it to be
> possible that the same link will sometimes invoke a Web-based version of
> an application and sometimes a native?

Yes indeed.

> That suggests to me that, rather
> than minting new URI schemes,

There is no proposal for creating new schemes. There's no need to create 
a web+mailto scheme, or a web+http scheme, or anything like that. The 
web+ prefix is only for future schemes. The idea (not mine, I'm just 
trying to explain) is that if somebody has an idea for a new scheme 
(lets say for the foobar protocol or some such), then they decide 
whether it may make sense for a Web application to handle this protocol 
or not. If yes, they register 'web+foobar' as the scheme name; if no, 
they register 'foobar' as the scheme name.

This then allows an HTML5 browser (see 
http://dev.w3.org/html5/spec/Overview.html#custom-handlers) to know 
whether it's a good idea to allow delegation of all URIs/IRIs in this 
scheme to a particular Web page after that Web page has requested it and 
the user has confirmed it, or not. For existing schemes, this decision 
already has been taken, you can find it under "whitelisted schemes" in 
the above section.

So the "web+" convention is intended for future schemes, and it's a 
security device on top of user confirmation, because one would not want 
a single page to handle e.g. all the HTTP traffic of a user, even if the 
user accidentally clicked okay when asked for permission.

> we need to enable the use of something in
> the spirit of URI templates in the client, so that links using existing
> URI schemes can be directed to Web or native apps as appropriate.

If you look at the above cited section of HTML5, then the "%s" in the 
url parameter of window.navigator.registerProtocolHandler indeed looks 
like a mini-template.


> Why do we need or want web+ for this?

I hope I have made it clear enough why the proponents of this prefix 
came up with it.

In *procedural* terms (and https://www.w3.org/html/wg/tracker/issues/189 
is to quite some extent written as a procedural issue),
it's not really such a problem. Indeed "web+" can't be registered the 
way it's currently proposed in the HTML5 spec, but we could just put a 
provision for such a prefix into RFC 4395bis, on which the IRI WG is 
working anyway. That would have the advantage that people who create new 
URI schemes might actually become aware of it.

The question is whether a prefix is a good idea. Julian strongly thinks 
it's not, and gives some good reasons. I also feel it's not a very good 
solution, but I think it would really help if somebody came up with an 
alternative.

There are several directions that I can think of:

- Put a 'column' into the URI/IRI registry that indicates whether
   a scheme is suitable for a web application or not.
   (problem: browsers need to be updated)
- Let browser makers decide, because they will ultimately be blamed for
   security issues. (problem: work for browser vendors)
- Keep the browsers out of the picture, let the OS handle it. Currently,
   the OS knows which application I want to use for http:, and which for
   mailto:,..., and this could be extended to allow redirection to
   another URI/IRI. (problem: OSes need to implement this, and they
   would have to make the same decisions)

I'm also a bit skeptical that a permanent decision can be made for which 
schemes to be allowed handling by Web applications. After let's say that 
ftp is getting even less popular than it is now, and browsers drop 
support for it, why wouldn't I be okay for a Web application to handle 
my ftp needs if I'm okay to let a Web application handle my mail?

Regards,    Martin.


> On 1/18/2012 9:59 PM, "Martin J. Dürst" wrote:
>> Hello Jonathan, Julian,
>>
>> On 2012/01/19 0:31, Jonathan A Rees wrote:
>>> On Sat, Jan 14, 2012 at 5:56 PM, Julian Reschke<julian.reschke@gmx.de>
>>> wrote:
>>
>>>> It seem<http://dev.w3.org/html5/spec/Overview.html#custom-handlers>
>>>> contains the rest of the information.
>>>
>>> Maybe it does, but it doesn't answer my question - to what problem is
>>> this a solution? Also how is it expected to play out in practice? What
>>> will the new security dialogs look like and will they baffle users
>>> like all the others do? Has anyone already implemented it?
>>>
>>> The list of 'legacy schemes' is a red flag for me. By what criteria is
>>> inclusion in the list determined? Suppose the list needs to be
>>> changed, does that require a change to the HTML specification? What is
>>> it about 'mailto', really, that causes it to be treated differently
>>> from 'http'? The word 'core' doesn't explain much to me.
>>
>> Actually, it's not too difficult to explain. And 'mailto' is really at
>> the
>> core of it. If you use a 'traditional' email client, and you click on a
>> 'mailto' link on a Web page, then the browser makes sure this 'mailto'
>> URI/IRI is handed off to your email client, and the email client
>> creates a
>> new mail message for you and lets you edit it.
>>
>> These days however, webmail is being used more and more. What web mail
>> users would like to have is the same facility: You click on a 'mailto'
>> link, and a new email message is created by your webmail. It's easy for 
a
>> webmail service to provide an URI/IRI where the 'mailto' URI/IRI can be
>> added and the result creates the new email message that you were hoping
>> for. But there's a missing piece: How to get the 'mailto' into that
>> URI/IRI
>> automatically.
>>
>> I have to admit that personally, I'm not using webmail. But at least
>> to me,
>> the above scenario, and the need for some additional facility, is quite
>> evident. And we probably don't want to restrict this to 'mailto' only,
>> because we don't know how technology will evolve.
>>
>> I think once we can agree that there's a need, we can look at the
>> issues in
>> more detail. Would you agree with what I wrote above as a starting 
point?
>> Also, Julian, you seems to be very clearly opposed to the specific
>> proposed
>> solution, with some serious arguments, but do you actually agree that
>> there
>> is a need to be able to activate webmail with a 'mailto' link, and that
>> there may be similar needs for other URI/IRI schemes?
>>
>> As you are asking for a distinction with 'http', that's easy: Because
>> http
>> is already handled by the browser, there's at least currently no need 
for
>> such a thing as 'webhttp' (i.e. a single web site handling all of your
>> browsing activity). But that also may not be set in stone, it may be
>> possible that in the future, some users will view all their pages 
through
>> facebook, and others through tor :-(.
>>
>> Regards, Martin.
>>
>>
>>> A more conservative design would be to have a single new web: URI
>>> scheme with a subscheme registry (sort of link urn:), rather than lots
>>> of new URI schemes. This wouldn't allow registering behavior for
>>> mailto:, but might mean fewer surprises and less standards innovation.
>>>
>>> Not opposed, just confused. Someone has thought about this a lot, and
>>> I don't know what they've thought.
>>>
>>>> Best regards, Julian
>>>
>>>
>>
>
>