Mozilla Nederland LogoDe Nederlandse

Abonneren op feed Mozilla planet
Planet Mozilla -
Bijgewerkt: 4 uur 43 min geleden

Air Mozilla: Privacy Lab - Privacy for Startups - January 2016

vr, 29/01/2016 - 03:00

Privacy Lab - Privacy for Startups - January 2016 Privacy for Startups: Practical Guidance for Founders, Engineers, Marketing, and those who support them Startups often espouse mottos that make traditional Fortune 500 companies cringe....

Categorieën: Mozilla-nl planet

Tanvi Vyas: No More Passwords over HTTP, Please!

do, 28/01/2016 - 23:14

Firefox Developer Edition 46 warns developers when login credentials are requested over HTTP.

Username and password pairs control access to users’ personal data. Websites should handle this information with care and only request passwords over secure (authenticated and encrypted) connections, like HTTPS. Unfortunately, we too frequently see non-secure connections, like HTTP, used to handle user passwords. To inform developers about this privacy and security vulnerability, Firefox Developer Edition warns developers of the issue by changing the security iconography of non-secure pages to a lock with a red strikethrough.

Firefox Developer Edition 46+ shows a lock with a red strikethrough on non-secure pages that have a password field, while Firefox Release does include that additional iconography

How does Firefox determine if a password field is secure or not?

Firefox determines if a password field is secure by examining the page it is embedded in. The embedding page is checked against the algorithm in the W3C’s Secure Contexts Specification to see if it is secure or non-secure. Anything on a non-secure page can be manipulated by a Man-In-The-Middle (MITM) attacker. The MITM can use a number of mechanisms to extract the password entered onto the non-secure page. Here are some examples:

      • Change the form action so the password submits to an attacker controlled server instead of the intended destination. Then seamlessly redirect to the intended destination, while sending along the stolen password.
      • Use javascript to grab the contents of the password field before submission and send it to the attacker’s server.
      • Use javascript to log the user’s keystrokes and send them to the attacker’s server.

Note that all of the attacks mentioned above can occur without the user realizing that their account has been compromised.

Firefox has been alerting developers of this issue via the Developer Tools Web Console since Firefox 26.

Why isn’t submitting over HTTPS enough? Why does the page have to be HTTPS?

We get this question a lot, so I thought I would call it out specifically. Although transmitting over HTTPS instead of HTTP does prevent a network eavesdropper from seeing a user’s password, it does not prevent an active MITM attacker from extracting the password from the non-secure HTTP page. As described above, active attackers can MITM an HTTP connection between the server and the user’s computer to change the contents of the webpage. The attacker can take the HTML content that the site attempted to deliver to the user and add javascript to the HTML page that will steal the user’s username and password. The attacker then sends the updated HTML to the user. When the user enters their username and password, it will get sent to both the attacker and the site.

What if the credentials for my site really aren’t that sensitive?

Sometimes sites require username and passwords, but don’t actually store data that is very sensitive. For example, a news site may save which news articles a user wants to go back and read, but not save any other data about a user. Most users don’t consider this highly sensitive information. Web developers of the news site may be less motivated to secure their site and their user credentials. Unfortunately, password reuse is a big problem. Users use the same password across multiple sites (news sites, social networks, email providers, banks). Hence, even if access to the username and password to your site doesn’t seem like a huge risk to you, it is a great risk to users who have used the same username and password to login to their bank accounts. Attackers are getting smarter; they steal username/password pairs from one site, and then try reusing them on more lucrative sites.

How can I remove this warning from my site?

Put your login forms on HTTPS pages.

Of course, the most straightforward way to do this is to move your whole website to HTTPS. If you aren’t able to do this today, create a separate HTTPS page that is just used for logins. Whenever a user wants to login to your site, they will visit the HTTPS login page. If your login form submits to an HTTPS endpoint, parts of your domain may already be set up to use HTTPS.

In order to host content over HTTPS, you need a TLS Certificate from a Certificate Authority. Let’s Encrypt is a Certificate Authority that can issue you free certificates. You can reference these pages for some guidance on configuring your servers.

What can I do if I don’t control the webpage?

We know that users of Firefox Developer Edition don’t only use Developer Edition to work on their own websites. They also use it to browse the net. Developers who see this warning on a page they don’t control can still take a couple of actions. You can try to add “https://” to the beginning of the url in the address bar and see if you are able to login over a secure connection to help protect your data. You can also try and reach out to the website administrator and alert them of the privacy and security vulnerability on their site.

