8 ms·

Mozilla hasn't made me very happy lately with their "choice" tactics. Resetting people's default search engine to Yahoo of all things on update was very opaque.

Mozilla hasn't made me very happy lately with their "choice" tactics. Resetting people's default search engine to Yahoo of all things on update was very opaque. Also the AMO signing fiasco, Pocket and Hello. Feels like an "It's only okay when we do it" kind of thing.

madars 11y ago
Changing search engine for existing users was a very unfortunate bug, which got fixed (https://support.mozilla.org/en-US/questions/1041571#answer-677594 https://support.mozilla.org/en-US/questions/1041571#answer-6...). Of course, changing the default for new users is nothing to be ashamed of.
- Spivak 11y ago
  I mean, it should be but it seems as though most people have accepted it.
oso2k 11y ago
I agree. And I extend that sentiment to their approach to Web Standards a few years ago too, like WebSQL [0] and NaCl [1], Dart [2]. That felt like NIH [3] or some other non-collaborative or ultra-competitive motivation on their part. Not a place of "speak for the Web". IMO, the choice of IndexedDB over WebSQL set the Web back 20 years. [0] https://en.wikipedia.org/wiki/Web_SQL_Database https://en.wikipedia.org/wiki/Web_SQL_Database [1] https://en.wikipedia.org/wiki/Google_Native_Client https://en.wikipedia.org/wiki/Google_Native_Client [2] https://en.wikipedia.org/wiki/Dart_(programming_language) https://en.wikipedia.org/wiki/Dart_(programming_language) [3] https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here
- Lazare 11y ago
  > IMO, the choice of IndexedDB over WebSQL set the Web back 20 years. Yep. I recognise that this may not have been a winnable fight, but I absolutely judge the people who were on the other side. WebSQL was a much better tech than IndexedDB. Was the dependence on Sqlite problematic? Sure. But Mozilla had the resources to make a pretty good try at fixing it; instead they refused to even implement it and gave us the relatively terrible IndexedDB instead. Which, in turn, Apple has refused to implement[1], and now here we are. Thanks Moz[2]. (I'm less concerned about NaCL and Dart, because it's less clear to me that these were obviously superior technologies that obviously needed cross-browser adaption. You're certainly right that the pattern is suggestive though.) [1]: Yeah, I know, they claim to have implemented it. Anyone who's tried to use their implementation will recognise this claim as a subtle joke. On us. [2]: Their blog post justifying themselves[3] has not aged well. I especially love the bit where they say IndexedDB is better than WebSQL because it has better "developer aesthetics", as if anyone is actually casually coding against IndexedDB without using some sort of wrapper or compatibility layer. Or as if anyone actually likes the IndexedDB syntax and API. [3]: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...
  - brighteyes 11y ago
    How would you fix WebSQL? Writing a from-scratch implementation of SQLite seems like the only option, and I don't think Mozilla had the resources for that at the time. I agree the situation sucks, but I'm not sure how to fix it even today.
    - kylec 11y ago
      One thing I never understood is why there needed to be a second implementation of WebSQL. SQLite is public domain, any browser vendor can choose to embed it in what they ship.
      - brighteyes 11y ago
        It's a standards process requirement. A standard must have a well-written spec, well-written enough that multiple implementations are possible. Showing multiple implementations that are compatible is enough to prove that. When there is just a single codebase, even if it is open source, it isn't a standard. Now, not everything needs to be a standard, but on the web standardization is a big part of why it is so successful. One example of why a single codebase is bad: Imagine that SQLite version X is the implementation of WebSQL, which all browsers must use. SQLite development is of course continuing, fixing security issues and making it faster, etc. Will browsers just keep using SQLite past version X? What if the SQLite community takes SQLite in a direction that isn't optimal for web browsers? Perhaps web browsers will fork it. What if browsers end up not agreeing on the fork, and some use the original project, and others use the fork - or there are multiple forks? All of that makes it very risky that compatibility issues will appear between browsers. Having a properly specced standard, with multiple compatible implementations, is so far the best way that we have found that can prevent such things.
      - BrendanEich 11y ago
        More succinctly: SQLite version whatever is specified only by its C source code, and C is woefully underspecified. Lots of Undefind Behavior on top of the memory-unsafe codebase itself. This is not a specification from which two independently implemented interoperable implementations could be written. Ergo, not a standard.
- pcwalton 11y ago
  NaCl and Dart aren't Web standards.
  - oso2k 11y ago
    I agree. And neither is WebSQL. I was speaking to the "approach to Web Standards", not actual Web Standards. My point being that Moz used (IMO) conjecture and FUD to roadblock those technologies. No attempt on their part to experiment with those technologies and prove their value. In return, we've got instead IndexedDB over WebSQL (which many devs choose to wrap), asm.js over NaCl (which v8 team as shown doesn't require a special compiler mode to optimize for), and ES5/ES5.1/ES6/ES7 language bloat over Your-Choice-Of-JS-Successor language or actually fixing the issues with JS.
    - pcwalton 11y ago
      I don't think it's FUD at all. asm.js is legitimately a more practical approach to the problem than NaCl, which is tied to the Pepper API. You can go back to the conversations on the plugin-futures mailing list in which everybody except Google was in agreement as to what should have been done instead of PPAPI; Google went with PPAPI anyway, sealing NaCl's fate with regards to adoption. Nowadays, we have Web Assembly, which Google and Mozilla are both working on, and which combines the best of both worlds. As for ES language improvements, I don't see at all how extending the existing language constitutes "bloat" over having two incompatible VMs. It's strictly less bloat, because you don't throw more VMs into the browser.
    - sonnyp 11y ago
      "we've got instead IndexedDB over WebSQL (which many devs choose to wrap)" It doesn't matter how developers choose to use IndexedDB, what does is for a Web standard to be sane and WebSQL never was. See https://news.ycombinator.com/item?id=9978713 https://news.ycombinator.com/item?id=9978713 "asm.js over NaCl (which v8 team as shown doesn't require a special compiler mode to optimize for)" I don't see how not requiring a special compiler is an argument against it. "ES5/ES5.1/ES6/ES7 language bloat over Your-Choice-Of-JS-Successor language or actually fixing the issues with JS" ES5/ES5.1/ES6/ES7 ARE efforts to fix issues with JS and mostly driven by Mozilla.
