4 ms·

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 (un

• shadowgovt 4y ago
  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?"
  • jrockway 4y ago
    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.
    • emmelaich 4y ago
      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.
      • alex_sf 4y ago
        > 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.
    • alex_sf 4y ago
      Hadn't seen that law before. Absolutely hate it. The harm from poor input invalidation over time is massive.
      • endgame 4y ago
        I imagine that it made more sense when your update cycle involved the postal system and took months.
      • deleted 4y ago
        [deleted]
      • ajosh 4y ago
        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.
        • tfigment 4y ago
          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.
          • shadowgovt 4y ago
            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.
          • 4y ago
    • SilasX 4y ago
      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 https://pastebin.com/TPj9RwuZ
      • fuckelonmusk 4y ago
      • shadowgovt 4y ago
        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...
        • slowmovintarget 4y ago
          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."
          • shadowgovt 4y ago
            True, but that means it has to be an ad hoc solution for every API instead of a standard.
        • pwdisswordfish9 4y ago
          It's not even an RFC, it's just a pastebin post pretending to be one.
        • SilasX 4y ago
          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".
• derefr 4y ago
  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?)
  • SilasX 4y ago
    >(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/042120640566.pdf https://pacer-documents.s3.amazonaws.com/33/188448/042120640... https://pacer-documents.s3.amazonaws.com/33/188448/042120640566.pdf?cQQp4119=1003 https://pacer-documents.s3.amazonaws.com/33/188448/042120640...