6 ms·

There's a big difference - before these moves, DRM delivery of video had to be done using shitty nonstandard plugins or native apps, right? Whenever this happe

There's a big difference - before these moves, DRM delivery of video had to be done using shitty nonstandard plugins or native apps, right? Whenever this happens, usability suffers as well. And we had a real opportunity here to give users an open and non-broken standard as an alternative, on top of which alternative platforms for content delivery could be built, alternatives that could have won simply because of the ubiquitousness of the standard browser. Besides, DRM is technically and fundamentally broken. All my respect for W3C has gone down the window.

Silhouette 12y ago
I understand your frustration, but I think you're complaining that you didn't get an option that was never realistically on the table in the first place. Your respect for the W3C matters a lot less to them than millions of people being able to watch content produced by a billion dollar industry, which much of that industry simply isn't willing to make available without DRM-style safeguards at the present time. Yes, we used to use plug-ins for video. This worked reasonably well for quite a long time. I do think calling those plug-ins non-standard is a bit of a joke, given that Flash had 90+% market penetration for years and ran acceptably well almost everywhere, putting it far ahead of any browser in terms of portability and compatibility. By any reasonable definition, it was the de facto standard for on-line video streaming. Then Apple decided not to follow that standard and broke the Web for their users. For those users, a lot of major sites still "don't work properly" today because of Apple's arrogance. Browser makers are playing along anyway, so now we have an HTML5 video ecosystem where the closest thing to a universally supported video format is patent-encumbered anyway. It is still supported on fewer systems than video using Flash players used to be. And instead of security flaws with your "non-standard" plug-ins like Flash, you're inevitably going to see security flaws with whatever media extensions you install instead (unless you think low-level, natively executed code written in error-prone programming languages and provided by the same kinds of organisations who used to provide the plug-ins is somehow magically going to be secure this time around, in which case I know a Nigerian prince who has a great deal to offer you). This isn't progress. In what is becoming a serious and recurring problem with the modern web, issues other than what gives the best experience to users and makes things easiest for content providers to provide content are dominating the discussions. Many of the proposals are advocated by other parties with vested interests. And in the end, the result is that less stuff works, and stuff works less well, than the "legacy", "insecure" standards that have actually done the required job pretty well for a decade or two.
- TazeTSchnitzel 12y ago
  > I do think calling those plug-ins non-standard is a bit of a joke, given that Flash had 90+% market penetration for years Flash was also proprietary. It's closed-source, patent-encumbered, and has a single implementation. It's completely under the control of Adobe. https://en.wikipedia.org/wiki/Open_standard https://en.wikipedia.org/wiki/Open_standard > For those users, a lot of major sites still "don't work properly" today because of Apple's arrogance. As Apple explained countless times, it is not because of "arrogance" that they did not support Flash. Adobe weren't able to supply them with a working mobile Flash runtime, and Flash's resource use was a big problem (memory, CPU, battery life), so it couldn't run on mobile devices. Recall that the first iPhones had severely limited RAM (128MB!) and CPUs, and even when, years later, Android devices with Flash bundled were released, they couldn't run it terribly well. Flash was also a massive security and stability headache: as Apple loved to point out, it was the single largest source of application crashes on OS X.
  - crwll 12y ago
    Flash existed for Symbian OS (think Nokia smartphones) way before there was iPhones, and those devices naturally had even lower hardware specs. (I still agree that not supporting Flash was the correct choice for Apple, though.)
    - TazeTSchnitzel 12y ago
      > Flash existed for Symbian OS (think Nokia smartphones) way before there was iPhones, and those devices naturally had even lower hardware specs. I'm well aware! I had an HP iPaQ "Pocket PC" for a long time, and you could run a stripped-down version of Flash on it. But it ran slowly, and it only really worked for simple animations. You couldn't use something like YouTube on it, and it's things like YouTube that were the killer app for Flash.
    - 0x0 12y ago
      The flash thing that existed for symbian was not "Flash", it was "FlashLite", a very different plugin that supported exactly 0 of all the .swf files I tried to throw at it, including even super simple animations.
