2 ms·
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 nee
by 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...>