Hacker News Reader

Comment by paride5745 | Hacker News Reader

This is a good news.

Firefox OS was never a real product, but a PoC.

IMHO, Mozilla should absorb the Tor project and focus on Free Web technologies, e.g. a really Free email service and a Free cloud storage service.

Yes, I intentionally use capitol F for Free.

How to raise money? Freemium model.

A good email+cloud storage service, with the optional pay model for using a custom domain.

And stop attacking the Linux distros for the Firefox trademark (forcing them to create the Iceweasel fork) or including proprietary services (e.g. Pocket) forcing the creation of the Icecat fork.

Just be a Free and Open browser, with some good cloud services, and make money within a Freemium model (allowed by Free Software Foundation policies).

View on HN

> IMHO, Mozilla should absorb the Tor project

Tor has too many legal and ethical issues around it for Mozilla to take that kind of risk.

> And stop attacking the Linux distros for the Firefox trademark (forcing them to create the Iceweasel fork) or including proprietary services (e.g. Pocket) forcing the creation of the Icecat fork.

Debian made a bunch of changes to Firefox and was still calling it Firefox. Debian also objected to Firefox's trademark policy despite Debian's trademark policy for their own trademark being virtually identical. This happened years ago and years before Pocket even existed.

Pocket code in Firefox is open source, you can examine it yourself. And, due to lazy loading, it's never even called if you don't interact with it. You can right-click and remove the button and never worry about it again. Using Pocket was to add a much-requested feature to Firefox without Mozilla having to invest to development hours into building something that already existed.

I don't think Debian "objected". Mozilla's trademark rules are not compatible with the DFSG, therefore Debian can't distribute an officially branded Firefox. I do think the ideal thing would be for Mozilla to distribute Firefox packaged in such a fashion that the branding can easily be swapped out (in the same way that e.g. Redhat isolates its trademarked material to a couple of packages and documents exactly what you need to replace if you want to distribute your own modified version of Redhat) so that there would be no need for a full fork.

Two things:

1. It's true that the Debian didn't initiate the schism. Mike Connor (Mozilla) told the Debian folks to stop distributing branded builds that weren't QAd by Mozilla.

2. When doing a build, it has always been trivial to create an unbranded version. Unbranded versions are what you'd get by default. At this point, I haven't run a build in years, but it would be surprising if this weren't still the case.

I don't think it's the case anymore. They used to name the releases and then brand it based on the name. The releases are treated as inconsequential now.

> Pocket code in Firefox is open source, you can examine it yourself

You can see the client side code but what Pocket is doing with all the data on the server side is completely opaque and source is unavailable.

This only matters if you use Pocket.

This is no different from search integration. There's local code that lets you do Google/Yahoo/etc searches from the home page or the awesomebar. What these sites do with your data on the server side is unknown.

Firefox gives many choices for search integration. Perhaps something like that would have made Pocket more acceptable.

Exactly. If the problem was note-saving integration, they should have built an open interface for it, and then maybe (maybe) endorsed Pocket as the reference implementation, featured in the extension gallery or on the start screen.

Bundling Pocket outright, like Mozilla was just another Silicon Valley company, was very shortsighted.

Almost like you could install Pocket whenever you wanted to use it in your browser and remove it when you didn't want it, like you can with search engines?

Also, I would not particularly call those search engines a great comparison. They are simply keyworded bookmarks - you set the URL and when you enter a character or click the icon it loads the bookmark. The extent of integration was the search options menu where you can add any website's search field and it inherits the icon from that website, so its generic.

The fact that we are still talking about Pocket being integrated in 2016 amazes me. Especially considering that Mozilla was designed and intended as a community project.

So is basically every single website you visit and all the data you share with them wittingly or unwittingly. Pocket isn't a password manager, it's a short scrapbook of things you want to read later.

Not every website I visit has its code integrated right into my open-source browser.

And you can build a pretty accurate profile of a user from analyzing the content people mark to "read later" (and how long they spend reading them).

You don't get access to the source of any site you're sending HTTP GET or POST requests (dynamic content) to with Firefox, yet you're complaining about client code for Pocket?

