Re: http+aes URI scheme

On Thu, Mar 8, 2012 at 12:50 PM, Noah Mendelsohn <nrm@arcanedomain.com> wrote:
>
> On 3/8/2012 11:53 AM, Jonathan A Rees wrote:
>>
>> This idea should be cross-referenced with the thread that began here
>>
>> http://lists.w3.org/Archives/Public/www-tag/2009Dec/0122.html
>>
>> which never got resolved (basically whether 'secret URIs' are good
>> practice
>> vs. bad practice).
>
>
> I was thinking exactly the same thing, but hadn't taken the trouble to dig
> up the old thread.
>
> FWIW: I remain in the camp that chooses to believe that, except perhaps in
> very specific cases, asking user agents and network systems to protect (for
> whatever definition of "protect") either Request-URIs or hrefs found in
> links is probably a mistake. If it had been spelled out as a requirement on
> day 1, well maybe, but we have a lot of software already deployed that deals
> with Request-URIs, traffic logs, pages, with links, etc., and it seems late
> to be stating new requirements on managing those things securely.

Yes, this is what I was trying to say your position was - you think
URI-ness inherently confers unprotectability.

What is being asked, at least by Tyler (I don't know about those
advancing the new URI scheme) is not new requirements on old software,
which would of course be ridiculous (and you take him for a fool if
you think this is what he's saying), but requirements on new software
dealing with new URIs. So the recommendation is that if a tool or data
path is likely to leak a confidential URI, then be darn sure that the
confidential URI never comes in contact with that tool. Maybe that
means the URI would never occur in an @href, or as the target of an
HTTP request. But it could occur in other places.

There may be additional considerations governing the advisability of
using URIs for this purpose, but saying that URIs shouldn't ever be
required to be kept confidential because there are some situations in
which they won't be just isn't a valid argument. If it were, it would
apply equally to strings in general, and we know that it doesn't.

More helpful would be to agree with the tautology that a URI
containing privileged information needs to be kept confidential, and
then enumerate representative cases where a URI headed along a
particular data path will be protected, or won't be protected, for
some number of data paths. Clearly the paths you list can easily lead
to leaks, and maybe all familiar paths in a conventional web context
can lead to leaks, in which case that should be said. But there are,
or easiily could be, other paths that won't lead to leaks.

Jonathan

Received on Thursday, 8 March 2012 20:11:09 UTC