HTML5 and URI scheme *name* prefixes

Discussion:

Julian Reschke

2012-01-14 13:16:42 UTC

Hi there,

ref: <https://www.w3.org/html/wg/tracker/issues/189>

HTML5 introduces a naming convention for URI scheme *names*; see

12.6 web+ scheme prefix
This section describes a convention for use with the IANA URI scheme registry. It does not itself register a specific scheme. [RFC4395]
URI scheme name
Schemes starting with the four characters "web+" followed by one or more letters in the range a-z.
Status
permanent
URI scheme syntax
Scheme-specific.
URI scheme semantics
Scheme-specific.
Encoding considerations
All "web+" schemes should use UTF-8 encodings were relevant.
Applications/protocols that use this URI scheme name
Scheme-specific.
Interoperability considerations
The scheme is expected to be used in the context of Web applications.
Security considerations
Any Web page is able to register a handler for all "web+" schemes. As such, these schemes must not be used for features intended to be core platform features (e.g. network transfer protocols like HTTP or FTP). Similarly, such schemes must not store confidential information in their URLs, such as usernames, passwords, personal information, or confidential project names.
Contact
Author/Change controller
References
W3C

I'm in the process of writing a Change Proposal asking for a removal of
this feature. In the meantime, it would be useful if the WG came up with
"official" feedback on overloading the scheme name.

Best regards, Julian

Mykyta Yevstifeyev

2012-01-14 14:11:33 UTC

Permalink

My personal opinion:

Neither RFC 4395 nor 4395bis provide a possibility to perform such
sorts of registrations. This is not a URI scheme but a prefix thereof
- theoretically, if this is register, de-facto an infinite range of
scheme names is registered; this is really not what authors of RFC
4395 wanted their document to serve for -, and additionally I can
hardly find what should schemes starting with "web+" stand for save
"The scheme is expected to be used in the context of Web
applications."; furthermore, this is impossible to understand how
should Web pages register such scheme names (this is in Sec.
considerations).

I support Julian's position on this.

Mykyta Yevstifeyev

Post by Julian Reschke
Hi there,
ref: <https://www.w3.org/html/wg/tracker/issues/189>
HTML5 introduces a naming convention for URI scheme *names*; see

12.6 web+ scheme prefix
This section describes a convention for use with the IANA URI scheme
registry. It does not itself register a specific scheme. [RFC4395]
URI scheme name
Schemes starting with the four characters "web+" followed by one or
more letters in the range a-z.
Status
permanent
URI scheme syntax
Scheme-specific.
URI scheme semantics
Scheme-specific.
Encoding considerations
All "web+" schemes should use UTF-8 encodings were relevant.
Applications/protocols that use this URI scheme name
Scheme-specific.
Interoperability considerations
The scheme is expected to be used in the context of Web applications.
Security considerations
Any Web page is able to register a handler for all "web+" schemes. As
such, these schemes must not be used for features intended to be core
platform features (e.g. network transfer protocols like HTTP or FTP).
Similarly, such schemes must not store confidential information in their
URLs, such as usernames, passwords, personal information, or confidential
project names.
Contact
Author/Change controller
References
W3C

I'm in the process of writing a Change Proposal asking for a removal of this
feature. In the meantime, it would be useful if the WG came up with
"official" feedback on overloading the scheme name.
Best regards, Julian

Chris Weber

2012-01-16 06:55:27 UTC

Permalink

Post by Julian Reschke
I'm in the process of writing a Change Proposal asking for a removal
of this feature. In the meantime, it would be useful if the WG came up
with "official" feedback on overloading the scheme name.

<hat type="individual" />

Is this the first example of a scheme prefix like "web+" overloading the
scheme name? I'm not clear on the history, use cases, and the impetus
behind "web+". Generally speaking, it seems that a great deal of care
has been put into the registration process for scheme names, and that
the "web+" prefix sidesteps all of that, albeit limited to the prefix.

Surely there's good reason for due diligence in the scheme registration
process, right? And speaking as someone who does a lot of Web
application penetration testing, one of my first thoughts when I saw
this, with eyebrows raised really high, was 'let the fun begin'...

Best regards,
Chris Weber

Julian Reschke

