Mozilla Firefox

A few days ago I wrote about insufficient protection of locally saved passwords in Firefox. As some readers correctly noted however, somebody gaining physical access to your device isn’t the biggest risk out there. All the more reason to take a look ... [More] at how browser vendors protect your passwords when they upload them to the cloud. Both Chrome and Firefox provide a sync service that can upload not just all the stored passwords, but also your cookies and browsing history which are almost as sensitive. Is it a good idea to use that service? TL;DR: The answer is currently “no,” both services have weaknesses in their protection. Some of these weaknesses are worse than others however. Chrome Sync I’ll start with Chrome Sync first, where the answer is less surprising. After all, there are several signs that this service is built for convenience rather than privacy. For example, the passphrase meant to protect your data from Google’s eyes is optional. There is no setup step where it asks you “Hey, do you mind if we can peek into your data? Then choose a passphrase.” Instead, you have to become active on your own. Another sign is that Google lets you access your passwords via a web page. The idea is probably that you could open up that webpage on a computer that doesn’t belong to you, e.g. in an internet café. Is it a good idea? Hardly. Either way, what happens if you set a passphrase? That passphrase will be used to derive (among other things) an encryption key and your data will be encrypted with it. And the big question of course is: if somebody gets hold of your encrypted data on Google’s servers, is translating the passphrase into an encryption key slow enough to prevent somebody from guessing your passphrase? Turned out, Chrome is using PBKDF2-HMAC-SHA1 with 1003 iterations. To give you an idea of what that means, I’ll again use the numbers from this article as a reference: with that iterations count, a single Nvidia GTX 1080 graphics card could turn out 3.2 million PBKDF2-HMAC-SHA1 hashes per second. That’s 3.2 million password guesses tested per second. 1.5 billion passwords known from various website leaks? Less than 8 minutes. A 40 bits strong password that this article considers to be the average chosen by humans? That article probably overestimates humans’ capabilities for choosing good passwords, but on average within two days that password will be guessed as well. It’s actually worse than that. The salt that Chrome uses for key derivation here is a constant. It means that the same password will result in the same encryption key for any Chrome user. That in turn means that an attacker who got the data for a multitude of users could test a password guess against all accounts. So they would only spend four days and the data for any account using up to 40 bits strong password would be decrypted. Mind you, Google themselves has enough hardware to do the job within minutes if not seconds. I am talking about somebody not willing to invest more than $1000 into hardware. I reported this as issue 820976, stay tuned. Site-note: Style points to Chrome for creative waste of CPU time. The function in question manages to run PBKDF2 four times where one run would have been sufficient. First run derives the salt from host name and username (both happen to be constants in case of Chrome Sync). This is pretty pointless: a salt doesn’t have to be a secret, it merely needs to be unique. So concatenating the values or running SHA-256 on them would do just as well. The next three runs derive three different keys from identical input, using different iteration counts. A single PBKDF2 call producing the data for all three keys clearly would have been a better idea. Firefox Sync Firefox Sync relies on the well-documented Firefox Accounts protocol to establish encryption keys. While all the various parameters and operations performed there can be quite confusing, it appears to be a well-designed approach. If somebody gets hold of the data stored on the server they will have to deal with password derivation based on scrypt. Speeding up scrypt with specialized hardware is a whole lot harder than PBKDF2, already because each scrypt call requires 64 MB of memory given the parameters used by Mozilla. There is an important weakness here nevertheless: scrypt runs on the Firefox Accounts server, not on the client side. On the client side this protocol uses PBKDF2-HMAC-SHA256 with merely 1000 iterations. And while the resulting password hash isn’t stored on the server, if somebody can read it out when it is being transmitted to the server they will be able to guess the corresponding password comparably easily. Here, a single Nvidia GTX 1080 graphics card could validate 1.2 million guesses per second. While the effort would have to be repeated for each user account, testing 1.5 billion known passwords would be done within twenty minutes. And a 40 bits strong password would fall within five days on average. Depending on what’s in the account, spending this time (or adding more hardware) might be worth it. The remarkable part of this story: Mozilla paid a security audit of Firefox Accounts, and that audit pointed out the client-side key derivation as a key weakness. So Mozilla has been aware of this issue for at least 18 months, and 8 months ago they even published this information. What happened? Nothing so far, the issue didn’t receive the necessary priority it seems. This might have been partly due to the auditor misjudging the risk: Further, this attack assumes a very strong malicious adversary who is capable of bypassing TLS Sure, somebody getting a valid certificate for api.accounts.firefox.com and rerouting traffic destined for api.accounts.firefox.com to their own server would be one possible way to exploit this issue. It’s more likely however that the integrity of the real api.accounts.firefox.com server is compromised. Even if the server isn’t hacked, there is always a chance that a Mozilla or Amazon (it is hosted on AWS) employee decides to take a look at somebody’s data. Or what if the U.S. authorities knock at Mozilla’s door? I originally reported this as bug 1444866. It has now been marked as a duplicate of bug 1320222 – I couldn’t find it because it was marked as security sensitive despite not containing any information that wasn’t public already. [Less]

