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