W3C home > Mailing lists > Public > public-ietf-w3c@w3.org > September 2012

RE: web+ and registerProtocolHandler

From: Larry Masinter <masinter@adobe.com>
Date: Sun, 16 Sep 2012 17:26:06 -0700
To: Adam Barth <w3c@adambarth.com>, Alexey Melnikov <alexey.melnikov@isode.com>
CC: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Peter Saint-Andre <stpeter@stpeter.im>, "michel@suignard.com" <michel@suignard.com>, "tony@att.com" <tony@att.com>, "plh@w3.org" <plh@w3.org>, "adil@diwan.com" <adil@diwan.com>, "robin@berjon.com" <robin@berjon.com>, "ted.ietf@gmail.com" <ted.ietf@gmail.com>, "John O'Conner" <jooconne@adobe.com>, "presnick@qualcomm.com" <presnick@qualcomm.com>, "chris@lookout.net" <chris@lookout.net>, "public-ietf-w3c@w3.org" <public-ietf-w3c@w3.org>
Message-ID: <C68CB012D9182D408CED7B884F441D4D1E2E032B45@nambxv01a.corp.adobe.com>
I wonder if the blacklist/whitelist aspects of "web+" is a "red herring", distracting from the heart of the matter: 

The fundamental problem of registerProtocolHandler and registerContentHandler  is the idea that new schemes and media types can be dynamically allocated and deployed through scripting, with a web security model, rather than by software installation, with a software initiation security model.

This is a huge shift. A "URI" is intended to be "Uniform" -- have the same meaning everywhere, by community agreement and adjudication through the management of the registry itself.  There's already an enormous problem with applications fighting each other for media type and "default browser" ownership. With dynamically allocated and locally registered schemes, the malware attack surface is enormously expanded, and the hints in the spec impossible to implement consistently such that any content author could rely on the feature.

And the feature's potential for negative impact on non-browser user of URIs and media types hasn't even been mentioned!  So I go to a web site, and suddenly my email client starts working differently?

Received on Monday, 17 September 2012 00:27:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:10:07 UTC