1. 15

  2. 3

    Do all new websites really require rel=noreferer? I suspect a lot of people would get options they don’t necessarily want, or they’d spend an equal amount of effort undoing what amount to a standardized set of personal preferences.

    1. 3

      Maybe not require noreferrer but… “pick secure defaults and document how to open the minimum needed set of holes” is a philosophy that works just fine for OpenBSD, right? :)

      IME, an average creaky old web app with a bunch of code in it from the 90s will only end up needing to override one to three of these headers for specific weird situations. A fresh build will often run into none of them.

      a standardized set of personal preferences

      The values that the article suggests are a little arbitrary but not egregiously so and they aren’t badly picked.

      1. 2

        Maybe, but I think there’s some differences between openbsd approach and “turn everything on then add an option to turn them off then more options to turn some things back on”. :) I guess this like the security equivalent of a CSS reset.

        1. 1

          We’ll not any time soon get to a state where everything is turned off by default because it’d be untenable for any web browser to ship code that breaks too many existing websites in one go.

          Turning everything off with one button so that you can turn pieces back on again is a safer approach than having to use a checklist to remember to individually turn each thing off. Unlike everything being turned off by default, it might be feasible.

          I’m not sure browsers actually need to be part of this approach though. I could imagine implementing this quite straightforwardly in httpd as a rule like: “if a backend app being http/fcgi/etc reverse-proxied sets the header X-SOTA: 1 then substitute the following headers unless already present in the backend response: X-Frame-Options: deny, X-UA-Compatible:IE=edge,chrome=1, …”

          1. 1

            Agree about browsers. Though I am a little sad they offer 98000 other options, but make it difficult to adjust things like this. Like why not a button to flip all the defaults and let me except sites that break?

            As for the actual proposal, is the problem that setting all the right headers is hard or that people don’t know about them? Does SOTA solve the latter more than a default nginx config recipe?

            And I guess, how long until the standard advice is “set SOTA to 99 for future security”? But then upgrading the browser will break sites, so will they skip ahead to version 100?

            Don’t get me wrong, I think http header security is a shitshow. And full disclosure, I’ve written a lot of it off. Like CSP, which seems like solving the wrong problem at the wrong level. But I’m a weirdo more than a little outside webdev mainstream.

            1. 1

              Like why not a button to flip all the defaults and let me except sites that break?

              I suppose the nearest you can get right now is NoScript + HTTPS Everywhere.

              I don’t think it’s politically possible for a browser vendor to ship a “turn on all the security policies by default” toggle because people who don’t understand the ramifications would activate it and it’d raise lots of ire.

              Shipping a “turn on all the security policies by default” toggle in a browser extension instead is perfectly viable though because the barrier to entry is higher, so it mostly won’t get switched on except by people who are prepared to deal with some things breaking as a result.

    2. 2

      It will have the same problem in the future though, as you wont be able to add new backwards-incompatible features to this header without potentially breaking websites. You probably want to make it’s value a version number or something.

      wrt SameSite, ideally you want a SameSite cookie and a non-same-site cookie.

      1. 2

        How should we call the other state? “quirksmode 2”?

          1. 4

            I see this posted a lot for this situation, but I don’t really get what it means if you have a true wrapper. Is there some specific example of this?

            For example, jQuery came around and offered a “standard” ajax function to handle all browser’s varying AJAX implementations.

            The issue is more when you have a “universal” implementation which is, in fact, not universal and misses a couple things.

            After all, if I write a wrapper around 14 other standards, then is it a new standard in the same sense? No one will write a wrapper around the 14 other standards plus my new standard.