Re: Are *relative* URIs as namespace nemes considered harmful?

To compare software which uses relative URIs to one which cannot distinguish
between safe image attachments and potentially destructive programming
languages is, if you ask me, getting extreme!  The interpretation of a
relative URI is trivial and
it is handled in billions of images in millions of web page every day.  This
is not new technology. To forbid it would be new. If there was a hack which
allowed a browser to be confused and images replaced I think we would have
seen it by now!  Please, if you can think of a scenario in which things can
be broken by a third party then please elaborate it.

(Compare this with the current suggestion that URIs be allowed to be
relative but compared as strings,
which is technically broken but that is another thread.)

Tim

-----Original Message-----
From: Michael Champion <Mike.Champion@SoftwareAG-USA.com>
To: xml-uri@w3.org <xml-uri@w3.org>
Date: Monday, May 15, 2000 5:55 PM
Subject: Re: Are *relative* URIs as namespace nemes considered harmful?


>
>----- Original Message -----
>From: "Tim Berners-Lee" <timbl@w3.org>
>To: "Michael Champion" <Mike.Champion@softwareag-usa.com>; <xml-uri@w3.org>
>Sent: Monday, May 15, 2000 4:50 PM
>Subject: Are *relative* URIs as namespace nemes considered harmful?
>
>>
>> The difficult bit is that you have to store the base URI with any
>document,
>> and you have to give an error when you absolutely need to absolutize a
>> relative URI and you have no base address. Note that the URI spec says
>there
>> should always be some a base address - in unix for example the file in
the
>> current directory if there are just a bunch of files.
>
>Right.  As Simon St. Laurent points out, XML Base will add yet another
>interesting twist here. It's easy in the static web page environment, but
>figuring out what the base URI in a document that is not "stored", but
>generated from an interesting combination of database queries, data
>transformations, template files, etc. can be non-trivial.
>
>>
>> I am always suspicious of the argument that you are giving users enough
>rope
>> to hang themselves.  When the designer knows better than the user then
>alarm
>> bells go off.
>
>Clearly this is a rather deep question about which reasonable people can
>disagree.  I guess many of us see the dark side of unfettered user
>creativity all too clearly.  Look at MS Outlook and the Windows Scripting
>Host; clearly its designers shared this philosophy and made didn't try to
>inhibit their users' ability to creatively write dynamic message content
...
>but made it easy for malicious people to create havoc. In retrospect I'd
>rather have had my creativity curtailed by a know-it-all designer than have
>endured the chaos of a couple of weeks ago!
>
>Or read David Megginson's XTech 2000 "When XML turns ugly" address for some
>examples closer to home as to how intruders/vandals might exploit some of
>the features of XML to raise hell when XML becomes more deeply rooted in
the
>Web infrastructure.  The message I took from it is to be VERY careful about
>opening up security holes whereby one object or resource masquerades as
>another ... and that is EXACTLY the kind of mechanism we're discussing
here.
>
>If, for the sake of argument, we don't restrict XML users' creativity and
>someone figures out how to crash the (hypothetical) worldwide XML B2B
>network via a hacked relative namespace URI, it's Tim Berners-Lee who's
>gonna be hauled before Congress to explain why all those nice campaign
>contributors lost all those billions of dollars <grin>.  I can't come up
>with a plausible scenario for this, but I think it illustrates the kind of
>paranoid mindset we have to take when considering the implications of
>decisions made about the infrastructure of the Web.
>

Received on Tuesday, 16 May 2000 19:25:04 UTC