Gregory's ServerThe "Recall can't record DRMed video content" thing is because DRMed video content is entirely invisible to the OS. The OS passes the encrypted content to your GPU and tells it where to draw it, and the GPU decrypts it and displays it there. It's not a policy decision on the Recall side, it's just how computers work.
|
53 comments
  @icing hmm I have no idea whether anyone's researched implementing the server side of widevine @mjg59 At least nothing mentioned on wikipedia. This whole thing is too stupid to not die. @mjg59 @bigolewannabe not trivially - the client would need to encrypt the window content and pass it through the DRM rendering API  This was years ago but i once told Windows that Firefox was a game i wanted to record and it let me record Netflix that way @RnDanger @bigolewannabe The least restrictive Widevine is implemented in Javascript and doesn't require GPU involvement so can be captured, and it's only fairly recently that Firefox got full Widevine support @RnDanger @mjg59 @bigolewannabe a lot of DRM content on the web you can still record by turning off "hardware acceleration" which makes the player use JavaScript instead of the GPU so it can't be DRMed  @mjg59 yeah it completely bypasses DXGI's compositing stuff, which results in some pretty bizarre behaviour if you try to watch HDCP DRM content on a multi-monitor multi-GPU setup, because it'll go to fallback mode (reduced quality and resolution) depending on which monitor you display it on versus which GPU is doing the video decode. @mjg59 luckily most of us don't need to give the slightest shit about this because rips go brrrrt  @gsuberland @mjg59 Can any program ask for that, or do you need some secret blessed keys - i.e. could you make a HDCP'd terminal? @penguin42 @gsuberland the hardware is expecting an encrypted media stream so in theory yes but your app would need to be encoding itself to h.264 or whatever @mjg59 @penguin42 you'd also need the correct keys, but that's not hard. @mjg59 @penguin42 for decoding, yeah, but I thought the DRM encoding needed knowledge of the keys? @gsuberland @penguin42 the HDCP side should be using keys that are dedicated to the hardware (so they can be revoked if leaked). I can't remember if Widevine requires known secret keys on the encoder side. @penguin42 @gsuberland @mjg59 this is exactly what I was thinking. Make signal use this so nothing, including recall, can take screenshots of your conversations @mainframed767 @penguin42 @mjg59 right now I think their best option is to detect Recall being enabled and refuse to display any messages at all until you confirm that you are aware that it is ingesting your messages and you are absolutely sure that this is acceptable for your threat model, with a link to learn more and steps to disable it. preferably with something like a "type 'recall' to continue" so users can't idly click through. @mainframed767 @penguin42 @mjg59 hopefully better solutions can be devised later but I don't think DRM is one of them because not all GPUs and monitors support it (many don't) @gsuberland @mainframed767 @penguin42 @mjg59 That needs to happen to all participants, of course. Just because you’re not recording doesn’t mean the conversation isn’t being logged by the other end. @KimSJ @mainframed767 @penguin42 @mjg59 hmm, I sort of agree there but as long as everyone's client makes them confirm it meets their threat model then there's no difference between that and the analogue hole, and there's no real way to enforce it beyond that. informing users when their recipient has Recall enabled seems possible but potentially iffy, and it may be better to take a user education approach ("other users may still capture your conversations with photos or screenshots") @gsuberland @mainframed767 @penguin42 @mjg59 True. The threat model is only slightly worse than the existing world, it just adds a layer making it easier to extract information from naive users’ computers. @KimSJ @mainframed767 @penguin42 @mjg59 yeah which is why I think the educational approach is one of the stronger options - not only does it help resolve this issue directly, but it also better informs their threat model and risk analysis beyond the immediate problem of Recall. @gsuberland @mainframed767 @penguin42 @mjg59 Are we now in the era of “The Internet, can’t live with it, can’t live without it”? @KimSJ @mainframed767 @penguin42 @mjg59 been there for a while but it is getting more exhausting @KimSJ @mainframed767 @penguin42 @mjg59 there's obviously the unintentional automated vs. intentional manual difference here, and Recall is particularly egregious due to the retroactive access aspect, but really users should be made aware that automated capture is something that could happen for a range of reasons (compromise, malware, user leaves VNC/TeamViewer open, accidental inclusion of conversations via other screenshots / screen recordings / videos / photos, etc.) @KimSJ @gsuberland @mainframed767 @mjg59 Here I was thinking of it more for a local terminal rather than a conferencing thing; still a fun challenge is whether you can prove HDCP use to someone else. @penguin42 @KimSJ @mainframed767 @mjg59 I cannot think of a more hellish thing to implement than robust cross-platform cross-architecture remote attestation of DRM usage @penguin42 @KimSJ @mainframed767 @mjg59 (which, itself, is a meaningless security control in the face of something as simple as someone accidentally taking a photo that has the messages in the background) @gsuberland @KimSJ @mainframed767 @mjg59 Indeed, still, it can't be much worse than confidential computing stuff  @mjg59 yeah, but apparently there is also a policy decision of essentially the same kind when it comes to recall not spying on porn mode in edge, in contrast to porn mode in other browsers.  @mjg59 @pluralistic the engineering effort wasted implementing DRM is a travesty rivalled only by advertising. None of it is defensible nor necessary, except in pursuit of the specious need to conjure artificial scarcity. Neoliberal sociopathy is a hell of a drug. it was only recently that many publishers even used unique DRM keys for media. they used to basically generate one private key blob and give the identical blob to people. now they're building systems with unique blobs that could be used to identify infringement and distribution back to an actual actor that facilitated the unlock of the original stream. i threat model some of those systems. there are tons of ways to implement DRM and i avoid it whenever i can.  @waderoberts @mjg59 @pluralistic I always find it infuriating that publishers both pushed for artificial digital scarcity *and* not allowing us to re-sell our digital purchases. Pick one. @mjg59 that's the best case. On my gaming PC, if I click "play" on Netflix on Windows my whole screen goes black and I have to alt-f4 the browser to regain control. No other streaming services have this, and Linux doesn't either (I assume something HORRIBLE going on w/ PlayReady, which Netflix forces on Windows) @mjg59 Yes, but can we get the same level of protection for encrypted emails and chat, please?  @mjg59 So it would record older DRM'd content? Say if I have an old DVD with a Hollywood movie... Intersting. @KarlHeinzHasliP yeah that's probably going to end up in the scanout buffer and be recordable @Amoshias correct (also why you can't screen-share DRMed video - that API just gives you back the OS view of the screen, which is a black window)    @mjg59 Interesting. So 'recall' still does the screen capture but the parts that are DRM'd just aren't visible?  @mjg59 It is a hardware design decision that tells you where their priorities lie and who they are willing to protect. |
(It is an incredible dick move, but this is Microsoft being hoist on their own petard)