Mozilla Nederland LogoDe Nederlandse

Laura Hilliger: Mozilla Academy Thoughts

Mozilla planet - to, 28/05/2015 - 15:23

Most of this post will be much easier to understand if you view Mark’s recent talk at the Next Billion in London, skim or reread Mark’s posts, and the Wiki.

Thoughts on messaging

One thing that strikes me is the balance b/w inclusivity and having an opinion. To me, it feels off-kilter for the long-term adoptability of Mozilla Academy. We’re idealists, I know, but it can be off-putting and if we’re thinking of the billions of FBers, it may hamper us.

Some specific examples:
  • “Freedom Fighters”Vernacular in our context vs mass context. We idealists believe we’re resisting accepted social structures that are outdated in the modern world, but I don’t think most people view the “old” world as oppressive or illegitimate.

“a person who is part of an organized group fighting against a cruel and unfair government or system”– Webster’s definition of “Freedom Fighter”

I’ve talked about structural crises before – the societal movement from agriculturally-based to industrial-based to digitally-based societies – to me the “freedom fighter” vernacular is too heavy handed, as it ignores culturally validated complacency as well as fear that is associated with structural change. People resist structural change, sometimes for hundreds of years, because they are unable to adjust as quickly as other people want them to. Or, they simply don’t want to / don’t believe it. Can we speak in a voice inclusive of these viewpoints? Is that setting the bar too high?

  • the Romans – Mark uses the Romans as an example of how powerful, effective communication can lead to strong empires. I think it’s a good analogy, but I also think there’s a note about “propaganda” lost in our messaging. Are we, as idealists, vocalizing our own propaganda? We are definitely bias…
  • the move from country to city – this analogy feels non-inclusive to me as it underscores an opinion that one way of life (city) is better than another (country), it reiterates a rejection of traditionalist ideas. While it might be true at an economic level, the personal level is the piece that speaks to people. This article on ambition and relationships in relation to human happiness articulates my internal conflict.
  • Compulsory education – In passing, Mark uses this as a societal innovation, but it would be good to consider it’s weaknesses (and what we’re doing about it) in the messaging. One could argue that our educational structures increasingly ignore psychological understandings of how learning works. See the unschooling movement (and next point).
Missed opportunity: Compulsory Education for the 21st Century

Mark says that the 3rd piece, digital literacy, is in his opinion the most important piece (I agree), but he stops short of vocalizing the connection to “being educated”. Your view is relative to your experiences, cultural background and social position, so technical skill acquisition can lead to the expansion of those perceptions by widening your network of influences. It’s a powerful and objective argument in educational theory, and could be simplified for mass appeal + understanding.

He touches ever so lightly on our pedagogy, but this is another place where this community is quite strong. Mozilla Academy as a beacon of learner-centric, production oriented learning is, IMHO, another strong selling point.

Messaging in short

I think the current messaging is powerful for kindred spirits, but potentially weak for mass appeal. Maybe that’s ok, intentional even, but I wanted to point it out. Obviously, as one can see from the other documentation that exists on this topic, the vision is considering the above points, so that’s just a messaging thing.


Mark also spoke about looking backwards and how people will think about the personal computing devices. Whether they’ll understand that they can do anything vs see their device the way people see televisions – this is another opportunity to weave in the educational value for society writ large. Increasingly our connections proliferate our lives. Governmental/Capitalist intervention is using ICTs as mechanisms of control – how can this aspect be brought in (in a balanced inclusive way)? I think convenience plays a big role here, so when I say “mechanisms of control” I don’t mean it intentionally negatively.

Common Approaches (on Curriculum)

For years I’ve been pushing a model of remixable, customizable curriculum. I’ve worked with folks across the community to integrate this model, and it’s been somewhat successful (e.g. everyone seems to be sold on the modularity as a non-negotiable, Mozillians are trying to use our pedagogy, etc). Yesterday, Robert Friedman and I talked about the layers of Mozilla Curriculum as being:

  1. Value Proposition Layer : The learning objectives and curriculum themselves
  2. Presentation Layer : Culture & Practice of teaching with that curriculum (in specific contexts)
  3. Mechanics Layer : the platform(s) that allow for modularity and customization outside of the example contexts we provide

Those three things likely need to be presupposed with the Web Literacy Map and Open Leadership Map as well as across the board components. Potentially, there are other competency and skill “maps” that need to sit on top of these two meta frameworks (e.g. Web Literacy for Science or Open Leadership for News). What we haven’t done is establish across the board components for that modularity, but I think a working group here might make that easier. For me, it’s been difficult to issue any sort of directive on “required” components because I’ve worried about innovation being stymied once we create such a framework. The Web Literacy Map contains enough flexibility to overcome this and what we’ve been talking about around Open Leadership is getting there too (assuming you think of these things as “a work in progress”) . How can we systematize curricular components with enough flexibility?

There’s a delicate balance between just enough and too much structure, and I think that conflicts will arise if we are too strict in our common approaches with such a diverse set of people/programs/topics.

The Academy Governance Model

“Highlighting value propositions through use cases (personas) helps clarify the vision / idea, makes others excited and wanting to participate) could be the start of both the development and structural strategy.” Mark’s “aha” moment from a recent workshop

There’s a lot to be learned from formal education, especially if you look at the all-to-familiar formulaic academic areas in tandem with our audience(s). Formal universities have Colleges, Departments, Subjects. Most develop pathways and curriculum separately from the “university” as a whole (but inform one another via their bicameral governance structures), and the “all to familiar” bit is the accepted standard of what is and is not a University Department (culturally defined).

If we start to think about the specific personas who would benefit from Mozilla Academy, we might be able to remix University structures to help us facilitate both the innovative development of specific Mozilla Academy “departments” (defined and built by personas in niche areas) as well as a meta framework and governance structure for what the Academy as a whole is and how it functions.

Currently, the working groups indicate a move towards a bicameral governance structure, but the “common approaches” note seems to pull away from that (with a step towards unicameral structures?). Stepping back from the working groups defined there and my questions around common approaches, I wonder whether it would be worthwhile to think about how bicameralism might (or might not) invite radical participation.

