Hacker News new | ask | show | jobs
by MisterWebz 4027 days ago
It is so unlike Mozilla to introduce something like that, I ran a virus scan and checked what programs had been installed recently -- I assumed it had been put there in the same way that IE users used to get the Ask Toolbar installed.

Exactly how I felt. What the hell were they thinking? I'm generally very supportive of Mozilla, I even supported their initiative to put advertisements on Firefox's start page. But bundling stuff like Pocket and Hello with Firefox is just ridiculous. Why not make it an official extension? That way users can easily disable or remove it.

10 comments

> Why not make it an official extension?

It says a lot about Mozilla when they decide to bundle fad features like these after spending years stripping existing features[1] out of Firefox. During their effort to dumb-down[2] Firefox, it was common to hear that removing those features didn't matter, as they should be provided by extensions instead. Apparently that cheap excuse is ignored when the feature when it is convenient to do so.

[1] the many options cut from the preferences dialog comes to mind - some that I have had to help a LOT of friends work around. Far too many man-weeks have been wasted ;_;

[2] which was a terrible idea that hurts the enthusiast that actually used those feature, hinders the inexperienced-but-interested users by hiding previously visible features behind the addons.mozilla.org, and doesn't do anything at all for the supposed target audience of non-technical users who by definition don't even use the preferences dialog.

i had memorized the index of my 65535 bookmarks, now have to scroll by +1 which forces me to a 17-bit mental pointer. who thought 17-bits was ok?
This completely captures my response as well. I run on the beta channel, so the day after 38.0 stable hit, this got rolled out the the beta channel. I checked the plugin/addon page and my user profile directory at least a dozen times, assuming that something unwanted had done this behind my back. I probably wasted half an hour looking into this. Finally, I took a (second) look at the release notes before actually realizing that this was something build in. (I missed it the first time because it didn't even register that they would be doing this.) What really shocked me was that it was added by default to standard toolbar, which seemed rather rude and presumptuous. (Maybe they rolled this out differently to the stable channel, I don't know.)

Worst of all, there has been almost no communication on this. I subscribe to Planet Mozilla and read everything that seems interesting to me, and I still didn't know this was coming. There still hasn't been much public discussion on this. On top of that, they did a weird 38.0.5 release cycle that I haven't seen before with the release train. It was almost like someone said: "there is no way we can introduce this to enterprise with an ESR release, so lets tweak the whole release model so we can shove it in everyone else's face once we spin the ESR release."

I've been a huge Mozilla supporter since back in the Pheonix days. I'm even okay with their ad ambitions (so far) and think that they made the right pragmatic decision with regards to DRM support. However, with this move I've now felt it necessary to take a step back and seriously question their motives. It just seems so far out of character. I've been thinking and reading about this for the last 3 weeks and I still have no idea what they are thinking.

Edit: I'd also like to add that I'm a huge Firefox Sync fan. The fact that they took such a user focused approach to encrypting everything client side, and minimizing their server-side exposure to user data seemed like such a principled approach and is probably the only thing that kept me from taking the leap to Chrome at a time when there were noticeable performance benefits to doing so. This integration seems like the exact antithesis.

In my view, they need to reverse course 180 degrees on things like Pocket and Hello, or it will be the beginning of the end for Firefox.

Firefox is a niche product that appeals to the privacy-consciuos. Stuff like Pocket and Telefonica/Hello basically eliminates its reason for being.

I have Firefox as my main browser now, but I won't keep it around for long if I have to swat down new marketing integrations in every new release.

I'm not as concerned with the Hello integration. With both features, I'd like to know more on the technical details.

