Hacker News new | past | comments | ask | show | jobs | submit login

I've been through all of Firefox `about:config` a few times in the past, fixing preferences to, e.g., try to disable umpteen different services that leak info or create potential vulnerabilities gratuitously, but this is the first I recall hearing of Normandy.

Apparently I missed `app.normandy.enabled`, because I think I would've remembered a name with connotations of a bloody massive surprise attack.

Incidentally, `app.normandy.enabled` defaults to `true` in the `firefox-esr` Debian Stable package. Which seems wrong for an ESR.

For personal use (not development), I run 3 browsers (for features/configurations and an extra bit of compartmentalization): Tor Browser for most things, Firefox ESR with privacy tweaks for the small number of things that require login, and Chromium without much privacy tweaks for the rare occasion that a crucial site refuses to work with my TB or FF setup.

Today's crucial cert administration oops, plus learning of yet another very questionable remote capability/vector, plus the questionable preferences-changing being enabled even for ESR... is making me even less comfortable with the Web browser standards "big moat" barrier to entry situation.

I know Mozilla has some very forthright people, but I'd really like to see a conspicuous and pervasive focus on privacy&security, throughout the organization, which, at this point, would shake up a lot of things. Then, with the high ground established unambiguously, I'd like to see actively reversing some of the past surveillance&brochure tendencies in some standards. And also see some more creative approaches to what a browser can be, despite a hostile and exploitive environment. Or maybe Brave turns out to be a better vehicle for that, but I still want to believe in Mozilla.




I too use Debian's Firefox ESR. I noticed the "Allow Firefox to install and run studies" option in Privacy & Security Preferences a long time ago. It was unchecked and greyed out (i.e., unclickable), and a label below it says "Data reporting is disabled for this build configuration", so I gave it no further thought. This morning I woke up and launched Firefox, noticed this headline, and then noticed my extensions were still running. I looked in about:config and lo and behold, app.normandy.enabled=default [true]. I'll be filing a bug with debian to disable this in the build configuration.

Edit: There are some questions about whether Normandy is really enabled in Debian Firefox ESR even if the about:config setting defaults to true. I've filed a bug report, and I'm sure once a Debian maintainer has a chance to look at it we'll find out the answer.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928433

Edit2: It should go without saying, but please do not spam this bug report with "me too" and its ilk.


I had mine disabled. So let's think about this for a second. If I disable a security hole that you can drive a semi-truck through, I remain foobar'd. If I run my "secure" firefox configuration, with the security hole enabled, then they un-foobar me first. Before anyone else. So I could effectively get rewarded, for always keeping a security hole open. But I didn't keep it open, so... yeah... they'll get around to me sometime.

?

>:-(

Grrr.

I'm just getting old and curmudgeonly maybe? I've decided though, I'm starting an animated security blog to show people the ludicrousness of all this kind of stuff in plain language. I'll be Statler, and I just need someone to be Waldorf. Because this stuff really is getting Statler and Waldorf level ridiculous.


> I'm just getting old and curmudgeonly maybe?

You're not. You just have standards.

We need people with standards in this industry, because that's the only source we have of market signals that prevent the market from going full user-hostile.


>If I disable a security hole that you can drive a semi-truck through, I remain foobar'd. If I run my "secure" firefox configuration, with the security hole enabled, then they un-foobar me first. Before anyone else. So I could effectively get rewarded, for always keeping a security hole open. But I didn't keep it open, so... yeah... they'll get around to me sometime.

That's needless drama. They will be rolling out the fix in a point release. Whatever way you use to update your browser will install that and get the fix. So the worst case is just going back to the old days where you'd have the issue until your distro issued a new package or you manually updated the browser version on Windows or OSX. What exactly would you expect that's not exactly what's happening?


> So I could effectively get rewarded, for always keeping a security hole open.

That's the way it always works, isn't it? Security and convenience are opposing concerns.


Good security designs increase convenience (eg ssh, touch id, single sign on).

The three goals of computer security are integrity, confidentiality and availability.

All three of those expand the usefulness of the system to the end user.


But the point here is not about integrity, confidentiality, or availability. It is about whether you trust Mozilla, and how much trustworthy they are.

A configuration where Mozilla cannot push remote updates is neither more secure nor less secure. Mozilla is often under fire for not allowing a privacy conscious, minimal trust use case.


Automatic updates aren't a security hole. They are a security enhancement


Unless the entity that pushes the updates become malicious, then they're a security hole.


How do you audit Firefox updates? Because if the answer is “I don’t”, Mozilla already controls the most important piece of userspace code on your computer. And if the answer is “I don’t install them”, then everyone with a few grand to spare already controls the most important piece of userspace code on your computer.


I rely on the Debian system to assist with that. Normandy bypasses that system, if it's enabled. (The jury is out whether it's actually enabled in Debian Firefox ESR.)