As always, it’s an open conversation so feel free to push back or share your thoughts here in the comments, in a responsive post or on Twitter.



Categorieën: Mozilla-nl planet

Mozilla begonnen met signeren van Firefox-extensies -

Nieuws verzameld via Google - to, 28/05/2015 - 11:31

Mozilla begonnen met signeren van Firefox-extensies
Mozilla is deze week begonnen met het signeren van Firefox-extensies, waarmee de browserontwikkelaar het gevecht tegen adware, toolbars en ongewenste extensies wil aangaan. Vanaf deze zomer zal Firefox namelijk alleen nog gesigneerde extensies ...

Categorieën: Mozilla-nl planet

Byron Jones: happy bmo push day!

Mozilla planet - to, 28/05/2015 - 09:06

it appears to be “bmo push week“.  today’s push addresses some issues caused by yesterday’s push.

the following changes have been pushed to

  • [1168900] “Can’t call method “id” on unblessed reference” when changing component for a bug
  • [1168790] “End this group of criteria” under Custom Search is broken for query.cgi
  • [1168751] Request nagger sends me ginormous emails because I have a lot of outgoing requests
  • [1168826] only include requests someone is waiting on in the manager’s “watching” emails

discuss these changes on

Filed under: bmo, mozilla
Categorieën: Mozilla-nl planet

Mozilla Open Policy & Advocacy Blog: It’s the final countdown: US surveillance reform nearing the finish line

Mozilla planet - to, 28/05/2015 - 07:02

The USA FREEDOM Act was born out of the shocking revelations of overbroad government surveillance that began two years ago. In its short life (it was first introduced in 2013) the USA FREEDOM Act has gone through many iterations; along with many others we have supported this legislation in our push for broader surveillance reform. The USA FREEDOM Act, although not perfect and clearly a product of compromise, deserved our support. Yet, even after overwhelming support in the House, the Senate failed to do its job late last Friday night and failed to pass the USA FREEDOM Act (defeated by a 57-42 vote). Just three more votes were needed to move this legislation forward. The word “disappointing” doesn’t really express the proper sentiment.

Facing expiration (at midnight on May 31, 2015) of three legal authorities authorizing US surveillance programs, the Senate also declined on Friday night to advance a two-month reauthorization of these authorities (by a vote of 45-54). The strategic decision-making here is still confounding. Why wait until the night before a holiday recess when the House has already left to take these votes to the floor? Now, Senate Majority Leader Mitch McConnell – left with few options — is taking the unusual step of calling a Sunday May 31st session to try again to pass something just hours before these authorities sunset. This won’t be without several challenges.

Any paths for emergency reauthorization or any “compromises” will face filibuster threats from, among others, Senator Rand Paul, who took to the floor for 10 and half hours last week to lambast the surveillance state and refused Majority Leader McConnell’s attempts on Friday evening to extend these expiring provisions by even one day. Senator Paul’s hardline opposition, combined with the nuances of the Senate’s arcane procedures and the presence of a number of other privacy champions in the Senate, means it will be nearly impossible to pass legislation in such a short window of time.

On the House side, Representatives passed the USA FREEDOM Act overwhelmingly. The House is scheduled to return from recess and vote no earlier than 6:30PM on June 1st – well after the authorities sunset. There may be some last minute wrangling during this recess week, but without some agreement from the House to take up an interim reauthorization prior to the May 31st expiration, it appears that the Senate must either pass the House version of USA FREEDOM or let these authorities sunset. Put another way, if the Senate doesn’t pass the House version of USA FREEDOM, there will be a gap in authorized collection by the intelligence community. Justice Department officials have indicated that the NSA has already begun shutting down the 215 programs so as to be in compliance if a sunset occurs.

So what actually happens if these provisions sunset? It is tempting to view a sunset as a privacy win, as the government would be restrained from bulk collection of our telephone records after all. While there’s truth to that, we can and should expect to see the national security hawks and the intelligence community push hard to reinstate some version of these authorities. A likely possibility is a Senate effort to pass a weaker “reform” bill, a watered down USA FREEDOM Act. For example, several senators have been vocal about their belief in the need for a data retention mandate — which we’ve spoken out against before — so if these authorities expire, we fear post-sunset legislative efforts will likely include such a requirement as a pathway to 60 votes in the Senate. Already Senate Intelligence Chair Richard Burr and Vice Chair Diane Feinstein have each floated bills to this end. We oppose both of these bills; they do not provide the reforms that we need.

However, as Harley Geiger of CDT notes in a recent post on Lawfare: “A few hours’ sunset may not make much difference to beltway insiders, but a post-sunset vote re-instating Sec. 215 can correctly be seen by voters as a huge expansion in government surveillance power after that power had gone dormant.” While the Senate may look to compromise after sunset, the House may well lean the other direction. House Judiciary Chairman Goodlatte and Ranking Member Conyers have indicated in a recent statement, “If the Senate chooses to allow these authorities to expire, they should do so knowing that sunset may be permanent.”

Yet, permanent sunset of Section 215 would not satisfy the Senate, and it would not be a panacea for civil liberties. The government could still conduct bulk collection in a few different ways:

  1. The government could use the FISA pen register/trap and trace statute (PR/TT), for example, which the government has previously used to conduct bulk collection of email metadata (the program allegedly ended in 2011 due to a lack of resources and demonstrated efficacy). It’s worth noting that while bulk collection under PR/TT is curtailed in the USA FREEDOM Act, this statute doesn’t otherwise have a sunset.
  2. Through other legal pathways — the vast majority of mass surveillance occurs under other authorities such as Executive Order 12333 and Section 702 of the FISA Amendments Act. While the USA FREEDOM Act doesn’t address these authorities either, we believe passing this legislation will serve as a better foundation for further reform than a sunset.
  3. Through grandfathering — Section 215’s sunset provision has a clause saying that investigations that were begun before the sunset occurred may continue. The FBI doesn’t put a time limit on its investigations, whatever broad investigation they’ve been using to justify bulk collection could foreseeably continue indefinitely. While the recent 2nd Circuit Court of Appeals opinion might mitigate this a bit, it’s unclear if the Foreign Intelligence Surveillance Court will apply that court’s reasoning to the government.