Not every website collects data. A pure HTML/CSS/JS site can be examined fully.

> or including proprietary services (e.g. Pocket) forcing the creation of the Icecat fork.

Your timeline is off by about a decade. IceCat was first released in 2008 and the GNUzilla project has existed since 2005. Firefox added Pocket support in 2015.

> And stop attacking the Linux distros for the Firefox trademark (forcing them to create the Iceweasel fork)

Debian's rules don't allow things that aren't free-free, and blocked the copyright-encumbered logo. Mozilla was protecting it's trademark and branding. Debian calling it iceweasel basically replaced the branding so that it could be used under Debian's rules. It turned out to be a fairly amicable result - debian still gets the software with full utility, and mozilla keeps their branding coherent (branding is important to making money with any model, but especially freemium).

Also, this licensing stoush was ten years ago; it's not like it's fresh wounds.

I am sorry you are down voted because fundamentally you are right. If you have a trademark, you are obliged to handle the use of your trademark very carefully, these are the rules and this is not because you are an organisation supporting free software that you can escape these rules.

Why isn't this a problem for Linux? Or Perl, Python, Drupal or many of the other packages that exist under their trademarked names in Debian and other distributions?

There are several options:

* The logos might be under a free license

* The logos might not even be shipped (not a big deal for Perl and Python, which are primariliy command line applications)

* The trademark protection only includes the name, not the logo, and so it doesn't force the owner to defend its usage to keep the trademark.

For example https://www.drupal.com/trademark mentions a drupal icon which is subject to traemark, and a logo, which is not (unfortunately the log link is a 404).

Trademarks that are only for the name are actually handled differently? If that's the case it would explain it I suppose. First time I hear of this being a special case.

Yeah, Drupal has the wordmark branding and the community branding as separate things. I just brought up these examples because all of them have Debian packages that apparently have no issues being named after the project but there are of course numerous others.

Firefox is a brand present in a highly competitive market. It's a brand known by consumers who are used to associate a name and a logo to an experience and can easily get confused (such as people seeing the "blue E icon" as the way to "start google" for instance).

Mozilla protected more agressively its Firefox brand to cope with malware-stuffed clones which were hijacking the name.

Projects such as VLC or Android protect their brand too, Chrome is only available through official closed-source builds, many linux distributions only package chromium.

I am aware of the reasoning they might have for this and was mostly asking about the parent's claim that Firefox is legally obligated to do this.

VLC is still gets packaged by Debian as VLC and even branding intact I believe. Chrome is a little different since you can't even build it so Debian's interest in including it instead of Chromium isn't probably all that high anyway.

So which part of replacing the Firefox brand with Iceweasel is coherent branding?

It's not just replacing the Firefox brand, it's replacing the onus of responsibility for the package. When Debian packages your software, they insert their own patches, they do their own disparate issue tracking and release archive management, they are quite effectively a separate product. If they called it Firefox, by Debian, it would be equally damaging to the Mozilla mark (in a sense of trademark law.) If they didn't do their usual Debian thing with the patches and the release management, it would be similarly damaging to the Debian mark, so-to-speak.

(All packages get this treatment, no upstream software release vendor gets special privileges.)