Do you have examples of real life attacks that occurred because of stolen passwords?

There are ample examples of password reuse leading to large scale compromise. There are fewer well-known examples of passwords being stolen by performing MITM attacks on login forms, but the basic techniques of javascript injection have been used at scale by Internet Service Providers and governments.

Why does my browser sometimes show this warning when I don’t see a password field on the page?

Sometimes password fields are in a hidden <div> on a page, that does not show up without user interaction. We have a bug open to detect when a password field is visible on the page.

Will this feature become available to Firefox Beta and Release Users?

Right now, the focus for this feature is on developers, since they’re the ones that ultimately need to fix the sites that are exposing users’ passwords. In general, though, since we are working on deprecating non-secure HTTP in the long run, you should expect to see more and more explicit indications of when things are not secure. For example, in all current versions of Firefox, the Developer Tools Network Monitor shows the lock with a red strikethrough for all non-secure HTTP connections.

How do I enable this warning in other versions of Firefox?

Users of Firefox version 44+ (on any branch) can enable or disable this feature by following these steps:

      1. Open a new window or tab in Firefox.
      2. Type about:config and press enter.
      3. You will get to a page that asks you to promise to be careful. Promise you will be.
      4. The value of the security.insecure_password.ui.enabled preference determines whether or not Firefox warns you about non-secure login pages. You can enable the feature and be warned about non-secure login pages by setting this value to true. You can disable the feature by setting the value to false.
Thank you!

A special thanks to Paolo Amadini and Aislinn Grigas for their implementation and user experience work on this feature!

Categorieën: Mozilla-nl planet

Support.Mozilla.Org: What’s up with SUMO – 28th January

do, 28/01/2016 - 22:00

Hello, SUMO Nation!