Privacy and security of users on the Internet is fundamental. Mozilla stands in continued support of the USA FREEDOM Act, as do hundreds of thousands of users, tech companies, privacy advocates, the Director of National Intelligence, the Attorney General, and the White House. Indeed, a bipartisan majority of both chambers of Congress support this legislation. We urge the House to stand behind their overwhelming vote to approve this legislation and to demand reforms that are at least as strong as the USA FREEDOM Act. Ultimately, this bill failed on a procedural vote on Friday night by just three votes. When the Senate reconvenes this Sunday, we hope three senators will step up to help enact the real reforms that users demand.



Categorieën: Mozilla-nl planet

Mike Conley: The Joy of Coding (Ep. 16): Wacky Morning DJ

Mozilla planet - to, 28/05/2015 - 04:12

I’m on vacation this week, but the show must go on! So I pre-recorded a shorter episode of The Joy of Coding last Friday.

In this episode1, I focused on a tool I wrote that I alluded to in the last episode, which is a soundboard to use during Joy of Coding episodes.

I demo the tool, and then I explain how it works. After I finished the episode, I pushed to repository to GitHub, and you can check that out right here.

So I’ll see you next week with a full length episode! Take care!

  1. Which, several times, I mistakenly refer to as the 15th episode, and not the 16th. Whoops. 

Categorieën: Mozilla-nl planet

Mozilla abandons Firefox tracking protection initiative: Is privacy protection ... - ZDNet

Nieuws verzameld via Google - to, 28/05/2015 - 02:59


Mozilla abandons Firefox tracking protection initiative: Is privacy protection ...
Mozilla has included a feature in Firefox that can dramatically speed up web browsing. In a paper that was awarded top honors in the recent Web 2.0 Security and Privacy workshop, Mozilla researchers reported that turning this feature on dramatically ...

Google Nieuws
Categorieën: Mozilla-nl planet

Mozilla Releases Major Update to CSS Animation Inspector in Firefox Developer ... -

Nieuws verzameld via Google - to, 28/05/2015 - 00:03

Mozilla Releases Major Update to CSS Animation Inspector in Firefox Developer ...
Mozilla has released the latest update of Firefox Developer Edition with always active network monitoring and CSS rules filtering. In the Mozilla Hacks article on Developer Edition 40, engineer Brian Grinstead said the release "took a major effort by ...

Google Nieuws
Categorieën: Mozilla-nl planet

Air Mozilla: Kids' Vision - Mentorship Series

Mozilla planet - to, 28/05/2015 - 00:00

Kids' Vision - Mentorship Series Mozilla hosts Kids Vision Bay Area Mentor Series

Categorieën: Mozilla-nl planet

Air Mozilla: Quality Team (QA) Public Meeting

Mozilla planet - wo, 27/05/2015 - 22:30

Quality Team (QA) Public Meeting This is the meeting where all the Mozilla quality teams meet, swap ideas, exchange notes on what is upcoming, and strategize around community building and...

Categorieën: Mozilla-nl planet

Benjamin Smedberg: Yak Shaving

Mozilla planet - wo, 27/05/2015 - 22:22

Yak shaving tends to be looked down on. I don’t necessarily see it that way. It can be a way to pay down technical debt, or learn a new skill. In many ways I consider it a sign of broad engineering skill if somebody is capable of solving a multi-part problem.

It started so innocently. My team has been working on unifying the Firefox Health Report and Telemetry data collection systems, and there was a bug that I thought I could knock off pretty easily: “FHR data migration: org.mozilla.crashes”. Below are the roadblocks, mishaps, and sideshows that resulted, and I’m not even done yet:

Tryserver failure: crashes

Constant crashes only on Linux opt builds. It turned out this was entirely my fault. The following is not a safe access pattern because of c++ temporary lifetimes:

nsCSubstringTuple str = str1 + str2; Fn(str);
Backout #1: talos xperf failure

After landing, the code was backed out because the xperf Talos test detected main-thread I/O. On desktop, this was a simple ordering problem: we always do that I/O during startup to initialize the crypto system; I just moved it slightly earlier in the startup sequence. Why are we initializing the crypto system? To generate a random number. Fixed this by whitelisting the I/O. This involved landing code to the separate Talos repo and then telling the main Firefox tree to use the new revision. Much thanks to Aaron Klotz for helping me figure out the right steps.

Backout #2: test timeouts

Test timeouts if the first test of a test run uses the PopupNotifications API. This wasn’t caught during initial try runs because it appeared to be a well-known random orange. I was apparently changing the startup sequence just enough to tickle a focus bug in the test harness. It so happened that the particular test which runs first depends on the e10s or non-e10s configuration, leading to some confusion about what was going on. Fortunately, I was able to reproduce this locally. Gavin Sharp and Neil Deakin helped get the test harness in order in bug 1138079.

Local test failures on Linux

I discovered that several xpcshell tests were failing locally on Linux which were working fine on tryserver. After some debugging, I discovered that the tests thought I wasn’t using Linux, because the cargo-culted test for Linux was let isLinux = (";1" in Cc). This means that if gconf is disabled at build time or not present at runtime, the tests will fail. I installed GConf2-devel and rebuilt my tree and things were much better.

Incorrect failure case in the extension manager

While debugging the test failures, I discovered an incorrect codepath in GMPProvider.jsm for clients which are not Windows, Mac, or Linux (Android and the non-Linux Unixes).

Android performance regression

The landing caused an Android startup performance regression, bug 1163049. On Android, we don’t initialize NSS during startup, and the earlier initialization of the addon manager caused us to generate random Sync IDs for addons. I first fixed this by using Math.random() instead of good crypto, but Richard Newman suggested that I just make Sync generation lazy. This appears to work and will land when there is an open tree.

mach bootstrap on Fedora doesn’t work for Android

