Language Selection

English French German Italian Portuguese Spanish

Mozilla: Firefox Startup Cache, Security of Passwords, and Servo

Filed under
Moz/FF
  • Improving Firefox Startup Time With The about:home Startup Cache

    We’re working on a thing to make Firefox start faster! It appears to work! Here’s a video showing off a before (left) and after (right):

    Improving Firefox Startup Time With The about:home Startup Cache

    For the past year or so, the Firefox Desktop Front-End Performance team has been concentrating on making improvements to browser startup performance.

    The launching of an application like Firefox is quite complex. Meticulous profiling of Firefox startup in various conditions has, thankfully, helped reveal a number of opportunities where we can make improvements. We’ve been evaluating and addressing these opportunities, and several have made it into the past few Firefox releases.

    This blog post is about one of those improvements that is currently in the later stages of development. I’m going to describe the improvement, and how we went about integrating it.

    In a default installation of Firefox, the first (and only) tab that loads is about:home.

  • A look at password security, Part II: Web Sites

    In part I, we took a look at the design of password authentication systems for old-school multiuser systems. While timesharing is mostly gone, most of us continue to use multiuser systems; we just call them Web sites. In this post, I’ll be covering some of the problems of Web authentication using passwords.

    As I discussed previously, the strength of passwords depends to a great extent on how fast the attacker can try candidate passwords. The nature of a Web application inherently limits the velocity at which you can try passwords quite a bit. Even ignoring limits on the rate which you can transmit stuff over the network, real systems — at least well managed ones — have all kinds of monitoring software which is designed to detect large numbers of login attempts, so just trying millions of candidate passwords is not very effective. This doesn’t mean that remote attacks aren’t possible: you can of course try to log in with some of the obvious passwords and hope you get lucky, and if you have a good idea of a candidate password, you can try that (see below), but this kind of attack is inherently somewhat limited.

    [...]

    Leaked passwords aren’t the only threat to password authentication on Web sites. The other big issue is what’s called phishing. In the basic phishing attack, the attacker sends you an e-mail inviting you to log into your account. Often this will be phrased in some scary way like telling you your account will be deleted if you don’t log in immediately. The e-mail will helpfully contain a link to use to log in, but of course this link will go not to the real site but to the attacker’s site, which will usually look just like the real site and may even have a similar domain name (e.g., mozi11a.com instead of mozilla.com). When the user clicks on the link and logs in, the attacker captures their username and password and can then log into the real site. Note that having users use good passwords totally doesn’t help here because the user gives the site their whole password.

    Preventing phishing has proven to be a really stubborn challenge because, well, people are not as suspicious as they should be and it’s actually fairly hard on casual examination to determine whether you are on the right site. Most modern browsers try to warn users if they are going to known phishing sites (Firefox uses the Google Safe Browsing service for this). In addition, if you use a password manager, then it shouldn’t automatically fill in your password on a phishing site because password managers key off of the domain name and just looking similar isn’t good enough. Of course, both of these defenses are imperfect: the lists of phishing sites can be incomplete and if users don’t use password managers or are willing to manually cut and paste their passwords, then phishing attacks are still possible

  • This Week In Servo 132

    In the past week, we merged 64 PRs in the Servo organization’s repositories.

    The latest nightly builds for common platforms are available at download.servo.org.

More in Tux Machines

Android Leftovers

GNUnet 0.13.2 released

This is a bugfix release for gnunet 0.13.1. It fixes some build issues and contains changes to the REST API implmementation (no change in the API itself) as well as OpenID Connect related fixes to re:claimID. Read more

What Does Mozilla Firing 25% of its Workforce Tells us About its Future

Mozilla has fired 250 employees which is 25% of its workforce. Why Mozilla did it and what lies ahead for Mozilla? Read more

HeliOS is a Tiny Embedded OS Designed for Arduino Boards

Mannie Peterson (aka FellFromTree) has developed an embedded operating system called HeliOS that’s designed specifically for 8-bit and 32-bit Arduino boards, and can easily be used from the Arduino IDE. HeliOS is said to have only 21 function calls and implements cooperative and event-driven multitasking, task notification/messaging, timers, and memory management. It’s a non-preemptive multitasking kernel so you won’t have to deal with mutexes. The developer explains how scheduling works with HeliOS: HeliOS uses a run-time balanced strategy which ensures tasks with shorter run-times are prioritized over tasks with longer run-times. This ensures all running tasks receive approximately equal total run-time without using context switching. The other multitasking option available in HeliOS is event driven multitasking, which uses the wait/notify and timer interfaces. Mixing cooperative and event driven tasks in HeliOS is not a problem. Read more