2012-01-16 08:20:06 UTC

Permalink

Post by Chris Weber

<hat type="individual" />
Is this the first example of a scheme prefix like "web+" overloading the
scheme name? I'm not clear on the history, use cases, and the impetus

I think so, unless you count the "s" *post*fix (but that's more like a
convention).

That being said, similar problems were introduced by XHR for HTTP header
fields ("Sec-" prefix). See
<http://www.mnot.net/blog/2011/08/24/distributed_hungarian_notation_doesnt_work>.

Post by Chris Weber
...

Best regards, Julian

Martin J. Dürst

2012-01-20 10:52:48 UTC

Permalink

Post by Chris Weber

<hat type="individual" />
Is this the first example of a scheme prefix like "web+" overloading the
scheme name?

See Julian's reply.

Post by Chris Weber
I'm not clear on the history, use cases, and the impetus
behind "web+".

Have a look at the www-***@w3.org mailing list (archives at
http://lists.w3.org/Archives/Public/www-tag/), in particular at the
thread starting at
http://lists.w3.org/Archives/Public/www-tag/2012Jan/thread.html#msg28.

Post by Chris Weber
Generally speaking, it seems that a great deal of care
has been put into the registration process for scheme names, and that
the "web+" prefix sidesteps all of that, albeit limited to the prefix.

I don't think there is any intention to sidestep the registration
process. Future schemes, whether with or without the web+ prefix, would
still go though the same registration process.

Post by Chris Weber
Surely there's good reason for due diligence in the scheme registration
process, right? And speaking as someone who does a lot of Web
application penetration testing, one of my first thoughts when I saw
this, with eyebrows raised really high, was 'let the fun begin'...

Can you be a bit more specific about the dangers you see?

Regards, Martin.

Chris Weber

2012-01-30 22:39:19 UTC

Permalink

<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 1/20/2012 2:52 AM, "Martin J. Dürst" wrote:
<blockquote cite="mid:***@it.aoyama.ac.jp" type="cite">
Have a look at the <a class="moz-txt-link-abbreviated"
href="mailto:www-***@w3.org">www-***@w3.org</a> mailing list
(archives at <a class="moz-txt-link-freetext"
href="http://lists.w3.org/Archives/Public/www-tag/">http://lists.w3.org/Archives/Public/www-tag/</a>),

in particular at the thread starting at <a
class="moz-txt-link-freetext"
href="http://lists.w3.org/Archives/Public/www-tag/2012Jan/thread.html#msg28">http://lists.w3.org/Archives/Public/www-tag/2012Jan/thread.html#msg28</a>.
 
</blockquote>
<hat type="individual" /> 
 
Hi Martin, that was helpful, thanks. 
 
<blockquote cite="mid:***@it.aoyama.ac.jp" type="cite">
I don't think there is any intention to sidestep the registration
process. Future schemes, whether with or without the web+ prefix,
would still go though the same registration process. 
</blockquote>
 
I don't follow. The idea of web+ seems to be that it allows for an
infinite number of ad hoc scheme registrations - e.g. web+tweet,
web+like, web+mail. Are you saying those each need to go through
the registration process? 
 
<blockquote cite="mid:***@it.aoyama.ac.jp" type="cite">
Can you be a bit more specific about the dangers you see? 
</blockquote>
 
From a penetration testing perspective, it's a new attack vector
that could be abused or misused. A good bit of the threats have
been listed at <a
href="http://dev.w3.org/html5/spec/Overview.html#security-and-privacy">http://dev.w3.org/html5/spec/Overview.html#security-and-privacy</a>.
I can see others relating to cross-origin issues and User Interface
confusion. For Web-apps, there's potential for data exfiltration
depending on the use case and implementation details, so, it's not
so much a fault of the new prefix as much as how it might be naively
used. I made some test cases that are available online at <a
href="http://www.lookout.net/test/handler/">http://www.lookout.net/test/handler/</a>
and posted my results across 20 different areas to <a
href="http://web.lookout.net/2012/01/testing-registerprotocolhandler-and-web.html">http://web.lookout.net/2012/01/testing-registerprotocolhandler-and-web.html.</a> 
 
Best regards, 
Chris Weber 
 
 
 
</body>
</html>