←back to thread

1318 points xvector | 7 comments | | HN request time: 0.205s | source | bottom
Show context
rmbryan ◴[] No.19825581[source]
Update: We have rolled out a partial fix for this issue. We generated a new intermediate certificate with the same name/key but an updated validity window and pushed it out to users via Normandy (this should be most users). Users who have Normandy on should see their add-ons start working over the next few hours. We are continuing to work on packaging up the new certificate for users who have Normandy disabled.
replies(20): >>19825596 #>>19825603 #>>19825612 #>>19825623 #>>19825631 #>>19825665 #>>19825705 #>>19825721 #>>19825744 #>>19825813 #>>19825905 #>>19825998 #>>19826421 #>>19826769 #>>19826772 #>>19826878 #>>19827050 #>>19829585 #>>19831941 #>>19840386 #
neilv ◴[] No.19825998[source]
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.

replies(6): >>19826214 #>>19826496 #>>19826548 #>>19827134 #>>19828158 #>>19840411 #
robolange ◴[] No.19826214[source]
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.

replies(6): >>19826340 #>>19826689 #>>19827160 #>>19830076 #>>19831023 #>>19831131 #
bilbo0s ◴[] No.19826340[source]
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.

replies(6): >>19826394 #>>19826427 #>>19826599 #>>19826656 #>>19826695 #>>19826715 #
shawnz ◴[] No.19826715[source]
Automatic updates aren't a security hole. They are a security enhancement
replies(1): >>19827090 #
1. neiman ◴[] No.19827090[source]
Unless the entity that pushes the updates become malicious, then they're a security hole.
replies(2): >>19827140 #>>19827994 #
2. lvh ◴[] No.19827140[source]
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.
replies(2): >>19827228 #>>19828248 #
3. robolange ◴[] No.19827228[source]
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.)
replies(1): >>19827424 #
4. lvh ◴[] No.19827424{3}[source]
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.

replies(1): >>19831081 #
5. neop1x ◴[] No.19827994[source]
exactly. Like here https://news.ycombinator.com/item?id=10624087 or here https://news.ycombinator.com/item?id=19482191 for example...
6. neiman ◴[] No.19828248[source]
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.

7. anfilt ◴[] No.19831081{4}[source]
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.