In this case since he mentions it's a "tree" of data (he means a "message"), it would be a sub-object that would become an initialized default. So there would be an "object" there, but it would have no "ads" array in it, or what not.

Protobuf does this so you can do `deep.dotted.paths` and you won't get null exceptions (probably a side effect of starting partly in Java). The leaf fields end up as empty strings, `0`, `false`, or an empty array for repeated fields.

It's a neat trick to get it to ignore a field, just not a "flaw." It's actually a compatibility feature in disguise.

(So it might be pretty hard to detect, versus the potentially-legitimate case of just not having any ads to show.)

The article actually shows a screenshot of the structure they are cutting off.

I would think that a dummy object would be trivial to detect.

It would be like receiving `{ads: []}`. How do you distinguish between the case of having no ads to show, and someone tampering with the data?

Is it ever reasonable to assume you have a properly decoded empty array because a user tampered with it, instead of that being what the server gave back to you?

If you have to choose between (a) the app shutting down or (b) the user not seeing ads bc the ad array is empty, you are probably going to pick B.

Anyway, none of this would be a problem if the TLS tunnel broke because the cert failed to validate against an issuer pin shipped with the app.

Maybe the reason they don’t do this is that many enterprise networks break up TLS.

Good point, hadn't thought of that