Hacker News Reader

Smoothly handling missing or unexpected fields is half the value proposition of protobuf. May as well switch a a much simpler versioned binary protocol instead of all this schema and field tagging complexity if you want to reject every message that doesn't match the client's schema.

But rejecting unknown messages would likely degrade the user experience. Just because Google releases a new version doesn't mean everyone instantly has that new version installed everywhere.

Certificate pinning would be a solution, but the world seems to have decided that that's very difficult to get right. Probably easier to get right in an app than in a website, but I understand not using it.

They could manually sign the protobuf messages to ensure integrity. Duplicating some of the work TLS would already do, but doing it decoupled from TLS infrastructure may be easier.

But unless something like OP's hack becomes mainstream, Google's current approach could be the right one. Sure, it leaves them open to message manipulation, but the potential lost ad revenue from even a tiny failure rate around update time from the other approaches could easily outweigh what they lose from a handful of people running middleware boxes to block ads.

AFAIK ignoring unknown fields is a MUST in the protobuf spec. It's safe to assume all of their tooling is built around this. It wouldn't make a difference anyway. As vitus pointed out, deleting the field isn't much harder than changing it to an unknown field.

You can do cert pinning. And the user can modify the app to pin their own cert. And you can lock down the device so the user can't modify the app. And the user can get a different device where they can modifiable apps. And you can add device attestation. And it's not yet feasible to extract an attestation key from a device, but it probably will be in the future. And then you will switch it to a physically uncloneable function. And then someone will figure out how to physically clone it anyway. And so on.

The war on ad-blocking is fundamentally the war on general-purpose computing. By the time you achieve unskippable ad blocking,

You know, you could also just refuse to send any video segments until the time when the ad is supposed to be over. Then the user may try to download their videos in advance, but most of the time they don't know what they're going to watch that far in advance, so they'll sit through the ad to avoid sitting through a black screen. That seems like a more sane thing to try. And you don't have to destroy the fabric of society to do it.

they'll sit through the ad to avoid sitting through a black screen

Bold claim.

AFAIK Twitch already sends a simple "there's supposed to be an ad here" video stream during ad breaks when viewing through a non-web player. I'd take 30 seconds of silence over 30 seconds of advertisements any day of the week.

