
Here’s to more HTTPS on the web - syck
https://developers.googleblog.com/2016/11/heres-to-more-https-on-the-web.html
======
Jaruzel
As much as I herald the ongoing march toward mass HTTPS adoption, I'm not sure
Google should be taking the credit.

It seems to me that they are now walking a very fine line between improving
the web, and taking over the web.

For many people Google IS the Internet - it's the provider of the search
results they always see. Chrome badgers you to sign up for a Google account,
and with it the associated services such as GMail.

9 out of 10 smartphones now run Android, and almost all of those are Google
controlled (AOSP[1] is hardly a thing any lay-user knows about). Therefore for
90% of internet users, Google is their gateway.

 _If Google don 't want to you know about something on the internet they have
many routes to ensure you never find out about it._

If this was Microsoft doing this - the world would be in uproar, but
apparently Google are allowed to get away with it? Where's the Antitrust
lawsuits against Google? There's a one smoldering on in Germany[2], but it's
getting almost no press - most probably because Google are suppressing any
mention of it in their results or in Google News (Crazy? Maybe, but you can't
disprove this either).

There are no web standards anymore - if Google want to add a feature to
Chrome, they just go ahead and do it, forcing the other browser makers to
adopt that feature lest they be left behind in the browser market.

Almost all big sites use some form of Google Analytics, along with advert
providers such as DoubleClick[3] (also a Google company). You simply cannot do
anything on the web without Google seeing in one way or another.

Put simply, the Internet is dead; All we have now is the Googlenet.

\--

