You're doing some subtle jiu jitsu and extracting a lot of benefit from responding to the previous message as if it said "if the names are not known to the public, then[...]". It does not.
Resource identifiers, on the web[1], are not private names—not even by virtue of the fact they were communicated over a private channel—and they need to be treated as public, full stop. URLs are not private names, simply because of what they are.
> It makes no difference from a theoretical standpoint [...] whether the high-entropy value is sent to the server as part of the URL or via a header or via POST data.
It makes no difference from an information theoretic standpoint. There is no reason, however, to narrowly consider the information content and its entropy and declare that you are done. From an information architecture standpoint, there is a difference.
> But that's no different from, like, the need to not expose your cookies
It is different, for the reasons above.
(Every entropy-based cryptographic protocol also begins with observations how hard it is to do something in practice, and is then founded on exploiting those side effects. To describe a system and then wave away concerns that it is merely unfit "from a practical standpoint" makes it a failure of a design. It is fundamentally at odds with not just the evaluation criteria that protocols fit for use are measured against, but from which they are born.)
I'm not following your argument. What is this thing that URLs are which makes them public?
For instance, I could argue "Fingerprints are not passwords, and they need to be treated as public, because of what they are" - because I can finish that sentence with "and what they are is a pattern that's left on every single random thing you touch, and is also immutable and impossible to rotate."
It's almost certainly true that you do, you're just being dishonest. (The alternative is worse.)
> What is this thing that URLs are which makes them public?
You mean other than being identifiers (universal identifiers, at that)? It's like you've never used or encountered someone else articulating an argument that incorporates (or would be appropriate to incorporate) the phrase "by definition" before.
If your security protocols are compromised by the card catalog or the Rolodex being invented—compromised not by knowing the contents of a given resource, but by knowing the correct way to refer to or otherwise describe the identity of that resource—then you don't really have very good security in your protocols (particularly in a world where those things have already been invented).
> What's the analogous thing for URLs?
What? What a bizarre request.
The next time someone asks you to make your case in terms of bad analogies just because they can't get away from using them themselves, you can go ahead and say, "No, thanks. I'll pass."
I understand full well that you are claiming that URLs are public by definition. I am disputing that you are interpreting the definition correctly.
The invention of the card catalog and the Rolodex does not compromise anything, because the card catalog and the Rolodex simply catalogue information that is public, but in a poorly-accessible format. No card catalog can find the name of an unpublished, self-printed book that is sitting in my house. No Rolodex can determine the extension of the direct line at my work. Since I am claiming the URL in question is not public in the first place, I am claiming that it would not end up catalogued.
Can you explain, clearly, how this URL would end up catalogued? "By definition" is not an argument.
You're mixing up "public" with "published" (intentionally, perhaps).
> I am disputing that you are interpreting the definition correctly.
And I question whether you've actually made an attempt to grok the subject as a matter of definition, rather than substituting your synthesis (based on an experiential mental model of the subject derived from firsthand inference) in place of what URLs actually are actually supposed to be. (Meaning the playing dumb comment would be apropos here as well.)
> Can you explain, clearly, how this URL would end up catalogued?
The mechanics of how don't have to be explained, because that's how definitions work (whether you accept it or not). Explaining how is not a pre-requisite to what.
But if you're really dying for some missing insight, how about pausing to demonstrate some awareness of the catalyst of this tedious exchange: that a company that was founded on the basis related to cataloguing documents and their public identifiers is (shocker) doing that, right before doing things to/with them—and this has led to people who built up a model of the world similar to yours getting upset because the mistaken assumptions that went into building that model conflict with they're now being told is happening.
Resource identifiers, on the web[1], are not private names—not even by virtue of the fact they were communicated over a private channel—and they need to be treated as public, full stop. URLs are not private names, simply because of what they are.
> It makes no difference from a theoretical standpoint [...] whether the high-entropy value is sent to the server as part of the URL or via a header or via POST data.
It makes no difference from an information theoretic standpoint. There is no reason, however, to narrowly consider the information content and its entropy and declare that you are done. From an information architecture standpoint, there is a difference.
> But that's no different from, like, the need to not expose your cookies
It is different, for the reasons above.
(Every entropy-based cryptographic protocol also begins with observations how hard it is to do something in practice, and is then founded on exploiting those side effects. To describe a system and then wave away concerns that it is merely unfit "from a practical standpoint" makes it a failure of a design. It is fundamentally at odds with not just the evaluation criteria that protocols fit for use are measured against, but from which they are born.)