As part of debugging the performance regression, I built Firefox for Android for the first time in several years. I discovered that mach bootstrap for Android isn’t implemented on Fedora Core. I manually installed packages until it built properly. I have a list of the packages I installed and I’ll file a bug to fix mach bootstrap when I get a chance.

android build-tools not found

A configure check for the android build-tools package failed. I still don’t understand exactly why this happened; it has something to do with a version that’s too new and unexpected. Nick Alexander pointed me at a patch on bug 1162000 which fixed this for me locally, but it’s not the “right” fix and so it’s not checked into the tree.

Debugging on Android (jimdb)

Binary debugging on Android turned out to be difficult. There are some great docs on the wiki, but those docs failed to mention that you have to pass the configure flag –enable-debug-symbols. After that, I discovered that pending breakpoints don’t work by default with Android debugging, and since I was debugging a startup issue that was a critical failure. I wrote an question and got a custom patch which finally made debugging work. I also had to patch the implementation of DumpJSStack() so that it would print to logcat on Android; this is another bug that I’ll file later when I clean up my tree.

Crash reporting broken on Mac

I broke crash report submission on mac for some users. Crash report annotations were being truncated from unicode instead of converted from UTF8. Because JSON.stringify doesn’t produce ASCII, this was breaking crash reporting when we tried to parse the resulting data. This was an API bug that existed prior to the patch, but I should have caught it earlier. Shoutout to Ted Mielczarek for fixing this and adding automated tests!

Semi-related weirdness: improving the startup performance of Pocket

The Firefox Pocket integration caused a significant startup performance issue on some trees. The details are especially gnarly, but it seems that by reordering the initialization of the addon manager, I was able to turn a performance regression into a win by accident. Probably something to do with I/O wait, but it still feels like spooky action at a distance. Kudos to Joel Maher, Jared Wein and Gijs Kruitbosch for diving into this under time pressure.

Experiences like this are frustrating, but as long as it’s possible to keep the final goal in sight, fixing unrelated bugs along the way might be the best thing for everyone involved. It will certainly save context-switches from other experts to help out. And doing the Android build and debugging was a useful learning experience.

Perhaps, though, I’ll go back to my primary job of being a manager.

Categorieën: Mozilla-nl planet

Air Mozilla: Security Services / MDN Update

Mozilla planet - wo, 27/05/2015 - 21:00

Security Services / MDN Update An update on the roadmap and plan for Minion and some new MDN projects coming up in Q3 and the rest of 2015

Categorieën: Mozilla-nl planet

Air Mozilla: Product Coordination Meeting

Mozilla planet - wo, 27/05/2015 - 20:00

Product Coordination Meeting Duration: 10 minutes This is a weekly status meeting, every Wednesday, that helps coordinate the shipping of our products (across 4 release channels) in order...

Categorieën: Mozilla-nl planet

Armen Zambrano: Welcome adusca!

Mozilla planet - wo, 27/05/2015 - 19:10
It is my privilege to announce that adusca (blog) joined Mozilla (since Monday) as an Outreachy intern for the next 4 months.

