Ask HN: How does Google Widevine work under the hood?
7 comments
It's a part of the browser. It's not doing it with Javascript if that's what you're asking. Chrome includes a file with the name widevinecdm.dll or something like that on Windows. No one knows exactly what this file does because it is incredibly obfuscated https://github.com/tomer8007/widevine-l3-decryptor/wiki/Reve.... But presumably that implements this functionality.
As for what Widevine actually does, it just uses a protobuf based protocol to request a decryption key from a license server. License request messages from the client have to be signed with a valid device private key, which are made difficult to extract but some occasionally leak.
As for what Widevine actually does, it just uses a protobuf based protocol to request a decryption key from a license server. License request messages from the client have to be signed with a valid device private key, which are made difficult to extract but some occasionally leak.
Does it mean the OS is volunteering the information that something is tapping into the framebuffer? Can that be disabled to render the browser clueless?
Same can happen with Chrome + Google Meet + OBS Studio btw.
Same can happen with Chrome + Google Meet + OBS Studio btw.
AFAIK, the OS provides this information and, at least on Windows, you can't circumvent it easily. I was told it is one of these things that large content providers demand.
I am curious how it works on Linux.
I am curious how it works on Linux.
I just tried it out on Ubuntu using Google Meet web app via Chrome, and tried streaming Netflix to my friend.
Nothing weird happened and all content could easily be streamed.
Nothing weird happened and all content could easily be streamed.
Thanks!
Widevine L3 is implemented in software and typically allows screen recording—and media providers only allow a lower bandwidth as a result. My guess is that the first browser used a form of DRM that uses hardware decryption. This probably wasn't Widevine unless you're using ChromeOS or Android (in which case it would be L1, the more trusted version)—it'd likely be Fairplay on Apple browsers or PlayReady on MS Edge (I'm not sure if 3rd party browsers on these platforms use them instead of Widevine software decryption). These do decryption in GPU hardware, then promptly re-encrypts it to send to a trusted monitor. There's no opportunity for screen capture to read the framebuffer. If you did use Brave with a plugin, I believe it would use software DRM that allows recording.
Widevine is just a way of deriving a CENC key. Widevine (and other DRM vendors) require implementors to conform to various policies. The policies they must conform to prevent what you want to do and are largely enforced in hardware at this point.
The app blanking the screen is just a legacy feature. Even if it didn't blank the screen, the display buffer holding the video will not be available for capture.
The app blanking the screen is just a legacy feature. Even if it didn't blank the screen, the display buffer holding the video will not be available for capture.
I did some digging and found the source of this technology: Google Widevine.
I tried circumventing this restriction and visited HBO Max from Brave browser, but even there, I was prompted to download this extension lest I wouldn't be able to access the site.
I'm a web developer, so a couple of questions come to mind:
1)How exactly would any browser environment be privy to me using a screen sharing via another mac app, zoom?
Some preliminary research suggests that browsers can't tap into the ScreenCaptureKit API, which has me a little perplexed.
I'm curious to know what information is being ingested by a browser when I screen share via zoom. How are the event listeners initialized? How is data being passed to them? What specific os permissions does a browser application need access to to tap into my mac's sceencapturekit api?