One of Mozilla’s biggest strengths is the people — a global community of engineers, designers, educators, lawyers, scientists, researchers, artists, activists and every day users brought together with the common goal of making the internet healthier. ... [More] A big part of Mozilla Foundation’s focus over the past few years has been increasing both the size and diversity of this community and the broader moveme. In particular, we’ve run a series of initiatives — the Internet Health Report, MozFest, our fellowships and awards — aimed at connecting and supporting people who want to take a leadership role in this community. Our global community is the lynchpin in our strategy to grow a global movement to create a healthier digital world. Over the next couple of months, we are looking for a new VP, Leadership Programs (click for job spec) to drive this aspect of Mozilla Foundation’s work. This role was formerly held by Chris Lawrence, who built an incredible team and foundational set of programs. Chris left Mozilla last November. We are seeking someone to step into this role and to help us increase the impact and global reach of these leadership programs. It’s worth lingering on this one point: we want to grow the global reach of our leadership development programs — and, in turn, increase the global scope and diversity of our community. That is one of the first priorities we will ask this new VP to tackle. Right now, the majority of our staff and much of our are in North America. Certainly, this has improved in the last few years. For example, our 2018 cohort of fellows has people based in Brazil, Canada, Chile, Germany, India, Kenya, Mexico, Netherlands, South Africa, Tunisia, and USA. However, this is just a start. This new VP will lead the effort to go further . With this in mind, the VP, Leadership Programs will be based in Mozilla’s Berlin office. Berlin is our biggest office outside of North America. It is well placed to work with people based in African, Middle Eastern and South Asian time zones. And, Berlin as a city is a cosmopolitan hub of open tech work — attracting people from all around the world. While putting one person in Berlin won’t immediately change things, it should help us shift our attention across the Atlantic and further eastward over time. Who are we looking for? Someone quite rare and special. Ideally, the new VP will be someone with both: deep experience working on some aspect of internet health; and a proven track record building high impact organizations and teams. They will need the vision to hone our leadership development and community building programs, working with our teams to take the Internet Health Report, our fellowships and awards program, and the annual Mozilla Festival to the next level of excellence. They will also need to look outwards, growing our community of partner orgs and foundations to building a movement for a healthier digital world. A full job spec is posted here. Our aim is to  make the process as open as we possibly can — knowing this is hard when you’re recruiting for a senior role and most of the people you want are in existing jobs. The first step is this blog post letting everyone know what’s up. If you have names to suggest or suggestions on other factors to consider, please reach out to myself or to Anna Sauter, the recruiter we are working with at i-potentials in Berlin. I will work with Anna to screen and shortlist a diverse slate of candidates. From there, these candidates will be interviewed by both our other VPs, directors in the leadership programs team and a handful of other staff and community members. Following this there will be an AMA with the final candidate for all staff and vouched Mozillians. I will post at least one more update here on my blog during the course of the process. Again: the job spec for the Mozilla Foundation, VP Leadership Programs is here. If you have candidates to suggest or feedback to offer, please contact Anna at i-potentials or myself. The post Mozilla Foundation is seeking a VP, Leadership Programs appeared first on Mark Surman. [Less]

