Hacker News Reader

Comment by empath-nirvana | Hacker News Reader

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.

View on HN

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.

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.

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.

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?

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?".

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

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.

> 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…) …

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.

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

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

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

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

You can if it's one link per user

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.

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?

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.

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.

Isn’t that basically a form of authentication?

I’m not sure if short lived temporary private links fit the model of private links as described above.

If that counts as a private link, what if I’m using a conventional session based app, I go into dev tools and “copy as curl”, does that qualify as a private link?

Yes it is. My point was more that it's a relatively lightweight way to create a shareable link that does not require the consumers to create a new account on the service hosting the linked resource in order to access it. At the same time, merely having access to the link doesn't really gain you anything, and so it is immune to the kind of issues discussed in the article

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

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.

Reply on news.ycombinator.com