For Hello, I think Mozilla (but actually unsure who's servers?) is only involved in initial discovery and, if needed, WebRTC NAT traversal. In terms of code bloat, I think Hello is just a bit of extra javascript on top of functionality already built into the web platform.

But I admit I haven't look that much into it. I don't know how or if crypto is used. I haven't used the feature yet either and would want to know more before using it in a corporate or privacy sensitive situation.

I guess the same goes for Pocket, I probably don't need to worry about it if I'm not using it. However, for me personally, it just seems to be such a stark contrast with their position on Sync. On top of that, the browser UI is _mine_! Nobody - not even Mozilla - should be adding something to the primary interface of _my browser_ without a very good reason. And this is where I feel my trust has been betrayed for the first time.

Hello uses Telefonica servers. My guess is that Mozilla's partnership with Telefonica is the reason why Hello was added to Firefox.
Not really. Hello was added in order to offer an alternative to Skype/FaceTime that uses open Web technologies and does not require you to create accounts or upload contacts. The partnership with Telefonica made it more convenient since they host the server side.
What's your beef with Hello, exactly? The whole point of Hello is to offer an alternative to Skype/FaceTime that uses open Web technologies and does not require you to create accounts or upload contacts. How does that not appeal to the privacy-conscious?
Because it doesn't belong within the core browser framework. A browser should not tie to your "internet identity", whether it's an account or a cookie fingerprint. That actually is the business of a service to manage.
Because it wasn't a choice I made to install it, and since it's not something I'll use, it's useless for me. I do use pocket, but I'd much rather use it as an extension vs a special integration with who-knows-what different permissions / sandboxing / control vs an extension.
Both features have near-negligible overhead if you don't use them. But having them in the product makes them accessible to the wide userbase, many of whom don't know what addons are or how to install them.

Therefore it seems reasonable to add them to Firefox.

I'd much prefer them to improve the memory and performance reporting features over adding some features that goes against their core values. right now I have a firefox that uses tons of ram and slows down to a halt very frequently but there are no decent tools to diagnose what addin/plugin/webpage/bug might be causing trouble. it's very, very frustrating.

edit: I am talking about multiple gigs of memory for firefox and multiple gigs of memory in the kernel task allocated for who knows what. stop firefox and it lowers the kernel memory to a reasonable level and (obviously) removes the memory usage of firefox.

If that's the intention, they failed horribly. Not because the lack of adoption, but because a propietary server is involved. Only the client is open.
You really start to wonder what pot they are smoking over there at Mozilla. Standard things you would expect from a browser, like a way to easily disabling javascript are apparently left to third-party extensions, because oh you don't want to bloat the browser. But hey, video conferencing on the other hand is such an essential part of the browsing experience.
They don't let users easily disable JS because that breaks so many webpages, and they didn't want to deal with supporting users who complained that Firefox wasn't working. http://limi.net/checkboxes-that-kill/
The vast majority of the described problems would be solved if Firefox provided more/better documentation and help text alongside such options. Or better yet, they could be solved by Firefox displaying warnings if pages appear to rely on certain settings.

Javascript disabled and a site relies on it? "Hey, this site would probably work better if you enabled Javascript, but you have it disabled. Would you like to enable Javascript again? Or perhaps just for this page?"

SSL/TLS disabled? "Hey, so TLS is disabled, but I need it in order to show you this web page. You want me to enable it for you?"

The overarching theme here is not that there are too many options, but that there are too many poorly documented options with poorly documented consequences. Fixing that problem would give users the best of both worlds: flexibility and ease-of-use.

This wouldn't work, the majority of users don't read so they would blame Firefox either way. And showing message box every damn time one site has Javascript/SSL (and considering that almost every site nowadays has one or another) would infuriate the users that really want to use this feature. It's a lose-lose option.

I think it's fine to have these options as extensions or even inside about:config, where the user would never disable by accident.

> This wouldn't work, the majority of users don't read

If they don't read, then they wouldn't be using Firefox, since all web pages (barring a few exceptions) would be gibberish to them :)

> And showing message box every damn time one site has Javascript/SSL

That's not what I'm advocating in that particular recommendation. I'm more advocating for some sort of heuristic analysis when Javascript is disabled. There are lots of sites that do silly things like rely entirely on Javascript for rendering text (for example); those should be easy-to-detect as scenarios where a warning would appear.

Also, most similar warnings presented by Firefox already (usually about outdated plugins and such) have a way to permanently dismiss, or to remember a setting for a particular website, or some other way to mitigate the understandable annoyance of always throwing warnings. A "don't ask me again" would immediately resolve the problem you identified.

> I think it's fine to have these options as extensions or even inside about:config, where the user would never disable by accident.

I think that's fine, too. My comment was more about identifying the correct cause of various effects - i.e. that the harmfulness of the checkboxes being criticized is due to their non-obviousness rather than their existence.

> If they don't read, then they wouldn't be using Firefox, since all web pages (barring a few exceptions) would be gibberish to them :)

