I, too, don't care for it, but I'm not going to pretend that the inclusion of a new button that doesn't do anything if you don't use it is like injecting malware into my browser.
The Firefox design team conducted user research experiments, and found that a significant amount of people like the feature (far more than dislike it). Most of those users are not techies, and would never even hear about an addon, so including it in the browser is the most realistic way to reach them.
Firefox is, has always been, and always will be, open source. The Mozilla server side is similarly also open source. But Mozilla is quite small compared to Google and Microsoft, and so must partner with external parties for things like Search and Pocket.
There is no expectation of an integrated closed source "cloud reader" and attempts to paint this like "aww gee shucks it would be great it we could do something about this but thats just the way they world is" come off as extremely disingenious, especially as the mobile version of firefox had this feature baked in with no reliance on any third party at all.
"Online advertisements with active content aren't shady, almost all networks use them!"
Except for course, what you said it's identical are a notoriously shady group of activities, which has led to much abuse my market leaders at various times (Google, Microsoft), and we see no difference here. For that matter, neither do you.
I get that Firefox benefits from shipping the integration, but you haven't provided any good technical reasons for it not being fundamentally a shift in the way you do business and kind of exploitative.
Holding up a bunch of famous exploitations as "me too!"ing is tonedeafly missing the complaint.
So yes, the market is fundamentally shady for "browser integrations".
I do think, however, that to compete with other browsers, such integration is necessary. If Firefox doesn't integrate with search, users will not find it useful, because they are so used to using google.com and so forth.
So I agree browsers would be better with no such integrations. It's a necessary, sometimes painful compromise.
This is a particularly weak case, because what's really needed for this feature at the browser level is an API for search providers, backed by several plugins which take advantage of the feature and offer various providers.
However, that's not what Firefox did here, as far as anyone can tell. Why not? No technical reason has been provided, and the replies have been so completely off topic as to cause a long debate thread over that very reasonable concern.
Firefox tightly coupled a technology to their platform rather than providing a service API and plugins, and we have no understanding of why a group committed to openness would make such a fundamentally close source move.
Historically speaking, the reasons groups do that is malice.
This is precisely why I don't use Chrome! I like Google search but I don't like how Chrome keeps me logged into their services.
What are you asking for, exactly? That the browser should force you to login twice?
It's nowhere near my only problem with Chrome, but it's one of the big ones.
I want to be logged in in Chrome so that my bookmarks sync between devices. But I want to be logged out of my Google session so that my searches aren't tied to my Google account.
On Mobile Chrome, if you log into Chrome, you log into your Google account. There's no way to separate the two.
"this has absolutely nothing to do with money. We're shipping Pocket because we love their product, and so do our users. Pocket is, by very far, the most popular reading-list add-on used with Firefox."
Apparently they went too far: it's the most popular extension of that kind among people that care about reading lists (hardly the majority I think) and it's being hated by everybody that don't tolerate imposed choices. No good can come for Firefox and Pocket from this. If I were Pocket I'd ask Mozilla to unbundle the code into an extension as soon as possible because this is starting to be a PR backslash.
It's true that this seems perhaps a little silly to people like us. We might prefer this to be opt-in. But we are a rare type of user. Studies show the best decision here is to bundle it by default.
I believe that there are meanings of 'best' for which this is true, but they aren't, I think, necessarily the right ones. In this case, it seems like 'best' is "best for widespread adoption of Pocket".
OK, so let's buy that widespread adoption of Pocket is a good goal because more users like it than don't. I'm sure there are lots of add-ons with this property, but we don't add them all on—so what is so special about this one, beyond just that it tested well, and moreover what is so fundamental about it that it has to be integrated at the browser, rather than extension, level?
There's actually a tour of it if you do a fresh update on a release build, IIRC.
The Firefox design team needs to test these things out. If y'all don't like it stick to Iceweasel or some other fork. Just don't expect much innovation from the forks.
So what?
Consider this argument: 80% like a feature 20% don't. You implement it, now 20% of the people aren't happy. Next feature is also 80%/20%, now between 36-20% aren't happy. Keep doing this and you will alienate most of your user base.
Did anybody actually want this feature? What percentage was that?
I'm pretty sure that was Mozilla's experience until they switched to rapid release.
And why Pocket? Maybe some Firefox users use Instapaper, and they had no say in the choice of Pocket.
It starts as a useful product until the network-effects take over and raise the cost of leaving, de facto locking people in. After they are hooked, you introduce various types methods to make the product rely more on remote services instead so more data can be captured. As few people understand the difference between a product that runs locally and a service that necessarily gives your data over to a 3rd party, this usually works without anybody noticing and objecting.
If a few nerds object, they are usually countered with a few lies about why such a service is "necessary", even when it isn't. In this case, the lie is that a 3rd party service is necessary so you can share your bookma^H^H^H^H^H^Hreading list on different devices (which assumes you have multiple devices, and that you want to move bookmarks between them). In hard cases, it may require some vague, misleading, and hard-to-prove statistics ("our data says user's like $foo", "everybody uses $foo"), or simply browbeating anybody that complains ("Then submit your own patches", "stop being paranoid").
The worst part is that for many of the engineers involved, this is probably unintentional. The human mind has a very limited "working set" that is given full attention; everything else is filtered heavily with various shortcuts[3], heuristics, and assumptions, making it incredibly easy to be distracted by endless technical details.
TL;DR - watch [2] for a much better explanation
[1] aka "big data" and sometimes "analytics"
[2] https://projectbullrun.org/surveillance/2015/video-2015.html...
[3] most illusions and magic tricks are based on this - Apollo Robbin even bases his entire show on working just outside the focus-set of his audience ( https://www.youtube.com/watch?v=T0k2gja3ym4 https://www.youtube.com/watch?v=d54ydsKUNGw )
Either way, it's a shitty thing for Mozilla to do, just as it was a shitty thing for Google to sneak in code in Chromium that downloads and installs proprietary blobs after compilation and packaging.
The list of truly open web browsers keeps getting smaller.
> The list of truly open web browsers keeps getting smaller.
What are you talking about?
I'm talking about what the author of the article pointed out. Did you read the article?
"Non-free software-powered. You want to host your own instance? You can't. Also, you can't modify, translate, reverse engineer, decompile, disassemble, or create any derivative works based on the Pocket Technologies, including any of its files, tables or documentation, or any portion thereof, or determine or attempt to determine any source code, algorithms, methods or techniques embodied in the Pocket application or any portion thereof. Yes, this service is integrated in your favourite Open-source web browser."
What I mean is, it's not so much about open source (I used closed source technology every day), it's about the overall openness of the project. Mozilla has chosen to integrate a proprietary service in what is supposed to be an open browser, and that bothers me enough to not use their product anymore.
And if it's not already apparent, no, I won't be using Pocket either. :)
This is the actual license of the Pocket code in Firefox: https://dxr.mozilla.org/mozilla-central/source/browser/compo...
It's a fucking BSD license. With an added remark that they own trademarks on the name.
In other words, my decision isn't based on whether the API is open source. Mozilla chose a proprietary platform instead of an open platform; whether out of laziness or due to a kickback from Pocket, I simply don't like it. I like choice, and I choose to stop using Firefox.
Which quite obviously don't apply to Firefox in their entirety. The quoted section specifically doesn't apply, and I hope it's obvious to see why.
You can decide whatever you want, but given that you specifically quoted that section as the reason earlier, it's obviously not based on sane reasoning but on self-justification.
Mozilla chose to use a service provider that is not only proprietary, but (as the terms I quoted indicate) aggressively anti open-source/open standards. This, combined with the fact that we can't choose a different "read later" provider, makes me wary of using Firefox from here on out. As I indicated in another comment, I also don't care for search engine integration, but that's a battle that was lost a long time ago. At least with most browsers (including Firefox) the user can change the search provider to one she prefers; with the Pocket integration, it's Pocket period because it's hardcoded with their API only. I would have preferred Mozilla either bundle Pocket as an add-on, or if they are going to integrate a "read later" function, do it using an open (as in open to any provider) API and publish the specs so any provider can then offer their services.
I hope that clears up any confusion on your part.
Actually, it's got very less footprint until you click it.