←back to thread

798 points bertman | 2 comments | | HN request time: 0.001s | source
Show context
xeonmc ◴[] No.45899355[source]
In ten years time YouTube will be entirely inaccessible from the browser as the iPad kids generation are used to doomscrolling the tablet app and Google feels confident enough to cut off the aging demographic.
replies(9): >>45899394 #>>45899462 #>>45899465 #>>45899525 #>>45899536 #>>45900001 #>>45900317 #>>45900441 #>>45900653 #
vachina ◴[] No.45899536[source]
They’d need dedicated hardware to enforce any kind of effective DRM. Encrypted bitstream generated on the fly watchable only on L2 attested device.
replies(7): >>45899618 #>>45899734 #>>45899739 #>>45899807 #>>45900214 #>>45900945 #>>45902867 #
yard2010 ◴[] No.45899807[source]
Can you explain in simple terms what would prevent one from running the decryption programmatically posing as the end client?
replies(5): >>45900061 #>>45900104 #>>45900132 #>>45900160 #>>45903399 #
1. Thorrez ◴[] No.45900061{3}[source]
Here are a couple ideas:

The decryption code could verify that it's only providing decrypted content to an attested-legitimate monitor, using DRM over HDMI (HDCP).

You might try to modify the decryption code to disable the part where it reencrypts the data for the monitor, but it might be heavily obfuscated.

Maybe the decryption key is only provided to a TPM that can attest its legitimacy. Then you would need a hardware vulnerability to crack it.

Maybe the server could provide a datastream that's fed directly to the monitor and decrypted there, without any decryption happening on the computer. Then of course the reverse engineering would target the monitor instead of the code on the computer. The monitor would be a less easily accessible reverse engineering target, and it itself could employ obfuscation and a TPM.

replies(1): >>45900137 #
2. ◴[] No.45900137[source]