Not can't read; don't read. See http://blog.codinghorror.com/teaching-users-to-read/, http://www.joelonsoftware.com/uibook/chapters/fog0000000062....

Users don't read material that's put in front of them. Modal dialogs get dismissed without reading, non-modal dialogs (Firefox's doorhangers, Chrome/IE's notification bars) get ignored completely or dismissed.

This comment makes me strongly believe you don't speak to end users.

You can't get them to read prompts at all, let alone text on a page.

My comment actually comes from lots of speaking to end users. I cut my teeth on help desk and desktop support roles; understanding end-user needs is baked pretty damn hard into my blood.

And from those discussions, and from my observations of those users, 99% of the problems discussed would be resolved if it was clear what options actually did. Users don't know or care what "Javascript" or "TLS" are, but you can bet your ass that if the relevant checkboxes had at least a basic explanation of why they should be checked (i.e. "Don't uncheck this box unless you know what you are doing; doing so will cause a lot of websites to break"), the vast majority of end-users will happily leave that box unchecked until they ask someone more knowledgable about it.

or somebody on a reddit thread tells them to do it.
That's what sensible defaults are for.

But in this case, we're dealing with users who somehow managed to disable JS, but are still surprised by the effects and don't read prompts.

I'm pretty sure such users exist, however instead of directly basing your UI descisions on this scenario, why not trying to investigate where such behavior comes from and how frequent it is?

