Re: HTML5 proposes introduction of new family of URI schemes

On Thu, 2012-01-19 at 12:47 +0100, Robin Berjon wrote:
> On Jan 19, 2012, at 04:43 , David Booth wrote:
> > On Wed, 2012-01-18 at 22:10 -0500, Noah Mendelsohn wrote:
> >> . . . 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. 
> > 
> > And that could be easily done by providing a browser configuration
> > option to tell it to use web mail at a particular URI instead of some
> > non-web-based email client, without any need for a new URI scheme.  
> 
> A configuration option is not user-friendly enough, which would hurt
> adoption of the Web as an application platform — providing web site
> with the ability to set this up easily is good (though there may be
> kinks in the current approach's security model). 

And that could be done by the web site offering "hints" that the user's
browser could choose to use or not.  "Click here to auto-configure your
browser to use Acme Web Mail as your default email client."

> What's more with your solution we'd still need some form of standard
> or convention for how to content of the URI (e.g.
> mailto:nrm@arcanedomain.com) would be transmitted to the web app.

Yes, to be totally seamless and user friendly, standards or conventions
would be needed in either case.  But in the end it could be just as
user-friendly, without the need for a new URI scheme.  It is a question
of what trigger is used to initiate this browser-website handshake: a
new URI scheme versus any of the existing mechanisms.
> 
> I think that the use cases here are legitimate. The obvious goal of
> the registerProtocolHandler and web+ is to help remove browsers from
> the critical path of innovation on the Web, which I think everyone,
> browser vendors included, agrees is a good thing. 

I strongly disagree.  While innovation is good, I think there is also a
big control issue at stake here, which could indeed lead to very bad
things.  IMO, web sites should *not* be in control of the user's
browsing experience.  *Users* should be in control.  Removing browsers
from the innovation loop runs an enormous risk of that innovation
leading to walled gardens of individual web sites controlling all of the
user's browsing experience.  Web sites *will* have the motivation to do
so, and users are not web experts: they will not be savvy enough to
realize or prevent it.  I think it is important to take this into
consideration when enabling innovation.

> [ . . . ] If I invent a wonderful new format with
> application/chupacabra media type, I really don't want to have to ask
> my users to go to some mysterious configuration panel and pasting in
> "application/chupacabra" and "http://chu.paca.br/a". I want them to
> just click on a link and have it work.

Sure, that's what the web site owner wants.  But that's also what every
phishing site owner wants: just get the user to click on a link, and it
will magically "work", without the user ever being the wiser.  And as we
all know, most users are *not* the wiser.  I think there is an inherent
danger in making this too easy.  
> 
> But that part isn't registerProtocolHandler, it's
> registerContentHandler, which doesn't use URI schemes but media types
> (and since it's blacklisting rather than whitelisting, it doesn't
> create a new magic +web suffix for media types). 

I don't understand that.  If registerContentHandler is blacklist driven
instead of whitelist driven, then what would prevent phishing sites from
inventing new legitimate-looking schemes that are not on the blacklist?

In short, I have three problems with this:

 - The way a feature is provided can have a big impact on larger issues
of security and user control.  I am concerned that the proposed feature
would take control from the user and add security risk.

 - AFAICT this functionality could be accomplished with existing
mechanisms rather than inventing new URI schemes.

 - What is the HTML5 group doing inventing new URI schemes anyway?
Standards groups are not the right place for research. 


-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Thursday, 19 January 2012 15:52:20 UTC