What do you think the median size of a Firefox release is, what do you think the resources (let’s call it US dollars FMV) are to audit that, and what do you think the resources Debian has to devote to it?

Clearly more eyes are good, but... In between “Wild West WebExtensions” and “Mozilla backdoors my Firefox and it gets used for nefarious purposes” and “delays in browser updates increase exploitation windows”, I know which threat models I’m buying.


I agree an unpatched vuneribility is probably more risky. However this feature can change settings the user explicitly sets. The bigger issue is it does not give me any indication the settings have been changed.


I audit software updates by looking at developers announcements and community discussions (in social media, forums etc) before installing updates.

Then, even if developers keys and computers are compromised, I would notice something is wrong.

* No, of course that I don't always do that. I even don't often do that. But I did do that in the past, and I'd like to have the option to do that.



Yes, that's right, if you install software that had a bug, then if you give someone permission to modify your software, you can get a bug fixes faster.


There are already channels for bug fixes, and some of the friction on those channels is intentional, such as for visibility and oversight/approval.


Exactly.

Why even have an official channel, providing visibility and official oversight, if when it comes down to it, you're just gonna push remote code updates through the same side channel a potential hacker would use?

People are saying it's for convenience. OK, but then they have to understand that doing things in that fashion is a really bad look. And now your users are set up to believe that, at least some of the updates coming from the side channel are "trust"-able.


This is a piece of code downloaded from Mozilla servers to re-enable extensions, which are other pieces of code you download from Mozilla servers. If your threat model includes not trusting Mozilla servers then you've presumably disabled browser extensions (or sideloaded them) and this issue is irrelevant to you. If you do use extensions and get updated versions from Mozilla I don't see any way in which this increases your attack surface.


> noticed my extensions were still running.

Reportedly, Firefox only checks the date once per day, so if it hasn’t yet checked for you today, this will be the result.

> I looked in about:config and lo and behold, app.normandy.enabled=default [true].

I would assume that the config setting only has any effect if the feature is available in the build. Which it isn’t in Debian.


that would be good news, how can I verify that the Normandy feature isn't available in the Debian build?

Has Mozilla provided instructions to manually fix the issue? if so where? (XORcat was helpful to provide a solution, but I refuse to apply it if it doesn't come from Mozilla itself...)


> how can I verify that the Normandy feature isn't available in the Debian build?

In the Debian bug about this issue¹ it says “Firefox from the Debian package has data reporting disabled so using studies is not possible.

1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928415


Thank you for reporting it. Debian's pro-user stance is one of the things I like about it... now tell me they've disabled Pocket too and I might just switch from Arch to Debian Sid.

FYI, I have learned from other user's comments and the Wiki page below that Studies and Normandy are different things. The former depends on the latter, but not vice versa. So it is possible that Debian disabled the studies program but did not disable the underlying Normandy tool. You might also want to look at whether firefox is affected in addition to firefox-esr.

https://wiki.mozilla.org/Firefox/Normandy/PreferenceRollout#...


On Windows I have the "Allow Firefox to install and run studies" option disabled and yet in about:config Normandy was still enabled. I haven't received the fix. Could be that Firefox simply hasn't checked for it, or it could be that there's more than that about:config setting that determine whether Normandy is run.

Weird.


Posting an update for posterity. It appears that even with app.normandy.enabled=default [true], as long as app.shield.optoutstudies.enabled=false, Normandy is disabled. app.shield.optoutstudies is the key controlled by the UI element "Allow Firefox to install and run studies".

I've closed the above bug report as it's not really a bug.


Can we get a clarification:

Unchecking "Allow Firefox to install and run studies" in the UI does not change "app.normandy.enabled" to "false".

Then, does unchecking "Allow Firefox to install and run studies" really disable Normandy, or not?


As explained on Normandy's wiki page, they are related but two different things:

> Preference rollout is meant for permanent changes that we are sure of. Shield is meant for testing variations and figuring out what, if anything, is the best thing to do.

https://wiki.mozilla.org/Firefox/Normandy/PreferenceRollout#...


Except as we have learned "preference rollout" is also "installing extensions". So this is much the same as studies, but studies was disgraced, so now this is studies 2.0, no option to disable this time around.

And if you look at the big normandy JSON, hey, it's all the same Pocket and heartbeat shit we've seen from studies.


That doesn't answer the question: does Normandy get disabled by the UI option or not?

One can guess based on the wiki page that the answer is "no", but that's just a guess.


"Explained" is perhaps too generous a word. I'm a software engineer and I found that page to be confusing. It seems to be written for internal Mozilla employees, not for the general public.


Okay I will try


Is there a CVE for this "normandy" backdoor?


ESR means extended support, not "never changes". As long as it is supported (and it is: the bug got fixed), it's appropriate for ESR.


As I said elsewhere: There are already channels for bug fixes, and some of the friction on those channels is intentional, such as for visibility and oversight/approval.


And this is another channel. How can you be sure this one has less friction than the others?




Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: