W3C home > Mailing lists > Public > www-tag@w3.org > October 2006

[metadataInURI-31] Update on Use of Metadata in URIs Draft

From: <noah_mendelsohn@us.ibm.com>
Date: Mon, 23 Oct 2006 10:20:50 -0400
To: www-tag@w3.org
Message-ID: <OF4E39E3D5.766107C9-ON85257210.004A5377-85257210.004ED204@lotus.com>
I have an action to update the last section of the metadataInURI draft.  I 
am well along in doing the editing, but somewhat behind where I'd hoped to 
be.  Specifically, it should be clear that I have blown the due date of 
Oct. 20.   I will be traveling from this afternoon thru Thursday.  With 
luck, I'll find time to wrap things up while I'm on the road, but failing 
that probably while I'm on the plane to the Schema meeting next Sunday. 
Note that I have already sent probable regrets for tomorrow's call (and 
for next week's).  I'll get the draft out as soon as I can, and we can 
figure out when to discuss once I do.

I would appreciate it if other concerned TAG members would doublecheck 
whether I've correctly heard the instructions from Vancouver [1]. 
Honestly, I still am having some trouble convincing myself that the story 
we told there (I.e. the one you asked me to tell in the finding) is 
entirely about URIs.  The story in a nutshell:

"Bob sees image on screen, right clicks to save, winds up with executable, 
is unhappy."

I think the implied markup is along the lines of:

Variant 1:

<a href="http://malicious.example.com/image.exe"> 
  <img src="http://malicious.example.com/image.jpg">

though the inner URI suffix doesn't seem to matter too much, as it's 
unlikely to be shown to the user or used as a point of type inference by 
the browser's rendering logic.   Am I thinking right about the markup you 
have in mind?  If so, then I think the confusion is mainly about the 
existence of two URIs, and only secondarily about their suffixes or 
metadata.  I think Bob would be at least as confused if we had:

Variant 2:

<a href="http://malicious.example.com/image1">  <!-- served as executable 
mime type -->
  <img src="http://malicious.example.com/image2">  <!-- served as 
image/jpeg -->

He'd still be looking at an image, still right mouse, and if the browser 
honored the media type would wind up with an executable, perhaps with a 
filename ending in .exe.

The only place URI confusion seems to come in is if we additionally assume 
a browser that, in violation of Web architecture (though in keeping with 
all too common practice), blindly preserves the URI suffix when writing to 
the OS filesystem.  Even in that case, the chances that Bob knows 
something is wrong are a bit higher in Variant 1, because he might see the 
.exe in the URI being saved and might guess that his browser violates Web 
architecture by honoring the URI suffix in preference to the media type. 
In either variant, Bob can: "see image, right click, save, be unhappy". 
That seems to show that URI metadata is a secondary, not primary issue 
here.  The main reason I see that URI metadata matters is the happenstance 
that there aren't ubiquitously deployed media/type conventions for serving 
executables to certain platforms, so using the .exe suffix may be needed 
to trick the browser into saving as executable.  I'm assuming the story 
you want me to tell is grounded in that whole messy combination of 
interacting factors, which together lead to Bob unexpectedly saving an 
executable when he thought he was saving an image.

Notwithstanding the above questions, I'm well along in telling a simple 
overall story about confusion regarding URI suffixes, about filesystems 
and their use of filename suffixes etc.  Indeed, I have a writeup that 
tells the story of variant 1, concluding: 

"Note that some of the confusion in these examples arises merely from the 
distinction between the image resource shown on the screen, and the 
content linked from the anchor that includes the image;  the confusion is 
potentially compounded by the tendency of users, browsers, and operating 
systems, each in their own way, to infer type information from URI and/or 
filename suffixes."

I just wanted to doublecheck that this is indeed the story you were asking 
me to tell.  You probably saw in Vancouver that I was having some trouble 
internalizing it, and to some extent still am.   My confusion arises, I 
think (a) from not noticing at first that the story involves two URIs, one 
for the rendered image and one for the anchor; and (b) because it's not 
clear that confusion about URI metadata is the fundamental problem in this 
case, as illustrated in variant 2.  Am I again missing something?  If not, 
I'll wrap it up in draft form and circulate ASAP.  Thank you.

Thank you.


[1] http://www.w3.org/2001/tag/2006/10/04-tagmem-minutes#item02

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
Received on Monday, 23 October 2006 14:21:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:13 UTC