Starting from this week, we’re moving things around a bit (to keep them fresh and give you more time to digest and reply. The Friday posts are moving to Thursday, and Fridays will be open for guest posts (including yours) – if you’re interested in writing a post for this blog, let me know in the comments.

Welcome, new contributors!
If you just joined us, don’t hesitate – come over and say “hi” in the forums! Contributors of the week

We salute you!

Don’t forget that if you are new to SUMO and someone helped you get started in a nice way you can nominate them for the Buddy of the Month! Most recent SUMO Community meeting The next SUMO Community meeting…
  • is happening on Monday the 1st of February – join us!
  • Reminder: if you want to add a discussion topic to the upcoming meeting agenda:
    • Start a thread in the Community Forums, so that everyone in the community can see what will be discussed and voice their opinion here before Monday (this will make it easier to have an efficient meeting).
    • Please do so as soon as you can before the meeting, so that people have time to read, think, and reply (and also add it to the agenda).
    • If you can, please attend the meeting in person (or via IRC), so we can follow up on your discussion topic during the meeting with your feedback.
Developers Community Social Support Forum
  • Today (was/is/will still be for a few hours) a SUMO Day, connected to the release week for Version 44. Keep answering those questions, heroes of the helpful web!
Knowledge Base Localization Firefox
  • for Android
    • It’s the Firefox 44 Release Week! Forum talk about the release.
    • Draft release notes are here.
    • This is a staged rollout using Google Play, addressing the crash rate discussions
    • IMPORTANT: Android OS versions 3.0 – 3.2.6 (Honeycomb) won’t be supported in a future release of Firefox for Android; when this happens the app will not be visible on the Google Play Store for users of these OS versions. When we have a more definite time frame for this we will publish another post.
  • for iOS
    • 2.0 is still under wraps – thank you for your patience!

That’s it for today, dear SUMOnians! We still have Friday to enjoy, so see you around SUMO and not only… tomorrow!

Categorieën: Mozilla-nl planet

Air Mozilla: Web QA Weekly Meeting, 28 Jan 2016

do, 28/01/2016 - 18:00

Web QA Weekly Meeting This is our weekly gathering of Mozilla'a Web QA team filled with discussion on our current and future projects, ideas, demos, and fun facts.

Categorieën: Mozilla-nl planet

Air Mozilla: Reps weekly, 28 Jan 2016

do, 28/01/2016 - 17:00

Reps weekly This is a weekly call with some of the Reps to discuss all matters about/affecting Reps and invite Reps to share their work with everyone.

Categorieën: Mozilla-nl planet

Mark Surman: Inspired by our grassroots leaders

do, 28/01/2016 - 16:32

Last weekend, I had the good fortune to attend our grassroots Leadership Summit in Singapore: a hands on learning and planning event for leaders in Mozilla’s core contributor community.


We’ve been doing these sorts of learning / planning / doing events with our broader community of allies for years now: they are at the core of the Mozilla Leadership Network we’re rolling out this year. It was inspiring to see the participation team and core contributor community dive in and use a similar approach.

I left Singapore feeling inspired and hopeful — both for the web and for participation at Mozilla. Here is an email I sent to everyone who participated in the Summit explaining why:

As I flew over the Pacific on Monday night, I felt an incredible sense of inspiration and hope for the future of the web — and the future of Mozilla. I have all of you to thank for that. So, thank you.

This past weekend’s Leadership Summit in Singapore marked a real milestone: it was Mozilla’s first real attempt at an event consciously designed to help our core contributor community (that’s you!) develop important skills like planning and dig into critical projects in areas like connected devices and campus outreach all at the same time. This may not seem like a big deal. But it is.

For Mozilla to succeed, *all of us* need to get better at what we do. We need to reach and strive. The parts of the Summit focused on personality types, planning and building good open source communities were all meant to serve as fuel for this: giving us a chance to hone skills we need.

Actually getting better comes by using these skills to *do* things. The campus campaign and connected devices tracks at the Summit were designed to make this possible: to get us all working on concrete projects while applying the skills we were learning in other sessions. The idea was to get important work done while also getting better. We did that. You did that.

Of course, it’s the work and the impact we have in the world that matter most. We urgently need to explore what the web — and our values — can mean in the coming era of the internet of things. The projects you designed in the connected devices track are a good step in this direction. We also need to grow our community and get more young people involved in our work. The plans you made for local campus campaigns focused on privacy will help us do this. This is important work. And, by doing it the way we did it, we’ve collectively teed it up to succeed.

I’m saying all this partly out of admiration and gratitude.  But I’m also trying to highlight the underlying importance of what happened this past weekend: we started using a new approach to participation and leadership development. It’s an approach that I’d like to see us use even more both with our core participation leaders (again, that’s you!) and with our Mozilla Leadership Network (our broader network of friends and allies). By participating so fully and enthusiastically in Singapore, you helped us take a big step towards developing this approach.

As I said in my opening talk: this is a critical time for the web and for Mozilla. We need to simultaneously figure out what technologies and products will bring our values into the future and we need to show the public and governments just how important those values are. We can only succeed by getting better at working together — and by growing our community around the world. This past weekend, you all made a very important step in this direction. Again, thank you.

I’m looking forward to all the work and exploration we have ahead. Onwards!

As I said in my message, the Singapore Leadership Summit is a milestone. We’ve been working to recast and rebuild our participation team for about a year now. This past weekend I saw that investment paying off: we have a team teed up to grow and support our contributor community from around the world. Nicely done! Good things ahead.

The post Inspired by our grassroots leaders appeared first on Mark Surman.

Categorieën: Mozilla-nl planet

Nathan Froyd: for-purpose instead of non-profit

do, 28/01/2016 - 15:16

I began talking with a guy in his midforties who ran an investment fund and told me about his latest capital raise. We hit it off while discussing the differences between start-ups on the East and West Coasts, and I enjoyed learning about how he evaluated new investment opportunities. Although I’d left that space a while ago, I still knew it well enough to carry a solid conversation and felt as if we were speaking the same language. Then he asked what I did.

“I run a nonprofit organization called Pencils of Promise.”

“Oh,” he replied, somewhat taken aback. “And you do that full-time?”

More than full-time, I thought, feeling a bit judged. “Yeah, I do. I used to work at Bain, but left to work on the organization full-time.”

“Wow, good for you,” he said in the same tone you’d use to address a small child, then immediately looked over my shoulder for someone new to approach…

On my subway ride home that night I began to reflect on the many times that this scenario had happened since I’d started Pencils of Promise. Conversations began on an equal footing, but the word nonprofit could stop a discussion in its tracks and strip our work of its value and true meaning. That one word could shift the conversational dynamic so that the other person was suddenly speaking down to me. As mad as I was at this guy, it suddenly hit me. I was to blame for his lackluster response. With one word, nonprofit, I had described my company as something that stood in stark opposition to the one metric that his company was being most evluated by. I had used a negative word, non, to detail our work when that inaccurately described what we did. Our primary driver was not the avoidance of profits, but the abundance of social impact…

That night I decided to start using a new phrase that more appropriately labeled the motivation behind our work. By changing the words you use to describe something, you can change how other perceive it. For too long we had allowed society to judge us with shackling expectations that weren’t supportive of scale. I knew that the only way to win the respect of our for-profit peers would be to wed our values and idealism to business acumen. Rather than thinking of ourselves as nonprofit, we would begin to refer to our work as for-purpose.

From The Promise of a Pencil by Adam Braun.

Categorieën: Mozilla-nl planet

The Mozilla Blog: It’s International Data Privacy Day: Help us Build a Better Internet

do, 28/01/2016 - 05:15

Update your Software and Share the Lean Data Practices

Today is International Data Privacy Day. What can we all do to help ourselves and each other improve privacy on the Web? We have something for everyone:

  • Users can greatly improve their own data privacy by simply updating their software.
  • Companies can increase user trust in their products and user privacy by implementing Lean Data Practices that increase transparency and offer user control.

By taking action on these two simple ideas, we can create a better Web together.

Why is updating important?

Updating your software is a basic but crucial step you can take to help increase your privacy and security online. Outdated software is one of the easiest ways for hackers to access your data online because it’s prone to vulnerabilities and security holes that can be exploited and that may have been patched in the updated versions. Updating can make your friends and family more secure because a computer that has been hacked can be used to hack others. Not updating software is like driving with a broken tail light – it might not seem immediately urgent, but it compromises your safety and that of people around you.

For our part, we’ve tried to make updating Firefox as easy as possible by automatically sending users updates by default so they don’t have to worry about it. Updates for other software may not come automatically, but they are equally important.

Once you complete your updates share the “I Updated” badge using #DPD2016 and #PrivacyAware and encourage your friends and family to update, too!

Why should companies implement Lean Data Practices?

Today we’re also launching a new way for companies and projects to earn user trust through a simple framework that helps companies think about the decisions they make daily about data. We call these Lean Data Practices and the three central questions that help companies work through are how can you stay lean, build in security and engage your users. The more companies and projects that implement these concepts, the more we as an industry can earn user trust. You can read more in this blog post from Mozilla’s Associate General Counsel Jishnu Menon.

As a nonprofit with a mission to promote openness, innovation and opportunity on the Web Mozilla is dedicated to putting users in control of their online experiences. That’s why we think about online privacy and security every day and have privacy principles that show how we build it into everything we do. All of us – users and businesses alike – can contribute to a healthy, safe and trusted Web. The more we focus on ways to reach that goal, the easier it is to innovate and keep the Web open and accessible to all. Happy International Data Privacy Day!

Categorieën: Mozilla-nl planet

Mozilla Open Policy & Advocacy Blog: Introducing Lean Data Practices

do, 28/01/2016 - 05:10

At Mozilla, we believe that users trust products more when companies build in transparency and user control. Earned trust can drive a virtuous cycle of adoption, while conversely, mistrust created by even just a few companies can drive a negative cycle that can damage a whole ecosystem.

Today on International Data Privacy Day, we are happy to announce a new initiative aimed at assisting companies and projects of all sizes to earn trust by staying lean and being smart about collecting and using data.

We call these Lean Data Practices.


Lean Data Practices in action

Lean Data Practices are not principles, nor are they a way to address legal compliance— rather, they are a framework to help companies think about the decisions they make about data. They do not prescribe a particular outcome and can help even the smallest companies to begin building user trust by fostering transparency and user control.

We have designed Lean Data Practices to be simple and direct:

  1. stay lean by focusing on data you need,
  2. build in security appropriate to the data you have and
  3. engage your users to help them understand how you use their data.

We have even created a toolkit to make it easy to implement them.

We use these practices as a starting point for our own decisions about data at Mozilla. We believe that as more companies and projects use Lean Data Practices, the better they will become at earning trust and, ultimately, the more trusted we will all become as an industry.

Please check them out and help us spread the word!

Categorieën: Mozilla-nl planet

Air Mozilla: PeninsulaJS

do, 28/01/2016 - 04:00

PeninsulaJS A Monthly Web development meetup for the Peninsula and South Bay Area. 4th Wednesday of every month.

Categorieën: Mozilla-nl planet

Nick Cameron: Macros and name resolution

do, 28/01/2016 - 02:43

This should be the last blog post on the future of macros. Next step is to make some RFCs!

I've talked previously about how macros should be nameable just like other items, rather than having their own system of naming. That means we must be able to perform name resolution at the same time as macro expansion. That's not currently possible. In this blog post I want to spell out how we might make it happen and make it work with the sets of scopes hygiene algorithm. Niko Matsakis has also been thinking about name resolution a lot, you can find his prototype algorithm in this repo. This blog post will basically describe that algorithm, tied in with the sets of scopes hygiene algorithm.

Name resolution is the phase in the compiler where we match uses of a name with definitions. For example, in

fn foo() { ... } fn bar() { foo(); }

We match up the use of foo in the body of bar with the definition of foo above.

This gets a bit more complicated because of shadowing, e.g., if we change bar:

fn bar() { fn foo() { ... } foo(); }

Now the use of foo refers to the nested bar function, not the one outside foo.

Imports also complicate resolution: to resolve a name we might need to resolve an import (which might be a glob import). The compiler also enforces rules about imports during name resolution, for example we can't import two names into the same namespace.

Name resolution today

Name resolution takes place fairly early on in the compiler, just after the AST has been lowered to the HIR. There are three passes over the AST, the first builds the 'reduced graph', the second resolves names, and the third checks for unused names. The 'reduced graph' is a record of all definitions and imports in a program (without resolving anything), I believe it is necessary to allow forward references.


We would like to make it possible to resolve names during macro expansion so that macros can be modularised in the same way as other items. We would also like to be a little more permissive with restricted imports - it should be allowed to import the same name into a scope twice if it refers to the same definition, or if that name is never used.

There are some issues with this idea. In particular, a macro expansion can introduce new names. With no restrictions, a name could refer to different definitions at different points in program expansion, or even be legal at some point and become illegal later due to an introduced duplicate name. This is unfortunate because as well as being confusing, it means the order of macro expansion becomes important, whereas we would like for the expansion order to be immaterial.

Using sets of scopes for name resolution

Previously, I outlined how we could use the sets of scopes hygiene algorithm in Rust. Sets of scopes can also be used to do name resolution, in fact that is how it is intended to be used. The traditional name resolution approach is, essentially, walking up a tree of scopes to find a binding. With sets of scopes, all bindings are treated as being in a global 'namespace'. A name lookup will result in a set of bindings, we then compare the sets of scopes for each binding with the set of scopes for the name use and try to find an unambiguously best binding.

The plan

The plan is basically to split name resolution into two stages. The first stage will happen at the same time as macro expansion and will resolve imports to define (conceptually) a mapping from names in scope to definitions. The second stage is looking up a definition in this mapping for any given use of a name. This could happen at any time, to start with we'll probably leave it where it is. Later it could be merged with the AST to HIR lowering or performed lazily.

When we need to lookup a macro during expansion, we use the sets of names as currently known. We must ensure that each such lookup remains unchanged throughout expansion.

In addition, the method of actually looking up a name is changed. Rather than looking through nested scopes to find a name, we use the sets of scopes from the hygiene algorithm. We pretty much have a global table of names, and we use the name and sets of scopes to lookup the definition.


Currently, parsing and macro expansion happen at the same time. With this proposal, we add import resolution to that mix too. The output of libsyntax is an expanded AST with sets of scopes for each identifier and tables of name bindings which bind names to sets of scopes to definitions.

We rely on a monotonicity property in macro expansion - once an item exists in a certain place, it will always exist in that place. It will never disappear and never change. Note that for the purposes of this property, I do not consider code annotated with a macro to exist until it has been fully expanded.

A consequence of this is that if the compiler resolves a name, then does some expansion and resolves it again, the first resolution will still be valid. However, a better resolution may appear, so the resolution of a name may change as we expand. It can also change from a good resolution to an ambiguity. It is also possible to change from good to ambiguous to good again. There is even an edge case where we go from good to ambiguous to the same good resolution (but via a different route).

In order to keep macro expansion comprehensible to programmers, we must enforce that all macro uses resolve to the same binding at the end of resolution as they do when they were resolved.

We start by parsing as much of the program as we can - like today we don't parse macros. We then walk the AST top-down computing sets of scopes. We add these to every identifier. When we find items which bind a name, we add it to the binding table. When entering a module we also add self and super bindings. When we find imports and macro uses we add these to a work list. When we find a glob import, we have to record a 'back link'; so that when a public name is added for the supplying module, we can add it for the importing module. At this stage a glob would not add any names for a module since we don't resolve the path prefix. For each macro definition, we add the pending set of scopes.

We then loop over the work list trying to resolve names. If a name has exactly one best resolution then we use it (and record it on a list of resolved names). If there are zero, or more than one resolution, then we put it back on the work list. When we reach a fixed point, i.e., the work list no longer changes, then we are done. If the work list is empty, then expansion/import resolution succeeded, otherwise there are names not found or ambiguous names and we failed.

If the name we are resolving is for a non-glob import, then we just record it in the binding table. If it is a glob import, we add bindings for every public name currently known.

If the resolved name is for a macro, then we expand that macro by parsing the arguments, pattern matching, and doing hygienic expansion. At the end of expansion, we apply the pending scopes and compute scopes due to the expanded macro. This may include applying more scopes to identifiers outside the expansion. We add new names to the binding table and push any new macro uses and imports to the work list to resolve.

If we add public names for a module which has back links, we must follow them and add these names to the importing module. When following these back links, we check for cycles, signaling an error if one is found.

If we succeed, then after running the fix-point algorithm, we check our record of name resolutions. We re-resolve and check we get the same result. We also check for un-used macros at this point.

The second part of name resolution happens later, when we resolve names of types and values. We could hopefully merge this with the lowering from AST to HIR. After resolving all names, we can check for unused imports and names.

Resolving names

To resolve a name, we look up the 'literal' name in the binding table. That gives us a list of sets of scopes. We can discard any which are not a subset of the scopes on the name, then order the remainder by sub-setting and pick the largest (according to the subset ordering, not the set with most elements). If there is no largest set, then name resolution is ambiguous. If there are no subsets, then the binding is undefined. Otherwise we get the definition we're looking for.

To resolve a path we look up the first segment like a name. We then lookup the next segment using the scope defined by the previous segment. Furthermore, in all lookups apart from the initial segment, we ignore outside edge scopes. For example, consider:

// scope 0 mod foo { // scope 1 fn bar() {} // scope 2 } fn main() { // scope 3 use foo::bar; }

The use item has set of scopes {0, 3} the foo name is thus bound by the module foo in scope {0}. We then lookup bar with scopes {1} (the scope defined by foo) and find the bar function. By ignoring outside edge scopes, this will be the case even if bar is introduced by a macro (if the macro is expanded in the right way).

Names which are looked up based on type are first looked up using the type, then sets of scopes are compared when checking names. E.g., to check a field lookup e.f we find the type of e then get all fields on the struct with that type. We then try and find the one called f and with the largest subset of the scopes found on f in e.f. The same applies for enum variants, methods, etc.

To be honest, I'm not sure if type based lookups should be hygienic. I can't think of strong use cases. However, the only consistent position seems to be hygiene everywhere or nowhere, including items (which sometimes causes problems in current Rust).

Data structures

The output of expansion is now more than just the AST. Each identifier in the AST should be annotated with its sets of scopes info. We pass the complete binding table to the compiler. Exported macros are still part of the crate and come with sets of pending scopes. I don't think we need any information about imports.

When a crate is packed into metadata, we must also include the binding table. We must include private entries due to macros that the crate might export. We don't need data for function bodies though. For functions which are serialised for inlining/monomorphisation, we should include local data (although it's probably better to serialise the HIR or MIR, then it should be unnecessary). We need pending scopes for any exported macros.

