- From: Jonathan A Rees <rees@mumble.net>
- Date: Tue, 23 Jun 2015 19:34:08 -0400
- To: capibara@xs4all.nl
- Cc: Noah Mendelsohn <nrm@arcanedomain.com>, "www-tag@w3.org" <www-tag@w3.org>
- Message-ID: <CAGnGFMJZJtc3ATs8AKNEcL0i6uOp13PMF0jfUbLU1jO16RvNvQ@mail.gmail.com>
Google Photos and the unguessable URL http://www.theverge.com/2015/6/23/8830977/google-photos-security-public-url-privacy-protected On Mon, Jun 9, 2014 at 7:10 AM, Rob Meijer <rmeijer@xs4all.nl> wrote: > On Mon, June 9, 2014 04:24, Noah Mendelsohn wrote: > > > > > > On 6/7/2014 10:22 PM, Jonathan A Rees wrote: > >> I don't think there's any point in discussing or even raising the > >> question of whether it's 'OK' to create unguessable URIs. > > > > > > On Sat, Jun 7, 2014 at 12:56 AM, Noah Mendelsohn <nrm@arcanedomain.com> > > wrote: > > > >> although there are cases where it is reasonable to gamble on having URLs > >> be kept secret, the Web is not in general designed to preserve such URL > >> secrecy. > > > > I don't see these two quotes, taken in isolation, as being in conflict > > with > > each other. I have never suggested that it's not "OK to create > unguessable > > URLs. I have suggested (and Rob obviously disagrees), that we should not > > expect the Web to then protect those URLs in ways that go much beyond > > what's already called for in normative specifications. > > > > Noah > > > > I don't disagree. I just believe that those normative specifications > combined with a good understanding of the security properties involved and > proper use of least authority based usage patterns, can combine to make > the use of sparse-caps the one with the lowest overall risk. > > There are issues with passwords, with cookies, with federated identity > management, with single granularity access control, etc, and yes there are > issues with capability URLs, at least in the way they are commonly > constructed and used. My problem currently lies in the fact that any > statement that effectively discourages the use of capability URLs, > implicitly encourages the techniques that have their own sets of issues. > > What I thus disagree with is what should be done with the 'conclusion' > that the use of capability URLs should NOT be the default. IMO the > 'proper' use of capability URLs removes more problems than it introduces. > My opinion thus is that its use SHOULD be the default, but I don't > advocate any such statement be put in the draft. I think the draft should > be about the 'proper' use of capability URLs, not about capabilities > versus ACL, passwords versus sparse-caps, IBAC vs ZBAC, etc. That is where > you propose to underline this 'conclusion', I propose to simply strike it > and declare any weighing of technologies that implicitly includes weighing > competing security architectural paradigms as 'out of scope'. > > > > >
Received on Tuesday, 23 June 2015 23:34:37 UTC