4 ms·

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 enoug

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.

cxr 3y ago
> 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.
ses1984 3y ago
You can’t revoke an individual user’s access to a hard to guess link.
- colecut 3y ago
  You can if it's one link per user
  - vel0city 3y ago
    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.
  - ses1984 3y ago
    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 3y ago
      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 3y ago
        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.
        ses1984 3y ago
        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?
        anonymousDan 3y ago
        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
kriops 3y ago
There is a big difference in how the browser treats the information, depending on how you provide it. Secrets in URLs leak more easily.
rfoo 3y ago
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 3y ago
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 3y ago
  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 3y ago
    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 3y ago
      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?".
LaGrange 3y ago
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.
nkrisc 3y ago
There’s a big difference. The latter requires information not contained in the URL to access the information.
- ironmagma 3y ago
  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.
- deathanatos 3y ago
  > Here's the URL to the thing: https://example.com/a/url?secret=hunter2 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 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…) …
  - nkrisc 3y ago
    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.
  - pests 3y ago
    Right, but you settled on the answer as well. You must communicate the password via a different medium, which is impossible with links.
OtherShrezzing 3y ago
There's at least one critical functional difference: The URL stays in the browser's history after it's been visited.

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.

cxr 3y ago

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

ses1984 3y ago

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

colecut 3y ago
You can if it's one link per user
- vel0city 3y ago
  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.
- ses1984 3y ago
  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 3y ago
    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 3y ago
      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.
      - ses1984 3y ago
        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?
        anonymousDan 3y ago
        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

kriops 3y ago

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

rfoo 3y ago

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 3y ago

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 3y ago
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 3y ago
  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 3y ago
    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?".

LaGrange 3y ago

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.

nkrisc 3y ago

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

ironmagma 3y ago
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.
deathanatos 3y ago
> Here's the URL to the thing: https://example.com/a/url?secret=hunter2 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 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…) …
- nkrisc 3y ago
  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.
- pests 3y ago
  Right, but you settled on the answer as well. You must communicate the password via a different medium, which is impossible with links.

OtherShrezzing 3y ago

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