Hello and welcome to another issue of This Week in Rust! Rust is a systems language pursuing the trifecta: safety, concurrency, and speed. This is a weekly summary of its progress and community. Want something mentioned? Tweet us at @ThisWeekInRust ... [More] or send us a pull request. Want to get involved? We love contributions. This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR. Updates from Rust Community News & Blog Posts Rust's 2018 roadmap. Rust is the most loved language for 3 years in a row in Stack Overflow Developer Survey. Writing an OS in pure Rust. Announcing the Tokio runtime. Redefining failure: Review of failure crate. Announcing Rust Compiler Performance Working Group. Announcing Rust Portability Working Group. Snips open sources Snips NLU - a Natural Language Understanding service written in Rust. Announcing relibc: A libc implementation in Rust. Exploring function overloading. Coping with mutable state in multiple threads with Rust. Crashing a Rust Hyper server with a denial of service attack. This week in Rust docs 96. [podcast] Rusty Spike Podcast - episode 22. Rust 1.24.1, the 2018 roadmap, compile times, SIMD, and Pathfinder. Crate of the Week This week's crate is cursive, a library for easy text-user interface applications. Thanks to Wangshan Lu for the suggestion. Submit your suggestions and votes for next week! Call for Participation Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started! Some of these tasks may also have mentors available, visit the task page for more information. Get started with these beginner-friendly issues. [good first issue] tera: Add loop controls. Tera is a template engine for Rust based on Jinja2/Django. If you are a Rust project owner and are looking for contributors, please submit tasks here. Updates from Rust Core 124 pull requests were merged in the last week replace all const evaluation with miri (epic PR) replace internal iterator structures with impl Trait NLL: Make causal tracking lazy turn feature-gate table into a query so it is covered by dependency tracking Warn about ignored generic bounds in for show used type variable when issuing a "can't use type parameters from outer function" error message suggest type for overflowing bin/hex-literals add functionality for gating feature flags on epochs; rejigger epoch lints optimize str::repeat add functions for reversing the bit pattern in an integer implement FromStr for PathBuf stabilize FusedIterator New Contributors 1011X Kurtis Nusbaum Maxim Nazarenko Peter Lyons Songbird0 Approved RFCs Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week: RFC 2341: Allow locals and destructuring in const fn. Update the disambiguation handling in RFC 1946 (intra-rustdoc-links) to match impl concerns. Final Comment Period Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now. This week's FCPs are: [disposition: merge] Standard library API for immovable types. [disposition: merge] Add Euclidean modulo & division functionality for integers. [disposition: merge] Constants in array repeat expressions. [disposition: merge] Self in type definitions allowing enum List { Nil, Cons(T, Box) }. [disposition: merge] Add std::num::NonZeroU32 and friends, deprecate core::nonzero. [disposition: merge] Allow if and match in constants. [disposition: close] Make Cargo aware of standard library dependencies. [disposition: close] Quick dbg!(expr) macro. New RFCs Simpler alternative dbg!() macro. Finalize syntax for slice patterns with subslices. Upcoming Events The community team is trying to improve outreach to meetup organisers. Please fill out their call for contact info if you are running or used to run a meetup. Mar 15. Hamburg, DE - Rust Hack & Learn with a Sprinkle of Web Assembly. Mar 15. Cambridge, GB - Cambridge Rust Meetup. Mar 16. Frankfurt, DE - Rust Table of Regulars. Mar 16. Pune, IN - Rust Hacks at Cummins. Mar 17. Chennai, IN - Monthly Meetup - March. Mar 18. Bangalore, IN - Rust for newbies (Part 5 of 12). Mar 18. Mountain View, US - Open Table / Icebreaker: what projects are you working on. Mar 19. London, GB - LDN Talks: March 2018. Mar 19. Karlsruhe, DE -`Hack and Meet. Mar 21. Berlin, DE - OpenTechSchool Berlin - Rust Hack and Learn. Mar 21. Vancouver, CA - Rust Study/Hack/Hang-out night. Mar 21. Rust Community Team Meeting at #rust-community on irc.mozilla.org. Mar 22. Rust release triage. Mar 25. Mountain View, US - Open Table / Icebreaker: what projects are you working on. Mar 27. Rust Community Content Subteam Meeting at #rust-content on irc.mozilla.org. Mar 27. Kitchener, CA - An Introduction To Rust & Writing a Crate (Kahan Sums). Mar 28. Rust Community Team Meeting at #rust-community on irc.mozilla.org. Mar 28. Rust Events Team Meeting. If you are running a Rust event please add it to the calendar to get it mentioned here. Email the Rust Community Team for access. Rust Jobs Librsvg and Gnome-class accepting interns. Senior Computing Engineer at Marginal Unit. Senior Data Engineer at Marginal Unit. Tweet us at @ThisWeekInRust to get your job offers listed here! Quote of the Week Captain's log, day 21 We have sailed on Reddit and Twitter for three weeks now, searching far and wide, yet the only thing we found was a barren landscape, with no end in sight. The supplies are shrinking, the men are growing impatient and hungry, and I fear we will have a mutiny soon. But I am stubborn and optimistic, and urge them to hold on and keep waiting until we find a quote of the week. — u/SelfDistinction on reddit. Thanks to u/nasa42 for the suggestion! Submit your quotes for next week! This Week in Rust is edited by: nasa42 and llogiq. [Less]

