Hacker News Reader

Comment by dylan604 | Hacker News Reader

right, but if you have a valid and current version of the player that decodes, say something like an app on an AppleTV 4K that pushes the video signal via HDMI, and inline box to bypass HDCP would not be affected by any key revocation what so ever. So again, how does this inline box get affected at all by any key revocation? After all, that's the subject of the TFA which we seem to have strayed a bit too far from the conversation with your hypothetical

View on HN

An app on Apple TV may be valid and current today, but if it's playing streaming media, it may not be valid and current to get streaming content tommorow. Updates to the app or Apple TV firmware could include revocations such that tomorrow's required version will not authenticate with your inline device.

What do you mean by ‘a player that decodes an app on an AppleTV’?

If your AppleTV is running an app that is playing media, that app is the player. And that app will add the new keys, that it finds in the media it is playing, to its revocation list so that app can no longer play any protected media to the blocked device. It will refuse to communicate with the inline box because the key used by the box is now on the revocation list.

And there probably is some mechanism that causes this to apply systemwide, either because the encryption and list management is in some dedicated chip or because the list is shared systemwide.

The inline box has to negotiate authentication with the player, which will see that the inline box has a revoked key and refuse to send data to it.

Thanks. This is the part that I was missing. So the Netflix/Prime/Hulu app receives the updated listed of revoked keys. When it sees that the device it is communicating with has a revoked key, it will refuse to play/launch/however it fails. At that point, it could even be put on Apple's shoulders that the AppleTV unit shouldn't even connect to that device and not be the app developers???

Reply on news.ycombinator.com