And here is the end result of people leaving Firefox for Chrome. You neutered Mozilla. There is no longer a browser vendor which has both your interests in heart and sufficient power to direct the evolution of the web.
Who now gets to choose which features are built into the majority of desktop and mobile browsers? Advertising companies.
Come on. This is the same Mozilla that promoted installing Adobe Flash for internet video since its very inception. If you're really such a purist, they should have been your enemy all along.
Nothing has changed, and the conclusion is nowhere near as dramatic as you're making it sound. The suggestion that Mozilla implemented this for market share reasons is also incredibly unsubstantiated and ignores the very obvious practical reasons they will have had: dropping reliance on large propietary application runtimes (the DRM module is much smaller and has less functionality), improving user experience, and the fact that it's an actual web standard (albeit the most controversial one).
I don't disagree that Mozilla was never a purist organization, but I think the suggestion is well substantiated. From the post announcing it:
"With most competing browsers and the content industry embracing the W3C EME specification, Mozilla has little choice but to implement EME as well so our users can continue to access all content they want to enjoy. (…) We have come to the point where Mozilla not implementing the W3C EME specification means that Firefox users have to switch to other browsers to watch content restricted by DRM."
One could argue Mozilla was quite purist when they ejected Brendan Eich because his personal beliefs were not shared by fellow employees... but more on that later.
Perhaps the real reason Brendan Eich was thrown out of Mozilla was because he didn't embrace DRM and EME? Given his stature as founder of Mozilla and creator of Javascript, he could have posed a significant roadblock if he had decided to reject EME's inclusion in Firefox.
If you put on your tinfoil hat, recall that Brendan's donation to Prop 8 was public information for several years... before it suddenly became an issue.
>"So long as people want Hollywood movies, and Hollywood is used to getting its way, and DRM vendors are pushing to perpetuate this and codify it, and put it under a fig leaf from the W3C, we have a real problem.".
This is an interesting theory and given what we know how how hollywood works in the backroom, plausible, but there are no facts to support it.
Eich was not "thrown out of mozilla". The board knew about his donation and appointed him anyways - the pressure for him to resign came from the community and Mozilla employees.
Hollywood is great at fomenting outrage, but not that much and not in that way :)
If only company boards listened to their employees and "community" all the time!
I think it's about opportunism. A situation developed and by simply stoking the fires of social media outrage, a major obstacle to adoption of DRM in a popular browser could be eliminated.
Consider the Mozilla position as soon as Brendan had been forced out - coincidence?
>"With most competing browsers and the content industry embracing the W3C EME specification, Mozilla has little choice but to implement EME as well so our users can continue to access all content they want to enjoy. Read on for some background on how we got here, and details of our implementation."
- Mozilla CTO Andreas Gal, 14 May 2014
"Mozilla will be adding a way to integrate Adobe Access DRM technology for video and audio into Firefox, via a common specification called Encrypted Media Extensions (EME)."
- The Mozilla Blog, 14 May 2014
Given that Mozilla is a nonprofit, they've got more reason than most to pay attention.
I don't really buy that narrative that all of Mozilla really really wanted to accept DRM in the browser, but this one guy is such a pain in the ass about shooting it down that they'll promote him and hope that the outrage machine takes him out, and thus fulfill their evil plan to ??????! Muahahah!
Ahem. Made-for-TV movie plots aside, it fails occam's razor, it fails basic logic, and as mentioned there isn't a single shred of a fact to support it. The actual story is shocking enough without trying to read patterns into it that don't actually exist.
"On April 3, 2014 Brendan Eich voluntarily stepped down as CEO of Mozilla."
(I'm not going to, but) I can tell you to stop posting on HN every single day of the year indefinitely. But I can't make you. I don't have that power. If you choose to, it's your choice. Eich was not fired. He resigned of his own free will.
If a customer comes into your job, tells you that you should resign, and then your boss says, "ignore him, you can stay", and you resign anyway, can you really tell me that your boss fired you?
> Bigotry? What are you smoking?
Unlike you apparently, I'm not. Since I know what words mean.
"a person who is utterly intolerant of any differing creed, belief, or opinion."
Eich was so intolerant of people who held a difference of opinion on what constitutes marriage, that he donated his own money to a cause whose sole purpose was to strip existing legal rights and protections, rights that he enjoyed himself, from a minority class through force of law. There is zero ambiguity here: I cannot possibly think of a clearer case of outright bigotry.
If you disagree, you might want to take a good, long, hard look in the mirror. Per the dictionary; I am selfish, tactless, and many other negative things. I don't pretend those words mean something that don't apply to me, just so I can feel better about myself.
This is madness. Have you ever heard of constructive dismissal?
California Supreme Court:
"the employer either intentionally created or knowingly permitted working conditions that were so intolerable or aggravated at the time of the employee's resignation that a reasonable employer would realize that a reasonable person in the employee's position would be compelled to resign"
Wikipedia:
"In employment law, constructive dismissal, also called constructive discharge, occurs when an employee resigns as a result of the employer creating a hostile work environment. Since the resignation was not truly voluntary, it is in effect a termination. For example, when an employer makes life extremely difficult for an employee, to attempt to have the employee resign, rather than outright firing the employee, the employer is trying to effect a constructive discharge."
Tell me again how Eich's employer made it a hostile working environment for him, please?
Given that he had no boss (being the CEO and all), we can only assume you mean the board members. Please point out to me a single board member who was in any way hostile toward him.
Even the two board members that resigned said it had nothing to do with Eich.
I don't think the parent's point was about purity of not having DRM in firefox, but rather that since Firefox's user base has decreased so much in recent years, Mozilla no longer has the leverage they used to in terms of browser features. In other words, if Firefox had 50% share of browser usage, they would be in a position to prevent EME from becoming an industry standard -- but since they have a much lower percentage (10% I think if you take mobile into account), they felt forced by pragmatism to include it.
And here I am heading towards Firefox from Chrome specifically because I can't watch DRM content in Chrome anymore (need silverlight to be able to watch GoT and Comedy central)
I actually do have Netflix running via Silverlight on Firefox on Linux. Winodws Silverlight is running in Wine, with Pipelight to display the Windows plugin in the Linux Firefox (actually Iceweasel) process.
I don't know what to tell you. My school uses an exchange server and I can't add attachments to emails on the online portal unless I use the old lite version on Chrome whereas I can on other browsers.
agreed. i try to explain to people that firefox is an open source program created by an organization that is trying to keep the web free, while chrome is created by one of the world's biggest advertising companies, but they don't seem to care enough to use firefox.
i feel like mozilla should give up on the soccer mom users and focus on being the power user browser. this is already the case to an extent, but they don't market firefox's advantages (like better extensions) well enough, and they don't quite focus on power-user-type features as much as i think they could.
I don't know a single non-technical user who equates freedom with their choice of a web browser. The tech community is in such a big bubble when it comes to this.
> And here is the end result of people leaving Firefox for Chrome.
Mozilla brought that on themselves by racing as fast as possible to become Chrome. If I'm going to be forced to use the Chrome UI, why would I settle for an inferior copy of it named Australis?
Then there was the Awesomebar, Hello, mandatory signed extensions, ads on your newtab page, forcing the retention of download history, and on and on. DRM is just the next step in a long, sad succession. Mozilla has been trying as hard as possible since 4.x to get us to stop using their browser. No surprise it's working.
I for one am pretty decided to move to Firefox once Mozilla integrates Servo into it (granted the performance benefits really are significant).
But I'm also waiting for Mozilla to implement its multi-process sandboxing system. Microsoft seems to be doing some interesting things on that front as well - I hope Mozilla is watching. I like the idea of having each tab in an secured app container, which sounds even better than Chrome's tab-in-a-process system.
Of course this will only work on Windows 10, but I don't think that's any reason to wait on implementing such a system (unless it has some major issues I'm not seeing, of course).
> I for one am pretty decided to move to Firefox once Mozilla integrates Servo into it
Hooray! I'm excited to have you back. :)
If your switch is gated on Servo, you might be in for a long wait: we're moving small, modular components into Firefox as we're able, but completely changing implementation languages for parts of a browser used by hundreds of millions of people is a slow, deliberate process which involves pretty significant changes not only to our codebase, but also to our build infrastructure.
Right now the immediate goal is to share either an image decoder or the URL parser between Servo and Firefox. Quite likely by the end of the year.
Follow these bugs to find out more when things land:
> I'm also waiting for Mozilla to implement its multi-process sandboxing system
I believe we're uplifting multi-process into the Dev Edition 40 release in a week or so. If not, it'll be in 41. Goal is to have it on by default in the release channel by the end of the year: https://wiki.mozilla.org/Electrolysis#Schedule
Are there any plans to build a completely new browser from Servo? Is there even any worth in that? (A firefox-esque "normal" one, not like that experimental html browser thing.)
No concrete plans. We hope to get a new mobile browser out. For Desktop we're hopeful about browser.html. As a research project we aren't really worrying about any of this yet.
browser.html is intended to be a "normal" browser, though in it's current state it isn't quite there yet :P (It's not pure web HTML, there is a small set of "mozbrowser" APIs which it uses to get sandboxing and the other necessary things)
Firefox's UI is anyway written in XUL (an html-esque xml thingy), so browser.html isn't too far from what Firefox does.
Thanks for the response. With browser.html, I think I meant functionally, like isn't it supposed to be marketed as a simple, out-of-box, no configuration browser for those who just want no hassle simple web browsing? (Because otherwise I might be confusing it with something else, although I was sure I saw that Mozilla research was doing something like this.)
Because if it is, I obviously don't want that... I "just" want a free software html/css/js spec compliant browser (obviously without the drm, or an option without that part, because that's not free software), but the catch is that I sort of need it to be quite customisable...
By which I mean something akin to the current firefox, which allows addons, a great powerful addon api, unlike chrome, allows modifying the ui (via userChrome.css), modifying display of web pages themselves (via userContent.css), developer console, setting configuration options via a config file, view page source etc.
This seems off-topic and almost like a personal feature request for Servo or whatever, but my point is that I know my "setup" isn't exactly 'mainstream', hence why I basically require powerful customisation options. For example, I'm on firefox (37), but it looks like this: http://i.imgur.com/L9P8XhC.png. And it's not exactly a whole heap of fragile customisations which are destined to break, it's "just" one userchrome file and one addon, so it's actually fairly reliable too.
I care about the ui in that I want the power to change it to what I like. If I can do that, I don't care what the default ui is. But I don't think browser.html's purpose is to be powerful like current firefox is it?
I guess normal isn't the right word. If anything, you're right, browser.html is normal, but not in the way I've grown accustomed to with the feature-filled firefox. If you're familiar with zsh and the fish shell, I mentally labelled browser.html as the special "fish shell" of browsers the first time I saw it, hence why I was quick to dismiss it as a future option. I should probably go and embed servo in emacs or something.. :)
I don't think there's a fixed end goal for browser.html; it's also a research project.
Spec compliance is Servo's problem. Customizability -- well, browser.html should be just as customizable as Firefox once it gets polished. Like I said, browser.html uses HTML, and Firefox uses XUL, both in mostly the same way. Firefox largely uses XUL because HTML wasn't so powerful in the past, but now it is, and technically we could replace a lot of the XUL with HTML5. Which is sort of what browser.html does. Many firefox UI components are slowly being replaced by html variants these days too.
Now with Firefox's addon API, you write addons using XUL/XPCOM. With browser.html it would be HTML/JS, and you'd be able to hook into any part of the chrome[1] you want. Addons would basically be like userscripts, except they would be for the whole browser chrome. So for example you could write a simple CSS addon that colors the location bar yellow, or write a more complex one that moves the tab strip to the side, or whatever.
Of course, since browser.html is still researchy, I don't think there are plans for an addon api yet. I'm just saying that an addon api for browser.html sounds like something that could be done. I haven't worked with browser.html, so I could be very wrong here.
Actually, fwiw you probably can write your own browser UI (right now!) from scratch using the same APIs that browser.html uses. Instead of fixing an existing UI by totally rearranging everything, write your own! Check out https://github.com/glennw/servo-shell to see what APIs work in Servo and how to use them.
Servo has a usable-ish embedding API, you might actually be able to do the emacs thing (it might help if you chat with zmike in the #servo Mozilla IRC room)
[1]: browser chrome = the stuff outside the layout engine; the UI (location bar, bookmarks, history, devtools, etc)
Wow thanks for the taking the time for the comprehensive reply! :) Really, my comment turned into a half-rant, and I wasn't expecting such a response!
Well honestly, if it does become "hackable" (i.e. ui, addons), then that invalidates all of what I said. But yes it is still experimental as you say of course, so I understand.
This is a bit off topic, but one thing that's really deterring me from firefox lately is the signed extensions thing. [1] To cut to the point, I'm not sure how credible random tweets are, but just as a light example, I got someone (from mozilla security) to admit it's a mistake [2]. (Sort of, I'm twisting the words I think, english actually not my native language, so I still have trouble expressing myself sometimes.)
My comment is just that I hope that servo/browser.html doesn't make the same "mistake". I.e. implement proper addon security, sandboxing etc. Because, if you guys do plan for an addons api, and if you give it the power ("except they would be for the whole browser chrome"), then you should also plan ahead on the security implications of that too, if any. I guess I should watch the servo project for any addon plans and bring it up there! But other than that, I'm not a security guy, so I cannot say what exactly to do.
If you're wondering why... yes extension signing is great of course, just not when only Mozilla has the power to do so imo: [3] (Not my blog, but iirc I think I agree with most of the post.)
And funny that you mentioned servo-shell by glennw, I actually remembered that when writing my previous comment and had a tab open on it! See my screenshot, top left! :p
Preface: I am not a Mozilla employee -- I'm a volunteer and don't speak for Mozilla. I also haven't ever written a Firefox addon, though I have contributed to Firefox in the past and roughly understand how addons work.
> I'm not sure how credible random tweets are, but just as a light example, I got someone (from mozilla security) to admit it's a mistake
Yeah, dveditz is calling it a mistake (and I have great respect for his opinions -- he's very frank about them and is very thorough when it comes to security matters). I believe he is calling the original design of addons (years ago) to be the mistake, though.
I personally wouldn't call it a mistake though. Not exactly. There are many options, and each would cause significant backlash. The blog post talks of the sandboxing that Chrome and Safari provide; but Chrome's extension API is very limited (I've used it). It's basically a userscript API with a small number of hooks.
A large chunk of Firefox's user base uses Firefox just because of the power of addons. There are many addons that would just not be possible in other browsers. Restricting the addon API would irreplacably break all these addons and many users would leave because their favorite addon just isn't possible anymore.
A proper permission based sandbox that exposes all the original features sounds easy, but isn't. The blog post seems to oversimplify things. The original API was to simply expose all the browser internals to the addons (with a bunch of extra utility methods). Creating a well-structured, sandboxed addon API with the same capabilities is a really, really hard problem. We can't just selectively expose functions -- browser internals were not designed to be secure in such usage, so we need to provide a whole new shim over the internals and take a lot of security things into consideration. This is a lot of work, and cannot be done in a reasonable timeframe. In the meantime, people are getting their browsers hijacked by rogue addons, which is much worse.
Same thing goes for transparency. You need a proper shim to get that, otherwise you need to turn on logging for the whole of the browser -- there's no way to tell if a request originated from a method call by a browser internal, or a method call by an addon (except for a direct request). There might not even always be a clear distinction!
The review experience could be improved; but Mozilla has limited resources and with reviewers mostly being volunteers, this is also very nontrivial.
Sideloading will always be possible unless addons are encrypted with the user's master password. Firefox's source code is public, so the format of the user data dir is public, so anyone can add stuff. Master password encryption for the full data dir is an interesting idea (it might already happen actually; never tried it), but I don't think it will fix the bulk of the problem which has to do with non-security-aware people getting their browsers filled with crap.
Making code signing optional -- It's a tossup here. I was quite annoyed when Chrome did that for their addons since it made it hard for me to share userscripts. But the sad thing is that people will just write instructions to flick that switch. I personally think that we should draw the line there, really[1] -- if we can't stop users from clicking through warningy warnings it's mostly a lost cause. Besides, attacks can always be through direct exe downloads in that case. I personally hope that Mozilla adds the option to bypass this in the future like Chrome did, but I don't think that's going to really solve the larger problem.
I think the best way to handle this would be to use signing as a stopgap measure, and slowly roll out a permission-based sandbox API that has limited functionality but doesn't need signing. It can start out with a Chrome-like API with the most commonly used features, and expand a bit into more APIs until eventually mostly everything is covered. I do believe that it was a mistake to not plan to do this, however note that this solution is still possible.
But overall I find it to be a case of "you can't please everyone" here.
> yes extension signing is great of course, just not when only Mozilla has the power to do so imo
FWIW the reviewers are volunteers, so it's not as closed a situation as it's made out to be. Still not perfect though.
> My comment is just that I hope that servo/browser.html doesn't make the same "mistake"
We don't plan to. No idea about browser.html, but Servo plans to have proper sandboxing and other things. See [2] for a library Patrick wrote to help for this (i nfact its use cases in Servo extend beyond plugin sandboxing). Plugins are on our mind, and sometimes come up during meetings/discussions, though we haven't done anything about them yet (no immediate plans either). Too many other priorities :)
Of course, servo plugins would be for stuff like Flash (ick) which need to interface with the browser engine itself. I'm not sure how browser.html plugins could pan out. It should be possible to provide a sandboxed API via the mozbrowser extensions, but I'm not sure.
> And funny that you mentioned servo-shell by glennw, I actually remembered that when writing my previous comment and had a tab open on it! See my screenshot, top left! :p
> Right now the immediate goal is to share either an image decoder or the URL parser between Servo and Firefox
Interesting, it seems like there would be an order of magnitude (or more) difference in effort to write these two things. The third link you gave links to mp4parse-rust, is that what you mean by image decoder?
Media Source Extensions (MSE)[1] were added for YouTube HTML5 video, and is different from Encrypted Media Extensions (EME)[2], which is what allows DRMed videos.
MSE allows things like adaptive bitrate while streaming and programmable video buffering without a plugin.
This is ridiculous. In every other example, we say "innovate or die" (think taxis and Uber). In this case, Mozilla did not innovate as quickly as Chrome, and made a number of bad decisions, which led to their loss of market share. Consumers should not be blamed for picking a new product when it outpaces the old.
Mozilla itself deserves to shoulder at least as much of the blame due to a number of decisions that range from mediocre to downright terrible. And I'm not even talking about what happened with Brendan. I'm talking about the organization's downturn during the years that directly correspond with the tenure of people like Gary "JavaScript rendering engine" Kovacs and the years that saw Sullivan at the height of his influence.
The engineers aren't blameless either, having allowed themselves and the engineering culture to become the target of whatever neutering that did occur. "But I mean, these are business people; this kind of stuff is what they should know, right?" Sure, right. Totally let 'em go ahead and pursue those useless fucking partnerships at the costs they're coming with. After all, that's what real businesses look like.
What happened with Brendan may be very relevant. See my post further up in this thread.
Brendan did not like what the W3C was doing with DRM and was quite vocal about it. His prop 8 donation was public knowledge for years and nobody had a problem with it... but then suddenly the board, the employees and the community were outraged.
As soon as he was forced out the other execs at Mozilla announced they would be implementing DRM and EME. Coincidence?
You forget that another significant event happened at the time; he was nominated for CEO. That puts a person under a lot of scrutiny in the first place. I would say that it was indeed a coincidence.
I left Internet Explorer for Firefox because I was unsatisfied and jumped to the first viable alternative. I left Firefox for Chrome for the same reason. I'll jump to the next viable alternative as soon as it's available.
You would think that but chrome is much more insidious than other browsers. I can log in to chrome on all my devices and share bookmarks, apps, sessions, passwords, etc. That makes me a sticky chrome user because I lose all that functionality if I ever switch.
You really don't. I switched a few months ago because Chrome was crashy, it took all of two days, and a few more until I stopped using Chrome completely.
What irks me about Firefox is that tabs aren't separate processes, so one sticky tab will make everything sluggish, but that's about it.
Firefox absolutely does that for you [1]. You can even run your own sync server if you are into that sort of thing [2]. Works on all desktop platforms and mobile platforms that firefox runs on.
Who now gets to choose which features are built into the majority of desktop and mobile browsers? Advertising companies.