W3C home > Mailing lists > Public > www-tag@w3.org > November 2010

Re: mime-web-info 6.1 feedback

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Mon, 1 Nov 2010 11:45:09 -0600
To: Larry Masinter <masinter@adobe.com>
Cc: "www-tag@w3.org" <www-tag@w3.org>, Adam Barth <ietf@adambarth.com>
Message-Id: <20101101114509.9590ab26.eric@bisonsystems.net>
Larry Masinter wrote:
> I was thinking about this, and wonder if the issue is really around
> the security considerations for sniffing and privilege escalation...

I don't think so, or at least that wasn't my concern.  I think it's a
fundamental question of Web architecture:  where to draw the line
between user request and sender intent.  HTTP is stateless, so even if
the application type is known, the context of the request can't be (a
user-agent that's an HTML editor may be in design or preview mode; in a
browser I may right-click on an inline image and request that it be
opened sans markup in its own tab).  In Web architecture, what the user
requested is considered paramount.

So perhaps this is a matter of how to word the current section 3.1.
The definition of a media type can't declare sender intent which would
cause a user-agent to take perhaps exactly the opposite action from
that which the user requested.  If the line is drawn such that image/
jpeg stops at defining a codec without attempting to define that the
sender intends the image to be viewed inline, then the context of the
request doesn't matter -- as well it shouldn't.

Nothing else the document discusses, has anything to do with sender
intent which conflicts with what action the user requested.  IOW, all
other concerns are within scope of what a media type should do; but it
is out-of-scope for a media type to imply that sender intent outweighs
the user's requested action (as represented by browser configuration,
i.e. are PDFs rendered in-place, saved, or rendered in an external app
-- these things are for the user to decide, not the server to dictate).

I think allowing media type definitions to declare that a file should
always be downloaded, even if the user requests it to be rendered,
probably does open a whole can of security worms that's best left
unopened by clearly defining the limits of sender intent well short of
*how* the user-agent should process the payload.

Received on Monday, 1 November 2010 17:45:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:33:08 UTC