> A good outcome of this certificate fiasco is that many firefox users learned about the "studies" and "Normandy" brain-damage and promptly disabled them.
I'm actually curious about how the common user reacted to this. There isn't a clue about this on (1) the add-on page, (2) Mozilla's home page, (3) no emails sent out (I get plenty of other emails from Mozilla).
Currently, when you try and (re)install an "unsupported" add-on, you get a cryptic message stating: "Download failed. Please check your connection."
So the only communication from Mozilla is that it's my fault and I need to "check" my connection.
Honestly... there's so much fail here - even at the communication level.
>I'm actually curious about how the common user reacted to this. There isn't a clue about this on (1) the add-on page, (2) Mozilla's home page, (3) no emails sent out (I get plenty of other emails from Mozilla).
That's a good question. Of course we have to assume we're talking about the common add-on user, since some users don't have addons.
An incredible 3.2 million users (out of 10 million daily active) attempted to download Adblock Plus on Saturday, after it was disabled. Some of these might be duplicates of course, but I think this suggests:
(1) most users who use addons noticed when they were disabled
(2) most of them were confused (at least initially) about the reason this happened, since there was no direct communication from Mozilla about the problem in the browser itself
(3) many of these attempted to redownload their extensions as a solution to the problem
It's just the usual tug of war between developers and users for control of the computer.
A completely careful open source project would normally leave such controversial things off by default, and moz which leans corporate will go part of the way towards enabling such features. I don't mind their compromise, they do good.
Because functionality like that can be used to enable/disable features outside of tests as well. For example gating new things which could become a stability issue. Sometimes it's a choice between control or no control. Sometimes it's between your browser crashing or not. The power users will care about control, but the general population of users not really.
> For example gating new things which could become a stability issue.
And yet we were somehow able to ship stable software to millions of people in the days before telemetry/studies. What telemetry/studies truly provides is offloading QA costs to users.
Sure we were. I have video games that were pressed to CDs with no possibility of updates and they still run to this day. On a complete play through of many of them you wouldn't notice a single bug.
Using users for QA has made us lazy and borderline incompetent.
I think you're thinking of extreme cases here like games which are released with bugs these days for holiday rush, because the patching is easy / built-in. That's not the case for everything and not the case for Firefox.
And the stable software in the past may be due to nostalgia. They had bugs. Even before dialup was common, games were patched: Diablo 1 had a number of patches for example, Quake 3 went up to 1.32, Dune 2 (1992) got 1.07. We just accepted bugs, because... what can you do?
Yes, running experiments on unknowning and unconsenting users is unethical, especially when the metrics being optimized for usually aren't in the users' best interests. The widespread acceptance for this behaviour could definitely be classified as brain damage.
> the metrics being optimized for usually aren't in the users' best interests
Do you have any source for that? If you truly believe that Firefox is optimizing metrics that aren't in the users' best interest in general, why are you even using said software in the first place?
>What other browser can you use if you are interested in some sort of privacy?
Waterfox, Safari. Some others too but they're a pain to use (ungoogled-chromium for example). Chrome itself has a bunch of binary blobs so I would stay away from that.
I think this can be compared to McDonald's slightly altering the recipe of something for part of the country. I don't find that unethical at all, and frankly the things we put in our body are a lot more personal than which web browser we use.
That is dismissive of how much value people place on their selves and digital aspects thereof. My identity, private conversations, and sexuality are infinitely more personal than the food I consume.
I agree that it’s appropriate to A/B test changes, within reasonable bounds. I wish the debate would focus more on what the reasonable bounds are to each objector.
Yes, but it isn't (well should not be if they want to stay within the law) adding completely random drugs an garbage to the food. It may be seeking cheaper recipes with no sales losses, better recipes to improve sales, or something else, but it all has to be within the context of proper regulation, i.e.,, FDA. (we can argue elsewhere about the effectiveness of that system).
This unlimited testing can easily be seeking to better maximize psychological exploits with no regulation.
So, yes, I'm happy to see someone putting in a bit of control.
> especially when the metrics being optimized for usually aren't in the users' best interests
I don't think so. Mozilla is not google, and apart from the mr. Robot error, that they apologized for, I am sure Mozilla is using it for making the browser better, and not to use you for targeted ads like the other browser maker does.
Google Chrome uses the RLZ tracking identifier for some installations.
"RLZ gives us the ability to accurately measure the success of marketing promotions and distribution partnerships in order to meet our contractual and financial obligations."
Yes. The testing should be done on users that opt in (likely less than 0.1% but that should be OK if it's done properly) and it should be rolled out by releasing an update to everyone.
By relying on opt-in you won't test whether a feature actually works for the average user, so if you don't test it, you might roll something useless/confusing/actively harmful out to all of them instead of just a few.
Exactly. The recent Windows 10 update fiascos demonstrate this perfectly: they are opt-in (Insider program) and there were too few users experiencing the bugs to overcome the noise of those who weren't. You need a truly random sample.
So instead of having enough voluntary or paid testers to detect catastrophic, file deleting bugs in a new version, your solution is to just roll out the new changes to random users expecting a stable system?
Something went terrible wrong somewhere, that we got to this.
I think they updated too many parts of Windows at once, not too many computers at once. And I'm not certain that a delayed rollout would have fixed it. Is it fair that a random sampling of people are given the problem?
And that's OK. Being honest to your users is much more important that having the most efficient deploy system.
I, for one, as a matter of principle, opt-in to all user tracking systems that are disabled by default, and try to opt-out whenever they are enabled by default. In the case of firefox, it was never clear to me that the tracking/remote install capability was enabled by default.
It isn't A/B testing that is bad, it is running and/or modifying stuff in the user's computer without their knowledge that is bad. If a site modifies some part of their layout or whatever isn't bad, but a browser installing addons or changing settings to see if it will crash is bad.
that's what the stable/experimental channels are for - a user who don't want to be tested on (such as a business user) can easily be sure that they are getting a stable release and their settings won't update under them.
Experimental/beta channels can have these changes pushed to it, since that's implied by the name, and those people who like living on the edge of new features do so knowingly.
Let the users control their destiny, let the users decide when. That's the hallmark of a trustworthy company.
Users who intentionally run beta / nightly are not normal users. How many of them run on cheap "desktop" computers they bought on sale at Target, do you think?
Wait, so running and modifying stuff on all users' computers is good, but a random sample isn't? That's what A/B testing deals with.
The discussion isn't "modify stuff" vs. "don't modify stuff". The discussion is "some users" vs. "all users".
And obviously if you have an auto-update mechanism you're modifying stuff on the user's computer. Chrome updates are near invisible on modern machines. That's a good thing. It keeps the browser evergreen and protects users. If everything were opt-in because "Google shouldn't modify stuff on my computer" that would be an absolute disaster for everyone. No way.
This is a technicality, users do not care about technicalities, they have their own expectations and if you are on -say- a stable branch with autoupdates enabled your expectation is that you'll get the latest version that everyone else is using.
A/B testing through that branch breaks that expectation (and no, mentioning it somewhere hidden in some EULA or equally obfuscated place does not mean people will not have the expectation - hell, even mentioning it right below the download wont make a difference).
Having a backdoor on by default while you’re pretending to be ‘the good guy’ is brain damage. It’s taking an age to build trust and then throwing it away in a second.
It certainly is not brain-damage, but it is however very user-hostile.
Are you the unlucky one that ended up with the broken A/B testing change? Well, sucks for you and nobody will be able to help you. Do you want to try a specific testing change because you like it/something is broken on your end and that will fix it? Sucks to be you again, you get no choice on this. Do you want to analyze the change to see if they have something bad in it? Nope, not possible unless if you end up being one of the lucky ones. In addition if Mozilla were to get compromised (either as an organization or in software side) could use it as a backdoor on unsuspecting users or even do targeted attacks.
None of that would not be an issue if they depended on nightly/beta for changes and error detection, nor would it be if they had a list of possible tests somewhere that the user could manually enable and possibly ask some users explicitly if they want to enable one on the browser startup.
I enabled it for the bugfix and it made some additional changes to the config that weren't related to the bug fix and not mentioned on about:studies. Changed the behavior of the browser.
HN has strong open-source and free-software constituencies. Many of those people feel strongly about Mozilla and Firefox. There's no need to assume bad faith (also in the site guidelines!)
If you see unfairly downvoted comments, give them a corrective upvote. That corrects most cases. If the problem persists, emailing us at hn@ycombinator.com so we can take a look, and possibly intervene, would be a helpful thing to do.
Calling people shills without proof is not an honest argument. Sometimes people just have different views. I downvote those comments because they're unsubstantiated and needlessly pessimistic. Mozilla is still one of the better organizations out there.
As author of the original "pessimistic" comment, I want to say that I agree 100% with you. Mozilla is indeed the most important free software project today. Thus, I am very sad and pessimistic when they exhibit subpar behavior such as this.
Given the HN guidelines on this, I’ll lay off on the specific type of comment I made. (Although it’s quite a normal thing to notice and point out in other communities).
However, precisely because of the importance projects like Mozilla and browser technology in general, I think it is perfectly reasonable to expect the highest standard of behavior. I personally have concerns about certain aspects of their activities (not related to downvoting) in recent years and am well within my rights to express them.