Due to the nature of functions, I think we can apply an optimisation of having local binding tables for function bodies. That makes preserving and discarding the right data easier, as well as making lookups faster because there won't be a million global entries for x. Any binding with a function's scope is put into that function's local table. Other than nested functions, I don't think an item can have scopes from multiple functions. I don't think there is a good reason to extend this to nested functions.

  • Do we ever need to find an AST node from a scope? I hope not.
  • How do represent a definition in a binding? An id, a reference to an AST node?
  • See above, hygiene for 'type-based' lookups.
Categorieën: Mozilla-nl planet

Air Mozilla: Quality Team (QA) Public Meeting, 27 Jan 2016

wo, 27/01/2016 - 22:30

Quality Team (QA) Public Meeting The bi-monthly status review of the Quality team at Mozilla. We showcase new and exciting work on the Mozilla project, highlight ways you can get...

Categorieën: Mozilla-nl planet

Air Mozilla: Bugzilla Development Meeting, 27 Jan 2016

wo, 27/01/2016 - 22:00

Bugzilla Development Meeting Join the core team to discuss the on-going development of the Bugzilla product. Anyone interested in contributing to Bugzilla, in planning, development, testing, documentation, or...

Categorieën: Mozilla-nl planet

Dave Townsend: Improving the performance of the add-ons manager with asynchronous file I/O

