[go: up one dir, main page]

Re: ACTION-278 Hiding metadata for security reasons

I've been giving this proposal some thought, and I'm not sure I buy the 
premise.  In particular:

> In special circumstances where URIs are adequately protected 
> for the application in question

> [...]

> 3. the URI is confined to secure data paths

Going down this path seems to divide the Web.  It suggests that there is 
the wild and wooly main part of the Web, in which URIs wind up in all 
sorts of places like logs, in memory in proxies, or in links get passed 
around in emails, etc.  The above suggests that there are also other 
Web-like networks, built of the same technology, but much more private. 
The suggestion is that there are little private Webs in which it is 
possible to bound the places where a particular URI may wind up.  I think 
this is what you mean by URIs that are "adequately protected for the 
application in question."

No doubt, it is possible to use technologies such as URIs and HTTPs to 
implement such protected networks.  Trivially, I could set up a one-hop 
network with air-gap isolation from all other networks, control both ends 
and run HTTP over that.  I don't think that the result is "the Web", the 
architecture of which the TAG attempts to describe.  It's a network in 
which linking is discouraged rather than encouraged.

In short, I'm tempted to stay away from the notion of protecting URIs.  It 
was certainly my premise as editor of the original metadata in URI finding 
that URIs were presumed to be unprotected.  I.e., it was assumed that in 
normal use on the Web, any URI may well be discovered by users or software 
not controlled by or associated with some particular application or 
security domain.  Furthermore, it's assumed that malicious software, and 
perhaps even just creative Web spiders, can synthesize and attempt to 
access URIs that are similar, but not identical to ones that are 
encountered in other Web traffic.  I'm so far unconvinced to change the 
finding.

Maybe I need to understand the Google calendar case a bit better than I 
do. 

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Jonathan Rees <jar@creativecommons.org>
Sent by: www-tag-request@w3.org
12/27/2009 11:46 AM
 
        To:     www-tag@w3.org
        cc:     Tyler Close <tyler.close@gmail.com>, "Mark S. Miller" 
<erights@google.com>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        ACTION-278 Hiding metadata for security reasons


Regarding ACTION-278, here is preliminary draft text to add to the end
of section
2.7 "Hiding metadata for security reasons" of TAG finding "The use of
Metadata in URIs" [2]

Criticism welcome; I'm expecting I'll have to substantially revise in
the face of
the wisdom to be precipitated.

<snip>

In special circumstances where URIs are adequately protected for the
application in question, it may be safe to create URIs that carry
sensitive metadata.  Most risks associated with metadata payloads are
avoided when the following rules are respected:
1. the URI conveys only specific, limited knowledge or authority
2. the URI protects the information it carries by a level of
   obfuscation such as encryption and/or indirection via a random key
3. the URI is confined to secure data paths
4. the URI is restricted to a single use and/or is valid only during a 
limited
   lifetime

For example, a calendar system may provide an option to share a
calendar with another user.  The access right may be designated by a
unguessable URI that can be sent to the other user, who on applying it
obtains read access in a coordinating mail application to the first
user's mailbox.

Adequacy of data path security is difficult to assess and great care
should be exercised in using this pattern.  The calendar case works
because the URI in question has special use contexts (it is not likely
that is will be used for general browsing or bookmarking), it conveys
limited authority (read access to one calendar, not login access to an
email account), email and HTTP connections are assumed to be
sufficiently private, and the providing and consuming applications
both take steps to minimize disclosure risks.

</snip>

Best
Jonathan

[1] http://www.w3.org/2001/tag/group/track/actions/278
[2] http://www.w3.org/2001/tag/doc/metaDataInURI-31#hideforsecurity

Received on Tuesday, 19 January 2010 03:21:48 UTC