61–70 of 133 posts
Honest question to Firefox dev's: I want to keep using firefox, but not the DRM thingy. I'd rather not see any video on the web, to be forced to use DRM technology. Do you plan to support a DRM-free version?
Honest question to Firefox dev's: I want to keep using firefox, but not the DRM thingy. I'd rather not see any video on the web, to be forced to use DRM technology. Do you plan to support a DRM-free version?
http://download.cdn.mozilla.net/pub/firefox/releases/38.0/wi...
Honest question to Firefox dev's: I want to keep using firefox, but not the DRM thingy. I'd rather not see any video on the web, to be forced to use DRM technology. Do you plan to support a DRM-free version?
Can someone explain why Mozilla is not signing gmpopenh264.dll and now eme-adobe.dll? These are executed from AppData (a folder with read/write permissions). Executing dll's from AppData is generally a bad idea but if I'm going to allow it I at least want a Publisher rule attached. Google signs their CDM (WideVine) dll delivered with Chrome that executes from AppData, why isn't Mozilla?
Earlier quoted context omitted.
My menu button on the right of the address/search bar doesn't work anymore either. (OSX 10.10.2) Gonna uninstall/reinstall
Was still doing it on a clean install, it didn't like something in my profile... renamed it, and re-installed my addons in a new profile and it's fine now. Unamused.
Interesting, I had not heard of ruby before! (more info here, as linked in TFA https://hacks.mozilla.org/2015/03/ruby-support-in-firefox-de... )
I was really surprised to see this wasn't implemented much earlier. Chrome apparently had support for XHTML 1.1 Ruby since 2010! I am also surprised to see how verbose actual ruby markup is. Better examples of mark-up on wikipedia: https://en.wikipedia.org/wiki/Ruby_character#HTML_markup
0: https://addons.mozilla.org/en-US/firefox/addon/html-ruby/
Earlier quoted context omitted.
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…
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…
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.
What happened to opportunistic encryption? I loved that feature but it was disabled because of a bug. I hoped it would be enabled again in the next major release, but no mention of it. Can someone from Mozilla tell me more?
Earlier quoted context omitted.
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…
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…
That's why there was a push for standardization anyways. Dealing with all the quirks of all the platforms was becoming difficult for the copyright owners.
There was no reason that the W3C should have made this easier for them. The only thing that the copyright owners want more than DRM is an audience. The browser vendors held the audience, and handed them over without even a fight.
That was the best opportunity we had. Sure we can try to get consumers to turn away from DRM, but that's just not going to happen, we already turned in our trump card.
Earlier quoted context omitted.
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…
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, w…
How well did Flash on Android work? The answer is "not very". Jobs was (apparently) entirely correct when he wrote that Adobe was never able to show him a version of mobile Flash that wasn't complete garbage.