wo, 27/01/2016 - 21:35

The add-ons manager has a dirty secret. It uses an awful lot of synchronous file I/O. This is the kind of I/O that blocks the main thread and can cause Firefox to be janky. I’m told that that is a technical term. Asynchronous file I/O is much nicer, it means you can let the rest of the app continue to function while you wait for the I/O operation to complete. I rewrote much of the current code from scratch for Firefox 4.0 and even back then we were trying to switch to asynchronous file I/O wherever possible. But still I used mostly synchronous file I/O.

Here is the problem. For many moons we have allowed other applications to install add-ons into Firefox by dropping them into the filesystem or registry somewhere. We also have to do things like updating and installing non-restartless add-ons during startup when their files aren’t in use. And we have to know the full set of non-restartless add-ons that we are going to activate quite early in startup so the startup function for the add-ons manager has to do all those installs and a scan of the extension folders before returning back to the code startup up the browser, and that means being synchronous.

The other problem is that for the things that we could conceivably use async I/O, like installs and updates of restartless add-ons during runtime we need to use the same code for loading and parsing manifests, extracting zip files and others that we need to be synchronous during startup. So we can either write a second version that is asynchronous so we can have nice performance at runtime or use the synchronous version so we only have one version to test and maintain. Keeping things synchronous was where things fell in the end.

That’s always bugged me though. Runtime is the most important time to use asynchronous I/O. We shouldn’t be janking the browser when installing a large add-on particularly on mobile and so we have taken some steps since Firefox 4 to make parts of the code asynchronous. But there is still a bunch there.

The plan

The thing is that there isn’t actually a reason we can’t use the asynchronous I/O functions. All we have to do is make sure that startup is blocked until everything we need is complete. It’s pretty easy to spin an event loop from JavaScript to wait for asynchronous operations to complete so why not do that in the startup function and then start making things asynchronous?

Performances is pretty important for the add-ons manager startup code, the longer we spend in startup the more it hurts us. Would this switch slow things down? I assumed that there would be some losses due to other things happening during an event loop tick that otherwise wouldn’t have but that the file I/O operations should take around the same time. And here is the clever bit. Because it is asynchronous I could fire off operations to run in parallel. Why check the modification time of every file in a directory one file at a time when you can just request the times for every file and wait until they all complete?

There are really a tonne of things that could affect whether this would be faster or slower and no amount of theorising was convincing me either way and last night this had finally been bugging me for long enough that I grabbed a bottle of wine, fired up the music and threw together a prototype.

The results

It took me a few hours to switch most of the main methods to use Task.jsm, switch much of the likely hot code to use OS.File and to run in parallel where possible and generally cover all the main parts that run on every startup and when add-ons have changed.

The challenge was testing. Default talos runs don’t include any add-ons (or maybe one or two) and I needed a few different profiles to see how things behaved in different situations. It was possible that startups with no add-ons would be affected quite differently to startups with many add-ons. So I had to figure out how to add extensions to the default talos profiles for my try runs and fired off try runs for the cases where there were no add-ons, 200 unpacked add-ons with a bunch of files and 200 packed add-ons. I then ran all those a second time with deleting extensions.json between each run to force the database to be loaded and rebuilt. So six different talos runs for the code without my changes and then another six with my changes and I triggered ten runs per test and went to bed.

The first thing I did this morning was check the performance results. The first ready was with 200 packed add-ons in the profile, should be a good check of the file scanning. How did it do? Amazing! Incredible! A greater than 50% performance improvement across the board! That’s astonishing! No really that’s pretty astonishing. It would have to mean the add-ons manager takes up at least 50% of the browser startup time and I’m pretty sure it doesn’t. Oh right I’m accidentally comparing to the test run with 200 packed add-ons and a database reset with my async code. Well I’d expect that to be slower.

Ok, let’s get it right. How did it really do? Abysmally! Like incredibly badly. Across the board in every test run startup is significantly slower with the asynchronous I/O than without. With no add-ons in the profile the new code incurs a 20% performance hit. In the case with 200 unpacked add-ons? An almost 1000% hit!

