4 ms·

> read some feed containing something relatively private, guess what, they're reading it too Everyone needs to accept the fact there's no such thing as a priva

by cxr 2y ago

> read some feed containing something relatively private, guess what, they're reading it too Everyone needs to accept the fact there's no such thing as a private URL. There are URLs that can be originally communicated to you privately—through a private channel, that is—but insisting on holding onto some (wrong) belief that we can or should be able to mint URLs that themselves possess some "private" quality goes against the fundamental design of the Web and what a URL even is. (Yes, this does mean that every podcaster that implements subscriptions by giving one feed URL to free listeners and having listeners who pay for premium content use a different URL is fundamentally broken. Yes, this does mean that that big engineering organization that implemented file uploads and read/write access through slugs consisting of unguessable 128+ bit tokens is also wrong.)

vilhelm_s 2y ago
The issue is that the company can track what you are reading.
- magicalhippo 2y ago
  Unless there's an explicit reason not to, you should indeed assume that men in the middle will look at what you pass by them. Then you have to decide for yourself if you're OK with that or not. I know Microsoft looks at my files when I put them on my OneDrive. I take that into account when I decide what to put there. I know Google reads my mail when Thunderbird sends it through their SMTP servers. I know it'll be read by some unknown parties along the way to the recipient. I take that into account when I write my mail. If I pasted a URL into a feed reader, I'd most certainly assume the app, and by extension its creators, would access that URL and read what's there. I'd take that into account when using the app.
  - vilhelm_s 2y ago
    She didn't think there would be anyone in the middle! She expected the app to access the URL, and it did, but she didn't expect it to also send a copy to its creators. Like, what if you discovered that each time you send an email, Thunderbird also sends the email address you were writing to to a server owned by Mozilla?
    - magicalhippo 2y ago
      > Like, what if you discovered that each time you send an email, Thunderbird also sends the email address you were writing to to a server owned by Mozilla? Then I wouldn't be surprised. I haven't read Thunderbirds privacy policy in detail, so for all I know there's a clause about collecting email addresses in there. Could even be for a good reason, spam filtering for example. And as mentioned I take that into account when writing emails. I do indeed avoid writing certain stuff and avoid sending certain mails due to privacy. For the rest I see it as an acceptable risk/reward tradeoff. I'm not a tinfoil hat kinda guy, but the innocence is gone when it comes to modern software.
paulddraper 2y ago
URLs are just as private as passwords. In, fact URLs by design explicitly supported passwords.
- pixl97 2y ago
  Of which as bit so many people in the ass so many times that anyone with any security sense will tell you "Don't do that". There are just too many ways URLs leak because there is little difference between security context with users.
miki123211 2y ago
Nothing is ever truly 100% private, but certain things are "private enough". A password can be leaked just as well as any URL, particularly if the password needs to be periodically sent to a downstream server to do the feed polling, and hence stored in plaintext. URLs generally have less protection than a password because that's how we design a lot of our systems (and this is a property of our systems and not of the URLs themselves), but the protection they do have is often enough. You protect podcast feeds for revenue, not privacy. The negligible loss of revenue you're going to experience if somebody hacks into a feed reader isn't worth inventing a new protocol. You need to protect against abusive sharing of URLs by authorized users anyway, usually by having a system that forces the url to be re-generated when it's getting too many visits, so if one of these databases becomes fully public, the problem is already solved anyway.
- cxr 2y ago
  > URLs generally have less protection than a password That's an understatement. Passwords are supposed to be private by design. URLs are not. > because that's how we design a lot of our systems (and this is a property of our systems and not of the URLs themselves) That's simply not true. URLs don't have protection because the notion of a private URL is a flat-out contradiction. As I said before: it goes against the fundamental design of the Web. URLs are not in any sense designed to be private. Like, at all. If anything, they are designed not to be private. URLs are by their nature public information[1]. Anyone who believes or wishes otherwise is someone who believes or wishes that the Web is something other than the thing actually proposed, designed, and implemented. Anyone can, at their own peril, try to devise other higher-level systems that exploit implementation details and other incidentals in non-normative ways while trying to justify it on the basis that it jibes with what you have observed in practice. You are also free to design a content-protection scheme that hinges on the whitespace in the client request varying just so, or where the HTTP heADEr naMEs follow a suPEr seCREt caPITALIZATIOn coNVENTIOn, etc. But no one else has any obligation to conform to the expectations necessarily prescribed by those lame designs nor to commit themselves to any action/inaction implied. "Leaking URLs" is a non-offense. 1. <https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-806 https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...>

by cxr 2y ago

vilhelm_s 2y ago

The issue is that the company can track what you are reading.

magicalhippo 2y ago
Unless there's an explicit reason not to, you should indeed assume that men in the middle will look at what you pass by them. Then you have to decide for yourself if you're OK with that or not. I know Microsoft looks at my files when I put them on my OneDrive. I take that into account when I decide what to put there. I know Google reads my mail when Thunderbird sends it through their SMTP servers. I know it'll be read by some unknown parties along the way to the recipient. I take that into account when I write my mail. If I pasted a URL into a feed reader, I'd most certainly assume the app, and by extension its creators, would access that URL and read what's there. I'd take that into account when using the app.
- vilhelm_s 2y ago
  She didn't think there would be anyone in the middle! She expected the app to access the URL, and it did, but she didn't expect it to also send a copy to its creators. Like, what if you discovered that each time you send an email, Thunderbird also sends the email address you were writing to to a server owned by Mozilla?
  - magicalhippo 2y ago
    > Like, what if you discovered that each time you send an email, Thunderbird also sends the email address you were writing to to a server owned by Mozilla? Then I wouldn't be surprised. I haven't read Thunderbirds privacy policy in detail, so for all I know there's a clause about collecting email addresses in there. Could even be for a good reason, spam filtering for example. And as mentioned I take that into account when writing emails. I do indeed avoid writing certain stuff and avoid sending certain mails due to privacy. For the rest I see it as an acceptable risk/reward tradeoff. I'm not a tinfoil hat kinda guy, but the innocence is gone when it comes to modern software.

paulddraper 2y ago

URLs are just as private as passwords. In, fact URLs by design explicitly supported passwords.

pixl97 2y ago
Of which as bit so many people in the ass so many times that anyone with any security sense will tell you "Don't do that". There are just too many ways URLs leak because there is little difference between security context with users.

miki123211 2y ago

Nothing is ever truly 100% private, but certain things are "private enough". A password can be leaked just as well as any URL, particularly if the password needs to be periodically sent to a downstream server to do the feed polling, and hence stored in plaintext. URLs generally have less protection than a password because that's how we design a lot of our systems (and this is a property of our systems and not of the URLs themselves), but the protection they do have is often enough. You protect podcast feeds for revenue, not privacy. The negligible loss of revenue you're going to experience if somebody hacks into a feed reader isn't worth inventing a new protocol. You need to protect against abusive sharing of URLs by authorized users anyway, usually by having a system that forces the url to be re-generated when it's getting too many visits, so if one of these databases becomes fully public, the problem is already solved anyway.

cxr 2y ago
> URLs generally have less protection than a password That's an understatement. Passwords are supposed to be private by design. URLs are not. > because that's how we design a lot of our systems (and this is a property of our systems and not of the URLs themselves) That's simply not true. URLs don't have protection because the notion of a private URL is a flat-out contradiction. As I said before: it goes against the fundamental design of the Web. URLs are not in any sense designed to be private. Like, at all. If anything, they are designed not to be private. URLs are by their nature public information[1]. Anyone who believes or wishes otherwise is someone who believes or wishes that the Web is something other than the thing actually proposed, designed, and implemented. Anyone can, at their own peril, try to devise other higher-level systems that exploit implementation details and other incidentals in non-normative ways while trying to justify it on the basis that it jibes with what you have observed in practice. You are also free to design a content-protection scheme that hinges on the whitespace in the client request varying just so, or where the HTTP heADEr naMEs follow a suPEr seCREt caPITALIZATIOn coNVENTIOn, etc. But no one else has any obligation to conform to the expectations necessarily prescribed by those lame designs nor to commit themselves to any action/inaction implied. "Leaking URLs" is a non-offense. 1. <https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven#comment-806 https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...>