W3C home > Mailing lists > Public > uri@w3.org > November 2006

Re: The 'javascript' scheme

From: Frank Ellermann <nobody@xyzzy.claranet.de>
Date: Sat, 04 Nov 2006 22:25:24 +0100
To: uri@w3.org
Message-ID: <454D0543.743@xyzzy.claranet.de>
Cc: uri-review@ietf.org

Bjoern Hoehrmann wrote:

> I think these are all either out of scope, widely known, or trivial.
> For example, your last point amounts to saying that not all
> applications implement the scheme--that is true for all schemes.
> I would rather have the document as clear and concise as possible.

Above all it must be clear and concise that javascript URIs belong
into the "worse" department of "bad ideas", maybe you find a better
way to express this.

Finding serious references, WAI etc., to support this point, should
be possible.  I just listed a few obvious, or as you say trivial,
issues with this scheme.

> I expect http://www.w3.org/TR/WCAG20-SCRIPT-TECHS/ to give advise
> here as that document matures.

I don't expect that anybody will read huge documents, 500 KB and
more, about accessibilty, so that won't do.  If all fails there's

 [encoding considerations]
> Could you be more specific what is unclear?

Which characters must be percent-encoded (based on RFC 3986), which
should not be percent-encoded (based on whatever user agent you pick
to check this), and what about the conflicts, if there are any.

More examples, in addition to the "#" case.  Would %23 work, and if
not, what does that say about the scheme ?

> The draft fully defines whether any given resource identifier
> conforms to it; the list of legal characters is implied by this
> definition, so I don't see any actual need to include it.

I haven't found it, sorry.  Can I use say "<" in an expression ?
Can I use %3C ?  With javascript:1<2 as "location" I get true, is
that as it should be ?

>> In the security considerations you say that it's the _same_
>> issue as for the data: scheme.  IMNSHO this hand waving is not
>> appropriate.

> For all I can tell, as established in the draft, they are equivalent.
> This has precise implications, I would not consider this handwaving
> in any way. What would you have me say instead?

More about why script URIs can be dangerous.  Bypassing spam and
phishing filters, manipulate the behaviour of the UA, the works.
Maybe you could copy the relevant part of 2397 and build on that.

> The intended status is given in the IANA considerations section;
> the scheme is in common use, and I do not think there is any kind
> of consensus that the scheme should not be used, as such
> 'historical' would be inappropriate.

Oops, yes, you write "permanent".  For that the requirements wrt
"security considerations" and vulnerabilities might be higher, or
rather that's my interpretation of chapter 7 in RFC 4395.

> the change controller matters only for provisional registrations

Maybe you can write "n/a" or "IETF" in a template contained in an
I-D approved by the IESG.  If you don't want the template to be
published together with the RFC maybe you can say that it should
be removed during the publication after IANA copied/registered it.

> the question is, do I absolutely have to include "No character
> is reserved" in the document.

How about a line of ABNF, something like:

    javascriptURI = "javascript:" *pchar

Obviously no reserved character.  And folks would also know that
they have to percent-encode anything that's not directly allowed.
I can't tell from your text if that's really the idea.

>> You should discuss favlets / bookmarklets, that's the only case
>> I'm aware of where this scheme is sometimes useful, folks can
>> copy code by bookmarking it.

> If you could suggest how to do this without making the Introduction
> longer, that would be great.

You can say that javascript: URLs should never be used for anything
related to navigation, copy text from WCAG 1.0.  After that explain
what a favelet / bookmarklet is, and how javascript URIs allow to
"bookmark" favelets, and execute them later on other pages.  See my
crude description on the page mentioned before.

This application is the only justification to register this scheme
at all, otherwise I'd propose to ignore it as harmful.  As soon as
it's registered folks will claim that it's a good "official" scheme
and multiply their efforts to abuse it (my crystal ball says).

Received on Saturday, 4 November 2006 21:35:21 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:49 UTC