acdha 12y ago
I'll second Silhouette's comments that the desirable world you'd like to live in was never an option. The problem is simple: the major copyright owners insist on DRM and the inconvenience has not been enough to get many people to stop buying all but the most encumbered content. Sure, the usability was worse. That didn't stop many people from doing whatever they needed to play the video — it just trained a generation of web users to blindly install binaries when some random site told them too, much to the delight of malware authors. The only difference is that now people don't need to a traditional installer, the DRM code is sandboxed, updates are handled by the top-notch browser security teams rather than Adobe's also-rans, and every other component in the system uses open standards rather than being controlled by whatever Adobe/Microsoft decided should happen in Flash/Silverlight. Mozilla is at least making this obvious by telling you when it happens and giving you the option to disable it or even download a version of Firefox without it should you prefer: https://blog.mozilla.org/blog/2015/05/12/update-on-digital-rights-management-and-firefox/ https://blog.mozilla.org/blog/2015/05/12/update-on-digital-r... > we had a real opportunity here to give users an open and non-broken standard as an alternative You still have as much opportunity as you did before: nothing prevents you from signing up people who don't believe in DRM to offer their videos on your service. However, the odds of getting Sony, et al. on board remain as close to zero as they were before. If you want to do more than rant about this on the internet, focus on the economic side and ask what will get the average user to stop paying for DRMed content. That's the only thing which can change the status quo.
- vezzy-fnord 12y ago
  That traditional DRM was inconvenient and prone to user error is the entire point. It's supposed to be unpleasant. That somehow making it more convenient and adding a standards-endorsed API to facilitate its activation will somehow assist in combating it, is a nonsensical proposition. Furthermore, there is a separation of concerns aspect here. Why are web standards writers under any obligation to serve the interests of content providers in the latter's aim to restrict the capabilities of playback device producers? This isn't the web's problem. The issue is the sole responsibility of the content providers, who are not deserving of special privilege more than any other party. Standardizing an API to facilitate DRM presents a dangerous prospect in its tacit approval of such practices, and will only serve to prolong the practice as endorsement of it by standards bodies will legitimize the idea of DRM.

Silhouette 12y ago

I understand your frustration, but I think you're complaining that you didn't get an option that was never realistically on the table in the first place. Your respect for the W3C matters a lot less to them than millions of people being able to watch content produced by a billion dollar industry, which much of that industry simply isn't willing to make available without DRM-style safeguards at the present time. Yes, we used to use plug-ins for video. This worked reasonably well for quite a long time. I do think calling those plug-ins non-standard is a bit of a joke, given that Flash had 90+% market penetration for years and ran acceptably well almost everywhere, putting it far ahead of any browser in terms of portability and compatibility. By any reasonable definition, it was the de facto standard for on-line video streaming. Then Apple decided not to follow that standard and broke the Web for their users. For those users, a lot of major sites still "don't work properly" today because of Apple's arrogance. Browser makers are playing along anyway, so now we have an HTML5 video ecosystem where the closest thing to a universally supported video format is patent-encumbered anyway. It is still supported on fewer systems than video using Flash players used to be. And instead of security flaws with your "non-standard" plug-ins like Flash, you're inevitably going to see security flaws with whatever media extensions you install instead (unless you think low-level, natively executed code written in error-prone programming languages and provided by the same kinds of organisations who used to provide the plug-ins is somehow magically going to be secure this time around, in which case I know a Nigerian prince who has a great deal to offer you). This isn't progress. In what is becoming a serious and recurring problem with the modern web, issues other than what gives the best experience to users and makes things easiest for content providers to provide content are dominating the discussions. Many of the proposals are advocated by other parties with vested interests. And in the end, the result is that less stuff works, and stuff works less well, than the "legacy", "insecure" standards that have actually done the required job pretty well for a decade or two.