Imagine a user whose internet isn't working. They go into their web browser's Preferences and start fiddling with things at random "until it works again" (for entirely unrelated reasons.) Then they leave things however they just made them.
Documentation only makes software easier to use if it is read. People don't read it.
By "documentation" I mean actually making the checkboxes better explained in their visible descriptions, or accompanying those descriptions with "a lot of websites rely on this box being checked" or somesuch. By no means am I calling for more things to be buried away in never-read manuals.
And you think people read those descriptions when they follow the latest tutorial (in the syle of http://www.tech-recipes.com/rx/2710/firefox_disable_the_down...) to make their firefox 25000% faster?
What a terrible article. So they have a problem of users who are ignorant about the fancier features in a big app like Firefox. So instead of trying to fix that ignorance with education and a better UI, they punish the people that used to use those features while justify those actions with claims about how important it is to nerf the internet to protect these ignorant users.

Anybody that read my posts in the recent HN thread on building devices for safety (and the Therac-25 discussion) knows that I advocate strongly for spending the time and effort to make sure a design fails safely. It would indeed be a terrible design, for example, to provide a checkbox or radio button that let you disable important TLS/SSL security features. As a potentially serious safety risk, those features should be handled with great care. On the other hand, disabling javascript or image loading is not a safety risk; the worst that can happen to the user is they can't use some webpages. Removing the ability to disable those features isn't doing anything for the benefit of the user, it's Mozilla trying to avoid having to deal with tech support.

Some things in life need to be learned by experience, and by limiting the safer opportunities to lean about how the browser and the internet works, Mozilla is working to keep users ignorant when they should be doing everything they can to give their users the education they obviously need.

As for websites that break without javascript, this i just an excuse for lazy programming. Such sites should break, and Mozilla should loudly send any users complaining back to the websites that wrote broken, incomplete pages. This is yet another example where appeasement only hurts you in the long run.

http://www.sitepoint.com/javascript-dependency-backlash-myth...

(there is a difference between reduced functionality (which is perfectly acceptable) and totally breaking)

// here come the down-votes; saying anything bad about javascript is easily one of the faster ways to draw down vote - probably because far too many HN reader's paycheck rely on the user not being able to disable javascript

// don't bother replying if you just want to assert that javascript is necessary, because i have multiple existence proofs to the contrary. This does require finding alternatives for a handful of broken sites. Such is the cost of safety.

Treat users like ignorant entitled idiots, and they'll just continue to act like ignorant entitled idiots. Meanwhile everyone else who does know what those settings are for suffers, and it decreases the chances of future users ever learning they could do that.

If users aren't putting in the effort to read warnings/error messages, or can't put two and two together and correlate why things aren't working on some sites with what they did with the settings (or even better, apply some more critical thinking and possibly Googling to figure out why), I think that's a sign of a deeper problem and trying to patch over it by dumbing down software interfaces is a horrible direction to take.

To become knowledgeable users of Web technologies and not mere consumers, they must be allowed to explore, experiment, and break, then fix things. Taking away these settings discourages that. "The only real mistake is the one from which we learn nothing."

FYI Alex Limi no longer works at Mozilla.

Virtually no one outside the tech world thinks twice about javascript. They have other things to think about. They're still users of the product, and they will never start tweaking it, because their lives are already full of other things.
And thus they should not tweak things they don't understand.

If you don't know what javascript is, don't disable it and complain things aren't working...

Good read, thanks for linking. Some points I'd never considered.
TL;DR: fck power users.

Well, fair game, given that those power users can switch browsers in the blink of an eye (). All my hopes go to the Vivaldi browser now.

The only problem is that these power users promote your browser and installed it on grandma's computer, and who make your precious extensions on occasion, often for free. Don't be surprised if you need partnerships now.

(*) Well, thinking about it normal users can also switch browsers in the blink of an eye, too. All it takes is Flashplayer update that sneakily install Chrome as the default browser. Just sayin'.

Standard things you would expect from a browser, like a way to easily disabling javascript

That is very far from being an expectation of the average user.

Disabling javascript is fairly easy on a page by page basis, right click on the page, inspect element to bring up the console, click on the settings cog, scroll down, disable javascript tickbox.
Could we avoid associating pot smoking with poor decisions? There's no science backing that up. ;)
The "Mozilla Manifesto and Pocket" email thread in the Firefox Dev mailing list gives some insight from the developers. [1]

To paraphrase: it seems they wanted a reading list feature but found it pointless to re-implement an existing solution with many desired features. (Work which was started but appears to have been scrapped.) This rationalized piggy-backing on Pocket. It gives Firefox a reading list for its users without Mozilla having to maintain it.

My personal problem with this has more to do with the anti-competitive nature of integrating services rather than Pocket's closed source.

[1] https://groups.google.com/forum/#!topic/firefox-dev/B3jJq_kU...

It would have been cool to have an API for plugins to hook in their "save this url" logic and UI callbacks. That way Mozilla control the core experience and any plugin can implement it like an interface. They could even ship with Pocket installed by default, just as a plugin implementing the same interfaces everyone else can.

I guess the "list URLs" side of things might be an awkward abstraction, although it'd let you merge multiple services which could be cool too. I use IFTTT to move starred pocket items to Evernote, so that'd be one possible use case if Evernote also implemented it.

It somewhat makes sense. If they want it that badly, though, maybe Mozilla should buy Pocket so that they can put it under the aegis of their license/philosophical charter. "Reading List" is currently right up there with "Web Browser" and "Email Client" as major programs that I would like to be neutrally owned by a public foundation.
I think you are confusing cause and effect. Pocket was not added to Firefox because Firefox users demanded a sophisticated offline reader. If that were all there is to it, Pocket would be an addon.

Pocket was added to Firefox because Mozilla wants the extra revenue from partnering with Pocket.

Pocket is not paying Mozilla, as said already.

Also, anyone implementing a compatible backend can switch to it by changing a pref.

Can we get a public statement from Mozilla describing its deal with Pocket?

I see a comment below from a Mozilla employee stating that "there is limited public information available about this deal", and claiming that the best quote is in an article that contains a paraphrase from an email from another Mozilla employee saying that Pocket didn't pay for placement.

When a non-profit gives prominent placement to a for-profit company, there are many ways for money to change hands beyond straight up payment for placement. I think we are owed a clear explanation of the Mozilla-Pocket deal.

> Can we get a public statement from Mozilla describing its deal with Pocket?

I've been pleading internally for an official public response. Nothing.

The only other source I've seen is an email reply from Mark Mayo at http://www.planet-libre.org/?post_id=18514

I for one don't use Pocket because they have a very poor privacy policy. For me the integration of a 3rd-part service like Pocket goes against everything Firefox says it stands for: free, open, and private internet.

I was enjoying the Firefox reading-list feature because it allowed me to save webpages and sync across my devices without having to put all that information into a proprietary 3rd party service. I thought the reading-list was one of the best features added to Firefox for years, and now they have scraped it. I really can't understand how Mozzilla executives came to the conclusion that this was a good idea.

Was money on the table to integrate Pocket into Firefox? Like with the default search engine payments Mozilla receives.
Almost certainly.
Mozilla employee here: That is incorrect. There is limited public information available about this deal, but the best quote so far is in this article: http://www.pcworld.com/article/2930532/reading-service-pocke...
This makes even less sense... I also assumed the Pocket integration was a paid placement, in which case I was fine having to spend the time removing the button and disabling it in about:config, since I saw it as a cost of actively developed free software (same with having to change my default search engine away from Yahoo all the time).

Integrating a third party API for free when plenty of browser-centric features are left as extensions makes me really question Firefox's goals.

How is elevating an arbitrary third-party service from an extension into native browser code "promoting openness, innovation & opportunity on the Web"?

I also assumed the Pocket integration was a paid placement, in which case I was fine having to spend the time removing the button and disabling it in about:config, since I saw it as a cost of actively developed free software

Apologies for being slightly off-topic, but I'd argue this would be questionable even if it were an openly announced partnership like with Yahoo. Yes, Mozilla is free software and is doing some enormous contributions to the open web. Which is why we should support them with donations and code contributions. (And I'd also fully endorse usage of paid services from them should they develop any).