adusca has an outstanding number of contributions over the last few months including Mozilla CI Tools (which we're working on together).

Here's a bit about herself from her blog:
Hi! I’m Alice. I studied Mathematics in college. I was doing a Master’s degree in Mathematical Economics before getting serious about programming.She is also a graduate from Hacker's School.

Even though Alice has not been a programmer for many years, she has shown already lots of potential. For instance, she wrote a script to generate scheduling relations for buildbot; for this and many other reasons I tip my hat.

adusca will initially help me out with creating a generic pulse listener to handle job cancellations and retriggers for Treeheder. The intent is to create a way for Mozilla CI tools to manage scheduling on behalf of TH, make the way for more sophisticated Mozilla CI actions and allow other people to piggy back to this pulse service and trigger their own actions.

If you have not yet had a chance to welcome her and getting to know her, I highly encourage you to do so.

Welcome Alice!

Creative Commons License
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Categorieën: Mozilla-nl planet

Mark Surman: Mozilla Academy Strategy Update

Mozilla planet - wo, 27/05/2015 - 18:13

One of MoFo’s main goals for 2015 is to come up with an ambitious learning and community strategy. The codename for this is ‘Mozilla Academy’. As a way to get the process rolling, I wrote a long post in March outlining what we might include in that strategy. Since then, I’ve been putting together a team to dig into the strategy work formally.

This post is an update on that process in FAQ form. More substance and meat is coming in future posts. Also, there is lots of info on the wiki.

Q1. What are we trying to do?

Our main goal is alignment: to get everyone working on Mozilla’s learning and leadership development programs pointed in the same direction. The three main places we need to align are:

  1. Purpose: help people learn and hone the ability to read | write | participate.
  2. Process: people learn and improve by making things (in a community of like-minded peers).
  3. Poetry: tie back to ‘web = public resource’ narrative. Strong Mozilla brand.

At the end of the year, we will have a unified strategy that connects Mozilla’s learning and leadership development offerings (Webmaker, Hive, Open News, etc.). Right now, we do good work in these areas, but they’re a bit fragmented. We need to fix that by creating a coherent story and common approaches that will increase the impact these programs can have on the world.

Q2. What is ‘Mozilla Academy’?

That’s what we’re trying to figure out. At the very least, Mozilla Academy will be a clearly packaged and branded harmonization of Mozilla’s learning and leadership programs. People will be able to clearly understand what we’re doing and which parts are for them. Mozilla Academy may also include a common set of web literacy skills, curriculum format and learning approaches that we use across programs. We are also reviewing the possibility of a shared set of credentials or roles for people participating in Mozilla Academy.

Q3. Who is ‘Mozilla Academy’ for?

Over the past few weeks, we’ve started to look at who we’re trying to serve with our existing programs (blog post on this soon). Using the ‘scale vs depth’ graph in the Mozilla Learning plan as a framework, we see three main audiences:

  • 1.4 billion Facebook users. Or, whatever metric you use to count active people on the internet. We can reach some percentage of these people with software or marketing that invite people to ‘read | write | participate’. We probably won’t get them to want to ‘learn’ in an explicit way. They will learn by doing. Which is fine. Webmaker and SmartOn currently focus on this group.
  • People who actively want to grow their web literacy and skills. These are people interested enough in skills or technology or Mozilla that they will choose to participate in an explicit learning activity. They include everyone from young people in afterschool programs to web developers who might be interested in taking a course with Mozilla. Mozilla Clubs, Hive and MDN’s nascent learning program currently focus on this group.
  • People who want to hone their skills *and* have an impact on the world. These are people who already understand the web and technology at some level, but want to get better. They are also interested in doing something good for the web, the world or both. They include everyone from an educator wanting to create digital curriculum to a developer who wants to make the world of news or science better. Hive, ReMo and our community-based fellowships currently serve these people.

A big part of the strategy process is getting clear on these audiences. From there we can start to ask questions like: who can Mozilla best serve?; where can we have the most impact?; can people in one group serve or support people in another? Once we have the answers to these questions we can decide where to place our biggest bets (we need to do this!). And we can start raising more money to support our ambitious plans.

Q4. What is a ‘strategy’ useful for?

We want to accomplish a few things as a result of this process. A. A way to clearly communicate the ‘what and why’ of Mozilla’s learning and leadership efforts. B. A framework for designing new programs, adjusting program designs and fundraising for program growth. C. Common approaches and platforms we can use across programs. These things are important if we want Mozilla to stay in learning and leadership for the long haul, which we do.

Q5. What do you mean by ‘common approaches’?

There are a number of places where we do similar work in different ways. For example, Mozilla Clubs, Hive, Mozilla Developer Network, Open News and Mozilla Science Lab are all working on curriculum but do not yet have a shared curriculum model or repository. Similarly, Mozilla runs four fellowship programs but does not have a shared definition of a ‘Mozilla Fellow’. Common approaches could help here.

Q6. Are you developing a new program for Mozilla?

That’s not our goal. We like most of the work we’re doing now. As outlined in the 2015 Mozilla Learning Plan, our aim is to keep building on the strongest elements of our work and then connect these elements where it makes sense. We may modify, add or cut program elements in the future, but that’s not our main focus.

Q7. Are you set on the ‘Mozilla Academy’ name?

It’s pretty unlikely that we will use that name. Many people hate it. However, we needed a moniker to use during the strategy process. For better or for worse, that’s the one we chose.

Q8. What’s the timing for all of this?

We will have a basic alignment framework around ‘purpose, process and poetry’ by the end of June. We’ll work with the team at the Mozilla All Hands in Whistler. We will develop specific program designs, engage in a  broad conversation and run experiments. By October, we will have an updated version of the Mozilla Learning plan, which will lay out our work for 2016+.

As indicated above, the aim of this post is to give a process update. There is much more info on the process, who’s running it and what all the pieces are in the Mozilla Learning strategy wiki FAQ. The wiki also has info on how to get involved. If you have additional questions, ask them here. I’ll respond to the comments and also add my answers to the wiki.

In terms of substance, I’m planning a number of posts in coming weeks on topics like the essence of web literacy, who our audiences are and how we think about learning. People leading Mozilla Academy working groups will also be posting on substantive topics like our evolving thinking around the web literacy map and fellows programs. And, of course, the wiki will be growing with substantive strategy documents covering many of the topics above.

Filed under: education, mozilla, webmakers
Categorieën: Mozilla-nl planet

Mozilla: We don't give a damn about cheap smartphones - The Register

Nieuws verzameld via Google - wo, 27/05/2015 - 17:31

The Register

Mozilla: We don't give a damn about cheap smartphones
The Register
Browser-turned-OS-institution Mozilla has acknowledged that its $25 phone has failed. Firefox OS was launched with a strategy of not being Google or Apple, into the warm bosom of Telefonica and seventeen other operators at Mobile World Congress in ...

Categorieën: Mozilla-nl planet

Manish Goregaokar: Wrapper Types in Rust: Choosing Your Guarantees

Mozilla planet - wo, 27/05/2015 - 16:59

In my previous post I talked a bit about why the RWlock pattern is important for accessing data, which is why Rust enforces this pattern either at compile time or runtime depending on the abstractions used.

It occurred to me that there are many such abstractions in Rust, each with their unique guarantees. The programmer once again has the choice between runtime and compile time enforcement. It occurred to me that this plethora of “wrapper types”1 could be daunting to newcomers; in this post I intend to give a thorough explanation of what some prominent ones do and when they should be used.

I’m assuming the reader knows about ownership and borrowing in Rust. Nevertheless, I will attempt to keep the majority of this post accessible to those not yet familiar with these concepts. Aside from the two links into the book above, these two blog posts cover the topic in depth.

Basic pointer types Box<T>

Box<T> is an “owned pointer”. While it can hand out borrowed references to the data, it is the only owner of the data. In particular, when something like the following occurs:

let x = Box::new(1); let y = x; // x no longer accessible here

Here, the box was moved into y. As x no longer owns it, the compiler will no longer allow the programmer to use x after this. A box can similarly be moved out of a function by returning, and when a box (one which hasn’t been moved) goes out of scope, destructors are run, deallocating the inner data.

This abstraction is a low cost abstraction for dynamic allocation. If you want to allocate some memory on the heap and safely pass a pointer to that memory around, this is ideal. Note that you will only be allowed to share borrowed references to this by the regular borrowing rules, checked at compile time.

Interlude: Copy

Move semantics are not special to Box<T>; it is a feature of all types which are not Copy.

A Copy type is one where all the data it logically encompasses (usually, owns) is part of its stack representation2. Most types containing pointers to other data are not Copy, since there is additional data elsewhere, and simply copying the stack representation may accidentally share ownership of that data in an unsafe manner.

Types like Vec<T> and String which also have data on the heap are also not Copy. Types like the integer/boolean types are Copy

&T and raw pointers are Copy. Even though they do point to further data, they do not “own” that data. Whereas Box<T> can be thought of as “some data which happens to be dynamically allocated”, &T is thought of as “a borrowing reference to some data”. Even though both are pointers, only the first is considered to be “data”. Hence, a copy of the first should involve a copy of the data (which is not part of its stack representation), but a copy of the second only needs a copy of the reference. &mut T is not Copy because mutable aliases cannot be shared, and &mut T “owns” the data it points to somewhat since it can mutate.

Practically speaking, a type can be Copy if a copy of its stack representation doesn’t violate memory safety.

&T and &mut T

These are immutable and mutable references respectively. They follow the “read-write lock” pattern described in my previous post, such that one may either have only one mutable reference to some data, or any number of immutable ones, but not both. This guarantee is enforced at compile time, and has no visible cost at runtime. In most cases such pointers suffice for sharing cheap references between sections of code.

These pointers cannot be copied in such a way that they outlive the lifetime associated with them.

*const T and *mut T

These are C-like raw pointers with no lifetime or ownership attached to them. They just point to some location in memory with no other restrictions. The only guarantee that these provide is that they cannot be dereferenced except in code marked unsafe.

These are useful when building safe, low cost abstractions like Vec<T>, but should be avoided in safe code.


This is the first wrapper we will cover that has a runtime cost.

Rc<T> is a reference counted pointer. In other words, this lets us have multiple “owning” pointers to the same data, and the data will be freed (destructors will be run) when all pointers are out of scope.

Internally, it contains a shared “reference count”, which is incremented each time the Rc is cloned, and decremented each time one of the Rcs goes out of scope. The main responsibility of Rc<T> is to ensure that destructors are called for shared data.

The internal data here is immutable, and if a cycle of references is created, the data will be leaked. If we want data that doesn’t leak when there are cycles, we need a garbage collector. I do not know of any existing GCs in Rust, but I am working on one with Michael Layzell and there’s another cycle collecting one being written by Nick Fitzgerald.


The main guarantee provided here is that the data will not be destroyed until all references to it are out of scope.

This should be used when you wish to dynamically allocate and share some data (read-only) between various portions of your program, where it is not certain which portion will finish using the pointer last. It’s a viable alternative to &T when &T is either impossible to statically check for correctness, or creates extremely unergonomic code where the programmer does not wish to spend the development cost of working with.

This pointer is not thread safe, and Rust will not let it be sent or shared with other threads. This lets one avoid the cost of atomics in situations where they are unnecessary.

There is a sister smart pointer to this one, Weak<T>. This is a non-owning, but also non-borrowed, smart pointer. It is also similar to &T, but it is not restricted in lifetime — a Weak<T> can be held on to forever. However, it is possible that an attempt to access the inner data may fail and return None, since this can outlive the owned Rcs. This is useful for when one wants cyclic data structures and other things.


As far as memory goes, Rc<T> is a single allocation, though it will allocate two extra words as compared to a regular Box<T> (for “strong” and “weak” refcounts).

Rc<T> has the computational cost of incrementing/decrementing the refcount whenever it is cloned or goes out of scope respectively. Note that a clone will not do a deep copy, rather it will simply increment the inner reference count and return a copy of the Rc<T>

Cell types

“Cells” provide interior mutability. In other words, they contain data which can be manipulated even if the type cannot be obtained in a mutable form (for example, when it is behind an &-ptr or Rc<T>).

The documentation for the cell module has a pretty good explanation for these.

These types are generally found in struct fields, but they may be found elsewhere too.


Cell<T> is a type that provides zero-cost interior mutability, but only for Copy types. Since the compiler knows that all the data owned by the contained value is on the stack, there’s no worry of leaking any data behind references (or worse!) by simply replacing the data.

It is still possible to violate your own invariants using this wrapper, so be careful when using it. If a field is wrapped in Cell, it’s a nice indicator that the chunk of data is mutable and may not stay the same between the time you first read it and when you intend to use it.

let x = Cell::new(1); let y = &x; let z = &x; x.set(2); y.set(3); z.set(4); println!("{}", x.get());

Note that here we were able to mutate the same value from various immutable references.

This has the same runtime cost as the following:

let mut x = 1; let y = &mut x; let z = &mut x; x = 2; *y = 3; *z = 4; println!("{}", x;

but it has the added benefit of actually compiling successfully.


This relaxes the “no aliasing with mutability” restriction in places where it’s unnecessary. However, this also relaxes the guarantees that the restriction provides; so if one’s invariants depend on data stored within Cell, one should be careful.

This is useful for mutating primitives and other Copy types when there is no easy way of doing it in line with the static rules of & and &mut.

Gábor Lehel summed up the guarantees provided by Cell in a rather succinct manner:

The basic guarantee we need to ensure is that interior references can’t be invalidated (left dangling) by mutation of the outer structure. (Think about references to the interiors of types like Option, Box, Vec, etc.) &, &mut, and Cell each make a different tradeoff here. & allows shared interior references but forbids mutation; &mut allows mutation xor interior references but not sharing; Cell allows shared mutability but not interior references.

[because Cell operates by copying, it can’t create interior references]

This comment by Eddy also touches on the guarantees of Cell and the alternatives


There is no runtime cost to using Cell<T>, however if one is using it to wrap larger (Copy) structs, it might be worthwhile to instead wrap individual fields in Cell<T> since each write is a full copy of the struct.


RefCell<T> also provides interior mutability, but isn’t restricted to Copy types.

Instead, it has a runtime cost. RefCell<T> enforces the RWLock pattern at runtime (it’s like a single-threaded mutex), unlike &T/&mut T which do so at compile time. This is done by the borrow() and borrow_mut() functions, which modify an internal reference count and return smart pointers which can be dereferenced immutably and mutably respectively. The refcount is restored when the smart pointers go out of scope. With this system, we can dynamically ensure that there are never any other borrows active when a mutable borrow is active. If the programmer attempts to make such a borrow, the thread will panic.

let x = RefCell::new(vec![1,2,3,4]); { println!("{:?}", *x.borrow()) } { let ref = x.borrow_mut(); ref.push(1); }

Similar to Cell, this is mainly useful for situations where it’s hard or impossible to satisfy the borrow checker. Generally one knows that such mutations won’t happen in a nested form, but it’s good to check.

For large, complicated programs, it becomes useful to put some things in RefCells to make things simpler. For example, a lot of the maps in the ctxt struct in the rust compiler internals are inside this wrapper. These are only modified once (during creation, which is not right after initialization) or a couple of times in well-separated places. However, since this struct is pervasively used everywhere, juggling mutable and immutable pointers would be hard (perhaps impossible) and probably form a soup of &-ptrs which would be hard to extend. On the other hand, the RefCell provides a cheap (not zero-cost) way of safely accessing these. In the future, if someone adds some code that attempts to modify the cell when it’s already borrowed, it will cause a (usually deterministic) panic which can be traced back to the offending borrow.

Similarly, in Servo’s DOM we have a lot of mutation, most of which is local to a DOM type, but some of which crisscrosses the DOM and modifies various things. Using RefCell and Cell to guard all mutation lets us avoid worrying about mutability everywhere, and it simultaneously highlights the places where mutation is actually happening.

Note that RefCell should be avoided if a mostly simple solution is possible with & pointers.


RefCell relaxes the static restrictions preventing aliased mutation, and replaces them with dynamic ones. As such the guarantees have not changed.


RefCell does not allocate, but it contains an additional “borrow state” indicator (one word in size) along with the data.

At runtime each borrow causes a modification/check of the refcount.

Synchronous types

Many of the types above cannot be used in a threadsafe manner. Particularly, Rc<T> and RefCell<T>, which both use non-atomic ref counts, cannot be used this way. This makes them cheaper to use, but one needs thread safe versions of these too. They exist, in the form of Arc<T> and Mutex<T>/RWLock<T>

Note that the non-threadsafe types cannot be sent between threads, and this is checked at compile time. I’ll touch on how this is done in a later blog post.

There are many useful wrappers for concurrent programming in the sync module, but I’m only going to cover the major ones.


Arc<T> is just a version of Rc<T> that uses an atomic reference count (hence, “Arc”). This can be sent freely between threads.

C++’s shared_ptr is similar to Arc, however in C++s case the inner data is always mutable. For semantics similar to that from C++, we should use Arc<Mutex<T>>, Arc<RwLock<T>>, or Arc<UnsafeCell<T>>3 (UnsafeCell<T> is a cell type that can be used to hold any data and has no runtime cost, but accessing it requires unsafe blocks). The last one should only be used if one is certain that the usage won’t cause any memory unsafety. Remember that writing to a struct is not an atomic operation, and many functions like vec.push() can reallocate internally and cause unsafe behavior (so even monotonicity may not be enough to justify UnsafeCell)


Like Rc, this provides the (thread safe) guarantee that the destructor for the internal data will be run when the last Arc goes out of scope (barring any cycles).


This has the added cost of using atomics for changing the refcount (which will happen whenever it is cloned or goes out of scope). When sharing data from an Arc in a single thread, it is preferable to share & pointers whenever possible.

Mutex<T> and RwLock<T>

Mutex<T> and RwLock<T> provide mutual-exclusion via RAII guards. For both of these, the mutex is opaque until one calls lock() on it, at which point the thread will block until a lock can be acquired, and then a guard will be returned. This guard can be used to access the inner data (mutably), and the lock will be released when the guard goes out of scope.

{ let guard = mutex.lock(); // guard dereferences mutably to the inner type *guard += 1; } // lock released when destructor runs

RwLock has the added benefit of being efficient for multiple reads. It is always safe to have multiple readers to shared data as long as there are no writers; and RwLock lets readers acquire a “read lock”. Such locks can be acquired concurrently and are kept track of via a reference count. Writers must obtain a “write lock” which can only be obtained when all readers have gone out of scope.


Both of these provide safe shared mutability across threads, however they are prone to deadlocks. Some level of additional protocol safety can be obtained via the type system. An example of this is rust-sessions, an experimental library which uses session types for protocol safety.


These use internal atomic-like types to maintain the locks, and these are similar pretty costly (they can block all memory reads across processors till they’re done). Waiting on these locks can also be slow when there’s a lot of concurrent access happening.


A common gripe when reading Rust code is with stuff like Rc<RefCell<Vec<T>>> and more complicated compositions of such types.

Usually, it’s a case of composing together the guarantees that one needs, without paying for stuff that is unnecessary.

For example, Rc<RefCell<T>> is one such composition. Rc itself can’t be dereferenced mutably; because Rc provides sharing and shared mutability isn’t good, so we put RefCell inside to get dynamically verified shared mutability. Now we have shared mutable data, but it’s shared in a way that there can only be one mutator (and no readers) or multiple readers.

Now, we can take this a step further, and have Rc<RefCell<Vec<T>>> or Rc<Vec<RefCell<T>>>. These are both shareable, mutable vectors, but they’re not the same.

With the former, the RefCell is wrapping the Vec, so the Vec in its entirety is mutable. At the same time, there can only be one mutable borrow of the whole Vec at a given time. This means that your code cannot simultaneously work on different elements of the vector from different Rc handles. However, we are able to push and pop from the Vec at will. This is similar to an &mut Vec<T> with the borrow checking done at runtime.

With the latter, the borrowing is of individual elements, but the overall vector is immutable. Thus, we can independently borrow separate elements, but we cannot push or pop from the vector. This is similar to an &mut [T]4, but, again, the borrow checking is at runtime.

In concurrent programs, we have a similar situation with Arc<Mutex<T>>, which provides shared mutability and ownership.

When reading code that uses these, go in step by step and look at the guarantees/costs provided.

When choosing a composed type, we must do the reverse; figure out which guarantees we want, and at which point of the composition we need them. For example, if there is a choice between Vec<RefCell<T>> and RefCell<Vec<T>>, we should figure out the tradeoffs as done above and pick one.

Discuss: HN, Reddit

  1. I’m not sure if this is the technical term for them, but I’ll be calling them that throughout this post.

  2. By “stack representation” I mean the data on the stack when a value of this type is held on the stack. For example, a Vec<T> has a stack representation of a pointer and two integers (length, capacity). While there is more data behind the indirection of the pointer, it is not part of the stack-held portion of the Vec. Looking at this a different way, a type is Copy if a memcopy of the data copies all the data owned by it.

  3. Arc<UnsafeCell<T>> actually won’t compile since UnsafeCell<T> isn’t Send or Sync, but we can wrap it in a type and implement Send/Sync for it manually to get Arc<Wrapper<T>> where Wrapper is struct Wrapper<T>(UnsafeCell<T>).

  4. &[T] and &mut [T] are slices; they consist of a pointer and a length and can refer to a portion of a vector or array. &mut [T] can have its elements mutated, however its length cannot be touched.

Categorieën: Mozilla-nl planet

Mozilla Addons Blog: Update on Extension Signing and New Developer Agreement

Mozilla planet - wo, 27/05/2015 - 16:10

If you have an active extension listing on AMO you probably got a message from us already, explaining how we will automatically sign your add-on and provide it to your users via automatic updates. The automatic signing process will run this week, in batches, and we will notify you when your add-on is signed. Please take some time to test the signed version in the current release version of Firefox and either Developer Edition or Nightly (where Firefox already warns about unsigned extensions).

If you’re unfamiliar with extension signing, please read the original announcement for context.

Next week, we will activate two new features on AMO: signing of new add-on versions after they are reviewed, and add-on submission for developers who wish to have their add-ons signed but don’t want them listed on AMO. We will post another update once this happens. When this is done, all extension developers will be able to have their extensions signed, with enough time to update their users before signing becomes a requirement in release versions of Firefox.

New Developer Agreement

Since we will be signing add-ons that won’t be listed on AMO, we have updated the Add-on Distribution Developer Agreement to cover the new ways in which we will handle add-ons. This document hadn’t been touched for years, so we took our time and significantly updated its contents to reflect how we do things now. Hopefully it is also easier to read than its previous version.

Note that the new agreement will go into effect on June 1st. The version that is displayed on AMO when you submit a new add-on will be updated then, and all active developers on AMO will be notified about it.

If you want to stay up to date with changes related to extension signing, you can follow this blog or check in regularly to the wiki page, where I update the timeline information as it becomes clearer.

Categorieën: Mozilla-nl planet

Air Mozilla: Bugzilla Development Meeting

Mozilla planet - wo, 27/05/2015 - 16:00

Bugzilla Development Meeting Help define, plan, design, and implement Bugzilla's future!

Categorieën: Mozilla-nl planet

Gervase Markham: The Jeeves Test

Mozilla planet - wo, 27/05/2015 - 14:56

What is a browser for? What should it do, or not do? What should it be?

People within the Mozilla project have been recently discussing the user value of some new features in Firefox. I think a person’s view of questions of this nature will depend on their view of the role of the browser. One option is the “featureless window on the web” view – the browser is nothing, the site is everything. But as one participant said, this leads to all the value-add and features being provided by the sites, which is not a recipe for user control, or for using the browser to advance the Mozilla mission.

I think the best vision for Firefox is as your “Internet butler” – quiet and refined, highly capable, provides what you need even before you know you need it, who gently guides you out of trouble but generally does his thing without you needing to think about him or provide explicit direction or management.

Bertie using an early voice interface prototype

So I’d like to propose the “Jeeves Test” for evaluating feature proposals for Firefox. It works like this: imagine Bertie Wooster, relaxing in an armchair in his apartment, with a cigarette, a gin and tonic, and a tablet computer. Then take the user value proposition of an idea, write it in appropriately deferential language, and see if you can imagine Jeeves whispering it into his ear. If you can’t, perhaps it’s not something we want to do.

To make that a bit more concrete, here are some examples of things that might pass: “Here’s an English translation of this Serbian page, sir”, or “For your safety, sir, access to this malware page has been blocked”. And here are some which might not: “For your convenience, sir, I’ve exempted from your popup blocker”, or “You’ll be pleased to find, sir, that the user interface has been substantially rearranged”.

There may be occasions where we’d want to do something which doesn’t obviously pass the Jeeves Test, if the effects on the broader web ecosystem of making the change are significantly positive. Some of the things we do to improve web security but which have a short-term compatibility impact might fall into that category. “Let me ensure this site doesn’t load for you, sir” generally doesn’t go down well, after all. But in those cases, that longer-term or broader value has to be clearly articulated – before we make the change – if we are to avoid an exasperated “Dash it, Jeeves… why?” from our userbase.

Categorieën: Mozilla-nl planet

Mozilla Release Management Team: Firefox 38.0.5 rc to rc2

Mozilla planet - wo, 27/05/2015 - 13:54

A small update for next week release. We took a patch to fix a JS top crash and 3 changes to fix an important regression in WebRTC.

  • 6 changesets
  • 10 files changed
  • 85 insertions
  • 35 deletions

ExtensionOccurrences cpp5 xml1 txt1 mn1 html1 h1

ModuleOccurrences js5 mobile1 media1 dom1 config1 browser1

List of changesets:

tbirdbldAutomated checkin: version bump for thunderbird 38.0b6 release. DONTBUILD CLOSED TREE a=release - 7eb2d1522ac2 Margaret LeibovicBug 1166392 - Include about:reader strings on Android. r=mfinkle, a=sledru - a468d1edeac8 Tooru FujisawaBug 1159973 - Abort parsing when TokenStream::SourceCoords hits OOM. r=jorendorff, a=sylvestre - 414d430012ee Paul AdenotBug 1166183 - Back out the direct listener removal landed by mistake in Bug 1141781. r=jesup, a=sledru - 9525d8723413 Paul AdenotBug 1166183 - Work around Bug 934512 in track_peerConnection_replaceTrack.html. r=pehrson, a=sledru - 6ee39f753d19 Andreas PehrsonBug 1166183 - Reset PipelineListener's flag after ReplaceTrack(). r=bwc, a=sledru - 19b9ffda6e2f

Categorieën: Mozilla-nl planet