Firefox 38 released(mozilla.org)
mozilla.org
Firefox 38 released
https://www.mozilla.org/en-US/firefox/38.0/releasenotes/
132 comments
Hey Touche, I work on Firefox at Mozilla. We launched EME on Win32 (Vista+) first because that is by far the biggest share of Fx users. We will keep rolling out new platforms, the work will be long and hard. Streaming providers want to move off of Silverlight and Flash but will still support them for the foreseeable future, so content is still available.
I don't doubt you will add EME to other platforms, but that doesn't mean anything if there are no supported DRM for that platform.
You should be ashamed of doing the work of adding EME to Firefox.
Please don't add it to other platforms. Remove it from Windows.
If the work will be long and hard there are better uses of your time than working to ensure that "streaming providers" can oppose Mozilla's vision of an open web.
Please don't add it to other platforms. Remove it from Windows.
If the work will be long and hard there are better uses of your time than working to ensure that "streaming providers" can oppose Mozilla's vision of an open web.
> If the work will be long and hard there are better uses of your time than working to ensure that "streaming providers" can oppose Mozilla's vision of an open web.
Your criticism is misguided; as soon as the W3C endorsed EME, it was all but a done deal that Firefox would have to support it. Microsoft and Google have no interest in keeping proprietary software out of their browsers, and the only alternative is for Firefox to fall behind in both standards compliance and market share. That serves nobody's interest.
If what you want is Firefox but without EME, then the answer is: Firefox. (Firefox doesn't require you to use EME). If you really want Firefox but without EME even available by default, then use Iceweasel[0].
[0] which is what I'm using to type this comment, FWIW.
Your criticism is misguided; as soon as the W3C endorsed EME, it was all but a done deal that Firefox would have to support it. Microsoft and Google have no interest in keeping proprietary software out of their browsers, and the only alternative is for Firefox to fall behind in both standards compliance and market share. That serves nobody's interest.
If what you want is Firefox but without EME, then the answer is: Firefox. (Firefox doesn't require you to use EME). If you really want Firefox but without EME even available by default, then use Iceweasel[0].
[0] which is what I'm using to type this comment, FWIW.
It wasn't even a question of the W3C endorsing it as much as Apple, Google and Microsoft making it clear that they were going to implement what Netflix, YouTube, etc. needed, producing the situation exactly as you described it. The W3C simply let more of that happen in the open rather than at private meetings.
Don't criticize Mozilla. The users have spoken and the vast majority don't care about DRM on streaming media. They just want to watch YouTube, Vimeo, Netflix, etc in their browser and have it work. Google, Apple et al put their full weight behind DRM and patent-encumbered formats, so Mozilla has to go along with it to stay relevant.
If you don't want EME on principle, an alternate version of Firefox without EME is available.
If you don't want EME on principle, an alternate version of Firefox without EME is available.
The users have spoken and the vast majority don't care about DRM on streaming media.
{{citation-needed}}
They just want to watch YouTube, Vimeo, Netflix, etc in their browser and have it work.
YouTube works fine now. Netflix is a temporary aberration most of the world has never heard of or used. It's not the browser's job to support broken, predatory businesses. We spent 15+ years waiting and just achieved flashless and open video... let's use it.
Google, Apple et al put their full weight behind DRM and patent-encumbered formats, so Mozilla has to go along with it to stay relevant.
{{citation-needed}}
Edit (out of posts): Yes, pay per view is a broken model. You are correct that Mozilla sticking to its guns risks a reduced user base. However, Mozilla blindly following other browser vendors removes its fundamental value and USP. The reality is that the internet wants not just 'open', but also meaningful choice. Many of us believe that Mozilla has, in this case, missed the boat.
{{citation-needed}}
They just want to watch YouTube, Vimeo, Netflix, etc in their browser and have it work.
YouTube works fine now. Netflix is a temporary aberration most of the world has never heard of or used. It's not the browser's job to support broken, predatory businesses. We spent 15+ years waiting and just achieved flashless and open video... let's use it.
Google, Apple et al put their full weight behind DRM and patent-encumbered formats, so Mozilla has to go along with it to stay relevant.
{{citation-needed}}
Edit (out of posts): Yes, pay per view is a broken model. You are correct that Mozilla sticking to its guns risks a reduced user base. However, Mozilla blindly following other browser vendors removes its fundamental value and USP. The reality is that the internet wants not just 'open', but also meaningful choice. Many of us believe that Mozilla has, in this case, missed the boat.
> YouTube works fine now.
YouTube cat videos work fine without DRM, but YouTube is expanding into pay-per-view content that relies on Google's own Widevine DRM.
> Google, Apple et al put their full weight behind DRM and patent-encumbered formats, so Mozilla has to go along with it to stay relevant.
Mozilla tried to hold out on H.264, waiting for Google to fulfill their promise to drop H.264 from Chrome. Google broke their promise and Firefox lost many users in the meantime. If Netflix doesn't work in Firefox or YouTube is "best viewed in Chrome", then Mozilla will lose users and relevance in guiding future web standards and privacy.
YouTube cat videos work fine without DRM, but YouTube is expanding into pay-per-view content that relies on Google's own Widevine DRM.
> Google, Apple et al put their full weight behind DRM and patent-encumbered formats, so Mozilla has to go along with it to stay relevant.
Mozilla tried to hold out on H.264, waiting for Google to fulfill their promise to drop H.264 from Chrome. Google broke their promise and Firefox lost many users in the meantime. If Netflix doesn't work in Firefox or YouTube is "best viewed in Chrome", then Mozilla will lose users and relevance in guiding future web standards and privacy.
That same 'vast majority' also don't seem to care about the erosion of liberty in western countries, but that doesn't make it right or good, does it.
> Mac OS X: Implemented a subset of the Media Source Extensions (MSE) API to allow native HTML5 playback on YouTube HTML5
Media Source Extensions, while compatible with Encrypted Media Extensions, the DRM system, are not DRM. They let JavaScript manipulate the byte streams of the video data before it goes to the video codec, so you can handle streaming and such from JS.
Media Source Extensions, while compatible with Encrypted Media Extensions, the DRM system, are not DRM. They let JavaScript manipulate the byte streams of the video data before it goes to the video codec, so you can handle streaming and such from JS.
What video could you watch before that you cannot watch now? I also wish we lived in a world which didn't need EME but it's not like the status quo was video which played for everyone. It just meant that everyone had to download monthly updates to avoid security problems with the massive plugin they used to play video and Linux, etc. users were largely still screwed.
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.
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.
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-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.
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-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.
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.
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.
> 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.
That is nonsensical but if you were to read my comment, you'll note it's not a proposition I made.
This really isn't hard: 1. Consumers are happily paying for DRMed content 2. The big media companies are not willing to consider releasing content without DRM 3. Nobody likes maintaining plugins or the lower video quality they entail 4. Apple, Google and Microsoft made it clear that they were going to solve #3 by implementing whatever Netflix, YouTube, Hulu, etc. need to 5. The W3C and Mozilla accepted #4 and used what power they do have to push the process into a public forum. Mozilla has been particularly active to increase user awareness and make it more obvious when your actions are being restricted at a content owner's bequest.
There was no step where someone waves a magic wand and Hollywood stops demanding DRM.
With or without a W3C spec, most desktop users and nearly all mobile users were going to have a browser with DRM playback features. That means there's no step where Mozilla makes EME content harder to use and the reaction is something better than users dropping Firefox for Chrome/IE/Safari.
Again, if you care about this issue the question to focus on is how changing #1. As long as people keep paying for DRMed content, none of the other parties will have the incentive or ability to change.
That is nonsensical but if you were to read my comment, you'll note it's not a proposition I made.
This really isn't hard: 1. Consumers are happily paying for DRMed content 2. The big media companies are not willing to consider releasing content without DRM 3. Nobody likes maintaining plugins or the lower video quality they entail 4. Apple, Google and Microsoft made it clear that they were going to solve #3 by implementing whatever Netflix, YouTube, Hulu, etc. need to 5. The W3C and Mozilla accepted #4 and used what power they do have to push the process into a public forum. Mozilla has been particularly active to increase user awareness and make it more obvious when your actions are being restricted at a content owner's bequest.
There was no step where someone waves a magic wand and Hollywood stops demanding DRM.
With or without a W3C spec, most desktop users and nearly all mobile users were going to have a browser with DRM playback features. That means there's no step where Mozilla makes EME content harder to use and the reaction is something better than users dropping Firefox for Chrome/IE/Safari.
Again, if you care about this issue the question to focus on is how changing #1. As long as people keep paying for DRMed content, none of the other parties will have the incentive or ability to change.
I disagree. The pains of DRM were growing. The usability wasn't bad enough yet, but it was getting worse. As people use more and more devices and they want their media in all places, the existing plugins were getting less suitable.
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.
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.
> There was no reason that the W3C should have made this easier for them.
MS, Google, and Apple would've set up their own venue to standardise the exact same thing. The W3C having it within their walls is really not that relevant to the outcome of this.
MS, Google, and Apple would've set up their own venue to standardise the exact same thing. The W3C having it within their walls is really not that relevant to the outcome of this.
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.
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.
> 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
> 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.
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
> 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.
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.)
(I still agree that not supporting Flash was the correct choice for Apple, though.)
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.
> 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.
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.
Even though Apple was right in the end, I think calling Apple "arrogant" is quite on the mark. It is they who denied opening up MobileSafari for 3rd party plugins (yet it supports 1st party plugins; in earlier versions you could even iterate the navigator.plugins property and see quicktime there). I remember seeing Adobe hinting heavily that they even had a working flash plugin (for jailbroken phones?) going internally. In fact, I think early Adobe Air applications targeting iOS shipped with an embedded flash player engine, until Apple started rejecting all applications "not compiled with apple-gcc from objective-c" and banning "interpreted code", so Adobe even went as far as writing an AS3 LLVM compiler, so that newer Adobe Air applications were compiled down to native arm assembly with no flash runtime present.
See for example http://web.archive.org/web/20130302154428/http://www.adobe.c...
I bet the real reason for blocking flash player in Mobile Safari was to block all the flash based ad banners of the day. It would have degraded battery life and the user experience quite a lot.
See for example http://web.archive.org/web/20130302154428/http://www.adobe.c...
I bet the real reason for blocking flash player in Mobile Safari was to block all the flash based ad banners of the day. It would have degraded battery life and the user experience quite a lot.
> It is they who denied opening up MobileSafari for 3rd party plugins
...how is that arrogant? They wanted to only allow standard technologies? What is wrong with that?
> yet it supports 1st party plugins; in earlier versions you could even iterate the navigator.plugins property and see quicktime there
It had "quicktime" as a "plugin" but I believe that just launched the video player. Similarly, Apple replaced YouTube video embeds (Flash) with the video player. No plugins there.
> I remember seeing Adobe hinting heavily that they even had a working flash plugin (for jailbroken phones?) going internally.
Yes, Adobe did. It didn't work very well.
> I bet the real reason for blocking flash player in Mobile Safari was to block all the flash based ad banners of the day. It would have degraded battery life and the user experience quite a lot.
Flash period would ruin battery life. Similar to why iOS has no multitasking.
...how is that arrogant? They wanted to only allow standard technologies? What is wrong with that?
> yet it supports 1st party plugins; in earlier versions you could even iterate the navigator.plugins property and see quicktime there
It had "quicktime" as a "plugin" but I believe that just launched the video player. Similarly, Apple replaced YouTube video embeds (Flash) with the video player. No plugins there.
> I remember seeing Adobe hinting heavily that they even had a working flash plugin (for jailbroken phones?) going internally.
Yes, Adobe did. It didn't work very well.
> I bet the real reason for blocking flash player in Mobile Safari was to block all the flash based ad banners of the day. It would have degraded battery life and the user experience quite a lot.
Flash period would ruin battery life. Similar to why iOS has no multitasking.
Flash was also proprietary. It's closed-source, patent-encumbered, and has a single implementation. It's completely under the control of Adobe.
Perhaps, but I'm not sure how any of this is different to the various media extension proposals/standards we're starting to see more recently.
And at least before, if you wanted to serve video from your web site, all you had to do was get one of the numerous Flash video players and prepare one version of your videos that would work in that player on almost any device.
As Apple explained countless times, it is not because of "arrogance" that they did not support Flash.
Please forgive me if I don't take their word for it. The thing is, Flash has run -- and reasonably well -- on numerous other mobile devices, even some from quite a few years ago, so I don't really buy the performance arguments. Even if they had been true for early generations of smartphones and tablets, the performance of these types of device was always expected to increase significantly over time, as indeed it has.
If the performance would still be a problem on today's iOS devices then presumably Apple's users would opt for other implementations instead, but as far as I'm aware, Apple still have an effective monopoly on distribution of software that runs on iOS devices, and they can and do block anything they don't like for sometimes not entirely clear (or, some might argue, entirely fair) reasons. So no-one was ever allowed to decide whether Flash running on a modern iPhone or iPad would have been OK, because that option was removed from the table, and we were left with devices that have bugs and/or non-standard behaviours in basic functionality.
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.
Leaving aside the disturbing implications of Apple actually having a reliable data set on which to base such a claim, browsers are a constant security and stability headache. Take a look at the release notes for Chrome or Firefox, and see how often that little update every few weeks includes at least one critical security update, and how often they have glitches so bad they have to push an out-of-band update instead of waiting just a few weeks. As I said before, there seems little reason to expect better results just because someone shifts things like video rendering and DRM technologies to a slightly different bit of low-level, native, closed source, patent-encumbered, even-the-browser-devs-don't-see-it code written in an error-prone language by the same kinds of development team that wrote the plug-ins.
Perhaps, but I'm not sure how any of this is different to the various media extension proposals/standards we're starting to see more recently.
And at least before, if you wanted to serve video from your web site, all you had to do was get one of the numerous Flash video players and prepare one version of your videos that would work in that player on almost any device.
As Apple explained countless times, it is not because of "arrogance" that they did not support Flash.
Please forgive me if I don't take their word for it. The thing is, Flash has run -- and reasonably well -- on numerous other mobile devices, even some from quite a few years ago, so I don't really buy the performance arguments. Even if they had been true for early generations of smartphones and tablets, the performance of these types of device was always expected to increase significantly over time, as indeed it has.
If the performance would still be a problem on today's iOS devices then presumably Apple's users would opt for other implementations instead, but as far as I'm aware, Apple still have an effective monopoly on distribution of software that runs on iOS devices, and they can and do block anything they don't like for sometimes not entirely clear (or, some might argue, entirely fair) reasons. So no-one was ever allowed to decide whether Flash running on a modern iPhone or iPad would have been OK, because that option was removed from the table, and we were left with devices that have bugs and/or non-standard behaviours in basic functionality.
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.
Leaving aside the disturbing implications of Apple actually having a reliable data set on which to base such a claim, browsers are a constant security and stability headache. Take a look at the release notes for Chrome or Firefox, and see how often that little update every few weeks includes at least one critical security update, and how often they have glitches so bad they have to push an out-of-band update instead of waiting just a few weeks. As I said before, there seems little reason to expect better results just because someone shifts things like video rendering and DRM technologies to a slightly different bit of low-level, native, closed source, patent-encumbered, even-the-browser-devs-don't-see-it code written in an error-prone language by the same kinds of development team that wrote the plug-ins.
> Perhaps, but I'm not sure how any of this is different to the various media extension proposals/standards we're starting to see more recently.
Encrypted Media Extensions is an open standard. The small DRM plugins that use it aren't open, but the core standard is. You've moved from a closed, proprietary system for the entire application, to a closed system for just the DRM and nothing else. That's huge progress.
> Please forgive me if I don't take their word for it. The thing is, Flash has run -- and reasonably well -- on numerous other mobile devices, even some from quite a few years ago
No it hasn't. "Flash Lite" worked, but slowly, and it couldn't do anything useful. The killer app for Flash was largely video and games, both of which don't work well in Flash on phones.
> Even if they had been true for early generations of smartphones and tablets, the performance of these types of device was always expected to increase significantly over time, as indeed it has.
By the time Flash could run well on the iPhone, the web had largely gotten rid of Flash and it was fast becoming a legacy technology, so there was no point in supporting it.
> If the performance would still be a problem on today's iOS devices then presumably Apple's users would opt for other implementations instead
The performance is now irrelevant because the web has moved on from Flash.
> browsers are a constant security and stability headache.
Yes, they are! But adding an extra attack surface for those two fronts is never a good idea if you can avoid it.
If you can avoid adding a binary blob to your browser that has frequent security issues, why wouldn't you do so?
> As I said before, there seems little reason to expect better results just because someone shifts things like video rendering and DRM technologies to a slightly different bit of low-level, native, closed source, patent-encumbered, even-the-browser-devs-don't-see-it code written in an error-prone language by the same kinds of development team that wrote the plug-ins.
No video rendering is done by EME, and EME doesn't and probably never will run on the iPhone.
Encrypted Media Extensions is an open standard. The small DRM plugins that use it aren't open, but the core standard is. You've moved from a closed, proprietary system for the entire application, to a closed system for just the DRM and nothing else. That's huge progress.
> Please forgive me if I don't take their word for it. The thing is, Flash has run -- and reasonably well -- on numerous other mobile devices, even some from quite a few years ago
No it hasn't. "Flash Lite" worked, but slowly, and it couldn't do anything useful. The killer app for Flash was largely video and games, both of which don't work well in Flash on phones.
> Even if they had been true for early generations of smartphones and tablets, the performance of these types of device was always expected to increase significantly over time, as indeed it has.
By the time Flash could run well on the iPhone, the web had largely gotten rid of Flash and it was fast becoming a legacy technology, so there was no point in supporting it.
> If the performance would still be a problem on today's iOS devices then presumably Apple's users would opt for other implementations instead
The performance is now irrelevant because the web has moved on from Flash.
> browsers are a constant security and stability headache.
Yes, they are! But adding an extra attack surface for those two fronts is never a good idea if you can avoid it.
If you can avoid adding a binary blob to your browser that has frequent security issues, why wouldn't you do so?
> As I said before, there seems little reason to expect better results just because someone shifts things like video rendering and DRM technologies to a slightly different bit of low-level, native, closed source, patent-encumbered, even-the-browser-devs-don't-see-it code written in an error-prone language by the same kinds of development team that wrote the plug-ins.
No video rendering is done by EME, and EME doesn't and probably never will run on the iPhone.
You've moved from a closed, proprietary system for the entire application, to a closed system for just the DRM and nothing else. That's huge progress.
Is it, really? You're still supporting DRM, because that's the basic requirement here. You're still therefore running unknown, closed source code that is prima facie working against your interests as a user. You still have an extra potential attack vector for malware. Sure, the scale may (or may not) be smaller, but qualitatively it seems the key facts are still the same.
The killer app for Flash was largely video and games, both of which don't work well in Flash on phones.
Flash on phones only really lasted for about two years, and given that the earliest phones somewhere around 2010 were running something like 1GHz low-power processors, it's not entirely surprising that the initial performance wasn't great.
The game was basically over by mid-2012 and Jelly Bean, but by that time, there had been quite a few reasonable investigations into how many of the reputed performance problems were real, and how many were either out-of-date or just plain false. Various video hosting sites that had been reported to perform badly in earlier criticism were debunked, with evidence that the other junk on the sites was causing more of a problem than the Flash video itself and that similar Flash videos could play just fine on devices of the 2011-2012 era. Likewise claims that Flash seriously reduced battery life didn't stand up to careful scrutiny over several days of investigation in some cases; battery life was generally found to be reduced, by sometimes by no more than a few minutes.
And that was with mobile technology from 3-5 years ago, which of course had quite a bit less processing power and lower battery life than the modern equivalents.
By the time Flash could run well on the iPhone, the web had largely gotten rid of Flash and it was fast becoming a legacy technology
When did Flash ever run on the iPhone?
The performance is now irrelevant because the web has moved on from Flash.
Given the number of sites I run into that still don't work properly on an iPad, I have to disagree. Maybe the sites you visit regularly have moved on, but there are a lot more sites using Flash than YouTube and other similarly large video sites with similarly large budgets to update their sites and convert their content to the brave new world of HTML5 video.
If you can avoid adding a binary blob to your browser that has frequent security issues, why wouldn't you do so?
Because I have concerns beyond just security. I don't run a browser so I can be secure. I run a browser so I can browse. When you take security so far that you break the basic functionality of your system, you aren't so much securing it as... breaking the basic functionality of your system.
In any case, with the new model using media extensions, we still will be adding binary blobs to the browser, and as I've said before, I see no reason to expect that these ones will somehow not turn into security vulnerabilities sooner or later the same way just about every other web technology in history has.
Is it, really? You're still supporting DRM, because that's the basic requirement here. You're still therefore running unknown, closed source code that is prima facie working against your interests as a user. You still have an extra potential attack vector for malware. Sure, the scale may (or may not) be smaller, but qualitatively it seems the key facts are still the same.
The killer app for Flash was largely video and games, both of which don't work well in Flash on phones.
Flash on phones only really lasted for about two years, and given that the earliest phones somewhere around 2010 were running something like 1GHz low-power processors, it's not entirely surprising that the initial performance wasn't great.
The game was basically over by mid-2012 and Jelly Bean, but by that time, there had been quite a few reasonable investigations into how many of the reputed performance problems were real, and how many were either out-of-date or just plain false. Various video hosting sites that had been reported to perform badly in earlier criticism were debunked, with evidence that the other junk on the sites was causing more of a problem than the Flash video itself and that similar Flash videos could play just fine on devices of the 2011-2012 era. Likewise claims that Flash seriously reduced battery life didn't stand up to careful scrutiny over several days of investigation in some cases; battery life was generally found to be reduced, by sometimes by no more than a few minutes.
And that was with mobile technology from 3-5 years ago, which of course had quite a bit less processing power and lower battery life than the modern equivalents.
By the time Flash could run well on the iPhone, the web had largely gotten rid of Flash and it was fast becoming a legacy technology
When did Flash ever run on the iPhone?
The performance is now irrelevant because the web has moved on from Flash.
Given the number of sites I run into that still don't work properly on an iPad, I have to disagree. Maybe the sites you visit regularly have moved on, but there are a lot more sites using Flash than YouTube and other similarly large video sites with similarly large budgets to update their sites and convert their content to the brave new world of HTML5 video.
If you can avoid adding a binary blob to your browser that has frequent security issues, why wouldn't you do so?
Because I have concerns beyond just security. I don't run a browser so I can be secure. I run a browser so I can browse. When you take security so far that you break the basic functionality of your system, you aren't so much securing it as... breaking the basic functionality of your system.
In any case, with the new model using media extensions, we still will be adding binary blobs to the browser, and as I've said before, I see no reason to expect that these ones will somehow not turn into security vulnerabilities sooner or later the same way just about every other web technology in history has.
> Is it, really? You're still supporting DRM, because that's the basic requirement here. You're still therefore running unknown, closed source code that is prima facie working against your interests as a user.
On far, far less websites, however. One or two video streaming services have DRM. Banner ads in most pages will not be using EME.
> You still have an extra potential attack vector for malware.
This is true, but one with a smaller surface area. One that might not even be installed, in many cases.
> Flash on phones only really lasted for about two years, and given that the earliest phones somewhere around 2010 were running something like 1GHz low-power processors, it's not entirely surprising that the initial performance wasn't great.
1GHz is slow, now? Wow, Flash must have sucked even more than I thought.
> Various video hosting sites that had been reported to perform badly in earlier criticism were debunked, with evidence that the other junk on the sites was causing more of a problem than the Flash video itself and that similar Flash videos could play just fine on devices of the 2011-2012 era. Likewise claims that Flash seriously reduced battery life didn't stand up to careful scrutiny over several days of investigation in some cases; battery life was generally found to be reduced, by sometimes by no more than a few minutes.
Links? I'd be highly sceptical of this claim: software video decoding is not good for battery life, for example. Of course if it's H.264 I'm sure Flash would use the hardware support, but why would you use Flash in that case?
> When did Flash ever run on the iPhone?
Never, but I mean by the time that the iPhone was powerful enough that getting Flash to run on it might be reasonable.
> Given the number of sites I run into that still don't work properly on an iPad, I have to disagree.
Most of the web has moved on. There are still plenty of sites that don't work with mobile devices and require plugin downloads to be used modern browsers, it's true, but it's a number that is continually decreasing.
> Because I have concerns beyond just security. I don't run a browser so I can be secure. I run a browser so I can browse. When you take security so far that you break the basic functionality of your system, you aren't so much securing it as... breaking the basic functionality of your system.
Flash support isn't "basic functionality". It's a bonus. Mobile devices can't and shouldn't support browsing every website made for a PC in existence, they just need to support most reasonably well, and that they do. After all, PCs still exist.
Mobile devices also don't support simulating right-clicks, Java applets, the Unity web player, ActiveX controls, and so on.
> In any case, with the new model using media extensions, we still will be adding binary blobs to the browser,
Smaller ones with much more limited scope, used in far less places, and which you can blacklist without breaking a lot of websites.
On far, far less websites, however. One or two video streaming services have DRM. Banner ads in most pages will not be using EME.
> You still have an extra potential attack vector for malware.
This is true, but one with a smaller surface area. One that might not even be installed, in many cases.
> Flash on phones only really lasted for about two years, and given that the earliest phones somewhere around 2010 were running something like 1GHz low-power processors, it's not entirely surprising that the initial performance wasn't great.
1GHz is slow, now? Wow, Flash must have sucked even more than I thought.
> Various video hosting sites that had been reported to perform badly in earlier criticism were debunked, with evidence that the other junk on the sites was causing more of a problem than the Flash video itself and that similar Flash videos could play just fine on devices of the 2011-2012 era. Likewise claims that Flash seriously reduced battery life didn't stand up to careful scrutiny over several days of investigation in some cases; battery life was generally found to be reduced, by sometimes by no more than a few minutes.
Links? I'd be highly sceptical of this claim: software video decoding is not good for battery life, for example. Of course if it's H.264 I'm sure Flash would use the hardware support, but why would you use Flash in that case?
> When did Flash ever run on the iPhone?
Never, but I mean by the time that the iPhone was powerful enough that getting Flash to run on it might be reasonable.
> Given the number of sites I run into that still don't work properly on an iPad, I have to disagree.
Most of the web has moved on. There are still plenty of sites that don't work with mobile devices and require plugin downloads to be used modern browsers, it's true, but it's a number that is continually decreasing.
> Because I have concerns beyond just security. I don't run a browser so I can be secure. I run a browser so I can browse. When you take security so far that you break the basic functionality of your system, you aren't so much securing it as... breaking the basic functionality of your system.
Flash support isn't "basic functionality". It's a bonus. Mobile devices can't and shouldn't support browsing every website made for a PC in existence, they just need to support most reasonably well, and that they do. After all, PCs still exist.
Mobile devices also don't support simulating right-clicks, Java applets, the Unity web player, ActiveX controls, and so on.
> In any case, with the new model using media extensions, we still will be adding binary blobs to the browser,
Smaller ones with much more limited scope, used in far less places, and which you can blacklist without breaking a lot of websites.
> 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.
I don't know why you're getting downvoted. I also gather downvotes whenevver I make a comment like this. The current crop of content producers will not produce content without some guarantees/safeguards. There was never an option to outright refuse these conditions because we would simply be left with no content at all or it would be completely locked to proprietary hardware and/or platforms.
I don't know why you're getting downvoted. I also gather downvotes whenevver I make a comment like this. The current crop of content producers will not produce content without some guarantees/safeguards. There was never an option to outright refuse these conditions because we would simply be left with no content at all or it would be completely locked to proprietary hardware and/or platforms.
If their only option is to produce content without "safeguards", they'll produce it without safeguards. Content will be pirated regardless of whether browsers have DRM.
It's not a question about the reality of the piracy situation, because that hasn't changed since the VHS copy protection days. Simply having some sort of protection there - no matter how ineffective - gives them legally-effective leverage to go after those bypassing it. You cannot, as a stakeholder (content producer, actor, etc), argue in good conscience for no protection whatsoever in a commercial venture.
Yes, there is a major distribution, availability, region and device-lockdown issue to be solved. But removing all protection is just the brute-force, blanket solution that is understandably one-sided and thus unworkable.
Yes, there is a major distribution, availability, region and device-lockdown issue to be solved. But removing all protection is just the brute-force, blanket solution that is understandably one-sided and thus unworkable.
> Simply having some sort of protection there - no matter how ineffective - gives them legally-effective leverage to go after those bypassing it.
Use JavaScript, then.
Use JavaScript, then.
But they'll always have the alternative option of providing content through iTunes/their own crappy locked down system.
Pretty much everything under the sun is already being pirated, and yet content produces are producing content without any guarantees or safeguards.
Thanks for the support. I didn't actually see that post go negative -- it's well into positive territory as I write this -- but it isn't that surprising to me.
There are a lot of people in tech, and particularly in web-related tech, who are very enthusiastic, but whose admirable enthusiasm is not always matched by their realism or level of experience. Any time you challenge an idealised view that something that's being done today is inherently better than something that was done yesterday, you tend to get some resistance. This tends to go double when the reasons for the challenge are based on pragmatic concerns rather than simply trying to use the newest and shiniest tech, as in this case.
There have been many examples over the years: the old CSS-vs-table-layout debate, progressive enhancement/graceful degradation, general hostility towards any sort of plug-ins, general hostility towards DRM schemes (or charging for access to anything, for that matter), "evergreen" browsers vs. IE, A/B testing vs. just about anything else, and recently more variations involving JS or CSS frameworks than I can even count any more. And of course $deity help you if you think flat design is mostly poorly executed rubbish and the worst general trend in design and usability for a generation, because Apple, Microsoft and Google all love it so it must be good! ;-)
So whether or not it attracts some downvotes, I think it's important for someone to challenge new assumptions in these kinds of cases. That's how we figure out what really works, because it stands up to scrutiny. It's also how we shine a light on people who are "moving forward in reverse", however good their intentions or interesting their ideas, and try to steer the industry a tiny bit closer towards something more productive.
There are a lot of people in tech, and particularly in web-related tech, who are very enthusiastic, but whose admirable enthusiasm is not always matched by their realism or level of experience. Any time you challenge an idealised view that something that's being done today is inherently better than something that was done yesterday, you tend to get some resistance. This tends to go double when the reasons for the challenge are based on pragmatic concerns rather than simply trying to use the newest and shiniest tech, as in this case.
There have been many examples over the years: the old CSS-vs-table-layout debate, progressive enhancement/graceful degradation, general hostility towards any sort of plug-ins, general hostility towards DRM schemes (or charging for access to anything, for that matter), "evergreen" browsers vs. IE, A/B testing vs. just about anything else, and recently more variations involving JS or CSS frameworks than I can even count any more. And of course $deity help you if you think flat design is mostly poorly executed rubbish and the worst general trend in design and usability for a generation, because Apple, Microsoft and Google all love it so it must be good! ;-)
So whether or not it attracts some downvotes, I think it's important for someone to challenge new assumptions in these kinds of cases. That's how we figure out what really works, because it stands up to scrutiny. It's also how we shine a light on people who are "moving forward in reverse", however good their intentions or interesting their ideas, and try to steer the industry a tiny bit closer towards something more productive.
> For those users, a lot of major sites still "don't work properly" today because of Apple's arrogance.
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.
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.
It worked fine, actually. Considering that was a good 5 years ago and phones were a fraction as fast as the ones today, you could watch videos and play games (Kongregrate had a section for touch flash games that worked very well). Adobe abandoned it simply because the effort required to maintain it was too high considering they were never going to be on iOS.
Honestly, I'd rather developers move their DRM-encumbered video services to native apps and leave the web alone.
Well ... I have found that thepiratebay works flawlessly to deliver videos on any platform. It is sad that we are moving backwards. Right now I WANT to give netflix money for Daredevil ... and there is no legal way for me to do so ...
Hmmm? What OS do you run? Netflix works great on the Linux version of Google Chrome. Yes, you have to use proprietary software, but it does work.
Proprietary software and live in a select group of countries and pay a fee that isn't cheap for everyone.
Countries yes. Proprietary software, probably not a good argument. For example, I use Firefox for my web browsing, and Safari for Netflix - Safari uses EME so it's a much smoother experience.
Fee that isn't cheap for everyone, I also doubt. Where I live, Netflix costs like £6.99. That is legitimately cheap for everyone. In Britain, you pay less for Netflix than the cost of a TV license.
Fee that isn't cheap for everyone, I also doubt. Where I live, Netflix costs like £6.99. That is legitimately cheap for everyone. In Britain, you pay less for Netflix than the cost of a TV license.
You live in one of the countries with the strongest economies in the world. That something is "cheap" for you doesn't mean it's cheap for everyone else.
£6.99 is small change to you, but it's about about four meals for me. It's also more than what I have in my wallet/bank account near at this very moment.
And there's places where economies are way weaker and my own. Heck, I know people who earn less than that per day.
£6.99 is small change to you, but it's about about four meals for me. It's also more than what I have in my wallet/bank account near at this very moment.
And there's places where economies are way weaker and my own. Heck, I know people who earn less than that per day.
It is what region I live.
I'm not sure how this is any different from following the ongoing development of any other feature that requires platform-specific code to be written (WebGL, etc.). You will periodically see updates that only pertain to one platform or another, especially during bringup. No conspiracy there.
Mozilla can implement/port WebGL for whatever platforms they want, but they can't implement Adobe Primetime DRM; they have to take whatever Adobe gives them.
Does EME being implemented finally mean that I can uninstall Silverlight for watching Netflix in Firefox in the near future?
I believe that now you can use the HTML5 player on Netflix if you're on OS X or Windows. Linux still can't however.
Now if only I could uninstall flash. One day...
Don't do it. I've been using the non-silverlight Netflix in Safari and it's such a nightmare I switched back. Constantly fails to load content.
I wonder why you have issues and I don't. The only new thing I've noticed with Netflix on HTML5 is my battery life has near-doubled.
Really? I had some issues with the very first release of HTML5 Netflix, but it is pretty solid now.
Might need to look at it again. I used it throughout the last OS X beta and then it still had issues in the first release so I moved away from it.
Safari on Mac OS X uses entirely different code than Firefox on Windows for encrypted media. It's more a limitation of OS X. On Windows, Firefox will download and install the Adobe Media bits to handle DRM video.
Well that`s annoying. At least the newer version of the Silverlight player supports HD, didn't appear to before. That was my main reason for wanting the HTML5 version.
Comparing HTML5 Netflix playback using Safari on OS X vs Firefox on Windows is not really an apples-to-apples comparison.
At least you have the option. My girlfriend`s Mac supports the latest version of OSX and Safari but not HTML5 playback.
That depends on which OS you use.
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?
Firefox checks SHA-512 hashes at download time. If you have local malware that changes the GMP DLLs thereafter, the malware might as well change Firefox itself.
I'm approaching it like this - I need to execute unsigned binaries from a location that does not have execute permissions. How can I manage this? The lack of a signature is at best an administrative burden and at worst an attack vector depending on how the Admin handles it ("let's just add a wildcard exeception"). Mozilla should recognize this and sign the dll's. I still haven't seen a reason for NOT signing them. We don't use WebRTC so ignoring gmpopenh264.dll was not a problem. However, now we're talking about "necessary" Adobe code. Need I say more? Chrome performs the same functions and adheres to common sense. This is one of those things that gets a package removed from offering. I like and use Firefox myself but I don't like the position Mozilla has put me in. Should I open a bug report or do you speak for Mozilla in an official capacity?
Please open a bug report and CC :hsivonen
I filed Firefox bug 1164948 for this issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=1164948
https://bugzilla.mozilla.org/show_bug.cgi?id=1164948
It can't change Firefox itself if it has no administrative privileges but it can change anything in the user's directories.
Your scenario already has the malware running with the user's privileges. This means that the malware already has more privileges than sandboxed GMPs in your scenario.
While that is a valid point, it doesn't changes the fact that the more attack surface the more likely to break through.
Sometimes you have few limited vulnerabilities that can add up to complete systems compromise.
Sometimes you have few limited vulnerabilities that can add up to complete systems compromise.
> If you have local malware that changes the GMP DLLs thereafter, the malware might as well change Firefox itself.
Well hopefully firefox itself is signed. This is exactly what signing is designed to prevent.
Well hopefully firefox itself is signed. This is exactly what signing is designed to prevent.
For software that runs as non-admin, authenticode is very much about checking delivery-time integrity. If you have admin-level malware, it can replace signed software (that gets run without admin privs and doesn't have UAC at launch) with unsigned lookalikes.
Not if the computer is configured to only run signed code, which is an option on Windows.
> If you have admin-level malware
...you should reinstall your OS. Really, that shouldn't even be an "if" these days. Of course security doesn't matter if people can just execute random code on your machine.
Anyway, code signing is not about delivery time integrity. It's easy to check whether a given binary is code signed at any given time—without it you wouldn't be able to revoke bad certificates. The only reason you shouldn't sign is if signing has some cost (like in the Mac OS X ecosystem) or you can't trust a single root certificate anyway (at which point you might as well move to OpenBSD anyway).
...you should reinstall your OS. Really, that shouldn't even be an "if" these days. Of course security doesn't matter if people can just execute random code on your machine.
Anyway, code signing is not about delivery time integrity. It's easy to check whether a given binary is code signed at any given time—without it you wouldn't be able to revoke bad certificates. The only reason you shouldn't sign is if signing has some cost (like in the Mac OS X ecosystem) or you can't trust a single root certificate anyway (at which point you might as well move to OpenBSD anyway).
Firefox is now a malware installer?
Awesome!
Awesome!
Your post may seem snarky, but I upvoted you for truth. Many of us consider Adobe's DRM software to be nothing but malware.
It's easy to remove (see https://support.mozilla.org/en-US/kb/enable-drm); or, if you don't want it at all, you retain that option: http://download.cdn.mozilla.net/pub/firefox/releases/38.0/wi...
> autocomplete=off is no longer supported for username/password fields
Super cool. Don't tell me what not to auto complete!
Super cool. Don't tell me what not to auto complete!
>Improved page load times via speculative connection warmup
turning into chrome!
turning into chrome!
So I got momentarily excited that there are new "tab preferences" (like having new tab open next to the current one), but unfortunately it's just a UI revamp of the settings pane, which since I'm on OS X I cannot care for much (the UI is a bit too flat and generally not as familiar as the native box, although who cares...)
I fail to see why Mozilla chose this direction. Firefox now looks more alien on all platforms with no real functional benefit.
Because this way you recognize Firefox everywhere when you see it, that's their reasoning. There was a presentation about it few years ago but I'm too lazy to hunt after the link right now.
> Ruby annotation support
Finally! After only 24 years, East Asian languages get some attention.
Perhaps next Western browser makers might consider vertical text support.
sigh
Finally! After only 24 years, East Asian languages get some attention.
Perhaps next Western browser makers might consider vertical text support.
sigh
Vertical text support is coming on quickly in Firefox. There’s still a bunch of blockers, but they’re being knocked off fast: https://bugzilla.mozilla.org/show_bug.cgi?id=145503
That's great to see!
the syntax is really confusing though. Duplicating characters? I thought it was hard to follow what would end up where https://hacks.mozilla.org/2015/03/ruby-support-in-firefox-de...
The syntax isn't that bad. It's written in a style that gracefully degrades: strip out the HTML tags, and it's perfectly readable, but the furigana shows up inline rather than above.
Portions are duplicated to ensure graceful degradation. You type 振り仮名(ふりがな) (with tags demarcating the sections, of course), repeating the り, so it'll show up properly if the browser lacks ruby text support. But if the browser does have ruby text support, it can hide the り from the furigana because it's redundant:
Portions are duplicated to ensure graceful degradation. You type 振り仮名(ふりがな) (with tags demarcating the sections, of course), repeating the り, so it'll show up properly if the browser lacks ruby text support. But if the browser does have ruby text support, it can hide the り from the furigana because it's redundant:
振 仮名
ふりがなOn iPad the り is only visible in the furigana. On top of that, the furigana is displayed below the text.
Yes, only Firefox 38 has support for advanced ruby text, unfortunately.
While advanced ruby text degrades great in browsers with no ruby text support at all, it doesn't seem to degrade well in browsers with basic support :(
While advanced ruby text degrades great in browsers with no ruby text support at all, it doesn't seem to degrade well in browsers with basic support :(
Oh wow, I screwed that up. I meant to type this:
ふ がな
振り仮名
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?
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?
To disable EME, go to the Firefox Preferences menu and uncheck the "Play DRM content" checkbox. That will disable EME and delete the Adobe CDM binary if it has been installed. This preference doesn't disable DRM in Flash and Silverlight, however.
https://support.mozilla.org/en-US/kb/enable-drm
https://support.mozilla.org/en-US/kb/enable-drm
Yes, we do. https://blog.mozilla.org/blog/2015/05/12/update-on-digital-r... has links to the following:
1) Instructions for disabling the DRM bit without uninstalling it.
2) Instructions for uninstalling the DRM bit (and having Firefox never install it again).
3) A link to a version of Firefox 38 that doesn't have the DRM bits.
It's worth reading the whole blog post, but the tl;dr is https://support.mozilla.org/en-US/kb/enable-drm and http://download.cdn.mozilla.net/pub/firefox/releases/38.0/wi... (with the latter sadly not as user-friendly as it might be).
1) Instructions for disabling the DRM bit without uninstalling it.
2) Instructions for uninstalling the DRM bit (and having Firefox never install it again).
3) A link to a version of Firefox 38 that doesn't have the DRM bits.
It's worth reading the whole blog post, but the tl;dr is https://support.mozilla.org/en-US/kb/enable-drm and http://download.cdn.mozilla.net/pub/firefox/releases/38.0/wi... (with the latter sadly not as user-friendly as it might be).
They already have releases without EME at all if you don't even want to disable it:
http://download.cdn.mozilla.net/pub/firefox/releases/38.0/wi...
http://download.cdn.mozilla.net/pub/firefox/releases/38.0/wi...
> 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?
Iceweasel (the version of Firefox shipped with Debian) will always be DRM-free, as per the Debian policies on free software. It's almost the exact same as Firefox, except the logo and the name - all the other functionality is identical.
> Do you plan to support a DRM-free version?
Iceweasel (the version of Firefox shipped with Debian) will always be DRM-free, as per the Debian policies on free software. It's almost the exact same as Firefox, except the logo and the name - all the other functionality is identical.
There's a "Play DRM content" checkbox in about:preferences#content. If I remember correctly, unchecking it will completely remove the CDM, checking it installs it again.
You might be interested in GNU Icecat[0]. It is a spinoff of Firefox that does not include antifeatures like DRM.
[0]https://www.gnu.org/software/gnuzilla/
[0]https://www.gnu.org/software/gnuzilla/
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
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
Its absence has been a persistent irritation to me. I'm glad that I can now retire this:
https://github.com/threedaymonk/furigana-shim
https://github.com/threedaymonk/furigana-shim
It's been possible to add support with an extension[0] for a long time.
0: https://addons.mozilla.org/en-US/firefox/addon/html-ruby/
0: https://addons.mozilla.org/en-US/firefox/addon/html-ruby/
At first, I thought they added support for client side scripting in Ruby.
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?
Opportunistic encryption is being tested again in Firefox 39, which is scheduled to release on June 30, 2015.
The broadcast channel support looks promising. Does anyone know if Chrome plans to support it in the future?
CanIUse pointed at a proposal for Chrome support which eventually points at this bug:
http://code.google.com/p/chromium/issues/detail?id=161070
There are some work-in-progress patches posted there.
http://code.google.com/p/chromium/issues/detail?id=161070
There are some work-in-progress patches posted there.
Could this be abused on iframed ad network domains / facebook like buttons / tweet buttons to track real time browser state and acitivity across all active tabs?
srcset! Finally, responsive images are gaining ground.
Anyone have any insight on why they removed autocomplete from username & password fields?
Presumably this: https://bugzilla.mozilla.org/show_bug.cgi?id=956906
I think it means that sites can't overrule the browser's inclination to store passwords. The argument seems to be the browser makers will store passwords safely.
I think it means that sites can't overrule the browser's inclination to store passwords. The argument seems to be the browser makers will store passwords safely.
> The argument seems to be the browser makers will store passwords safely.
Not quite. Unless you set a master password, whoever owns your computer will own the passwords stored by your browser.
The argument is that disabling autocomplete makes users choose poor passwords that are easy to remember, or write passwords down somewhere, which is at least as bad as having passwords stored in your browser profile.
Not quite. Unless you set a master password, whoever owns your computer will own the passwords stored by your browser.
The argument is that disabling autocomplete makes users choose poor passwords that are easy to remember, or write passwords down somewhere, which is at least as bad as having passwords stored in your browser profile.
writing passwords down somewhere, such as on PAPER, is not a particularly bad idea unless you keep the paper by your computer.
There are some valid use-cases, e.g. in web-apps with an user-admin section. It's useful that when adding user 2 (or N) it won't auto-fill with details from the previous user (that you just added).
If anyone has that issue, a workaround is to add multiple email/password inputs (dummies) around the real-one, and hide them. In Chrome, this causes it to 'give up' and not try to auto-fill the fields.
If anyone has that issue, a workaround is to add multiple email/password inputs (dummies) around the real-one, and hide them. In Chrome, this causes it to 'give up' and not try to auto-fill the fields.
They removed the ability of a site maker to tell user if they should use password manager on their website. A much needed feature aka 'no, I do not care about password for your stupid site'.
IMO, what's even more annoying are sites that detect whether you've used a password manager to fill your credentials and then 1) won't log you in, 2) frequently require you to clear your cookies and 3) sometimes make you change your password.
They also removed the ability of a site maker to tell the browser "no, this isn't the user's login form, it's where he inputs the username of somebody else".
From the bug tracker https://bugzilla.mozilla.org/show_bug.cgi?id=956906#c100
Summary of the change, so people don't have to wade through a long discussion:
Summary of the change, so people don't have to wade through a long discussion:
- This change makes it so that `autocomplete=off` does not stop the Password Manager from working. Normal form autofill can be disabled as usual.
- The password manager *always* prompts if it wants to save a password. Passwords are not saved without permission from the user.
- We are the third browser to implement this change, after IE and Chrome.
- This can be undone locally by flipping the `signon.storeWhenAutocompleteOff` pref (from about:config) off.
- The rationale behind this change was the widespread abuse of the `autocomplete` attribute to prevent password saving where no prevention is required. This change gives users full control over password saving, without compromising on security (again, the user is always prompted).Uninstalled. I have enough of you guys copying Chrome and turning Firefox into a DRM and social media browser. Get lost!
At least the Seamonkey guys know that advanced users also have the right to have their Options inside of the browser's code, something what you Mozilla guys are unable to understand these days!
What is good for Chrome is not equal as good for Mozilla Firefox!
At least the Seamonkey guys know that advanced users also have the right to have their Options inside of the browser's code, something what you Mozilla guys are unable to understand these days!
What is good for Chrome is not equal as good for Mozilla Firefox!
[deleted]
The Readinglist feature seems to have disappeared from the Desktop build. I really liked using it in Nightly and on Android.
I briefly looked at Bugzilla and can't figure out its future. Is it really being replaced with a tie-in to a closed source US based startup company, Pocket? Can any devs comment?
I briefly looked at Bugzilla and can't figure out its future. Is it really being replaced with a tie-in to a closed source US based startup company, Pocket? Can any devs comment?
This worked, so I imagine its being silently developed
http://www.ghacks.net/2015/02/07/mozilla-starts-to-push-read...
http://www.ghacks.net/2015/02/07/mozilla-starts-to-push-read...
Worked for me too. Thanks for the pointer.
Anyone else having issues with the bookmarks toolbar in 38? Mine draws blank when you open a window. I have to hide/show it before it draws correctly.
This occurs each time a window is opened.
This occurs each time a window is opened.
My menu button on the right of the address/search bar doesn't work anymore either.
(OSX 10.10.2)
Gonna uninstall/reinstall
Gonna uninstall/reinstall
Looks like (haven't tested yet), this will finally support meet.jit.si for true free/open group video chat!
[deleted]
>CRITICAL Vulnerability can be used to run attacker code and install software, requiring no user interaction beyond normal browsing.
Uh, glad they fixed this one, but it sounds pretty bad. I'd kinda like to see the actual CVE/bug report.
Uh, glad they fixed this one, but it sounds pretty bad. I'd kinda like to see the actual CVE/bug report.
You're looking at the key which defines what CRITICAL means. Look further down the page for info about actual vulns. I believe they're running a bit late posting the vulns for 38 today.
[deleted]
[deleted]
> Implemented Encrypted Media Extensions (EME) API to support encrypted HTML5 video/audio playback (Windows Vista or later only) HTML5
> Automatically download Adobe Primetime Content Decryption Module (CDM) for DRM playback through EME (Windows Vista or later only)
:( Notice which OSes are left off the list. I don't blame Mozilla as they were just following inevitability but it's a sad day for the web as there's now a lot of content that, by design of W3C, only works on certain OSes.
Of course the EME champions promised us that this wouldn't happen and they are apparently silent for the moment.