4 ms·

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 m

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.

fjsolwmv 8y ago
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.
- neilv 8y ago
  There are already channels for bug fixes, and some of the friction on those channels is intentional, such as for visibility and oversight/approval.
  - bilbo0s 8y ago
    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.
    - pedrocr 8y ago
      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.
TeMPOraL 8y ago
> 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.
taneq 8y ago
> 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.
- hedora 8y ago
  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.
  - afiori 8y ago
    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.
deleted 8y ago
[deleted]
pedrocr 8y ago
>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?
shawnz 8y ago
Automatic updates aren't a security hole. They are a security enhancement
- neiman 8y ago
  Unless the entity that pushes the updates become malicious, then they're a security hole.
  - lvh 8y ago
    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.
    - robolange 8y ago
      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.)
      - lvh 8y ago
        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.
        anfilt 8y ago
        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.

fjsolwmv 8y ago

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.

neilv 8y ago
There are already channels for bug fixes, and some of the friction on those channels is intentional, such as for visibility and oversight/approval.
- bilbo0s 8y ago
  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.
  - pedrocr 8y ago
    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.

TeMPOraL 8y ago

> 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.

taneq 8y ago

> 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.

hedora 8y ago
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.
- afiori 8y ago
  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.

deleted 8y ago

[deleted]

pedrocr 8y ago

>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?

shawnz 8y ago

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

neiman 8y ago
Unless the entity that pushes the updates become malicious, then they're a security hole.
- lvh 8y ago
  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.
  - robolange 8y ago
    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.)
    - lvh 8y ago
      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.
      - anfilt 8y ago
        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.