- sonnyp 11y ago
  About WebSQL Firefox already had (and still has) Sqlite dependency (it is uses for bookmarks, history, ...) it is not the issue. The problem is that the Web SQL standard states "User agents must implement the SQL dialect supported by Sqlite 3.6.19." [0] which made agents rely on a outdated dependency and non standard (sqlite is not SQL ansible compatible) SQL. A nightmare for Web standards. They made the right (and hard) choice. NaCl isn't portable (Mozilla is working on Web Assembly) Dart excerpt taken from Dart FAQ; question: "Will the Dart VM get into Chrome?" response: "No. Dart is designed to compile to JavaScript to run across the modern web, and the dart2js compiler is a top priority for the team." [1] [0] http://www.w3.org/TR/webdatabase/#web-sql http://www.w3.org/TR/webdatabase/#web-sql [1] https://www.dartlang.org/support/faq.html#q-will-the-dart-vm-get-into-chrome https://www.dartlang.org/support/faq.html#q-will-the-dart-vm...
  - michaelwww 11y ago
    Google has the Dart VM running in Chrome and it's called Dartium. If Mozilla had not been so vigorously negative towards Dart the story of Dart and Blink may have turned out differently.
    - BrendanEich 11y ago
      No, Google Chrome people rebelled against the overhead of a cross-language-engine garbage cycle collector. Are you aware of the technical details? Before this, before Blink forked WebKit, Apple rejected naive DartVM pre-integration changes for the same reason: https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... Whining for the poor Google-Goliath, blaming little Mozilla-David, is rich. No comment on the Pocket deal or other recent Mozilla changes. On this tangent about Dart, I'm happy that Chrome people prevailed.
      - tkubacki 11y ago
        >On this tangent about Dart, I'm happy that Chrome people prevailed I'm not. We are sentenced for another 20+ yrs for lang with broken 'this' pointer