This goes way back - I was a documentation volunteer in the run-up to the Mozilla 1.0 launch in 2002, and Debian did all manner of weird things to their Mozilla package that we then had to sort through to distinguish from the mozilla.org binaries (e.g. someone had to make a list of Debian Mozilla useragents so we weren't specifically checking their behaviour).

Mozilla wants people to be able to trust the Firefox brand. They don't even use "Firefox" branding on their own nightly or dev builds. They only put it on software that's been through their own QA. So you're free to use the code, but they won't let you put the name or logo on any forks or even builds they haven't signed off on.

I think at this point that the Firefox brand has been tarnished, unfortunately.

For many average users, the term "Firefox" reminds them of the slow browser they used to use before switching to Chrome.

For more advanced users, the term "Firefox" reminds them of the browser that includes ads (even if these are being removed), has unnecessary functionality built in (Pocket, Hello), and has undergone questionable UI changes (Australis).

For web developers, the term "Firefox" reminds them of the extra effort they still need to expend to test their creations in a browser that fewer and fewer people are using.

For others, the term "Firefox" will now remind them of this failed mobile OS project.

"Firefox" as a brand had a great reputation 5 years ago. But that reputation has eroded away since then.

I disagree.

Most "normal" users who used Firefox before Chrome came around are savvy enough to understand that software improves and evolves. There's no doubt that Chrome gave Firefox a much-needed shot in the arm.

Many developers/advanced users, including myself, see Firefox as a bastion of freedom in what is otherwise a land grab by major OS vendors, an attempt to further increase their lock-in. Users remember Firefox as the browser that was so flexible, Firebug was possible, which sent every browser vendor into a tizzy to try to clone the featureset natively. Users remember Firefox as the browser that gives them control over their experience, unlike Chrome which babysits and won't let you interfere with Google's need to harvest data.

The first 2 years that Chrome was out, it trounced Firefox all around. I switched back to Fx around that time. These days, Firefox's JavaScript performance is comparable if not better than Chrome's [0] and its extension ecosystem and extreme configurability make it a much better option than Chrome for me. The only reason I use Chrome now is to take advantage of the proprietary extensions that allow me to use Netflix or Flash on Linux.

Mozilla has always and will always be a tinkerer's vendor. These people are not going to be offended when reasonable experiments are conducted, nor when reasonable experiments fail, as Firefox OS did.

The biggest grudge I hold against Mozilla is really more about the community than the company itself, and that's the Brendan Eich debacle.

[0] http://arewefastyet.com/

Users remember Firefox as the browser that gives them control over their experience

Power users, or users? Among the crowd here, sure. But in the rest of the world?

unlike Chrome which babysits and won't let you interfere with Google's need to harvest data.

Firefox has been getting more and more nannyish and chromelike with every release.

* There's the "let's throw out semantic versioning since Chrome already did it"

* There's the UI rework which sacrificed information density and usability for what I evaluate as a weak attempt to look more like Chrome.

* There's the "thou shalt not install plugins from places other than we say is okay" rule that was recently implemented - which Chrome did first.

* There's the upcoming "all your plugins are going to break, many permanently" when XUL gets thrown out and the new hotness won't have feature parity at release (in other words, Firefox plugins will be as limited as Chrome plugins)

> There's the "let's throw out semantic versioning since Chrome already did it"

Firefox never followed semantic versioning. Versions 2.0, 3.0, 3.5, 3.6, and 4.0 all had equally major changes to them. It's worse if you look at the internal version numbers: 1.8, 1.9, 1.9.1, 1.9.2, 4.0. The change to the rapid-release model was driven more by the pain of the protracted Firefox 4 release than by trying to ape Chrome.

> There's the UI rework which sacrificed information density and usability for what I evaluate as a weak attempt to look more like Chrome.

Actually, Firefox started developing the design before Chrome did. They just took far, far, far longer.

As far as I can tell, the Australis work dates back roughly to 2012 (that's when their wiki meeting notes start, and when the Australis tracking bug in Bugzilla was opened).

You may be mixing Australis up with the theme work done for Firefox 4.0 (which moved tabs to the top by default and added the orange Firefox menu button). The early work on that would've been contemporaneous with the earliest public versions of Chrome (2/3/4)-- the design that would become Firefox 4 started being shown off in public around the fall of 2009.

Fair enough on the versioning thing - but as far as the UI, Chrome's main interface has remained almost identical to its initial release seven years ago. Firefox was really working on something similar for that long?

> * There's the upcoming "all your plugins are going to break, many permanently" when XUL gets thrown out and the new hotness won't have feature parity at release (in other words, Firefox plugins will be as limited as Chrome plugins)

As a long time firefox user this is the one that hurts the most. I honestly hope someone forks firefox to preserve this functionality. I know it is a losing proposition in the long run, but right now my only option is to not upgrade firefox (which isn't an option for very long). I post this here to vent and with the hopes that there already exists a project to preserve XUL functionality and I am simply unaware.

P.S. I use tab groups, a native feature, and have been dreading this ominous warning that appears whenever I open them: "Heads up! Tab Groups will be removed from Firefox soon." I can't even disable the warning.

You can change the API without removing functionality. WebExtensions are going to be based upon the Chrome extension API, but will be expanding on that so that many of the "uniquely Firefox" addons can still exist.

Palemoon

I've been a happy user of it more many years.

Once you use it, you'll wish you'd found it sooner ;)

Version numbers and menu placement have nothing to do with being "nannyish" or data collection.

Can you name three good plugins? Removing an insecure legacy tech is not a big problem when the extension API is right there.

I said more nannyish AND chromelike.

Three good plugins? Have nine. Here's my plugin load right now:

    * uBlock
    * Privacy Badger
    * HTTPS Everywhere
    * Calomel SSL Validation
    * FoxReplace
    * Vimperator (which used to be Pentadactyl before Mozilla decided that I can't use it anymore[1])
    * Noscript
    * DevEdition theme enabler
    * 1Password

And please spare me the "insecure legacy tech" argument. The new plugin architecture explicitly can't do things that the existing plugins can, per Mozilla's own words[2]. And also per Mozilla's own words, the new architecture takes after Chrome.

if I wanted to use Chrome and have its limitations, I'd fucking use Chrome.

And I have zero faith that they will fix those limitations by launch time either. seeing as how their attitude towards adding features nobody wants (Pocket, Hello, Australis) or removing features people actually want (installing whatever plugins I damn well please without a nann^H^H^H^H approval process, accessing sites with broken certs) up until now has been to ignore all feedback and just do it anyways.

[1]: https://pbs.twimg.com/media/CZVvYtKUsAAtMl7.png:large

[2]: https://blog.mozilla.org/addons/2015/08/21/the-future-of-dev...

XUL is insecure legacy tech. There isn't a coherent argument otherwise: XUL is insecure in that it gives addons all the power of the browser, and XUL is legacy, unspecified, single-implementation-wedded XML stuff from the '90s whose functionality has been entirely superseded by HTML at this point. The idea that nothing can be insecure and legacy unless the new alternatives support absolutely everything the old technology did is absurd: that would prevent us from calling DOS "obsolete and legacy" because apps running in ring 0 can do things that apps running in ring 3 can't.

XUL may well be insecure legacy tech that performs a useful task for you, and that's why care is being taken to make sure the important extensions continue to work in the new Web Extensions world.

> ...whose functionality has been entirely superseded by HTML at this point...

This is just not true. Not all functionality enabled by XUL can be executed with Web Extensions. Perhaps this will be so in the future.

> ...and that's why care is being taken to make sure the important extensions continue to work...

Who decides what extensions are "important" and therefore worthy of working in this new "web extensions world"? I guess my point is that if there were true parity between web extensions and XUL there would be no need for concern. However, that is not the case and we know many extensions cannot be recreated. Therein lies the problem. Many users will be negatively affected by this change and I am still trying to understand the benefit. For example, why are Web Extensions mutually exclusive to XUL extensions? I get that supporting both is inelegant, but it at least reflects the current reality of Firefox usage.

> This is just not true. Not all functionality enabled by XUL can be executed with Web Extensions. Perhaps this will be so in the future.

We should be careful to separate XUL-the-layout-system from XPCOM (really, Firefox's XPCOM components). The layout features of HTML and standard CSS have entirely superseded the layout features of XUL in the ways that matter. (There are some exceptions—the tree view control is often cited—but there are lots of HTML substitutes for these things, and XUL has so many problems that on balance the downsides outweigh the upsides at this point.)

What you're actually referring to is the XPCOM components provided by Firefox. It is true that Web Extensions, as of this moment, do not replicate all of that functionality. However, as I said before, that isn't a valid argument that XUL should be kept around forever any more than the fact that 16-bit DOS apps have direct control over the hardware is a valid argument that DOS support should be kept around forever.

> For example, why are Web Extensions mutually exclusive to XUL extensions?

Well, they aren't. But the reason for Web Extensions is to deprecate XUL extensions, and the reason for deprecating XUL extensions is that XUL is legacy, insecure tech.

Thank you for explaining the difference between XPCOM and XUL layouts

> that isn't a valid argument that XUL should be kept around forever any more than the fact that 16-bit DOS apps have direct control over the hardware is a valid argument that DOS support should be kept around forever

I don't think I argued that it should be kept around forever. The point I was refuting was that Web Extensions are ready to replace existing firefox extensions. At some point it will be true that Web Extensions are as capable as existing firefox extensions. At that point deprecating existing extensions make sense (or slightly sooner). Lots of people rely on existing extensions. Taking those extensions away without a real alternative solution is just rude to end users. This move may be past due from a security standpoint, but it is extremely premature from a user experience perspective.

Is there a list somewhere of which extensions have been deemed "important"?

As far as I'm concerned, every single Firefox extension I currently use is important, regardless of what Mozilla thinks of their importance.

I also have several extensions that I wrote myself for my own personal use. I'm not looking forward to having to modify them, assuming they'll even work with the new model.

This is a good example of the Firefox brand being tarnished.

The name "Firefox" used to make me think of empowerment, and being able to get so much more out of the web browser and the web experience.

Now when I think of "Firefox" it makes me think of uncertainty, of broken extensions, of my time being wasted updating my own extensions, and of enduring all of this for little to no benefit to me.

There's a tradeoff between keeping legacy code working and deprecating old APIs that are holding the platform back. Keeping all extensions working without changes is essentially incompatible with the migration to a sandboxed, multiprocess browser. Keeping XUL is incompatible with any future migration to a next-generation layout engine. XUL also holds back Gecko development because Gecko essentially has to support two different rendering modes; time spent keeping XUL working is time not spent improving security and performance of the Web stack.

Even if you don't want those architectural improvements, a lot of people do, and I find it hard to blame Firefox for doing what's best for the needs of the majority of its users.

Don't get me wrong, I'm not against Firefox improving and evolving.

And I really don't care if Firefox is or isn't using XUL. As a user, that's quite irrelevant to me.

However, as a user of Firefox, I am weary about being put in a position where the extensions I depend on no longer work, and either I don't have any recourse (if what the extensions do is no longer permitted or possible) or the recourse involves a large expenditure of effort on my part (rewriting my own private extensions).

The friction of using Firefox has been steadily increasing over time for me.

At this point, it's only the Firefox-specific extensions I use that keep me from switching to an alternative browser.

I know I'm not alone.

Many in the Firefox community already went through the broken extension experience back around Firefox 5 and we are not eager to go through that again.

If Firefox users do experience problems with these upcoming extension changes, then I fear it will be the last straw for many of us.

And if there's one thing that Firefox and Mozilla really can't afford right now it's to lose more users. There are very few of us, relatively speaking, as it is.

I'm less worried about the architectural improvements than I am Mozilla's blasé attitude toward making things work - history shows us that MO is to break it and fix things later, rather than releasing something that'll be mostly feature complete on day one.

Oh, you weren't talking about plugins.

The XUL removal is annoying but in theory the new system should be able to support almost everything the old system did. It's not going to be like chrome where you can't even change the tabs.

The extension signing is about the only thing nanny-ish, and they're trying not to restrict people. For the most part it's an automatic scan, they won't block you based on what your extension does, and you can personally use a build that doesn't care about signing. It's not perfect, sometimes there are delays, but they're trying. They don't want to be a massive malware vector.

I can totally understand having an approval process for things they distribute.

I can not understand refusing to let people install their own plugins unless they use some other random build.

What's the actual problem being solved here? If you've already got malware on your machine with the ability to install plugins in the browser, don't you have bigger problems than an unwanted toolbar popping up?

Furthermore, how do you think people are going to react to plugins they use being suddenly switched off, with no recourse, other than downloading, installing, and configuring a new browser? (Which, by the way, misses that critical bit of security, leading back to the "why?" question)

I can tell you how I felt when Pentadactyl stopped working. It's enraging. https://twitter.com/TKWare/status/690580588416339968

We're in a weird world of '''Potentially Unwanted Programs''' that pretend to be something the user wanted while spamming them and collecting info on them. If they can't sneak in, some will give up, and some will patch firefox and become politically easier for anti-malware to kill.

When the time comes, I think Mozilla should move on from the Firefox brand to an exciting new browser brand. Mozilla forked Phoenix from SeaMonkey. Microsoft forked Edge from IE.

When or if Mozilla can start merging the Servo engine or Electrolysis multi-process support into Firefox might be a good time. (I like the name Servo for the whole browser. :-) Like IE, Firefox has had a hard time shaking its old reputation (e.g., memory leaks and add-on breakage). A new brand says "this is something new; give us a try again."

I was thinking of having the two browsers coexist for a while now. Firefox for those who need XUL add-on support, the new Servo-based browser for those who don't.

That's kinda ironic, cosnidering Firefox OS was a pos.

> including proprietary services (e.g. Pocket) forcing the creation of the Icecat fork.

What? GNU IceCat has nothing to do with Pocket. https://en.wikipedia.org/wiki/GNU_IceCat#Origins_of_the_name

Yes and they should allow us who want to actually use the capital F.. Free part of the licence to use your own servers for everything. It is really hard to do now with Sync in Firefox for example.

What is hard about it? I've never used it, but have been meaning to for a while. Are there licensing issues? or is it just hard to actually get working?

In version 28 or so they removed the ability to configure Firefox Sync against a custom Sync server. You could continue to use an existing setup but there is no UI for setting up a new one. (all AFAIK)

It's things like this which become annoying. Almost like an old school corporate mentality... despite being an open-source platform. I'm trying to get into using Firefox again but the lack of transparency from Mozilla Inc. is frustrating.

To add to this reasoning: [ Remove "Ask me everytime" cookies option](https://bugzilla.mozilla.org/show_bug.cgi?id=606655).

> a really Free email service

What do you mean, exactly?

Service that's Free as in "Free Software"? We have enough of free MTA, MDA and MRA software, and while they can be always improved further there's need to start a new project. There are also a lot of packaging efforts, where anyone can find what they'll be pleased with (from source tarballs to build to one-click "rent a server and provision everything there, pre-configured" web-based buttons). And Mozilla have finally ditched their MUA (Thunderbird) recently, so I somewhat doubt they'll venture in that field again, even if they'd decide to make a web-based MUA (instead of desktop software) this time.

Service with some nice-to-hear policies? There are enough services that do all sort of pinky promises (and, I must admit, some try to bring some technological measures, but core email protocols don't allow much here, so it's mostly still relies on trust) of privacy, security and all sorts of stuff. Not sure if we need another one.

Something else?

A Gmail that doesn't sniff your emails to serve ads to you or hand them over to the government, that's based on a FOSS project and can be hosted on your own server if you'd like to. Throw in an encryption option and you have a winner.

I would love to use a email/webmail service from Mozilla. It would have to be ads supported but there might not be as much of a stigma against it as with suggested tiles.

I mean there is Mozilla Thunderbird, but it hasn't been the focus of much development since 2012, with intention to decouple it from Firefox development in 2015.

[https://en.wikipedia.org/wiki/Mozilla_Thunderbird] [https://www.mozilla.org/en-US/thunderbird/]

That's just a client we were talking about a service. (eg. Yahoo Mail, Gmail etc.)

I agree, email from mozilla would be a killer. I'd pay for it.

> including proprietary services (e.g. Pocket) forcing the creation of the Icecat fork.

The search bar is an equally proprietary backend service, and pretty much universally funds Mozilla, but I don't hear many complaints about it.

At the time it was implemented, it was controversial; but the overall sentiment was that it was a necessary evil to get Mozilla some stable funding. Also, OpenSearch is a standard and anyone could easily replace the default.

Pocket was simply an extension that got bundled outright. After decades of Mozilla declining to include even uber-popular extensions in order to "keep up appearances" of being a neutral community project, they basically endorsed a random startup without any sort of consultation or public competition. That's what people objected to. If they had implemented a standard and just blessed Pocket as a reference implementation without bundling it, nobody would have complained.

Reply on news.ycombinator.com