Asa Dotzler: Firefox and more

This is pretty effective when it's Firefox that is the target.

But what about when it's a plug-in like flash? The Mozilla team would take leaps and bounds in terms of securing their users if they could convince companies like adobe, to at least allow automatic notification of a new plug-in, or have an update system like the extension system.

With everyone running black-box plugins like flash, it doesn't matter if there's 1 billion IE users or 100. The attackers just go for the plugin instead.

But checking for updates if the user isn't running Firefox isn't useful, since you can't be exploited via an app you have installed but never run. It just means you end up using resources and possibly annoying users who don't need those updates. Feels like Apple, really ;)

As for increasing check frequency - it still takes some time for each point-release. (Would two point releases get out within 24 hours?)

Do you have any statistics on how many people are updating? That should give a pretty accurate indication of how many Firefox users there are.

It's always nice to pat oneself on the shoulder, but for me the biggest problem is not directly the security of Firefox itself, but more the (in)security of its extensions that are circulating.

The number of browsers out there has gotten to be so huge that you don't need to exploit a large percentage of them to do real damage.

An interesting corollary to that thought: I wonder if sheer numbers will encourage the bad guys to start paying more attention to less well-known browsers.

>But what about when it's a plug-in like flash? The Mozilla team would take leaps and bounds in terms of securing their users if they could convince companies like adobe, to at least allow automatic notification of a new plug-in, or have an update system like the extension system.

fyi, the flash player does have a push update mechanism. More info here:

http://kb.adobe.com/selfservice/viewContent.do?externalId=16701594

mike chambers

mesh@adobe.com

What would be great is to handle the few percent users which are not admin and can't update by themselves (https://bugzilla.mozilla.org/show_bug.cgi?id=374900)
Unfortunately, nobody is working on this.
For example, I have to go to my parent's pc from time to time, close apps, delog and relog as admin, update firefox,....
time to deploy in this case is not very good...
solution in my opinion is to handle update via a service running with admin rights. browser process should not need to run with admin privilege...

Like Mook said, people don't want another random "updater" app running in the background. The people that know about them in the first place, that is. Keep it optional at a minimum.

Ahh yes Mike, I have occasionally seen that, thanks for pointing it out.

Jilles, certainly they know how many people download from their own servers, but still I wouldn't consider that (in isolation) anywhere close to accurate, for the usual reasons: some people have more than one computer, most corporate users run on restricted accounts (and software updates are rolled in batches by sysadmins), almost every single Linux user today installs and updates exclusively through their distro's packaging and update system...

@Damian, I've been a vocal advocate of more sophisticated update systems for all internet connected apps, especially browesers, for years. There's just not much leverage that Mozilla has here -- especially with vendors who have some form up update system already in place. What we can do, however, is something called blocklisting.

If flash becomes vulnerable to a critical security exploit, Firefox has the capability to disable that particular version of Flash and can do so for most users in about a day's time (I believe -- I need to look into this feature more.) Working with Adobe to do that is always an option. But, as I'm sure you can imagine, Firefox disabling a plugin has other consequences so we'd have to be careful about how we used it and how we communicated its use to users.

Even more important, and something Mozilla can do something about, is that Flash stop having a monopoly as the Web's video player and vector graphics engine. When a single point of failure like Flash stretches across every machine, you've got the same kinds of problems you had with the IE monoculture that reigned for half a decade before FIrefox came along to change things.

There needs to be more choice there and one answer to that is to move video out of the plugin and into the browser with the <video&ft; tag back-ended by code that varies from browser to browser and operating system to operating system and for browsers to all get serious about native SVG support. These "Open Web" technologies will be a mix of open source and blackbox and will hopefully decrease the need for everyone to have installed a single vendor solution and a single point of failure like Flash.

The more competition and choice, the less likely that you can have catastrophic failures. Firefox, Apple, and Opera are all on board with native video support and are all working on improving their SVG implementations. Let's see if IE does the same.

@ant, actually, I don't think that's true. Browser exploits are still the more common exploit. browsers are more complex pieces of software than the flash or other popular blackbox plugins and that makes the liklihood of the existence of flaws somewhat greater. I do think that's changing some as the plugins are getting a lot more attention from the security researchers and the bad guys.

That being said, even if your assessment is true, we can change that by bringing competition to that space. See my response to Damian above.

@Mook, Firefox doesn't check for an update until its running. Then it waits for the user to restart. If Firefox had a background daemon of some sort, making checks even when Firefox wasn't running, it could find and fix bugs before Firefox was even launched. It absolutely could cut down on the time to deploy a security patch. Whether it's worth the other trade-offs is up for debate.

Nowhere did I suggest that this checking would happen if Firefox wasn't installed. If "but if the user never intended to use Firefox ever again" is your argument, then why not make the security check offer to either update or uninstall the vulnerable version of Firefox.

Jilles, yes, actually that's how we get our user number. In any given day, about 60 million people perform an update check. Over the course or a month, we estimate three times that many connect to the web using Firefox. That's how we arrive at 160-180 million (depending on where that starting number is -- it was at 59.6M last time I looked about a week ago. You can see how we calculate this (though the actual data is quite old now) at John's blog.

Kelson, sure. It's happened to Firefox, but it wasn't until the numbers were pretty high. Think about the bad guys as belonging to a multi-billion dollar a year industry (because they are) and then you start to see why they want to operate efficiently -- one part of that being going after the largest number of users possible. Firefox, now that it's approaching 200 million users, is a prime target -- and probably has been for a couple of years.

But, as I said, I don't think it's going to be so much as targeting in terms of trying to find the exploit. The browser vendors themselves disclose eploits when they fix them. The bad guys can use a process like the one I linked and craft and deploy an exploit within just hours of the update being available. Some will for sure appreciate being able to run their exploit under the radar for as long as possible, but for most, I think, why put in all the effort to actually finding the exploit when you can get sufficient return while devoting your time to making the attack itself more potent.

So, it's large chunks of users using homogeneous setups that's the real problem here and that's why competition and variety in software is so important and why competition and choice are a fundamental component of Mozilla's mission. It's the monoculture, and especially the large-scale monopoly driven monoculture that produce the worst security outcomes for users as much or more than it's the actual integrity of the code. (that last part is wholly my opinion.)

matp75, yeah. that certainly would help. I don't have any data to back it up, but I bet that's a niche case and that we'd get more gains (more protected users faster) by improving the time to deploy for the more common cases. But yes, fixing the edge cases is important too.

- A

@Mook and @anon, well, since Windows Update doesn't offer third party integration (a shame,) then there's not really much choice here. Either the apps only check when they run, and so give the bad guys a much bigger target, or each app implements its own update daemon.

I would add, though, that just because other background updaters suck (and boy do they suck) doesn't mean that Firefox would implement a POS. I'd bet that it could be done in a really friendly way. Just compare Firefox's update system with all the other updates out there and you can see that we're very, very considerate of the user. We make a very small ping and if there's an update available, we grab it in tiny chunks only during times when there isn't other network activity, etc. That same care could be put into an always on updater, I bet.

-A

@Daniel Luz, we have much better numbers than raw downloads. We've done modeling of the entire adoption and retention funnel against a representative sample of Firefox users and we've got pretty strong data on daily update checks so we can measure our active daily user number with some decent precision.

- A