4 ms·

i don't think the explanation as to why this works is correct. the poster says it's because Google and Microsoft "have been working closely with Netflix to get

by aroman 12y ago

i don't think the explanation as to why this works is correct. the poster says it's because Google and Microsoft "have been working closely with Netflix to get the needed DRM code required for HTML5 streaming", yet: 1. the user-agent switch involves adding a Safari identifier (rather than IE or a new Chrome one) 2. at WWDC 2014, Apple announced that it had been working closely with Netflix along those lines, and that the upcoming version of Safari would be able to play Netflix without Silverlight. (And indeed Safari on Yosemite can do just that in the developer previews)

mappu 12y ago
That is a chrome UA, it has Chrome/X in it. Safari/X is a compatibility shim.
nacs 12y ago
That is the Chrome user agent. It mentions Safari and AppleWebkit for compatibility reasons but it's Chrome. Windows Chrome user-agent for reference: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36
- emergentcypher 12y ago
  Ah, yes, another reminder of the hilariously bad user-agent situation in today's web...
compedit 12y ago
(And indeed Safari on Yosemite can do just that in the developer previews) Yep, it's definitely a bit buggy and stops occasionally but it's usable!
voyou 12y ago
"the user-agent switch involves adding a Safari identifier" Well, the default user agent string for Chrome already has a Safari identifier in it, but I don't think Safari user agents have a Chrome identifier. The change being made in the post doesn't add a Safari identifier, because there was one there already, but it does change the OS string to Windows. So I think the explanation in the post is probably right.
azernik 12y ago
For a humorous history of why exactly the Chrome UA string claims to be Safari, see this: http://webaim.org/blog/user-agent-string-history/ http://webaim.org/blog/user-agent-string-history/
- TazeTSchnitzel 12y ago
  It's not complete without the new Windows Phone user agent, though: https://mobile.twitter.com/0xabad1dea/status/497122542885556224/photo/1 https://mobile.twitter.com/0xabad1dea/status/497122542885556...
higherpurpose 12y ago
I thought the whole point of "HTML5 DRM" was to be backed by hardware DRM. So are they giving up on that idea for Linux? And if they are, maybe hardware DRM isn't necessary on other platforms either.
- jiggy2011 12y ago
  HTML5 DRM (EME) only defines an interface between the DRM system and the browser, it doesn't specify the mechanism for the DRM itself, the CDM is a black box . You could have a DRM scheme based on ROT13 and it would be entirely valid. https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med...
