There's no need for it. The image isn't even done particularly well. It's too specific to a browser scenario with some information not properly reflected/explained in the legend.
I have no reason to try make my own or look for an alternative. If someone is particularly interested they can look online for more or less broad explanations as they see fit.
This is to fix some security vulnerabilities. The main dependency locking this to 4.8.0 for so long was pycaption, which was updated to support 4.9.1 in v2.1.0.
This ensures that a partially parsing input (because of optional flags in the proto) does not get past any verification checks.
This prevents issues like an invalid License Challenging from getting an exception later down the line, as well as possibility of it also passing that check by pure luck, resulting in hard to debug issues.
The main change is that it isn't stored as 16-bytes. Effectively not stored like it realistically probably meant to be. It's instead stored as a hex string that was then encoded to bytes (32 data is now taken up).
But I've also improved the comments about my research for the first half of the request ID. This research is likely still incomplete as I'm just not fully sure about the randomness of bytes 5-8.
This is now possible because everything relating to an underlying session is now finally fully remote thanks to the changes surrounding the new get_keys() method.
Any client code still getting keys by accessing `_sessions` manually should be updated to use the get_keys() method.
We shouldn't really provide the derived context keys. There isn't any use to them outside of that specific license request and license response for which it was derived from. The only use to them would be to allow the client to decrypt the keys manually, which wont be necessary nor secure.
This is actually possible and in some cases necessary. While v0 boxes do not use key_IDs field of the PSSH Box, we can store the provided key_ids in the init data. E.g., Apple Music.
rlaphoenix