+1. Especially those obnoxious, super-loud ads (seems like it's 99% of ads these days)

I’d be thrilled to have a black screen instead of ads. I suspect you assume that my motivation is to escape the interruption. To me, let me tell you—the interruption is a mild annoyance, while the ads themselves are an active assault.

Especially now that they’re individually and programmatically targeted to showcase and inflame the neuroses, health concerns, and predilections of each of the specific people in the room around the television.

Amazing how the HIV commercials only appear when individuals in risk groups are around. Those outed a friend once—luckily in a supportive environment.

And the random miscellaneous cancer drug ads come on when the friend who’s an older cancer survivor comes to visit. And the sports betting ads when friends facing gambling addiction are around. And if I hear one more ad hawking supplies for squealing tiny humans when new parents are around, so help me…

Instead of a black screen, I'd like to watch calm cat/dog sleeping videos when they try to serve ads. Maybe one day uBO will add this opt-in feature, like mute the lie and overlay it with a 5-minute preloaded neutral cute content, for desperate services that force users into it.

PS. spent 5 minutes on "a dog sleeping" without stupid music and couldn't find one. Search these days, man...

i'll give you one better for free. Behold the Sea Otters of the Monterey Bay Aquarium: https://www.montereybayaquarium.org/animals/live-cams/sea-ot...

Thank you!

I am completely mesmerized.

Locally to me, far from anywhere it belongs, an independent-spirited Japanese man operates a little izakaya as a solo enterprise. Jazz, shockingly varied menu for the square footage and manpower; the whole deal.

He keeps a television set up at the bar he works behind—pointed away from the bar, toward him. He shows only kittens playing and views from train drivers’ windows…

I would rather watch a black screen than a majority of YouTube ads. Because:

- they are for a product that I just bought x 20 times;

- they are for a product that I do not need x 20 times;

- “we know you are old, so do this stupid thing… (have I said “x 20 times”?)

- “we know you are rich, so do that stupid thing…

And so it goes.

Except that Google introduced NEVER-ENDING ads in the middle of content. I was willing to watch normal-length ads at intervals. But when Google made it impossible for me to watch stuff while cooking because I have to keep herding the program along by pressing Skip every few minutes, I installed an ad-blocking client.

It's pathetic how Google pulls this douchebaggery and then whines when people fight back.

I remember when everybody in HN said they wished they could pay to avoid seeing ads and then Google introduced that feature.

And?

> AFAIK ignoring unknown fields is a MUST in the protobuf spec.

Yes, but there isn't only an unknown field, but also a missing field. (The old field index) Thus it doesn't meet the requirements of the client.

Now that probably could be circumvented by doing more edits to the protobuf message. If nothing else works by injecting 0s length ads instead.

They removed required fields from the spec for similar reasons.

> You know, you could also just refuse to send any video segments until the time when the ad is supposed to be over.

As I understand it, many ads are skippable after a certain amount of time, so you'd have to allow for that, but that does seem like a sensible idea.

(This is a similar approach to what Twitch does, by the way.)

The point is that when ignoring unknown fields leads to users defeating your business model, even though the protocol requires it, the business logic of your software almost certainly should not. Protobuf working as intended, youtube client not so much. Agree that cert pinning is not the solution.

Protobuf and the app are behaving the right way. 99.999% of users aren't going to MitM your protocol.

How exactly should you deploy client code to the edge, which may not be updated, to handle "unknown" tag number fields? You don't, because that's crazy. Nobody should write software like that because it creates a maintenance hell where you can't upgrade or downgrade because "smart" applications are doing stupid, undeterministic things with the protocol.

It's impossible to reason and engineer backward / forward compatibility when you don't treat the wire format and API with respect.

Most of the major migration headaches I've had in my career have been the result of engineers trying to be clever in the time and place they wrote the code.

The next best option is to version the api and support all old versions going back 10+ years

I agree, what they are doing with proto is much better

Uh… how about display an error message if the user isn’t subscribed to premium and the server doesn't send any ads?

YouTube often degrades the user experience when it suspects ads being blocked. I think the idea that Google would care more about following prorobuf's best practices than rejecting ad blockers is strange from a business perspective.

Cert pinning for YouTube would actually be quite easy, as Google runs its own CA. They can just hard pin their root CA and update the app in twenty years or so when that expires.

If you want to prevent MitM modification attacks, the way to do it is to sign the data. Trying to do it by making the serialization format less forgiving isn’t the right approach at all. It still has to be pretty flexible. It’s going to be pretty hard to come up with a format that cannot possibly be altered to make the client show no ads. Something like certificate pinning is way easier.

I'm very surprised Google isn't already certificate pinning.

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.

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.

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

> 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.

Only naively. You can do a key exchange.

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.

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.

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.

I'd consider cert pinning malware behaviour if it rejects the certificates explicitly trusted/installed by the user.

> I'd consider cert pinning malware behaviour if it rejects the certificates explicitly trusted/installed by the user.

You might be interested to know that this is official policy on Android. Yes, I'm appalled too.

Funny you mention that, because unnecessary "security" controls on streaming data is how Google broke Chromecasts lacked week, and still hasn't figured out how to fix.

I haven't had any trouble on my dumb Chromecast so I think they must've pushed an update to fix the issue already. The only app I remember breaking was Jellyfin, ironically enough.

Security controls weren't the reason the devices broke, which is why applications that didn't care about things like DRM still played just fine. The internal CA for the Chromecast hardware certification expired, which requires updating all Chromecasts or temporarily ignoring the expiry date in client apps. It seems like apps are doing the latter while Google is figuring out how to update the Chromecast certificate infra on short notice.

Thoughts my own, smooth, uninterrupted video playback is much higher priority than recovering a small amount of ad revenue.

Ironically, Protobuf does have field options for "required" and "optional", but over a decade ago (I guess shortly after it was first introduced), Google added a huge "do not use required! validate required fields in your own logic!" warning to the docs, because a missing "required" field throws out the whole packet. (And when it's time to deprecate a required field -- it's way more effort)

We originally used "required" for fields that must be present and it screwed us over later due to that. Switched everything to "optional" with the code checking for those fields' existence instead.