HTTPS Everywhere is great, but comes with its own set of headaches. Especially when we start encrypting videos.
Don’t get me wrong. Encryption and privacy are important. They are essential to our Internet at this day and age as more and more people conduct real business and larger portions of their life over this medium.
I think that Google’s initiative of HTTPS Everywhere is a really important one. They even had a whole session at Google I/O only for that:
Earlier this month, Dror Gill wrote a piece on TechCrunch, detailing the issues related to video over the internet and the battle raging between Netflix and carriers.
He gives 3 solutions to the massive amount of video going over the internet:
- Caching, where data is stored closer to the network edge – usually in the data centers of the Internet service provider
- Adaptive bit rate, where the stream is stored in multiple bit rates and the data streamed to the device can change between bitrates based on the network condition dynamically
- Compress better
Adaptive bit rates and better compression can be dealt with by the service hosting the video itself (Netflix, YouTube or others) and can also be achieved by the internet service provider.
Caching can only be achieved by the internet service provider. A close alternative is using a CDN, and a wishful thinking one is hosting your own servers inside the internet service provider’s data centers (Netflix is doing that wherever possible).
All of these 3 options can be done by an internet service provider by means of proxies in his network. Since all data flows through his data centers anyway, he can cache or modify the resulting video to optimize for his own network.
BUT – if the actual video is encrypted, then there’s nothing an internet service provider can do, besides knowing it may be a video stream:
- He can’t cache the video, as he won’t know when the same video is requested again
- He can’t apply his own adaptive bit rate mechanisms, as he can’t access the video stream
- He can’t compress something he can’t decompress in the first place
For the most part, the video flowing through the Internet is coming from large domains such as YouTube and Netflix. They already have adaptive bit rate and better compression handled. The problem is with caching of popular videos. These can’t be handled between some kind of an agreement between the content provider (Netflix, YouTube) and the internet service providers – at least not when the requests as well as the data streams themselves are encrypted.
The current focus of HTTPS Everywhere is on web pages. Once it moves on to video content, this will become a larger issue.
Your discussion is to late:
1. YouTube already uses HTTPS, even for delivery of the video itself. This is with HTML5-video and also Flash. Just take your Wireshark and have a look.
2. Google is one of the best connected networks (peering). Basically what they call a Tier 1 network.
So it’s already happening and it’s already working. For access providers that want to keep the most popular Netflix videos local you just call Netflix and you can get some Netflix Open Connect appliences. it reduces the cost for Netflix and the access provider.
Lennie,
The YouTube one is exactly my point – when video gets encrypted, there are less options for non-content providers to interfere, even if that interference is for good reasons.
The Netflix one isn’t that easy – just look at the fights between Comcast, Verizon and Netflix over peering – these service providers decided not to put Netflix appliances in their data centers for their own reasons.
What would Vimeo and 100’s of other video streaming services do? Will it end up being Google, Netflix, Apple, Facebook and Akamai as the only video providers out there?
Youtube is a different model than Netflix. To access content on Netflix, the user needs to be authenticated, so a simple cache wouldn’t work. For YouTube type of content, i.e., free to stream, caching is important.
HTTPS wont really be a problem for caching because DASH has fixed segment sizes, and the cache’s can do DASH segment caching instead of doing TCP segment caching.
But with adaptive streaming (similar to DASH), the problem is not encryption but the quality videos being watched and those in the cache — mainly how the client algorithm switches between quality levels when cache-hits and cache-misses occur.
OTOH, the issue with the encryption would be being able to replay the encrypted packets.
I don’t think HTTPS is going to be any useful when in relation to ranking the content. Yes HTTPS is secure but other than that, it is not so useful. I have not seen any blog outranking the other because of https.
This new rule by Google is brand new. Wait a year, and then we will see how much weight does HTTPS has on website ranking.
I think the reason they are trying to move people to HTTPS is because it prevents profiling: http://www.youtube.com/watch?v=zojjHWSTdy8
Profiling applies to all websites, so HTTPS should also apply to all websites.
Ironically Google owns the largest advertising network, which probably makes them profiler of them all.
Maybe they do this because they know how much profiling can reveal about a person.