What happened?

Ok so that wasn’t the best result but at least it will stop bugging me now. I figure there are two things going on here. The first is that OS.File might look like you can fire off I/O operations in parallel but in fact you can’t. Every call you make goes into a queue and the background worker thread doesn’t start on one operation until the previous has completed. So while the I/O operations themselves might take about the same time you have the added overhead of passing messages between the background thread and promises. I probably should have checked that before I started! Oh, and promises. Task.jsm and OS.File make heavy use of promises and I have to say I’m sold on using them for async code. But. Everytime you wait for a promise you have to wait at least one tick of the event loop longer than you would with a simple callback. That’s great if you want responsive UI but during startup every event loop tick costs time since other code might be running that you don’t care about.

I still wonder if we could get more threads for OS.File whether it would speed things up but that’s beyond where I want to play with things for now so I guess this is where this fun experiment ends. Although now I have a bunch of code converted I wonder if I can create some replacements for OS.File and Task.jsm that behave synchronously during startup and asynchronously at runtime, then we get the best of both worlds … where did that bottle of wine go?

Categorieën: Mozilla-nl planet

Air Mozilla: The Joy of Coding - Episode 42

wo, 27/01/2016 - 19:00

The Joy of Coding - Episode 42 mconley livehacks on real Firefox bugs while thinking aloud.

Categorieën: Mozilla-nl planet

Air Mozilla: January 2016 Brantina: The Right Way to Build Software: Ideals Over Ideology with Jocelyn Goldfein

wo, 27/01/2016 - 19:00

 Ideals Over Ideology with Jocelyn Goldfein Rapid releases. Closed source software. Dogfooding. For legitimate reasons, Mozillians end up on all sides of these (and other) debates. We're not alone. Leading software...

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: Add-ons Update – Week of 2016/01/27

wo, 27/01/2016 - 17:35

I post these updates every 3 weeks to inform add-on developers about the status of the review queues, add-on compatibility, and other happenings in the add-ons world.

The Review Queues

In the past 3 weeks, 1446 add-ons were reviewed:

  • 1068 (74%) were reviewed in less than 5 days.
  • 74 (5%) were reviewed between 5 and 10 days.
  • 304 (21%) were reviewed after more than 10 days.

There are 212 listed add-ons and 2 unlisted add-ons awaiting review.

If you’re an add-on developer and would like to see add-ons reviewed faster, please consider joining us. Add-on reviewers get invited to Mozilla events and earn cool gear with their work. Visit our wiki page for more information.

Firefox 44 Compatibility

This compatibility blog post is up. The bulk compatibility validation was run last week. Some of you may have received more than one email because the first validation run had many false positives due to a bug and many add-ons failed validation incorrectly.

If you’re using the Add-ons SDK to build your add-on, make sure you’re using the latest version of jpm, since some of the JavaScript syntax changes in 44 affect add-ons built with cfx and older versions of jpm.

As always, we recommend that you test your add-ons on Beta and Firefox Developer Edition to make sure that they continue to work correctly. End users can install the Add-on Compatibility Reporter to identify and report any add-ons that aren’t working anymore.

Extension Signing

The wiki page on Extension Signing has information about the timeline, as well as responses to some frequently asked questions. The current plan is to remove the signing override preference in Firefox 46 (updated from the previous deadline of Firefox 44).


Electrolysis, also known as e10s, is the next major compatibility change coming to Firefox. Firefox will run on multiple processes now, running content code in a different process than browser code.

This is the time to test your add-ons and make sure they continue working in Firefox. We’re holding regular office hours to help you work on your add-ons, so please drop in on Tuesdays and chat with us!


If you read the post on the future of add-on development, you should know there are big changes coming. We’re working on the new WebExtensions API, and we recommend that you start looking into it for your add-ons. You can track progress of its development in

We will be talking about development with WebExtensions in the upcoming FOSDEM. Come hack with us if you’re around!

Categorieën: Mozilla-nl planet