However, what they are doing now is basically selling their good reputation and their wide user base to force some features on their users that they don't need in return of (presumably) payment. That strikes me as deeply unethical.

But installing stuff users don't want is working so well for SourceForge why would Mozilla not want to follow such a great lead /s.
Quote from the article: "There's no monetary benefit to Mozilla from the integration: Pocket didn't pay for placement in the browser."
Maybe not monetary incentive, but perhaps this was a condition to get Pocket to integrate with Firefox Accounts?
Mozilla wanted users to be able to use Pocket without needing to create an additional account.
It also encourages users to create a Firefox account to use Pocket.

I suspect a lot of people are wary of "signing in" to browsers.....

Hello is just a thin wrapper around WebRTC. That's why Chrome can receive Hello calls without an extension. There's barely anything to add on in that case.
Not many resources perhaps, but a lot of additional UI surface, which clutters up the menus with irrelevant options.
Click on the hamburger. Click on "Customize". Drag the "Hello" icon off of the tool bar. It is now removed from the UI.
I wouldn't say a lot, it's just one button.

Is there a cost to adding even a button? Yes. But that has to be weighed against the benefit. And a significant amount of users benefit from having the button.

"Just one button" led to Netscape 6 and subsequently Firefox in the first place. It's easy to miss the significant amount of user benefit from not having that one button, since it's a smaller amount of benefit per person across a lager number of users.
That's a fair point and I agree, there is benefit to not having more buttons on the UI. It's hard to know what the right tradeoff is, between the benefits of adding buttons and not adding them. There are good reasons to prefer both more and less.

In this case, data on user behavior indicated that it was worth adding the buttons. It's still possible that the data is imperfect somehow and a more optimal tradeoff could have been chosen. Still, I think there is good reason to believe the current data and decisions make sense.

The problem isn't the size, the problem is that it adds features which are outside the scope of 'a Browser'.
WebRTC is now a web standard and ships in multiple browsers. If you consider such technology to be outside the scope of a browser, then you're going to need to convince a whole lot of people.
The complaint is not about WebRTC, but about Hello.

The comments in this thread are going in loops.

  "Hello shouldn't be bundled with a browser."
    "But it is just a small wrapper around WebRTC."
     "Yeah, but it's out of scope for the browser."
       "WebRTC is a web-standard"
Mozilla's mission is to promote openness, innovation & opportunity on the Web. There's nothing specific about browsers in the mission, though it is used to help further the mission.

If you take that into context when you look at Hello, you can see why the organization might want to leverage the Firefox user base to introduce something with negligible overhead (Hello) that would help to advance that mission.

They bundele it because they get payed for it. Same story with the new suggested site advertising. The alarming thing is that this way Mozilla is loosing it's independency.
As repeatedly said elsewhere in this thread, Pocket is not paying Mozilla for this integration.
This is Mozilla gaining independency. When they were completely reliant on Google they had no independency.
Is there a practical difference between disabling the features and just ignoring them?
Memory and CPU utilization for starters
Firefox makes extensive use of lazy initialization for a lot of its code. You typically don't pay the price for those features unless you actually use them.
A button that does an API call consumes very less resources until clicked.
that hits home. because there was a malware that distributed itself as a mozilla add-on. even sent in patches because it affected a bank i used.
I always get devoted when I support chrome on here but I think history will prove me right.