
YouTube's road to HTTPS - seanwatson
https://youtube-eng.blogspot.com/2016/08/youtubes-road-to-https.html
======
coob
> We found that HTTPS improved quality of experience on most clients: by
> ensuring content integrity, we virtually eliminated many types of streaming
> errors

Wow, what were carriers doing to the streams?!

~~~
Animats
It's turning out that HTTPS is more important for content integrity than for
security. It's not surveillance that's the big problem for static content.
It's middle boxes designed with the delusion they're entitled to mess with the
content.

~~~
abalone
_> It's not surveillance that's the big problem for static content._

Why would you say this? Surveilling what URLs someone is accessing / content
they are watching / books they're checking out of the library has been a major
security issue, historically.

~~~
Animats
HTTPS doesn't conceal the domain, or the length, or the order of requests.
It's less of an issue for Google, because so much stuff comes from one domain.
For small sites, figuring out who read what isn't a hard problem. In practice,
you can probably buy that info from an ad tracking service.

~~~
abalone
You didn't qualify your claim as only pertaining to small sites. You simply
said surveillance is not the big problem for static content. Given that most
static content is served by large sites and the article is about Youtube, you
haven't really supported that claim.

------
dchuk
What a strange thing to automatically (I assume) add to the end of these
blogposts:

> Sean Watson, Software Engineer, recently watched "GoPro: Fire Vortex Cannon
> with the Backyard Scientist."

> Jon Levine, Product Manager, recently watched "Sega Saturn CD - Cracked
> after 20 years."

~~~
TD-Linux
At least they didn't watch anything embarassing. My Youtube recommendations
page is a dumpster fire.

~~~
munificent
TD-Linux: Hacker News Commenter - Last watched "Relaxing Background Videos
Volume IIV: 4 Hours of a Peaceful Dumpster Fire (with sound)".

~~~
mey
I've watched worse, such as 10 hour loops

~~~
TD-Linux
Indeed, I had FUKKIRETA X 9 on my Watch it Again. I did.

------
drewg123
It would be interesting to know how much overhead HTTPS added for them. Eg, a
comparison of CPU usage between HTTP and HTTPS on the server side, whether or
not they are using hardware offloads, etc.

Netflix has some papers about their experience transitioning to HTTPS:

[https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf](https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf)
[https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf](https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf)

However, I expect the YouTube workload would be vastly different from the
Netflix workload due to the sheer size of the YouTube catalog.

~~~
mschwaig
I would also be interested in that. What differnce would you expect from the
catalog size? I would guess that aside from maybe the handshake, decoupling
storage and encryption would not be worth it in all cases where the storage
medium is slower than AES-NI and this would apply even more to youtube than to
netflix, exactly because of the bigger catalog.

~~~
drewg123
With a small catalog, you can pre-encode everything. That means that in the
unencrypted case, media files can be sent directly from the kernel's page
cache, as unmapped I/O. Eg, the data is not even touched by the CPU. But in
the encrypted case, you're suddenly touching every byte with the CPU, thereby
doubling your memory bandwidth requirements.

With a large catalog like YouTube's, I would expect that most of the titles
are saved in some master format, and are encoded on the fly. That means that
the data is already being touched by the CPU to re-encode it on the fly for
whatever format is needed by a particular client.

My expectation is that if YouTube was re-encoding on the fly due to the
catalog size, they would suffer less of a CPU hit than Netflix did, so SSL
would be "easier" for them to implement.

~~~
rasz_pl
> encoded on the fly

no, and often their encoders will go bad and produce invalid output
(blocky/purple) in one of the resolutions/formats. There is ZERO options for
fixing that other than deleting your video and reuploading (losing all the
comments/upvotes). Even if you have 200K subs there is no way of contacting YT
for help, mmaybe they will speak with you at 1mil subs :/

------
JoshTriplett
> In short, some devices do not fully support modern HTTPS.

I'd love to know which devices, and what "modern HTTPS" features they don't
support.

~~~
drzaiusapelord
Its only fairly recently that Android got TLS 1.2 support with 4.1 in 2012.
The problem is that for years budget Chinese android phones were shipping with
2.3, which was very light on resources and good for low powered phones with
minimal ram.

I believe this changed with an effort to use less ram and cpu with 4.4 or 5.0,
but by then millions of these phones were sold and are still out there. Heck,
up until a year or two ago, these were on shelves in the US at budget places
like Cricket. I think almost 10% of Androids in the wild still don't support
1.2. Maybe more considering Google has limited snooping abilities in China and
may not fully know the extent of these installs.

IE7/IE8/IE9 have a combined global marketshare of about 8% also.

~~~
TazeTSchnitzel
> The problem is that for years budget Chinese android phones were shipping
> with 2.3, which was very light on resources and good for low powered phones
> with minimal ram.

Not just budget Chinese phones. Low-end Samsung phones and such, too.

------
niftich
Is there an 'Unencrypted user traffic by device type' [1] chart just for
YouTube traffic, as opposed to all Google services?

Specifically, are non-HTTPS connections coming from desktops, mobile/device
outside of an official app, or mobile/device through an official app?

[1]
[https://www.google.com/transparencyreport/https?hl=en#device...](https://www.google.com/transparencyreport/https?hl=en#devices)

------
0x0
So annoying when websites hijack pinch-to-zoom touch events and replace them
with "load a random article".

------
minikites
> Today we added YouTube to Google's HTTPS transparency report. We're proud to
> announce that in the last two years, we steadily rolled out encryption using
> HTTPS to 97 percent of YouTube's traffic.

What's the point of the report if you only add things that are already in good
shape?

------
iptables
> You watch YouTube videos on everything from flip phones to smart TVs

what year is this?!

~~~
pki
I am less curious about the year and more curious as to how the hell flip
phones are rendering video. Like 64p 3GPP or something realtime transcoded?

~~~
euyyn
ASCII art.

~~~
dredmorbius
aalib and aaxine, baby!

[https://m.youtube.com/watch?v=mGphynqDkS4](https://m.youtube.com/watch?v=mGphynqDkS4)

------
richard_mcp
Last I checked, YouTube still does not support encryption when broadcasting a
live stream.

------
homero
How'd finance decrease

~~~
greenimpala
The irony eh!

