Hacker News Reader

Comment by SilasX | Hacker News Reader

Semi-related: there was some quirk with Amazon S3 where you could designate a resource as open to the world, but it would still reject anyone that submitted (unnecessary) authentication credentials as part of the request.

View on HN

Their thinking there was actually good UX, in a way.

A misconfigured world-open resource is a huge security risk, but world-open resources have valid use cases. The only signal Amazon has that somebody might have misconfigured a resource to be world-open is if somebody tries to access it with authentication credentials, so they decided to interpret that configuration as "hey user, did you really intend for this to be world-open?"

People really like Postel's law, which is basically "don't reject anything you don't understand". But the robustness comes at the cost of correctness and security. Sometimes it's good to trade in some robustness/reliability against malfunctioning clients for security against mistakes.

Hadn't seen that law before. Absolutely hate it. The harm from poor input invalidation over time is massive.

You have to think about Postel's law in terms of protocols and mistakes in your implementation. You assume your implementation isn't perfect and neither is the other. Do your best to be perfect and if you get something that isn't quite right, do your best to handle it well. That doesn't mean you don't validate inputs, it means that if data should come with a \n but instead comes with \n\r, you should treat it as a \n.

I think you miss their point which is that has led to a large number of security bugs. Because it is then path to exploits and sloppiness which then cannot be corrected because of backward compatibility or such.

Anyone else remember the time, years ago, when someone introduced a new performance feature to TCP, using an otherwise-unused bit in the header. Unfortunately, rolling it out turned into a giant clusterfuck because many routers on the internet interpreted "this bit is unused" as "this bit will always be zero"?

Ah yes, the fyranny of the middlebox.

Postel's Law isn't why we can't correct errors for backwards compatibility reasons.

We can't correct those because backwards compatibility is necessary to creating a global network that lasts decades. It's the railway effect... One simply can't expect every player to update their architecture religiously because they can't afford to, therefore what is made public tends to stick around for ages, and anything that fails to recognize that stickiness (IPv6 is my go to example) does so at its own peril.

Hyrum's Law is the near reverse of Postel's and i think it should be taught.

I imagine that it made more sense when your update cycle involved the postal system and took months.

Indeed, it's what got us "quirks mode" and that took years and years to dig the internet out from under.

I tried to split the difference with my April Fool's RFC, which proposes the HTTP status "397 Tolerating" for when you want to say "yeah, I know what you want, and I'll give you that, but here's how you were supposed to ask for it".

https://pastebin.com/TPj9RwuZ

I am borderline sad that this is only an RFC.

The number of services I use that I wish had a "warning" side-channel for letting me know something in my query was off, let me tell you...

There's nothing that says you can't have system messages as a boilerplate part of response bodies, even if you don't populate it.

In fact, it's the recommended way to do things like tell a client things it might need to know. Example: "The game servers will be shutting down in 15 minutes for maintenance."

True, but that means it has to be an ad hoc solution for every API instead of a standard.

It's not even an RFC, it's just a pastebin post pretending to be one.

Heh, after I posted it, a former co-worker forgot that was just an April Fool's joke and then, at his new workplace, seriously suggested handling one case by "throwing a 397".

I think Postel is misrepresented. It was addressed to programmers who anally rejected everything that was not (in their opinion) in spec.

Working code and rough consensus is how we progress.

> It was addressed to programmers who anally rejected everything that was not (in their opinion) in spec.

What's wrong with that? The only issue I see is the _in their opinion_ bit. If there's confusion about the spec, then it should clarified and codified. But otherwise: yes, you should absolutely aggressively reject everything not in spec.

Sounds like an SRE prioritizing middlebox cacheability over developer UX. Something like:

"Public-readable resources get requested a lot, with no predictability over who or how many independent agents could be requesting them at once; so, to decrease the likelihood of requests on such resources DDoSing our backend, we could at least limit there to being exactly one canonical way to acceptably request the URLs of such resources. That way, such resources will end up hot in any edge-cache after the first request, and any non-normalized requests will break [and so be removed from the logic] — rather us needing to serve the same resource multiple times to get it saved under under multiple cache keys."

(I'm guessing that S3 also errors out if you submit random unrecognized query-string parameters on such requests?)

>(I'm guessing that S3 also errors out if you submit random unrecognized query-string parameters on such requests?)

Doesn't look like it. I checked out the recent bankruptcy filing that was posted to s3, and you get the doc just the same with or without random query params:

https://pacer-documents.s3.amazonaws.com/33/188448/042120640...

Reply on news.ycombinator.com