Re: ACTION-278 Hiding metadata for security reasons

On Tue, Dec 29, 2009 at 5:14 PM, Jonathan Rees <jar@creativecommons.org> wrote:
> One thing puzzled me: The only really secure solution (against DNS
> attacks, MITM, and so on) is to put the unguessable part in the
> fragid. This would point directly at the webkeys approach. The google
> calendar case is something like
>
> http://www.google.com/calendar/hosted/creativecommons.org/embed?src=jonathan.rees%40gmail.com&ctz=America/New_York&pvttk=ebbb36156aaf108300c96ad196573f5d
>
> (The bits have been changed to protect the innocent.) Note (1) http
> not https, (2) unguessable portion before #, not after #.
>
> Do we endorse this kind of thing, tolerate it, or advise against it?
> Are any private URIs other than web-keys OK? I guess I was trying to
> hedge, which in retrospect was a bad idea.

The web-key <http://waterken.sf.net/web-key> convention of putting the
unguessable token in the URL fragment primarily guards against Referer
leakage, as John Kemp noted in his email. I think it's a good idea for
the TAG to recommend this convention, since designs like the one
above, or the Craigslist example in John's email, are brittle in the
face of maintenance. It's just too easy for someone to add an outbound
link to the page without thinking about the Referer header.

It's not feasible to recommend against putting the unguessable token
in another part of the URL, since even in the web-key design, the
token must appear in the Request-URI when actually fetching the data.
In the web-key paper, this is the second request in Figure 2:

http://waterken.sourceforge.net/web-key/#browser_how

As I've noted in that section, it is useful to recommend that the
unguessable token be placed in the query string of the Request-URI,
since some popular software already recognizes the query string as
potentially containing confidential information to be protected.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Tuesday, 5 January 2010 17:51:30 UTC