[mikepurvis]

Bit of a tangent, but I was recently advised by a consultant that pushing private Nix closures to a publicly-accessible S3 bucket was fine since each NAR file has a giant hash in the name. I didn't feel comfortable with it so we ended up going a different route, but I've continued to think about that since how different is it really to have the "secret" be in the URL vs in a token you submit as part of the request for the URL?

And I think for me it comes down to the fact that the tokens can be issued on a per-customer basis, and access logs can be monitored to watch for suspicious behaviour and revoke accordingly.

Also, as others have mentioned, there's just a different mindset around how much it matters that the list of names of files be kept a secret. On the scale of things Amazon might randomly screw up, accidentally listing the filenames sitting in your public bucket sounds pretty low on the priority list since 99% of their users wouldn't care.

[radlad]

> how different is it really to have the "secret" be in the URL vs in a token you submit as part of the request for the URL?

I'm not sure I grok this. Do you mean, for example, sending a token in the POST body, or as a cookie / other header?

One disadvantage to having a secret in the URL, versus in a header or body, is that it can appear in web service logs, unless you use a URI fragment. Even then, the URL is visible to the user, and will live in their history and URL bar - from which they may copy and paste it elsewhere.

[mikepurvis]

In this case it's package archives, so they're never accessed from a browser, only from the Nix daemon for binary substitution [1]: https://nixos.wiki/wiki/Binary_Cache

[nmadden]

I wrote about putting secrets in URLs a few years ago: https://neilmadden.blog/2019/01/16/can-you-ever-safely-inclu...

[Sn0wCoder]

Question in the Waterken-Key flow with token in the URL fragment the URL looks like HTTPS www.example.com/APP/#mhbqcmmva5ja3 – but in the diagram its hitting example.com/API/#mhbqcmmva5ja3 Is this a type-o OR are we mapping APP to API with the proxy so the user thinks they are going to the APP with their Key. Or does the browser do us for us automatically when it sees app in the URL and then stores the key in window.location.hash. I am confused and might just find the answer on Google but since you appear to be the author maybe you can answer the question here.

[nmadden]

Oops, that’s a typo.

[cxr]

> I've continued to think about that since how different is it really to have the "secret" be in the URL vs in a token you submit as part of the request for the URL

Extremely different. The former depends on the existence of a contract about URL privacy (not to mention third parties actually adhering to it) when no such contract exists. Any design for an auth/auth mechanism that depends on private links is inherently broken. The very phrase "private link" is an oxymoron.

> I am not sure why you think that having an obscure URI format will somehow give you a secure call (whatever that means). Identifiers are public information.

<https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...>