6 ms·

While the point of the article is not incorrect, I would say the title is #0 and #1 are intrinsically part of HTTPS #2 and #3 are just because Google and brow

While the point of the article is not incorrect, I would say the title is #0 and #1 are intrinsically part of HTTPS #2 and #3 are just because Google and browser vendors simply limit these things to HTTPS. It is not like it can only come with HTTPS. Finally, #4 is a side effect of #0. So the only thing really provided BY HTTPS is encryption and authenticity.

nailer 11y ago
I see your point - many of these are side effects of encryption - but the reason I (the author) wanted to focus on some of these things, particularly 2, 3 and 4, is that people don't realise there may be problems they encounter from not using HTTPS, even if privacy wasn't their main concern. E.g, you run an online video company, and (for some silly reason) you don't care about privacy. You still don't want T-Mobile turning your great HD content into a low resolution blocky mess. Edit: actually, thinking about it, you're right. I've updated the article to use the word 'privacy' to better separate it from the other aspects on encryption. Thanks datalist!
vtlynch 11y ago
>#2 and #3 are just because Google and browser vendors simply limit these things to HTTPS Seems like a pretty real and legitimate reason to me.
- untog 11y ago
  Seems like a pretty real and legitimate reason to me. Sure, but HTTPS doesn't provide it. I mean, not really. HTTPS is the flag by which browser manufacturers have toggled the behaviour.
  - ybx 11y ago
    HTTPS doesn't directly provide it, sure, but it's still a benefit you get when using HTTPS. This is just pedantic.
JoshTriplett 11y ago
> #2 and #3 are just because Google and browser vendors simply limit these things to HTTPS. It is not like it can only come with HTTPS. True for "signaling value", but for powerful browser features that the user grants or denies on a site-by-site basis, there's a critical reason to only allow those for HTTPS. If you allow those features for HTTP, you allow them for anyone who can MITM your connection and spoof those sites. Any random ISP, open wifi, or other entity could trivially MITM a popular site via HTTP and obtain privileges it should not have.
- theandrewbailey 11y ago
  > Any random ISP, open wifi, or other entity could trivially MITM a popular site via HTTP and obtain privileges... If a user is MITM'ed, it doesn't matter if some features are disabled. The attackers can do anything they damn well please, like directing the user to a compromised HTTPS site to access those features, or to a drive by download to do worse things.
  - JoshTriplett 11y ago
    Not true at all. A user's grant of permission applies to a particular site, and HTTPS ensures that nobody can spoof that site. If the user visits an HTTP page and an MITM attack redirects that to some HTTPS page elsewhere, that page will still have to ask the user for permission. But if HTTP pages can ask for permission to access those same features, then an MITM attacker can redirect to a spoofed version of a popular HTTP site that asks for that permission. Concrete example: geolocation permission. You visit some popular mapping site that uses HTTP, and grant it persistent permission to use your location. Later, you browse something else via HTTP over a Tor connection. In that browsing session, if you saw any permission prompt for geolocation, you'd reject it. However, a malicious exit node could MITM you and use that to determine your location by pretending to be the mapping site, without a permission prompt. Ditto for getUserMedia (webcam/audio), fullscreen, and any other permission a user can grant or deny on a site-by-site basis. So, browsers want to drop the possibility to use those features from HTTP, not just to push sites to HTTPS but because the entire concept of granting permission only to a specific site doesn't doesn't work with HTTP.
wepple 11y ago
Yeah exactly my thoughts. The cynic in me is thinking "hey, funny that a company selling SSL Certs wrote an article about how great SSL Certs are which doesn't do much more than state side-benefits to one primary benefit of having SSL" HTTPS gets you privacy, tamper-resistance, and authenticity for the end-user. This is the one that I often forget: just because something is encrypted doesn't mean it can't be meaningfully manipulated without knowledge of cleartext.

nailer 11y ago

I see your point - many of these are side effects of encryption - but the reason I (the author) wanted to focus on some of these things, particularly 2, 3 and 4, is that people don't realise there may be problems they encounter from not using HTTPS, even if privacy wasn't their main concern. E.g, you run an online video company, and (for some silly reason) you don't care about privacy. You still don't want T-Mobile turning your great HD content into a low resolution blocky mess. Edit: actually, thinking about it, you're right. I've updated the article to use the word 'privacy' to better separate it from the other aspects on encryption. Thanks datalist!

vtlynch 11y ago

>#2 and #3 are just because Google and browser vendors simply limit these things to HTTPS Seems like a pretty real and legitimate reason to me.

untog 11y ago
Seems like a pretty real and legitimate reason to me. Sure, but HTTPS doesn't provide it. I mean, not really. HTTPS is the flag by which browser manufacturers have toggled the behaviour.
- ybx 11y ago
  HTTPS doesn't directly provide it, sure, but it's still a benefit you get when using HTTPS. This is just pedantic.

JoshTriplett 11y ago

> #2 and #3 are just because Google and browser vendors simply limit these things to HTTPS. It is not like it can only come with HTTPS. True for "signaling value", but for powerful browser features that the user grants or denies on a site-by-site basis, there's a critical reason to only allow those for HTTPS. If you allow those features for HTTP, you allow them for anyone who can MITM your connection and spoof those sites. Any random ISP, open wifi, or other entity could trivially MITM a popular site via HTTP and obtain privileges it should not have.

theandrewbailey 11y ago
> Any random ISP, open wifi, or other entity could trivially MITM a popular site via HTTP and obtain privileges... If a user is MITM'ed, it doesn't matter if some features are disabled. The attackers can do anything they damn well please, like directing the user to a compromised HTTPS site to access those features, or to a drive by download to do worse things.
- JoshTriplett 11y ago
  Not true at all. A user's grant of permission applies to a particular site, and HTTPS ensures that nobody can spoof that site. If the user visits an HTTP page and an MITM attack redirects that to some HTTPS page elsewhere, that page will still have to ask the user for permission. But if HTTP pages can ask for permission to access those same features, then an MITM attacker can redirect to a spoofed version of a popular HTTP site that asks for that permission. Concrete example: geolocation permission. You visit some popular mapping site that uses HTTP, and grant it persistent permission to use your location. Later, you browse something else via HTTP over a Tor connection. In that browsing session, if you saw any permission prompt for geolocation, you'd reject it. However, a malicious exit node could MITM you and use that to determine your location by pretending to be the mapping site, without a permission prompt. Ditto for getUserMedia (webcam/audio), fullscreen, and any other permission a user can grant or deny on a site-by-site basis. So, browsers want to drop the possibility to use those features from HTTP, not just to push sites to HTTPS but because the entire concept of granting permission only to a specific site doesn't doesn't work with HTTP.

wepple 11y ago

Yeah exactly my thoughts. The cynic in me is thinking "hey, funny that a company selling SSL Certs wrote an article about how great SSL Certs are which doesn't do much more than state side-benefits to one primary benefit of having SSL" HTTPS gets you privacy, tamper-resistance, and authenticity for the end-user. This is the one that I often forget: just because something is encrypted doesn't mean it can't be meaningfully manipulated without knowledge of cleartext.