Summary I work at Mozilla. I work on a lot of stuff: a main project I do a ton of work on and maintain: Socorro a bunch of projects related to that project which I work on and maintain: Antenna, Everett, Markus some projects that I work on ... [More] occasionally but don't maintain: mozilla-django-oidc one project that many Mozilla sites use that somehow I ended up with but has no relation to my main project: Bleach some projects I'm probably forgetting about a side-project that isn't related to anything else I do that I "maintain": Standups For most of those projects, they're either part of my main job or I like working on them or I get some recognition for owning them. Whatever the reason, I don't work on them because I feel bad. Then there's Standups which I work on solely because I feel bad. This blog post talks about me and Standups, pontificates about some options I've talked with others about, and then lays out the concept of swag-driven development. Read more… (8 mins to read) [Less]

It’s been a bit over five months since we launched Firefox Screenshots in Firefox 56, and I wanted to take a moment to reflect on what’s happened so far and to look forward to what’s coming next.So far, our users have taken more than 67 million ... [More] screenshots. This is a big number that makes my manager happy, but more interesting is how we got here.The changing shape of FirefoxWe launched Firefox Screenshots in Firefox 56 in late September of 2017. This was one release before the widely hailed Firefox Quantum release, back when Firefox still had curvy tabs.When we launched, the screenshot button appeared in the browser toolbar with a little badge highlighting the new feature.Firefox 56 UI with Screenshots appearing in the toolbarIn Firefox Quantum, actions such as bookmarking, sending a tab to a mobile device, or saving to Pocket were all moved into a contextual menu. The Firefox Screenshots control moved to this new home as well.Firefox Quantum with a hidden Screenshots controlAs a Firefox user, I really like this new design: it’s cleaner, more consistent than what came before. As the Product Manager for Screenshots, I was definitely worried about how the change would affect our numbers.We did take a pretty sizable hit in the short term. Firefox Quantum launched on November 14th and rolled out over the following week. In the four weeks that followed, 23.2% fewer shots were taken than prior to the Firefox Quantum launch.The dark purple line show shots taken in the 28 days after Quantum, while the lighter line shows shots taken in the 28 days prior.Taking a step back, the logic of Firefox’s redesign starts to show. While the graph above measures shots actually taken, the one below shows total shots initiated during the same period. Shots are initiated when someone clicks the screenshots button or right-clicks to trigger the screenshots UI.Users started to take a lot more shots in the month before Quantum.These charts show that while users started to take a lot more shots before Firefox Quantum, they didn’t actually wind up taking that many more shots. This difference really shows in the relative rates of shots canceled before and after Firefox Quantum. Canceled shots just mean that a user escapes the Screenshot UI without capturing a screenshot by refreshing the page, hitting escape, or clicking the cancel button. As the graph below show, these events fell off a cliff after Firefox Quantum.After Quantum, canceled shots fell drastically.So, yes, we lost users with the Firefox Quantum launch, but the change was actually quite positive for us because the changes made engagements with Firefox Screenshots a lot more likely to end in a shot actually being taken.The chart at left shows all shots initiated, canceled and taken from September 28th, 2017 through March 1st, 2018 split by the Firefox Quantum release. The change in ratio between taken and canceled is pretty impressive. Before Firefox Quantum there was 1 shot taken for every 2 shots canceled. Since Firefox Quantum there have been 2 shots taken for every shot canceled. It seems that users who engage with Screenshots in Firefox Quantum do so intentionally whereas before people might have simply clicked the new button to to see what happened.Another noteworthy feature of Firefox Quantum is that right-clicking (aka context clicking) to start a shot has long-since become our users’ preferred way to begin engagement with Screenshots. This makes sense given that people take screenshots in order to complete tasks such as sending along flight information or grabbing a chat bubble for later reference. In the chart below (which really shows the effect Firefox Quantum had on starting shots) context clicking surpasses the toolbar menu just after Firefox Quantum launched.Most users now start shots through a context click.What kind of shots are people taking?When we launched Screenshots in Firefox 56 there were two different kinds of shots our users could take. They could drag select a region of the page and either download the highlighted region or upload it and get a URL copied to their clipboard to share.Over the last several releases, we’ve added different ways of capturing shots so that now there are 9 different methods of taking and saving shots. As of Firefox Quantum users could capture regions, visible parts of a page, or an entire page. In the Firefox release after Quantum we added the ability to copy images directly to the clipboard.Users have lots of different options when it comes to saving shots.So, how do all of these different shot types compare? Well, the most popular shot type is downloading a region, followed by saving a region and getting a URL. This has been the case pretty much throughout the life of Screenshots. Interestingly, this ranking was reversed when we were testing Screenshots in Test Pilot back when it was called Page Shot.The view since Quantum: downloading and uploading regions are still the most popular options, but copying a region to clipboard has grown a lot since it launched in late JanuarySince we started launching more shot options in Firefox Quantum, copying directly to clipboard (above in aqua) has grown particularly popular (it’s how I added charts to this post). The chart below shows all shots taken in the last month, the relative changes in each category, and shot totals. There are a few highlights here: Clipboard shots are growing like crazy. They appear to be cannibalizing shots that might have otherwise been saved to a URL. We’re growing! All the ways people took shots from February 5th to March 6th 2018And we’ve been growing. Since the new year, a time when we expect to see a seasonal decrease in users, we’ve grown every single week in 2018. We’re not quite back to the raw weekly shot numbers we had before Firefox Quantum, but as the chart below shows, we’re getting awfully close, and these shots are far more likely to be taken intentionally than prior to the Firefox Quantum launch.Up nextHey look, annotations!We’re still actively improving Firefox Screenshots all the time. In fact, we’re launching an annotations feature today! This feature will let users draw on or re-crop any saved shot.Beyond this, we’ve got a few other ideas up our sleeves to make Firefox Screenshots even cooler than it is now. If you’re interested in helping out, please check out our repo on GitHub and feel free to contribute! 🏄‍♀️So, How’s Screenshots Doing? was originally published in Firefox Test Pilot on Medium, where people are continuing the conversation by highlighting and responding to this story. [Less]

