3 ms·

This would work, but I think the issue is that there's an unacknowledged reversal of thinking going on here: HTTPS is the "norm", and HTTP is the aberrant case.

This would work, but I think the issue is that there's an unacknowledged reversal of thinking going on here: HTTPS is the "norm", and HTTP is the aberrant case. The commenter doesn't seem to agree with this reversal, or hasn't realized that it is occurring.

dragonwriter 12y ago
I personally disagree with it -- I think its fine in outline, but should be configurable so that HTTP internal to a controlled network, as specified by the user (or, perhaps more accurately, administrator) can be treated as trusted. Once that is established, enabling/disabling features based on connection trust makes sense; but I don't like the rush to do so on protocol alone.
- quinndupont 12y ago
  I agree with you. To anyone who's been paying attention there's a pretty palpable recent rush to encrypt everything (largely as a response to the Snowden revelations). There should be a genuine debate about the implications on social, political, ethical, and technological levels, but instead we only hear about the bogeymen of NSA spying (although, this is a legitimate concern). I'm a strong advocate of cryptography, but I think we need to come up with a way to speak meaningfully about it, instead of just rushing to encapsulate all human expression within cryptography.
- icebraining 12y ago
  On a controlled network, why not push a self-signed certificate to the browsers instead of using HTTP? You don't need a paid cert, just to run a couple of openssl commands.
  - dragonwriter 12y ago
    > On a controlled network, why not push a self-signed certificate to the browsers instead of using HTTP? Why should we accept the browser forcing internal networks to bear the technology costs (if not the additional financial/administrative costs) of securing for the public internet? Especially for services that might need to communicate with things other than browsers and might not want the overhead.
    - icebraining 12y ago
      Why should we accept the browser forcing internal networks to bear the technology costs (if not the additional financial/administrative costs) of securing for the public internet? You shouldn't. Feel free to not those browsers. Especially for services that might need to communicate with things other than browsers and might not want the overhead. If you're not communicating with a browser - don't use HTTPS. It's not like you're prevented from supporting both protocols.

dragonwriter 12y ago

I personally disagree with it -- I think its fine in outline, but should be configurable so that HTTP internal to a controlled network, as specified by the user (or, perhaps more accurately, administrator) can be treated as trusted. Once that is established, enabling/disabling features based on connection trust makes sense; but I don't like the rush to do so on protocol alone.

quinndupont 12y ago
I agree with you. To anyone who's been paying attention there's a pretty palpable recent rush to encrypt everything (largely as a response to the Snowden revelations). There should be a genuine debate about the implications on social, political, ethical, and technological levels, but instead we only hear about the bogeymen of NSA spying (although, this is a legitimate concern). I'm a strong advocate of cryptography, but I think we need to come up with a way to speak meaningfully about it, instead of just rushing to encapsulate all human expression within cryptography.
icebraining 12y ago
On a controlled network, why not push a self-signed certificate to the browsers instead of using HTTP? You don't need a paid cert, just to run a couple of openssl commands.
- dragonwriter 12y ago
  > On a controlled network, why not push a self-signed certificate to the browsers instead of using HTTP? Why should we accept the browser forcing internal networks to bear the technology costs (if not the additional financial/administrative costs) of securing for the public internet? Especially for services that might need to communicate with things other than browsers and might not want the overhead.
  - icebraining 12y ago
    Why should we accept the browser forcing internal networks to bear the technology costs (if not the additional financial/administrative costs) of securing for the public internet? You shouldn't. Feel free to not those browsers. Especially for services that might need to communicate with things other than browsers and might not want the overhead. If you're not communicating with a browser - don't use HTTPS. It's not like you're prevented from supporting both protocols.