Re: ACTION-278 Hiding metadata for security reasons

On Sun, 2009-12-27 at 11:20 -0800, Tyler Close wrote:
[...]
> I think the current section 2.7 should be split into two new sections
> that correctly address the concerns raised in the current body text.
> The first would motivate:
> 
> Good Practice: URI assignment authorities SHOULD NOT put confidential
> metadata in a URI whose protocol does not support confidentiality.
> 
> The second section would motivate:
> 
> Good Practice: URI assignment authorities SHOULD identify a
> confidential resource using a URI whose protocol provides
> confidentiality.
> 
> Good Practice: URI assignment authorities SHOULD identify a
> confidential resource using an unguessable URI.

Yes, that's what I've been looking for recently.

I was a stick-in-the-mud about this for years, but I'm
now convinced that the unguessable URI pattern is as
secure as you like, and completely appropriate in lots
of cases.

I'm not sure when the lightbulb went off, but it was
sometime before our June meeting when Jonathan took
this action:

[[
DC: there is a style where URI is a capability 
... Tyler's analysis is that leaking of URIs is less of a problem than
phishing+cross-site request forgery

NM: so, advice in 2.7 of Metadata in URIs is still good advice?

JAR/DC: no, Tyler et al say this is bad advice!
]]
 -- http://www.w3.org/2001/tag/2009/06/23-minutes.html#item05



> I am happy to provide body text for these two new sections.

I'd like to see that.

I'm afraid the impact of this has ripples all over TAG writings;
e.g.

"The Web provides several mechanisms to control access to resources;
these mechanisms do not rely on hiding or suppressing URIs for those
resources. For more information, see the TAG finding "'Deep Linking' in
the World Wide Web"."
 -- http://www.w3.org/TR/webarch/#id-access
  -> http://www.w3.org/2001/tag/doc/deeplinking.html



-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Saturday, 23 January 2010 21:12:57 UTC