Google and HTTP

Dave Winer:

I’ve been writing about Google’s efforts to deprecate HTTP, the protocol of the web. This is a summary of why I am opposed to this.

DaveW’s take on Google’s pitch:

  1. Something bad could happen to my pages in transit from a HTTP server to the user’s web browser.
  2. It’s not hard to convert to HTTPS and it doesn’t cost a lot.
  3. Google is going to warn people about my site being “not secure.” So if I don’t want people to be scared away, I should bend to their will (as if the web were their platform).

The rest of the article is Dave’s rebuttal, a thoughtful read from a very smart someone who knows this stuff inside and out. A few bits:

Google is a guest on the web, as we all are. Guests don’t make the rules.

And:

A lot of the web consists of archives. Files put in places that no one maintains. They just work. There’s no one there to do the work that Google wants all sites to do.

And:

Google has spent a lot of effort to convince you that HTTP is not good. Let me have the floor for a moment to tell you why HTTP is the best thing ever.

If you care about HTTP vs HTTPS, take a few minutes to read Dave Winer’s post. Then dig into Nick Heer’s excellent In Defence of Surfing the Insecure Web for a bit wider perspective.

Neither take is about bashing HTTPS, or about ditching security in any way. It’s about thinking carefully before ditching openness and about how decisions about the internet are and should be made.

Good stuff.



17 thoughts on “Google and HTTP”

  1. Given that Dave can hype a problem out of proportion I have a few worries:

    Is Google actually trying to depreciate HTTP? Or is Dave reading too much into Google’s actions at encouraging HTTPS adoption, and alerting users to risks of HTTP.

    His concerns about older archives that would be left behind due to the cost of converting strikes me as a bit odd. If the procedures to switch to HTTPS would be too much, I’d imagine the ongoing costs of maintaining the server, the bandwidth, and the electricity would cause a desire to shut down these older archives as well.

    Is transitioning to the use of a security certificate really that much of a hassle?

    Side note: The Nick Heer article likens it to how creating on the web has gotten more difficult:

    I don’t intend to hold myself up as a barometer of the complexities of modern web programming or anything — I just don’t know what’s going on any more. I’ve been doing this stuff for nearly twenty years. I don’t know how someone who is eight years old could start digging into React, or Node.js, or any of the other modern JavaScript-based ways of writing

    hello world

    .

    True, there are too many kludges in what most consider to be “modern” web programming out there. But basic HTML and CSS still work very simply and elegantly. Browsers, by and large, adhere to standards pretty well, even while pushing the envelope on adopting new technologies.

    hello world

    still works quite nicely.

  2. I’m not a huge fan of Winer, but I do very much like “Guests don’t make the rules.”

  3. Winer has the amazing ability to make me want to disagree with him even when I shouldn’t, yes.

    (Defaulting to “hey, I can’t guarantee this site is legit or the traffic is secure” seems like a win to me; as long as the browser lets you say “yeah, shut up and lemme see” and “stop pestering me about not being https”, I don’t care.

    I am amused by the way he says “it’s for Google’s benefit”, when the “benefit” is “your ISP can’t edit the content to insert its own ads”.

    Yeah, thanks, Dave. I totally want my ISP even seeing the content of my traffic, let alone inserting content. This is obviously only a benefit to Google, that https ensures my content is unaltered, and my traffic secure and private.

    You insufferable prat, Dave. Ugh. See first sentence of comment.)

    (Agreed completely on the side note – nobody’s making people use node.js or The Flavor Of The Week Toolkit.

    An eight year old can still write and publish Pure Unadorned HTML; hell, they can do it on their own $35 Raspberry Pi server that they can configure themselves, including their choice of http or https or both!

    We live in a golden age of computing and access to content creation!)

  4. They will, in Chrome, start calling out any HTTP site as not secure regardless of whether it matters or not.

  5. I don’t like it.

    Without any context of what makes an one a “guest” or not, it sounds to me like Winer is saying, “only people I agree with should be allowed to make the rules”.

  6. HTTPS does NOT guarantee that a site is legit. All a DV cert does is guarantee that the site is the domain that it says it is. There’s ZERO assertion that the business behind it is legit.

    As far as security… it doesn’t always matter. For example on this site, what does SSL buy us? We’re not entering information here. Or on, say, si.com where I’m reading sports news and can’t even comment.

    A “not secure” warning will be taken by most regular people as “Is risky, might be a threat to you” when that’s simply not the case for many many sites.

  7. Given the ability to insert third party content during transit, and general privacy concerns, it will always matter. Though one can agrue about the degree it matters

  8. “Is transitioning to the use of a security certificate really that much of a hassle?”

    Not really. But the basic DV certificates don’t really do much aside from provide some comfort that you’re on the domain you think you are and that your info is encrypted. See below for why that’s not a big deal in some cases. See Dave’s post for why some sites that aren’t actively maintained might not do this.

  9. ‘general privacy concerns’ is vague. On a site that’s read only what privacy concerns… SPECIFICALLY are there really? Note that you can still insert 3rd part JS etc on an HTTPS site so being SSL does not mitigate that at all.

  10. There’s ZERO assertion that the business behind it is legit.

    True. No one has claimed that HTTPS does that (to my knowledge). That’s a separate matter.

    A “not secure” warning will be taken by most regular people as “Is risky, might be a threat to you” when that’s simply not the case for many many sites.

    The site itself may not be a problem, But how the information is monitored or altered during transit might be. Encrypted traffic protects against third party intrusion.

  11. I remember similar sentiment being attributed to him. But if he’s making a case that deprecating http is somehow equivalent to making the Web more limited and proprietary, I’m curious enough to see where he goes with it.

  12. If there was some way I could get away without being extorted having to pay for a certificate so Google doesn’t flag my site as malicious simply because I have a self-signed certificate I could get behind https everywhere.

  13. By “legit” I meant exactly what you said.

    “Not being impersonated”, nothing more.

  14. The site can insert 3rd party JS etc., yes. (Either directly or via ad networks or whoever it lets put stuff on the page.)

    But being https means nobody between them and you on the open internet can insert, view, or remove content.

  15. Sure, we agree on the benefits. But the issue Winer is raising and which I think is valid is that Google is using market power to force this and to make it sound like any non SSL site is a risky place when, frankly, MITM attacks are fairly rare. Come on, you KNOW that a ‘This site is not secure” messages will be interpreted by a lot of people as “this site is risky and might hurt you”.

    I didn’t have an issue with them doing this on pages with forms, etc. Even for forms that are not collecting sensitive data SSL is a good idea. But for plain read only content?

    Thew larger point is that this is reminiscent for some of us of MSFT’s power when IE was dominant and they could force things on the market.

  16. But it doesn’t mean that. DV certs only tell me that the domain is the domain I thought I was connecting to. So, yes, legit in that way but it doesn’t protect against, say, someone spoofing a site with a very close misspelling of a known domain. EV certs would, but those are costly and not something that can be automated in the way Let’s Encrypt is.

Leave a Reply

Your email address will not be published. Required fields are marked *