[QuercusMax]

I've always been a bit suspicious of infinite-use "private" links. It's just security thru obscurity. At least when you share a Google doc or something there's an option that explicitly says "anyone with the URL can access this".

Any systems I've built that need this type of thing have used Signed URLs with a short lifetime - usually only a few minutes. And the URLs are generally an implementation detail that's not directly shown to the user (although they can probably see them in the browser debug view).

[empath-nirvana]

There's functionally no difference between a private link and a link protected by a username and password or an api key, as long as the key space is large enough.

[rfoo]

Most of developers are aware that username or password are PII and if they log it they are likely to get fired.

Meanwhile our HTTP servers happily log every URI it received in access logs. Oh, and if you ever send a link in non E2EE messenger it's likely their server generated the link preview for you.

[vel0city]

There's one big functional difference. People don't normally have their username and password or API key directly in the URL.

Example 1:

Alice wants Bob to see CoolDocument. Alice generates a URL that has the snowflake in the URL and gives it to Bob. Eve manages to see the chat, and can now access the document.

Example 2:

Alice wants Bob to see CoolDocument. Alice clicks "Share with Bob" in the app, grabs the URL to the document with no authentication encoded within and sends it to Bob. Bob clicks the link, is prompted to login, Bob sees the document. Eve manages to see the chat, follows the link, but is unable to login and thus cannot see the document.

Later, Alice wants to revoke Bob's access to the document. Lots of platforms don't offer great tools to revoke individual generated share URLs, so it can be challenging to revoke Bob's access without potentially cutting off other people's access in Example 1, as that link might have been shared with multiple people. In example 2, Alice just removes Bob's access to the doucment and now his login doesn't have permissions to see it. Granted, better link management tools could sovle this, but it often seems like these snowflake systems don't really expose a lot of control over multiple share links.

[Dylan16807]

Example 2 sounds like a pretty big pain if I can't go directly from Bob's chat account to his document account. Which is the case the vast majority of the time.

[vel0city]

And yet somehow you managed to log in to this site to post this comment here despite needing to log in. Crazy huh, I would have thought it would have been a pretty big pain.

Or are you saying its a pain for you, Eve, not being able to see Bob's documents so easily?

[Dylan16807]

The problem isn't logging in. It's trying to figure out what account to share access to. For a pretty straightforward analogy, I have never had to figure out somebody's steam handle in order to reply to them on HN.

And when I'm replying to someone on HN, I never have to worry "do they have an HN account already?".

[nkrisc]

There’s a big difference. The latter requires information not contained in the URL to access the information.

[deathanatos]

> Here's the URL to the thing: https://example.com/a/url?secret=hunter2

This is indexable by search engines.

> Here's the URL to the thing: https://example.com/a/url and the password is "hunter2".

This is indexable by search engines.

Yes, the latter is marginally harder, but you're still leaning on security through obscurity, here.

The number of times I have had "we need to securely transmit this data!" end with exactly or something equivalent to emailing an encrypted ZIP with the password in the body of the email (or sometimes, some other insecure channel…) …

[pests]

Right, but you settled on the answer as well. You must communicate the password via a different medium, which is impossible with links.

[nkrisc]

Sure if you’re comparing worst case of one to best case of the other it’s functionally similar, but if the password is strong and handled properly then they are not functionally similar at all.

[ironmagma]

That's not a fundamental difference but a difference of convention. A lot of us have been in the convention long enough that it seems like a fundamental.

[kriops]

There is a big difference in how the browser treats the information, depending on how you provide it. Secrets in URLs leak more easily.

[OtherShrezzing]

There's at least one critical functional difference: The URL stays in the browser's history after it's been visited.

[ses1984]

You can’t revoke an individual user’s access to a hard to guess link.

[colecut]

You can if it's one link per user

[ses1984]

True but if you’re generating one link per user, at what point do you lift up your head and wonder if it wouldn’t be easier to just use authentication?

[jddj]

The friction that semi-private links remove is that the recipient doesn't need an account for your service.

Any tradeoffs should be viewed in that context.

[anonymousDan]

I like how google docs does it. You can specify the email of a user allowed to access the link (doesn't need to be gmail). When they click it they will be told to check for a validation email containing a link to the actual document.

[vel0city]

Lots of platforms I've used with these public share links don't really support multiple share links, and if they do the management of it is pretty miserable. Clicking share multiple times just gives the same link.

[cxr]

> There's functionally no difference between a private link and a link protected by a username and password or an api key

You mean mathematically there is no difference. Functionally there is a very, very big difference.

[LaGrange]

I mean, there's a functional difference if your email client will try to protect you by submitting the URL to a public database. Which is incredible and mind-boggling, but also apparently the world we live in.

[voiper1]

>At least when you share a Google doc or something there's an option that explicitly says "anyone with the URL can access this".

Unfortunately, it's based on the document ID, so you can't re-enable access with a new URL.

[nightpool]

Not true, as you may have heard they closed this loophole in 2021 by adding a "resource key" (that can be rotated) to every shared URL: https://9to5google.com/2021/07/28/google-drive-security-upda....