A Certification Authority (CA) is an organization that browser vendors (like Mozilla) trust to issue certificates to websites. Last year, Mozilla published and discussed a set of issues with one of the oldest and largest CAs run by Symantec. The ... [More] discussion resulted in the adoption of a consensus proposal to gradually remove trust in all Symantec TLS/SSL certificates from Firefox. The proposal includes a number of phases designed to minimize the impact of the change to Firefox users: January 2018 (Firefox 58): Notices in the Browser Console warn about Symantec certificates issued before 2016-06-01, to encourage site owners to replace their TLS certificates. May 2018 (Firefox 60): Websites will show an untrusted connection error if they use a TLS certificate issued before 2016-06-01 that chains up to a Symantec root certificate. October 2018 (Firefox 63): Distrust of Symantec root certificates for website server TLS authentication. After the consensus proposal was adopted, the Symantec CA was acquired by DigiCert; however, that fact has not changed Mozilla’s commitment to implement the proposal. Firefox 60 is expected to enter Beta on March 13th carrying with it the removal of trust for Symantec certificates issued prior to June 1st, 2016, with the exception of certificates issued by a few subordinate CAs that are controlled by Apple and Google. This change affects all Symantec brands including GeoTrust, RapidSSL, Thawte, and VeriSign. The change is already in effect in Firefox Nightly. Mozilla telemetry currently shows that a significant number of sites – roughly 1% of the top one million – are still using TLS certificates that are no longer trusted in Firefox 60. While the number of affected sites has been declining steadily, we do not expect every website to be updated prior to the Beta release of Firefox 60. We strongly encourage operators of affected sites to take immediate action to replace these certificates. If you attempt to visit a site that is using a TLS certificate that is no longer trusted in Firefox 60, you will encounter the following error:  Clicking on the “Advanced” button will allow you to bypass the error and reach the site: These changes are expected to be included in the final version of Firefox 60 that is planned to be release on May 9th, 2018. In Firefox 63, trust will be removed for all Symantec TLS certificates regardless of the date issued (with the exception of certificates issued by Apple and Google subordinate CAs as described above). Wayne Thayer Kathleen Wilson The post Distrust of Symantec TLS Certificates appeared first on Mozilla Security Blog. [Less]

Winter’s icy hand is releasing its grip, birds are returning from southern migration which means it’s that time of year where people everywhere rank things, put them in brackets and … Read more The post March Add(on)ness is here appeared first on The Firefox Frontier.

Winter’s icy hand is releasing its grip, birds are returning from southern migration which means it’s that time of year where people everywhere rank things, put them in brackets and … Read more The post March Add(on)ness is here appeared first on The Firefox Frontier.

The Monday Project Meeting

This is a quick note addressed to those reading this blog via a subscription to Planet Mozilla. Following my stepping back from the Mozilla project, posts to this blog are unlikely to feature Mozilla-related content in the future, and will instead be ... [More] about, well, what it’s like to be dying :-) I therefore won’t be syndicating them. If you wish to keep reading what I write, you may want to take a direct subscription. Here’s my direct feed. [Less]