fafner 12y ago
What they mean is that the "Digital Restriction Management in HTML5" proposal is pushed by Google, Microsoft, and Netflix into the W3C spec. Apple has simply followed the proposal and implemented it as well. AFAIK Chrome, IE, Safari ship with it. Firefox will follow suite by adding a Restriction Module from Adobe (given Adobe's track record it will certainly be an amazingly fast, flexible, beautiful, efficient, and nice way of viewing videos...). So Web-Restrictions is kinda unstoppable now. Instead of having a plugin-free future with HTML5 we have an even worse situation.
- Karunamon 12y ago
  "No DRM" was never an option. The option was between 1 DRM standard and 50 (so silverlight and widevine and....). The W3C made the most pragmatic choice, here. I think DRM is still crap, but one system is unambiguously better than >1.
  - girvo 12y ago
    Except Flash was at least used for stuff other than just DRM, so there was an incentive to get it working across all OSes. Linux is going to struggle once this is adopted, at least open browsers will, and that makes me sad
    - jiggy2011 12y ago
      The openness of the browser has nothing to do with it, the browser provides an interface to the DRM mechanism which could be open or closed source. Open source browsers like firefox already support proprietary plugins such as Flash. If anything this makes Linux support easier, because you no longer have to provide support for an entire virtual machine and all APIs such as Flash or Silverlight. The only software required will be the DRM module itself as everything else can be provided by the browser.
      - fafner 12y ago
        The DRM mechanism can't really be open source. You could simply change it to write the unencrypted video data to the disk if it were. A plugin DRM module will also have to do all of the video rendering and displaying. Because if it just hands the unencrypted stream back to the browser then you could change the browser to simply write it to disk. The relevant DRM mechanisms will come from Apple, Microsoft, Google, and Adobe. Both Apple and Microsoft have no interest in supporting GNU/Linux. You won't get their DRM on GNU/Linux no matter how simple it is. Google seems to ship their DRM now on the GNU/Linux version of Chrome. But I don't know if the license allows using it in other browsers. Which would be hindered by the fact that Google uses their own unspecified PAPPI. Adobe wants to provide a DRM module for Firefox EME mechanism. But we all know from enough bad experience how well Adobe does GNU/Linux support. Flash on GNU/Linux was even worse than on any other system until they simply stopped it. They recently even stopped distributing Acrobat Reader for GNU/Linux. So yeah, great hope there. Even if they compile the module for GNU/Linux because Mozilla asks them to then we can expect the typical Adobe software safety and quality... Remember HTML5 was supposed to rid the world of Flash, Silverlight, and such things. Not force those binary blobs into the spec.

by aroman 12y ago

mappu 12y ago

That is a chrome UA, it has Chrome/X in it. Safari/X is a compatibility shim.

nacs 12y ago

That is the Chrome user agent. It mentions Safari and AppleWebkit for compatibility reasons but it's Chrome. Windows Chrome user-agent for reference: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36

emergentcypher 12y ago
Ah, yes, another reminder of the hilariously bad user-agent situation in today's web...

compedit 12y ago

(And indeed Safari on Yosemite can do just that in the developer previews) Yep, it's definitely a bit buggy and stops occasionally but it's usable!

voyou 12y ago

"the user-agent switch involves adding a Safari identifier" Well, the default user agent string for Chrome already has a Safari identifier in it, but I don't think Safari user agents have a Chrome identifier. The change being made in the post doesn't add a Safari identifier, because there was one there already, but it does change the OS string to Windows. So I think the explanation in the post is probably right.

azernik 12y ago

For a humorous history of why exactly the Chrome UA string claims to be Safari, see this: http://webaim.org/blog/user-agent-string-history/ http://webaim.org/blog/user-agent-string-history/

TazeTSchnitzel 12y ago
It's not complete without the new Windows Phone user agent, though: https://mobile.twitter.com/0xabad1dea/status/497122542885556224/photo/1 https://mobile.twitter.com/0xabad1dea/status/497122542885556...

higherpurpose 12y ago

I thought the whole point of "HTML5 DRM" was to be backed by hardware DRM. So are they giving up on that idea for Linux? And if they are, maybe hardware DRM isn't necessary on other platforms either.

jiggy2011 12y ago
HTML5 DRM (EME) only defines an interface between the DRM system and the browser, it doesn't specify the mechanism for the DRM itself, the CDM is a black box . You could have a DRM scheme based on ROT13 and it would be entirely valid. https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-med...

fafner 12y ago

What they mean is that the "Digital Restriction Management in HTML5" proposal is pushed by Google, Microsoft, and Netflix into the W3C spec. Apple has simply followed the proposal and implemented it as well. AFAIK Chrome, IE, Safari ship with it. Firefox will follow suite by adding a Restriction Module from Adobe (given Adobe's track record it will certainly be an amazingly fast, flexible, beautiful, efficient, and nice way of viewing videos...). So Web-Restrictions is kinda unstoppable now. Instead of having a plugin-free future with HTML5 we have an even worse situation.

Karunamon 12y ago
"No DRM" was never an option. The option was between 1 DRM standard and 50 (so silverlight and widevine and....). The W3C made the most pragmatic choice, here. I think DRM is still crap, but one system is unambiguously better than >1.
- girvo 12y ago
  Except Flash was at least used for stuff other than just DRM, so there was an incentive to get it working across all OSes. Linux is going to struggle once this is adopted, at least open browsers will, and that makes me sad
  - jiggy2011 12y ago
    The openness of the browser has nothing to do with it, the browser provides an interface to the DRM mechanism which could be open or closed source. Open source browsers like firefox already support proprietary plugins such as Flash. If anything this makes Linux support easier, because you no longer have to provide support for an entire virtual machine and all APIs such as Flash or Silverlight. The only software required will be the DRM module itself as everything else can be provided by the browser.
    - fafner 12y ago
      The DRM mechanism can't really be open source. You could simply change it to write the unencrypted video data to the disk if it were. A plugin DRM module will also have to do all of the video rendering and displaying. Because if it just hands the unencrypted stream back to the browser then you could change the browser to simply write it to disk. The relevant DRM mechanisms will come from Apple, Microsoft, Google, and Adobe. Both Apple and Microsoft have no interest in supporting GNU/Linux. You won't get their DRM on GNU/Linux no matter how simple it is. Google seems to ship their DRM now on the GNU/Linux version of Chrome. But I don't know if the license allows using it in other browsers. Which would be hindered by the fact that Google uses their own unspecified PAPPI. Adobe wants to provide a DRM module for Firefox EME mechanism. But we all know from enough bad experience how well Adobe does GNU/Linux support. Flash on GNU/Linux was even worse than on any other system until they simply stopped it. They recently even stopped distributing Acrobat Reader for GNU/Linux. So yeah, great hope there. Even if they compile the module for GNU/Linux because Mozilla asks them to then we can expect the typical Adobe software safety and quality... Remember HTML5 was supposed to rid the world of Flash, Silverlight, and such things. Not force those binary blobs into the spec.