News for hackers. Stuff that matters.
Re:U.S. sues Apple, accusing it of maintaining an iPhone mon... by Thorrez on Friday March 22, 2024 @12:30AM (#39787491)
>Documentation like "this bit of this word must always be '1'" Which as any engineer knows, if it really was always '1' then that bit didn't have to be in the protocol, so what did it do when it wasn't '1'?

Maybe it was a deprecated part of the protocol, and setting it would cause an error or do nothing.

Re:U.S. sues Apple, accusing it of maintaining an iPhone mon... by thaumasiotes on Friday March 22, 2024 @01:47AM (#39787761)
Maybe it's there to prevent desyncing errors that occur for long strings of zeroes. Information theory isn't the only possible consideration.
Re:U.S. sues Apple, accusing it of maintaining an iPhone mon... by technothrasher on Friday March 22, 2024 @07:38AM (#39789653)
Or it could be a placeholder for future expansion and while it would do nothing now, in the future it might break things if you've ignored the documentation.
Re:U.S. sues Apple, accusing it of maintaining an iPhone mon... by bluGill on Friday March 22, 2024 @09:48AM (#39790733)
If you design a protocol without at least one field reserved for future expansion you are a bad engineer. Generally I would call this the protocol version number field, but there are other options. The important thing is there is some field that currently has a defined range, but can get an a larger range in the future and you check that field and abort if it is out of range.

I also recommend a second field called protocol ID which is set to a known random value (your wife's birthday) so that if someone gets an unknown message if they see that value they can guess what the protocol is.