8 ms·

> I hate HSTS and will not use it. HSTS is just a flag. What you "hate" is that a piece of software under ~YOUR~ control (the web browser) happens to be correc

> I hate HSTS and will not use it. HSTS is just a flag. What you "hate" is that a piece of software under ~YOUR~ control (the web browser) happens to be correctly enforcing the intent of that flag. If you don't like HSTS, it is ~YOUR~ choice whether you use a web browser that will follow your instructions or someone else's. If your web browser does not offer a method to disable HSTS like Firefox does, switch to a browser that is willing to follow your instructions. > HSTS is terrible That is an absurd opinion. HSTS makes the internet objectively safer by requiring trust between your web browser and web servers. Who would want optional trust between themselves and their online bank to be the default state of affairs? If a website deals with money (or other items of value) and it is not HSTS preloaded, it is being stupidly and dangerously unsafe.

zzo38computer 8y ago
I know that about the flag, and managed to hack Firefox so that HSTS won't work. (Although I wrote a document how to write a better web browser program, but it isn't implemented.) Trust between whatever (and other options about what features to enable/disable/alter, such as what fonts to use, any kind of URL redirections, etc) should be defined by the user. There are several reasons you may wish to alter the settings. (Anyways, you can configure cookies for secure connections only; the user should also be allowed to configure whether or not to use key pinning for secure cookies (individually per domain).) (I also think that both HTTP and HTTPS are bad for banking anyways, and that a specialized kind of bank/money protocol that can be worked over SSH might be working better (preferably that can be used with text, so that even without specialized software you can still do some stuff with it; IRC does that too and that is what makes IRC good). This is independent of the above stuff, though.)
- sjwright 8y ago
  All of the above assumes that the broader population are well informed about the nuances of digital security. The reality is most people have better things to do. As for your third paragraph—I would agree that banks should act more like APIs and less like their own countries. But that is independent from the use of a protocol. Arguing between TLS (HTTPS) and SSH borders on bikeshedding. The reality is more than a billion people are successfully using HTTPS to safely and securely manage their money, and HSTS is improving the guarantees around that security. I'm sure you've solved every security and trust risk with this hypothetical bank-over-IRC-over-SSH protocol with non-mandatory security... but I'm not yet convinced.
  - zzo38computer 8y ago
    You are correct about that; you could do HTTPS (or otherwise TLS) too would also work, to define such API; it does not have to be SSH. (Actually, now that I consider, HTTP requests (with HTTPS) might be better than SSH anyways for many of the things being done, such as downloading a bank statement. So, it may likely do better. However, the common authentication protocols are better in SSH, but similar kind of authentication protocols is probably still possible with HTTPS too, just it does not seem to be as commonly used, but perhaps it should be.)

zzo38computer 8y ago

I know that about the flag, and managed to hack Firefox so that HSTS won't work. (Although I wrote a document how to write a better web browser program, but it isn't implemented.) Trust between whatever (and other options about what features to enable/disable/alter, such as what fonts to use, any kind of URL redirections, etc) should be defined by the user. There are several reasons you may wish to alter the settings. (Anyways, you can configure cookies for secure connections only; the user should also be allowed to configure whether or not to use key pinning for secure cookies (individually per domain).) (I also think that both HTTP and HTTPS are bad for banking anyways, and that a specialized kind of bank/money protocol that can be worked over SSH might be working better (preferably that can be used with text, so that even without specialized software you can still do some stuff with it; IRC does that too and that is what makes IRC good). This is independent of the above stuff, though.)

sjwright 8y ago
All of the above assumes that the broader population are well informed about the nuances of digital security. The reality is most people have better things to do. As for your third paragraph—I would agree that banks should act more like APIs and less like their own countries. But that is independent from the use of a protocol. Arguing between TLS (HTTPS) and SSH borders on bikeshedding. The reality is more than a billion people are successfully using HTTPS to safely and securely manage their money, and HSTS is improving the guarantees around that security. I'm sure you've solved every security and trust risk with this hypothetical bank-over-IRC-over-SSH protocol with non-mandatory security... but I'm not yet convinced.
- zzo38computer 8y ago
  You are correct about that; you could do HTTPS (or otherwise TLS) too would also work, to define such API; it does not have to be SSH. (Actually, now that I consider, HTTP requests (with HTTPS) might be better than SSH anyways for many of the things being done, such as downloading a bank statement. So, it may likely do better. However, the common authentication protocols are better in SSH, but similar kind of authentication protocols is probably still possible with HTTPS too, just it does not seem to be as commonly used, but perhaps it should be.)