- anotherangrydev 11y ago
  To add another example, I normally do JS using Node and there (and also in IE) you have a very useful function: setImmediate. A few days ago, when doing some client-side JS I wanted to use it and I saw that it is not part of a standard, not only that, it has actually been REJECTED. It's really sad to see the development of the language crippled for a reason that basically boils down to "No, because it was proposed by Microsoft".
byuu 11y ago
Yeah, this is the most "pot calling the kettle black" article I've seen all month. Let's see: * no opt-out for Australis * removal of tabs on bottom * forced signed extensions * removing option to not retain download history (unless you give up browsing history too) * bundling of Hello * bundling of Pocket (requires a lot of effort to disable) * bundling of DRM web extensions * bundling ads out of the box (can be disabled fairly easily) * on and on ... I can't even keep track of it all anymore
- brighteyes 11y ago
  I think reasonable criticisms were made regarding some of those, like Pocket. However, Australis for example was a large redesign of the UI. I'm not sure how you can support an opt-out, as that would mean supporting two codebases - two different and separate UIs, at once. Regarding bundling of DRM, it isn't bundled, but it is downloaded on demand. This is a sad thing even so, but Google, Microsoft and Netflix just left other browsers no choice when they invented, standardized and shipped EME DRM. Mozilla fought DRM, but lost.
  - m45t3r 11y ago
    Yep, this is what I think too. The Pocket and Hello case could at least have a disable option, even Google allows you to disable the new features that it brings in Chrome like Google Now and more recently the "Ok Google" hotword detection. However, the Australis case is much more complicated. An UI is tons of code, if Mozilla opted too maintain two different codebases they would need to update both everytime they added a new feature. This would be a maintenance nightmare, to say at least. I think it's ok to have this feature as a separate extension, maintained by people that actually care about the older interface.
    - byuu 11y ago
      > The Pocket and Hello case could at least have a disable option I really don't think burying an opt-out option justifies these things. This is the same tactic used to push malware in installers, Ubuntu's farming your search results to Amazon, and many of the new Windows 10 privacy intrusions. "You can opt-out (if you know you need to (and you know where to look (and you know about the gotchas like it only applying to enterprise customers)))" If they were honest, these things would be opt-in. But they're not, because that wouldn't make them their money. (and if you really believe someone at Mozilla isn't getting paid for Pocket integration, then I have a bridge to sell you.)
akkartik 11y ago
It's also disingenuous to call Mozilla a non-profit, given its wholly-owned for-profit subsidiary: https://www.mozilla.org/en-US/about/governance/organizations https://www.mozilla.org/en-US/about/governance/organizations. Used to be that mozilla.com was the homepage for the for-profit wing, but I see now that it just redirects to mozilla.org. https://en.wikipedia.org/wiki/Mozilla https://en.wikipedia.org/wiki/Mozilla doesn't mention the for-profit subsidiary either. (I'm still a happy user of firefox. I just care about keeping them accountable.)
- fabrice_d 11y ago
  Technically for profit, but with no external shareholders to bow to, no stock options for employees, etc. Don't be misguided by the administrative setup. Mozilla is earning money from partnerships, but the company goals are driven by the not-for-profit mission statement. It takes resources to stay in the game...
  - rhino369 11y ago
    Exactly. It's a non-profit that owns a company. All proceeds go into the non-profit.
iuzyyce 11y ago
Agreed. The only time I've used Firefox's customize mode is to remove crap they keep insisting on putting in my toolbar. I think it's pretty clear that the only reason Mozilla is complaining about this is because they think it will hurt their bottom line.

madars 11y ago

Changing search engine for existing users was a very unfortunate bug, which got fixed (https://support.mozilla.org/en-US/questions/1041571#answer-677594 https://support.mozilla.org/en-US/questions/1041571#answer-6...). Of course, changing the default for new users is nothing to be ashamed of.

Spivak 11y ago
I mean, it should be but it seems as though most people have accepted it.

oso2k 11y ago

I agree. And I extend that sentiment to their approach to Web Standards a few years ago too, like WebSQL [0] and NaCl [1], Dart [2]. That felt like NIH [3] or some other non-collaborative or ultra-competitive motivation on their part. Not a place of "speak for the Web". IMO, the choice of IndexedDB over WebSQL set the Web back 20 years. [0] https://en.wikipedia.org/wiki/Web_SQL_Database https://en.wikipedia.org/wiki/Web_SQL_Database [1] https://en.wikipedia.org/wiki/Google_Native_Client https://en.wikipedia.org/wiki/Google_Native_Client [2] https://en.wikipedia.org/wiki/Dart_(programming_language) https://en.wikipedia.org/wiki/Dart_(programming_language) [3] https://en.wikipedia.org/wiki/Not_invented_here https://en.wikipedia.org/wiki/Not_invented_here

Lazare 11y ago
> IMO, the choice of IndexedDB over WebSQL set the Web back 20 years. Yep. I recognise that this may not have been a winnable fight, but I absolutely judge the people who were on the other side. WebSQL was a much better tech than IndexedDB. Was the dependence on Sqlite problematic? Sure. But Mozilla had the resources to make a pretty good try at fixing it; instead they refused to even implement it and gave us the relatively terrible IndexedDB instead. Which, in turn, Apple has refused to implement[1], and now here we are. Thanks Moz[2]. (I'm less concerned about NaCL and Dart, because it's less clear to me that these were obviously superior technologies that obviously needed cross-browser adaption. You're certainly right that the pattern is suggestive though.) [1]: Yeah, I know, they claim to have implemented it. Anyone who's tried to use their implementation will recognise this claim as a subtle joke. On us. [2]: Their blog post justifying themselves[3] has not aged well. I especially love the bit where they say IndexedDB is better than WebSQL because it has better "developer aesthetics", as if anyone is actually casually coding against IndexedDB without using some sort of wrapper or compatibility layer. Or as if anyone actually likes the IndexedDB syntax and API. [3]: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis-and-the-road-to-indexeddb/ https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...
- brighteyes 11y ago
  How would you fix WebSQL? Writing a from-scratch implementation of SQLite seems like the only option, and I don't think Mozilla had the resources for that at the time. I agree the situation sucks, but I'm not sure how to fix it even today.
  - kylec 11y ago
    One thing I never understood is why there needed to be a second implementation of WebSQL. SQLite is public domain, any browser vendor can choose to embed it in what they ship.
    - brighteyes 11y ago
      It's a standards process requirement. A standard must have a well-written spec, well-written enough that multiple implementations are possible. Showing multiple implementations that are compatible is enough to prove that. When there is just a single codebase, even if it is open source, it isn't a standard. Now, not everything needs to be a standard, but on the web standardization is a big part of why it is so successful. One example of why a single codebase is bad: Imagine that SQLite version X is the implementation of WebSQL, which all browsers must use. SQLite development is of course continuing, fixing security issues and making it faster, etc. Will browsers just keep using SQLite past version X? What if the SQLite community takes SQLite in a direction that isn't optimal for web browsers? Perhaps web browsers will fork it. What if browsers end up not agreeing on the fork, and some use the original project, and others use the fork - or there are multiple forks? All of that makes it very risky that compatibility issues will appear between browsers. Having a properly specced standard, with multiple compatible implementations, is so far the best way that we have found that can prevent such things.
    - BrendanEich 11y ago
      More succinctly: SQLite version whatever is specified only by its C source code, and C is woefully underspecified. Lots of Undefind Behavior on top of the memory-unsafe codebase itself. This is not a specification from which two independently implemented interoperable implementations could be written. Ergo, not a standard.
pcwalton 11y ago
NaCl and Dart aren't Web standards.
- oso2k 11y ago
  I agree. And neither is WebSQL. I was speaking to the "approach to Web Standards", not actual Web Standards. My point being that Moz used (IMO) conjecture and FUD to roadblock those technologies. No attempt on their part to experiment with those technologies and prove their value. In return, we've got instead IndexedDB over WebSQL (which many devs choose to wrap), asm.js over NaCl (which v8 team as shown doesn't require a special compiler mode to optimize for), and ES5/ES5.1/ES6/ES7 language bloat over Your-Choice-Of-JS-Successor language or actually fixing the issues with JS.
  - pcwalton 11y ago
    I don't think it's FUD at all. asm.js is legitimately a more practical approach to the problem than NaCl, which is tied to the Pepper API. You can go back to the conversations on the plugin-futures mailing list in which everybody except Google was in agreement as to what should have been done instead of PPAPI; Google went with PPAPI anyway, sealing NaCl's fate with regards to adoption. Nowadays, we have Web Assembly, which Google and Mozilla are both working on, and which combines the best of both worlds. As for ES language improvements, I don't see at all how extending the existing language constitutes "bloat" over having two incompatible VMs. It's strictly less bloat, because you don't throw more VMs into the browser.
  - sonnyp 11y ago
    "we've got instead IndexedDB over WebSQL (which many devs choose to wrap)" It doesn't matter how developers choose to use IndexedDB, what does is for a Web standard to be sane and WebSQL never was. See https://news.ycombinator.com/item?id=9978713 https://news.ycombinator.com/item?id=9978713 "asm.js over NaCl (which v8 team as shown doesn't require a special compiler mode to optimize for)" I don't see how not requiring a special compiler is an argument against it. "ES5/ES5.1/ES6/ES7 language bloat over Your-Choice-Of-JS-Successor language or actually fixing the issues with JS" ES5/ES5.1/ES6/ES7 ARE efforts to fix issues with JS and mostly driven by Mozilla.
sonnyp 11y ago
About WebSQL Firefox already had (and still has) Sqlite dependency (it is uses for bookmarks, history, ...) it is not the issue. The problem is that the Web SQL standard states "User agents must implement the SQL dialect supported by Sqlite 3.6.19." [0] which made agents rely on a outdated dependency and non standard (sqlite is not SQL ansible compatible) SQL. A nightmare for Web standards. They made the right (and hard) choice. NaCl isn't portable (Mozilla is working on Web Assembly) Dart excerpt taken from Dart FAQ; question: "Will the Dart VM get into Chrome?" response: "No. Dart is designed to compile to JavaScript to run across the modern web, and the dart2js compiler is a top priority for the team." [1] [0] http://www.w3.org/TR/webdatabase/#web-sql http://www.w3.org/TR/webdatabase/#web-sql [1] https://www.dartlang.org/support/faq.html#q-will-the-dart-vm-get-into-chrome https://www.dartlang.org/support/faq.html#q-will-the-dart-vm...
- michaelwww 11y ago
  Google has the Dart VM running in Chrome and it's called Dartium. If Mozilla had not been so vigorously negative towards Dart the story of Dart and Blink may have turned out differently.
  - BrendanEich 11y ago
    No, Google Chrome people rebelled against the overhead of a cross-language-engine garbage cycle collector. Are you aware of the technical details? Before this, before Blink forked WebKit, Apple rejected naive DartVM pre-integration changes for the same reason: https://lists.webkit.org/pipermail/webkit-dev/2011-December/018811.html https://lists.webkit.org/pipermail/webkit-dev/2011-December/... Whining for the poor Google-Goliath, blaming little Mozilla-David, is rich. No comment on the Pocket deal or other recent Mozilla changes. On this tangent about Dart, I'm happy that Chrome people prevailed.
    - tkubacki 11y ago
      >On this tangent about Dart, I'm happy that Chrome people prevailed I'm not. We are sentenced for another 20+ yrs for lang with broken 'this' pointer
anotherangrydev 11y ago
To add another example, I normally do JS using Node and there (and also in IE) you have a very useful function: setImmediate. A few days ago, when doing some client-side JS I wanted to use it and I saw that it is not part of a standard, not only that, it has actually been REJECTED. It's really sad to see the development of the language crippled for a reason that basically boils down to "No, because it was proposed by Microsoft".

byuu 11y ago

Yeah, this is the most "pot calling the kettle black" article I've seen all month. Let's see: * no opt-out for Australis * removal of tabs on bottom * forced signed extensions * removing option to not retain download history (unless you give up browsing history too) * bundling of Hello * bundling of Pocket (requires a lot of effort to disable) * bundling of DRM web extensions * bundling ads out of the box (can be disabled fairly easily) * on and on ... I can't even keep track of it all anymore

brighteyes 11y ago
I think reasonable criticisms were made regarding some of those, like Pocket. However, Australis for example was a large redesign of the UI. I'm not sure how you can support an opt-out, as that would mean supporting two codebases - two different and separate UIs, at once. Regarding bundling of DRM, it isn't bundled, but it is downloaded on demand. This is a sad thing even so, but Google, Microsoft and Netflix just left other browsers no choice when they invented, standardized and shipped EME DRM. Mozilla fought DRM, but lost.
- m45t3r 11y ago
  Yep, this is what I think too. The Pocket and Hello case could at least have a disable option, even Google allows you to disable the new features that it brings in Chrome like Google Now and more recently the "Ok Google" hotword detection. However, the Australis case is much more complicated. An UI is tons of code, if Mozilla opted too maintain two different codebases they would need to update both everytime they added a new feature. This would be a maintenance nightmare, to say at least. I think it's ok to have this feature as a separate extension, maintained by people that actually care about the older interface.
  - byuu 11y ago
    > The Pocket and Hello case could at least have a disable option I really don't think burying an opt-out option justifies these things. This is the same tactic used to push malware in installers, Ubuntu's farming your search results to Amazon, and many of the new Windows 10 privacy intrusions. "You can opt-out (if you know you need to (and you know where to look (and you know about the gotchas like it only applying to enterprise customers)))" If they were honest, these things would be opt-in. But they're not, because that wouldn't make them their money. (and if you really believe someone at Mozilla isn't getting paid for Pocket integration, then I have a bridge to sell you.)

akkartik 11y ago

It's also disingenuous to call Mozilla a non-profit, given its wholly-owned for-profit subsidiary: https://www.mozilla.org/en-US/about/governance/organizations https://www.mozilla.org/en-US/about/governance/organizations. Used to be that mozilla.com was the homepage for the for-profit wing, but I see now that it just redirects to mozilla.org. https://en.wikipedia.org/wiki/Mozilla https://en.wikipedia.org/wiki/Mozilla doesn't mention the for-profit subsidiary either. (I'm still a happy user of firefox. I just care about keeping them accountable.)

fabrice_d 11y ago
Technically for profit, but with no external shareholders to bow to, no stock options for employees, etc. Don't be misguided by the administrative setup. Mozilla is earning money from partnerships, but the company goals are driven by the not-for-profit mission statement. It takes resources to stay in the game...
- rhino369 11y ago
  Exactly. It's a non-profit that owns a company. All proceeds go into the non-profit.

iuzyyce 11y ago

Agreed. The only time I've used Firefox's customize mode is to remove crap they keep insisting on putting in my toolbar. I think it's pretty clear that the only reason Mozilla is complaining about this is because they think it will hurt their bottom line.