[1] [https://source.android.com/](https://source.android.com/)

[2] [http://www.ibtimes.com/android-antitrust-googles-big-
problem...](http://www.ibtimes.com/android-antitrust-googles-big-problem-
europe-could-result-75b-fine-2355465)

[3]
[https://en.wikipedia.org/wiki/DoubleClick](https://en.wikipedia.org/wiki/DoubleClick)

~~~
MichaelBurge
> There are no web standards anymore - if Google want to add a feature to
> Chrome, they just go ahead and do it, forcing the other browser makers to
> adopt that feature lest they be left behind in the browser market.

Isn't that normal? First you add the feature to your browser, then if people
start using it you think about standardizing it. The alternative is to spend a
bunch of effort standardizing things nobody wants.

If anything, I'd like to see more standards that first require a concrete
implementation. I think everyone's been handed a spec that has loads of
problems when you actually try to implement it. Look at the 'export' keyword
in C++.

~~~
duskwuff
> If anything, I'd like to see more standards that first require a concrete
> implementation.

This is how the standards process has always worked! Per RFC6410, a proposed
standard can't advance to an "Internet Standard" until there are at least two
independent working implementations.

The W3C has a bad habit of writing "standards" before any code has been
written; sometimes even before it's clear that any code _should_ be written.
(EmotionML, for example.)

~~~
euyyn
Never heard of EmotionML before. OMG.

------
3pt14159
I asked this earlier today on its own thread:

Why don't browsers default to trying HTTPS if there is a DNS record but no
response on port 80? Or better yet, default to just trying HTTPS first. I
understand I can add my site to browser based HSTS lists, but this doesn't
really help people developing command line applications or API client
libraries where a 302 could be followed without the developer even noticing
and if I want to develop a MITM proof application I currently have a usability
problem.

Is there a reason to support HTTP at all, other than current user experience
in the browser?

~~~
pfg
That was discussed here, starting with [1]. tl;dr: Too many broken sites out
there, and this kind of opportunistic encryption doesn't hold up in any
adversarial threat model (MitM blocks :443 and forces downgrade to :80).

[1]:
[https://news.ycombinator.com/item?id=12872100](https://news.ycombinator.com/item?id=12872100)

------
phlo
This is great news. Furthering HTTPS adoption is the best way we have to
combat pervasive surveillance, and we're making steps in the right direction
before HTTP2's opportunistic encryption [1] will improve things on an even
wider scale.

We'll also face some new challenges. Over the years, many users have learned
to "look for the padlock" before entering their passwords. More sites moving
to HTTPS will also increase the percentage of phishing/attack sites served
over encrypted connections -- with the padlock to match. We'll need to renew
our focus on training users to check for the correct domain name (and possibly
an EV cert), or phishing sites with a cert from Let's Encrypt will become a
real threat. Browsers are moving in the right direction, displaying https less
conspicuously than before, and emphasizing connections with EV certs.

[1] [http://httpwg.org/http-extensions/draft-ietf-httpbis-
http2-e...](http://httpwg.org/http-extensions/draft-ietf-httpbis-
http2-encryption.html)

~~~
Symbiote
Pervasive surveillance is also helped with browser fingerprinting, and Google,
Facebook and so on are doing nothing to prevent that.

I'd like to see the default User-Agent header for HTTP2 be as short as
"Chrome". Remove cookies, find ways to keep the identity of a user private.

~~~
phlo
Good idea. I wonder why the privacy-protecting Add-Ons (ABP, uBlock Origin)
don't mask the UA by default.

On the other hand, trackers will probably just switch to detecting the
capabilities of the browser using JS and then map each distinct set of
capabilities to the matching browser version. In that scenario, an Add-On
replacing your UA will actually increase trackability, as long as the majority
of people aren't using it.

~~~
jhasse
Because many sites (including most of Google's) won't work then ;)

Also it would be _very_ easy to detect if a user is running an adblocker then.

------
throw2016
Why is https is promoted as a way to fight surveillance when the typical HN
user knows https does no such thing.

How does https stop NSA or any resourced state actor? Even ordinary run of
mill organizations routinely mitm https.

And to add insult to injury this naive https protects against surveillance is
promoted aggressively by people and entities who are known to be in bed with
state entities, leading purveyors of spyware and are aggressively building
profiles of individuals every second.

~~~
danblick
I guess maybe you're being downvoted for the tone of your comment, but I came
here wondering the same thing. Usually we think of communication as secure
when messages can be read only by their intended recipients. We don't really
get that when we're using the public key infrastructure in modern browsers.
I'm not sure how much it matters (I don't mind if the government knows my
credit card number), but I don't like the way PKI makes "private
communication" sort of ambiguous...

~~~
pfg
The public key infrastructure in modern browsers allows you to use HPKP, which
gives you all you need in order to fully control that a message can only be
read by its intended recipient, if you need that level of assurance. (Yes,
it's TOFU, but is there any large-scale protocol that isn't either TOFU or
requires out-of-band verification?)

The public key infrastructure in modern browsers is also about to require that
CAs use Certificate Transparency (a year from now), which is definitely an
obstacle even for nation-state adversaries if they want to stay under the
radar (once it's fully rolled out and backdating in order to bypass the
requirement isn't possible anymore).

Finally, if you're the target of a nation-state adversary, there are probably
things you'd have to worry about other than the Web PKI. It's unlikely to be
the most effective way to own you. The Web PKI isn't the weakest link by far.

------
seba_dos1
Here's to static text blog posts that don't display without JavaScript.

That surely doesn't make the web any safer ;P

~~~
helb
Works fine without JS for me, except the Google+ comment box and some Youtube
channel link widget thing.

~~~
cesarb
Looking at the page source, the whole content can be found both within a
<script type='text/template'> tag and within a <noscript> tag (yes, there are
two copies of the whole content). The problem is that some Javascript blockers
like uBlock Origin ignore the <noscript> tag; see
[https://github.com/gorhill/uBlock/issues/308](https://github.com/gorhill/uBlock/issues/308).

~~~
angry-hacker
I can't think what we're the engineers that implemented that stuff were
thinking.

Blogger sort of worked fine until they hugged it with js and their latest
super cool network and view engine. Let's see if they rewrite the whole
blogger thing in webgl soon. I wouldn't be surprised.

Also I'm sick and tired if closing those cookie notifications.

PS. I browse the web with js enabled like the majority but there is no need to
use js to render 50kb of text.

------
fiatjaf
It is still expensive and cumbersome to implement HTTPS. Everybody seems to be
neglecting the small websites deployed by hand, which are probably 99% of all
the internet websites.

~~~
the_duke
Cumbersome? For most non-professionals running a small site, absolutely.
That's where hosting providers need to step up to make it as easy as possible.

Expensive? How?

Thanks to Let's encrypt and others, certificates are now free.

~~~
LunaSea
I'm sorry but I wouldn't call certificates with a lifetime of 90 days
practical and I'm a developer.

Let's Encrypt is still far from being convenient and usable for small
companies or individuals that don't want to manage infrastructures and
administration like writing a cron job that refreshes your certificate.

~~~
clarry
Yes that one liner takes so much effort to write [EDIT: copy from one of the
bazillion articles that have already done it for you]. That's why we can't
have security. It takes too much effort.

~~~
Jaruzel
For fun, next time you are on public transport, or sitting in an airport
lounge, stand up and ask loudly 'Does anyone know what cron is?"

The lack of raised hands, should answer for you why LetsEncrypt is not ready
for mainstream use.

Until Cert renewal is baked into all the hosting apps/platforms - HTTPs will
never be ubiquitous.

~~~
inimino
Most of those people don't host their own websites, either.

~~~
fiatjaf
But there are some who do.

Not that they host it with their own computers, but they rent some space
online and host it there.

------
TekMol
I wonder how effective HTTPS is against MITM attacks. When I type
www.somedomain.com into my browser, it goes to
[http://www.somedomain.com](http://www.somedomain.com). If the page then
redirects to [https://www.somedomain.com](https://www.somedomain.com) it is
too late already.

A MITM attacker could intercept my initial request and then proxy everything
afterwards. So he would get all the data in clear text.

Somebody could probably put an app onto a phone that offers a wifi hotspot and
then MITMs everything. By walking around with that phone he would probably
capture all kinds of "private" communication all the time. And none of us
would know.

When I am in an airport and see a hotspot "Free Airport Wifi" I always suspect
it is such an app in reality. I mean, everybody can call their hotspot "Free
Airport Wifi".

~~~
pfg
That's why preloaded HSTS exists - basically a list of domains included in
browser binaries that those browser will only ever visit via HTTPS.

~~~
TekMol
Wouldn't it be easier to make the browser use https by default? And then if a
domain does norespond to a https request ask the user "There seems to be no
secure way to communicate with www.somedomain.com - want to switch to
insecure?".

~~~
Edmond
Probably won't sit well with website owners. If you attempt to connect over
TLS when it isn't supported, there is a performance impact, basically you have
to attempt one failed connection for every http request, do that for every
request on a page and performance becomes a big problem.

You'll also be going against specs, HTTP should go to port 80( which typically
isn't secure.), a browser unilaterally deciding to go against a legitimate
user wish is bad form.

~~~
marcosdumay
Hum... If I explicitly type "[http://example.com"](http://example.com"), then
by all means, go to the plaintext site. But everybody just types "example.com"
and expects the browser to go to the site - this one should favor the TLS
version, not the plaintext one.

Besides, now that most sites run on https, making the http-only ones slower
would be a good thing.

~~~
Edmond
I think the current approach of allowing site owners to decide how they're
going to support TLS is the right approach, browsers taking it upon themselves
to enforce it is a bad idea. Some additional reasons why it is a bad idea have
already been mentioned by other folks.

When it comes to security, TLS is crucial to the security infrastructure of
the internet as a whole; however most of the current security problems on the
internet don't actually involve TLS vulnerabilities, even though those tend to
make a lot of news in the technology press.

The bar for exploiting TLS vulnerabilities generally requires setting up a
legitimate seeming entity and injecting yourself into the internet traffic
routing infrastructure, it is very much possibly (and indeed easy for state
actors) but it is a much higher bar for common cyber criminals.

~~~
3pt14159
They can decide themselves by 301ing to http and setting some sort of "I'm a
crappy website, just use insecure requests" header.

~~~
Edmond
they can't 301 if they don't already support TLS. If you attempt to connect to
a site over TLS that doesn't support it, for starters port 443 is not likely
to be open. 301 is part of the HTTP protocol, TLS is transport layer.

------
ecesena
Does anyone know why there are holes in the CromeOS chart?

At first I thought the fact that the percentage is higher is because by
default they contact more google services (presumably all over https) than
other os/browsers. If this hypothesis is correct, does it mean that the holes
are periods where some of these services were failing to provide https?

~~~
notatoad
i think it's more likely a temporary spike in popularity of some non-HTTPS
site than a temporary failure to provide HTTPS by a site that normally does.

------
greggman
Is there a need for IoT devices to serve HTTPS?

~~~
danblick
I'm curious how well that would work? I think it would be awkward to deploy a
secret key to a (difficult-to-configure) home device and then keep that secret
key secure. It worries me that your IoT device might claim to use HTTPS but
actually depend on a private key that had been compromised.