TazeTSchnitzel 12y ago
> I do think calling those plug-ins non-standard is a bit of a joke, given that Flash had 90+% market penetration for years Flash was also proprietary. It's closed-source, patent-encumbered, and has a single implementation. It's completely under the control of Adobe. https://en.wikipedia.org/wiki/Open_standard https://en.wikipedia.org/wiki/Open_standard > For those users, a lot of major sites still "don't work properly" today because of Apple's arrogance. As Apple explained countless times, it is not because of "arrogance" that they did not support Flash. Adobe weren't able to supply them with a working mobile Flash runtime, and Flash's resource use was a big problem (memory, CPU, battery life), so it couldn't run on mobile devices. Recall that the first iPhones had severely limited RAM (128MB!) and CPUs, and even when, years later, Android devices with Flash bundled were released, they couldn't run it terribly well. Flash was also a massive security and stability headache: as Apple loved to point out, it was the single largest source of application crashes on OS X.
- crwll 12y ago
  Flash existed for Symbian OS (think Nokia smartphones) way before there was iPhones, and those devices naturally had even lower hardware specs. (I still agree that not supporting Flash was the correct choice for Apple, though.)
  - TazeTSchnitzel 12y ago
    > Flash existed for Symbian OS (think Nokia smartphones) way before there was iPhones, and those devices naturally had even lower hardware specs. I'm well aware! I had an HP iPaQ "Pocket PC" for a long time, and you could run a stripped-down version of Flash on it. But it ran slowly, and it only really worked for simple animations. You couldn't use something like YouTube on it, and it's things like YouTube that were the killer app for Flash.
  - 0x0 12y ago
    The flash thing that existed for symbian was not "Flash", it was "FlashLite", a very different plugin that supported exactly 0 of all the .swf files I tried to throw at it, including even super simple animations.

acdha 12y ago

I'll second Silhouette's comments that the desirable world you'd like to live in was never an option. The problem is simple: the major copyright owners insist on DRM and the inconvenience has not been enough to get many people to stop buying all but the most encumbered content. Sure, the usability was worse. That didn't stop many people from doing whatever they needed to play the video — it just trained a generation of web users to blindly install binaries when some random site told them too, much to the delight of malware authors. The only difference is that now people don't need to a traditional installer, the DRM code is sandboxed, updates are handled by the top-notch browser security teams rather than Adobe's also-rans, and every other component in the system uses open standards rather than being controlled by whatever Adobe/Microsoft decided should happen in Flash/Silverlight. Mozilla is at least making this obvious by telling you when it happens and giving you the option to disable it or even download a version of Firefox without it should you prefer: https://blog.mozilla.org/blog/2015/05/12/update-on-digital-rights-management-and-firefox/ https://blog.mozilla.org/blog/2015/05/12/update-on-digital-r... > we had a real opportunity here to give users an open and non-broken standard as an alternative You still have as much opportunity as you did before: nothing prevents you from signing up people who don't believe in DRM to offer their videos on your service. However, the odds of getting Sony, et al. on board remain as close to zero as they were before. If you want to do more than rant about this on the internet, focus on the economic side and ask what will get the average user to stop paying for DRMed content. That's the only thing which can change the status quo.

vezzy-fnord 12y ago
That traditional DRM was inconvenient and prone to user error is the entire point. It's supposed to be unpleasant. That somehow making it more convenient and adding a standards-endorsed API to facilitate its activation will somehow assist in combating it, is a nonsensical proposition. Furthermore, there is a separation of concerns aspect here. Why are web standards writers under any obligation to serve the interests of content providers in the latter's aim to restrict the capabilities of playback device producers? This isn't the web's problem. The issue is the sole responsibility of the content providers, who are not deserving of special privilege more than any other party. Standardizing an API to facilitate DRM presents a dangerous prospect in its tacit approval of such practices, and will only serve to prolong the practice as endorsement of it by standards bodies will legitimize the idea of DRM.