Re: [Uri-review] Updated 'javascript' scheme draft

[[
   The in-context evaluation operation necessitates extreme caution in
   deciding where resource identifiers using this scheme are recognized
   and permitted and what facilities are made available to script code,
   like access to private information and operations with side effects.
]]

I probably would have said something a bit stronger than that.
JavaScript URLs are a security disaster.  I wouldn't recommend their
use by anyone with a choice in the matter.  :)

Other than that, the document looks pretty good.  There are some
interesting questions w.r.t. whether leading whitespace is permitted
before JavaScript URLs found in HTML documents, but I think it's fine
to view that as a media type specific issue.

Adam


On Mon, Oct 4, 2010 at 9:17 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * Martin J. Dürst wrote:
>>[http://www.ietf.org/id/draft-hansen-iri-4395bis-irireg-00.txt]
>>[http://www.ietf.org/id/draft-hoehrmann-javascript-scheme-03.txt]
>
> A concern that Julian (and someone else offlist) voiced is that my draft
> talks about "resource identifier scheme", defining that by reference to
> RFC 3986 and RFC 3987, as there are only "URI schemes". The 4395bis
> draft validates my usage, doing the same thing, which I welcome.
>
> My draft does not include the registration template. That has a lead to
> some complaints, but my reading of RFC 4395 is that it is not required,
> and http://www.w3.org/mid/455CCAAD.2040407@att.com Tony Hansen confirmed
> that. The template is not currently used outside the specification when
> it is part of an RFC, and in my case it would just be a TOC for the do-
> cument; I think it should be clarified that it is not needed in this
> case.
>
> Both RFC 4395 and the bis draft attempt to regulate using among other
> things "/" in the scheme-specific part. In case of "javascript", it is
> common for people to write, say
>
>  javascript:open('http://example.org')
>
> or
>
>  javascript:'example'.match(/../)...
>
> which RFC 4395 says should be avoided. I do not think it's possible to
> convince authors to do that, and think the suggestions/requirements
> should be reconsidered. Right now my draft says percent-encoding the
> slash is encouraged, which also handles `javascript://...` cases where
> the first line would be interpreted as comment. There is some remote
> utility in that as you can actually get into cases where the javascript
> identifier will be used as a "base", but that's evil territory.
>
> That's all that comes to mind. I do hope to submit my draft to the IESG
> some time later this month; there have been no notable technical changes
> since I published the first draft four years ago.
> --
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
> 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>
>

Received on Tuesday, 5 October 2010 06:14:12 UTC