Cert pinning is not a solution and defeats legitimate traffic inspection cases. It also just moves the goalposts as the author discusses it can be defeated by a modified app binary. The industry has moved on. Sign your data if modification in-flight is a threat. I’m surprised google isn't doing that.
Cert pinning is a solution. Just because it is not an ideal solution and it is anti-consumer does not make it "not a solution". You can't modify an app binary on an Apple TV without first jailbreaking.
So cert pinning in this case would go from "anyone with a pihole or equivalent can block YT ads on their Apple TV" to "people who jailbreak their Apple TV and install a cert pinning breaker and have a pihole type setup can block ads".
If you are google and your goal is to get people to watch ads, cert pinning is clearly a win if you are at all worried about things like the OP. Clearly they are not very worried, presumably because the bar set by the OP is already too technical for most people (even if it was packaged in a more consumable way).
When you're running a proprietary video service that's supported by ads and analytics, there aren't that many "legitimate traffic inspection cases". Google prefers people not to mess with their network traffic and would also prefer it to be a bit harder to write YouTube downloader scripts.
From a user perspective, you'd want to break all TLS connections and sniff every bit of data on your network, but that's not the perspective Google has when developing their code.
Signing data is just duplicating TLS security measures with a second key. TLS already signs the data, Google just needs to verify the root of trust.
> Sign your data if modification in-flight is a threat.
Which effectively pins a different key in the binary. Might as well use certificate pinning, which provides both signing and encryption without a second layer of crypto.
Alternatively perhaps the cost of implementing / performing the overhead of signing and verification isn’t worth the cost given the relatively few people who are likely to do this
A legitimiate traffic inspection case, from the content publisher's perspective, would have an alternate certificate backed by a trusted authority who agreed to protect the ads.
> It also just moves the goalposts as the author discusses it can be defeated by a modified app binary. The industry has moved on. Sign your data if modification in-flight is a threat.
As a sibling comment has also pointed out, signing the data won't help against a user who's modifying the client. You can change the signature the client is expecting on your certificate... and you can also change the signature the client is expecting on your data.
It protects against things other than the intended client modifying the data. Someone said we need cert pinning to protect data integrity in the face of MITM. I am saying signing your requests solves MITM modifying the traffic, so you don’t need cert pinning. Solving binary integrity in hostile compute environments is a different problem.
Google still supports the YouTube app on the PlayStation 3. They are not going to rotate hashes/certs on that app because it's very likely there are between zero and two people who know how in the whole org. There are countless other supported devices like this that are either EOL or not receiving updates, and part of YouTube's value proposition is that they are available everywhere.
The current YouTube certificate has a lifetime of 84 days. The next one will live that long or even shorter. Certificates are rotated too quickly nowadays for pinning to be viable. They'd be better off pinning their CA than their certificate, but that might cause issues for users in certain scenarios.
