Re: Comments on "Good Practices for Capability URLs" FPWD

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'.
>
>
>
>
>