Google is clearly feeling the crunch from Mozilla moving to Yahoo as the default search provider. I noticed this today on Google (I use Yahoo primarily but do use Google too).

After clicking this it brings up an overlay with instructions specifically for Firefox users and notably I did not get this message in other browsers I tried so clearly this detection code they added is specific to trying to win Firefox users back.

I wish Google instead of trying to fight over search dominance would instead focus on building an awesome open web with Mozilla and others

http://feedproxy.google.com/~r/BenjaminKerensaDotComMozilla/~3/KVFFxWMJAME/google-trying-to-win-firefox-users-back

In this fifth episode, I didn’t work on any bugs. Instead, I did a bunch of code review. Ever wanted to know what a Firefox engineer does to review a patch? If so, then this episode is for you!

Episode Agenda

References:
Bug 1140898 – [e10s] “View” > “Switch Page Direction” doesn’t work in e10s

Bug 1140878 – [e10s] “Switch Page Direction” in remote browser causes unsafe CPOW usage warnings

Bug 1066531 – [e10s] Switching tabs can result in old content being displayed for a split second after the tab bar is updated

http://mikeconley.ca/blog/2015/03/11/the-joy-of-coding-episode-5-much-code-review/

I could apologize for the clickbaity title, but I won’t. I have no shame.

Today I want to talk about some code that we imported from Chromium some time ago: I replaced it in Mozilla’s codebase a while back in bug 1072752:

261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277

    // A WM_* message is available.
    // If a parent child relationship exists between windows across threads
    // then their thread inputs are implicitly attached.
    // This causes the MsgWaitForMultipleObjectsEx API to return indicating
    // that messages are ready for processing (Specifically, mouse messages
    // intended for the child window may appear if the child window has
    // capture).
    // The subsequent PeekMessages call may fail to return any messages thus
    // causing us to enter a tight loop at times.
    // The WaitMessage call below is a workaround to give the child window
    // some time to process its input messages.
    MSG msg = {0};
    DWORD queue_status = GetQueueStatus(QS_MOUSE);
    if (HIWORD(queue_status) & QS_MOUSE &&
        !PeekMessage(&msg, NULL, WM_MOUSEFIRST, WM_MOUSELAST, PM_NOREMOVE)) {
      WaitMessage();
    }

This code is wrong. Very wrong.

http://dblohm7.ca/blog/2015/03/11/waitmessage-considered-harmful/

This week, we merged 35 pull requests

Want to work on the Servo team? We’re hiring a Staff Research Engineer and an Operations engineer!

Notable additions

• Patrick implemented ordered lists, CSS counters, and quotes
• Matt fixed RTL/LTR layout
• M'aty'as Mustoha added support for arc() in canvas
• James Gilbertson implemented the vw, vh, vmin, and vmax CSS units
• Manish added servobuild support for $CARGO_HOME and moved the default cargo cache inside the Servo root. We now do not create any build artefacts outside of the repo clone.

New contributors

• Dan Fox
• M'aty'as Mustoha
• Mikko Perttunen
• Zack Slayton

http://blog.servo.org/2015/03/11/twis-27/

This week, we merged 35 pull requests

Want to work on the Servo team? We’re hiring a Staff Research Engineer and an Operations engineer!

Notable additions

• Patrick implemented ordered lists, CSS counters, and quotes
• Matt fixed RTL/LTR layout
• M'aty'as Mustoha added support for arc() in canvas
• James Gilbertson implemented the vw, vh, vmin, and vmax CSS units
• Manish added servobuild support for $CARGO_HOME and moved the default cargo cache inside the Servo root. We now do not create any build artefacts outside of the repo clone.

New contributors

• Dan Fox
• M'aty'as Mustoha
• Mikko Perttunen
• Zack Slayton

http://blog.servo.org/2016/03/11/twis-27/

Weekly coordination meeting for Firefox Desktop & Android product planning between Marketing/PR, Engineering, Release Scheduling, and Support.

https://air.mozilla.org/product-coordination-meeting-20150311/

Watch mconley livehack on Firefox Desktop bugs!

https://air.mozilla.org/the-joy-of-coding-mconley-livehacks-on-firefox-episode-4-20150311/

TL; DR : I am joining the leadership team of a very cool French startup called Cozy Cloud as Chief Product Officer. My book about online privacy and mass surveillance is almost finalized. The world needs Cloud solutions that enable users to have control over their data.

I’m joining Cozy Cloud as their Chief Product Officer.

It did not take me long to find a new very cool job. Cool, because it’s really aligned with my values. I suspect that most of my English readers haven’t heard about Cozy Cloud, so let me explain. In short, Cozy is a Free Libre Open Source piece of Software that runs on a personal server (such as a Rasbperry PI 2) and its goal is to offer a personal Cloud so that user can enjoy the benefits of the Cloud while retaining control of their data.

My role at Cozy Cloud will be to increase the number of users of the platform, engage with apps developers so that they build apps for the platform and also to find new contributors to the product.

Another cool side of this job is that the team is small, self-motivated and technically amazing. The energy they put into the project made me accept their offer. (They’re also very nice people).

My book (in French) on privacy and mass surveillance is almost done

What does it have to do with my new job? It’s simple: when writing the book, I thought about Information Systems that would Give Back Control to Users (in French, it becomes SIRCUS, which sounds a lot better than in English). Such systems must respect the 7 following principles:

1. Open source software, so that we know what’s running and what’s happening to our data
2. Server control, ideally with self-hosting
3. Encryption, as the network cannot be trusted
4. A sustainable business model (not based on targeted advertising, as it encourages services to profile users and gather as much personal data as possible)
5. Great UX. (Worth repeating)
6. Standards-based and inter-operable
7. Unique value proposal for the user that differentiate the offer from centralized silos.

This one looks like a mystery until you study what Cozy is working on. The fact that users control the server enables completely new ways of using personal data. One can imagine mashing up phone bills details with an address book. Instead of having a long list of numbers called, we would get a list of names. This is just an example, but tons of other use cases can be imagined around electricity bills, bank statements, quantified self data and such…

The world needs cloud services that respect users

It became even more obvious when I was working on my book: centralizing personal data in huge silos in order to generate targeted advertising is not sustainable. As users, we’re trading our invaluable personal data against cheap service (Facebook costs roughly $5 a year per person). On top of that, centralizing data makes mass surveillance economically feasible. And we know how bad this can be.

This does not mean that we should all get rid of cloud services. They’re useful. We just should not have to trade all of our data to enjoy them.

Some perspective

In 2003, 13 years ago, I co-founded Mozilla Europe in order to launch Firefox because it was very clear that the Internet Explorer monopoly was killing the Web.

In 2015, it’s obvious that big proprietary cloud silos are a threat to our personal data and liberties. We need an alternative.

Is it reasonable, with a small startup to decide to challenge the Google, Facebook and other huge services? No it’s not. But it’s tempting and we could succeed. IT’s just like in 2003 when I told people around me that a non-profit with a handful of employees was going after the 95% market share of Internet Explorer by giving away open source software. It worked.

I’m walking in Oscar Wilde’s footstep in this respect:

Wisdom is to have dreams big enough not to lose sight when we pursue them.

http://standblog.org/blog/post/2015/03/11/Why-I-m-joining-Cozy-Cloud-%28hint%3A-personal-cloud-matters%29

On March 11th, 2005, a small group of nerds studying in the overly boring city of Blois, France, decided to buy a domain to play with self hosting DNS and email.

10 years later, linuxwall.info is still (mostly) self-hosted and we are (mostly) nerds. It has been, and still is, a lot of fun and I believe the learning process has to progress two to three times faster than my peers who don't self-host.

(on the left: probably the first server to host linuxwall.info, back in my apartment in Blois)

10 years is probably long enough of an experiment to draw lessons on the state of self-hosting. So let's start with the conclusion: self-hosting is entirely possible, but only if you invest the time and energy to do it right. There is no good way to self-host without spending time on it. Symptoms of poorly done self-hosting include loss of email, website headaches, connectivity issues and angry spouse.

What follows is a rapid overview of what I learned doing self-hosting for a decade, starting with the most frustrating aspect of it...

Don't count on your ISP for help

Over the last 10 years, the people who own the pipes have made absolutely zero effort to facilitate self-hosting. I've hosted linuxwall.info on Free.fr, Neuf/SFR, Comcast and Verizon. The only one who provided me with a static IP was Free.fr. Comcast went as far as blocking tcp/25 inbound without providing a way to disable the blocking. ISPs are completely uncooperative with self-hosters, and for no particular reason other than pushing people toward "business" class of bandwidth (same exact thing, but with a static IP and an extra $100 on your monthly bill).

Uplink is probably what self-hosters fear the most. Will it be enough bandwidth? Will it slow down the Internet for the rest of the house? Here is the truth: you need almost no bandwidth to self-host. For many years, linuxwall.info was hosted with 128kbps of uplink, and it worked fine. The handful of inbound email, http connections, xmpp chats or DNS requests will fit into a tiny percentage of your uplink, and you won't even notice it. Just make sure you don't run offsite backups while your spouse is watching netflix... (or use QoS).

Self-hosters need friends

Don't self-host alone, that won't work. The chances of your internet connection going down are too great. Self-hosting must be done the way the internet was built: if one endpoint goes down, there must be another endpoint that takes over. For DNS, that's easy enough with slaves in multiple locations. For web or email, it's more difficult.

(on the right: the linuxwall.info crew: steph, franck, christophe, myself and jerome, circa 2005)

Hosting email servers is definitely the hardest, because building an IMAP distributed cluster with something like dovecot or cyrus-imap is far from trivial. However, it is fairly easy to build a secondary MX with postfix that buffers inbound emails when the primary is down, and just forwards them to the primary when it comes back online.

That's how linuxwall's MX operates. smtp.linuxwall.info is a primary email server (described here), and if it goes down, smtp2.linuxwall.info will receive the inbound mail, cache it, and forward it to the primary when back online. SMTP2 is really just running Postfix with a very basic transport configuration, so we avoid the madness of synchronizing IMAP datastores across servers.

$ dig +short MX linuxwall.info
20 smtp2.linuxwall.info.
10 smtp.linuxwall.info.

root@smtp2:/etc/postfix # cat transport
linuxwall.info  relay:smtp.linuxwall.info:25

DNS is another one that Nowadays, linuxwall's DNS servers host more than one domain. Besides the main one, there is 1nw.eu, chatonly.org, frimousse-action.com, insecure.ws, lesroutesduchocolat.{fr,com}, tzib.net, necto.org and a few more. The root DNS is hosted in my house, but on a dynamic IP, so it is only used as an authority to the 3 slaves that have static IPs. DNS outages are rare because of the distributed nature of the platform, but it does require that several people participate in the network. Don't self-host alone!

Do hard things and write about it

DNS, Email, XMPP, distributed storage, VPN, public websites, ... The hardest things to self-host are also the most interesting. After many years of internet presence, I have enough public websites to warrant paying for a hosted server at online.net. Most of the critical parts of my infra (email, dns slave, websites) are now hosted on linux containers on that host. For a while though, everything that touched the linuxwall.info domain was hosted on personal ADSL connections (the french equivalent to cable).

Linuxwall.info was created to experiment with all sorts of cool technologies that we simply didn't have access to as students. One of the goal was to write about these technologies, and logically the first site we created was http://wiki.linuxwall.info. Over the years, we've written about dozens of tools, setups, successes and failures and some of these articles have become quite popular:

• Journey to the Center of the Linux Kernel: Traffic Control, Shaping and QoS
• Building and using a PKI (in french)
• Nginx performance tuning
• Local Jabber/XMPP server with ejabberd and Debian
• Effectively fighting spam with DSPAM
• DKIM Signature and verification using DKIMproxy
• Nagios with Nginx on Fedora (or Amazon Linux AMI)
• Mysql 5 clustering (in french)
• Postscreen, l'exterminateur de zombies (in french)
• Necto: full linux stack for self-hosting email
• Soft RAID5 on linux 2.6 (in french)
• and the list goes on and on at http://wiki.linuxwall.info/doku.php/start

As it turns out, most of the tech we experimented with is identical to what is deployed in "professional" environments. Same Apache conf, same postfix, same VPN, same DKIM, same RAID, etc... Sometimes, self-hosting is even more advanced that what you'd find in your typical LAMP stack at work, because the constraints on hosting stuff at home require a good amount of engineering creativity.

Most certainly, self-hosting helped me become a better engineer. It helped me acquire experience much more quickly than if I had waited for exposure at work. It does come with the cost of many and many weekends spent deploying, fixing, upgrading and operating an infrastructure that could just as well been hosted elsewhere. For free. But without the satisfaction or making it all work myself.

Control the traffic

QoS is perhaps the most interesting networking challenge a self-hoster can take upon. I have spent hours tweaking the QoS of my gateway server, and wrote a lengthy analysis of Linux's QoS stack at Journey to the Center of the Linux Kernel: Traffic Control, Shaping and QoS. Studying QoS not only helps understand the details of network protocols, but also made me appreciate minimalistic designs: almost all network services that run on the internet today can be hosted with just a few kilobytes per seconds of bandwidth. The myth of gigabits internet connections for residences is built by ISPs as a marketing tool. Even at pick times, self-hosting at home while doing video-conferences does not make my uplink use more than one megabit of traffic. And I verizon pay for 25 of those!

(on the left: a week of uplink from my house, using up to 720kbps)

I can't remember a time when I filled up an uplink during normal operations. Sure, there are times when a large uplink is pleasant - for example when recovering 20GB of email backups from a friend's server - but 99% of the time a basic QoS policy will ensure that your services have the necessary bandwidth without annoying all the users in the house.

The takeaway

Most people get exhausted of self-hosting after a few years, give up and move everything to "the cloud". We haven't, and it's been 10 years. The secret is to take the time to do things right, and not do it alone.

For sure, there will be times of reading your emails directly from the cache of Postfix, because the IMAP server is down Or times when you arrive at a nice vacation spot only to realize that the IP of your home server has changed, and you can't update the DNS for a week. Those times suck. But they also help you think about reliability and high-availability. Stuff that, once you've acquired the knowledge, people will pay a lot of money for.

tl;dr: self-hosting is awesome. 10 years in and going strong, Linuxwall.info is reading for the next 10!

https://jve.linuxwall.info/blog/index.php?post/2015/03/11/10-years-of-self-hosting-Linuxwall.info

Releng systems are complex, with many moving parts. Making changes to these systems used to be fraught with peril. Even for people who had been working with buildbot for many years, it was hard to write a patch and be certain that wouldn’t break some downstream system.

Last year, releng introduced a suite of unittests for the repository that was the worst offender, buildbot-configs. These tests run under tox. We then took the next logical step, hooking those unittests up to travis. Now every time code lands in buildbot-configs — and more recently in buildbotcustom, mozharness, tools, and more — travis tests get run automatically against the github mirror once the commit is synced from hg.

However, this workflow is still not ideal. These tests only run on code that has already made it into the system. Patch authors needed to setup their own testing environments for working with hg. It would be better if contributors could get feedback *before* submitting a patch for review and without needing to setup the test environment themselves beforehand. If they could run the exact same tests, they could then include links to the test results for their patch along with their review request, making the reviewers job much simpler. Some might simply call this a “modern workflow.”

This modern workflow doesn’t exist with hg (we never wrote it), but we get it almost by accident if we switch to using github for development.

Today, if a user forks the buildbot-configs repo (or any of the other repos set up with travis) and has enabled travis testing on the fork, they get the same tests run against their fork automatically when they commit. This will be a boon for releng in terms of increasing the velocity of testing and reviewing patches. It also makes it dead-simple for people *outside* of releng (sheriffs, a-team, …) to contribute solid patches.

We are not setup for pull requests yet, but releng *is* planning to switch our repositories-of-record (RoRs) from hg to github. On the list of things we still need to figure out is how release tagging would work when github is our new RoR. We are also in the midst of adding even more useful informational output to travis, namely diffs of builder lists and master configurations caused by a given commit. This is one of those key elements we look at when evaluating the fitness of a particular patch.

If you’ve been holding off on getting your hands dirty with releng automation, there’s no better time. Get forking!

http://coop.deadsquid.com/2015/03/better-releng-patch-contribution-workflow/

This week I started on the generic worker. Work under development here:

https://github.com/petemoore/generic-worker

So far, I’m able to publish tasks to the queue with a fake provisionerId, and then the generic worker can discover the task, and claim it. It is not yet running any tasks, so there is still some way to go.

It can currently handle the prioritisation workflow, and detect numerous failure conditions. It also receives all the task data in a structured format which it unmarshals into go types as a starting point for running a task.

First pass will assume good behaviour from a task, that it writes files only under a specified filepath top-level work directory. The worker will take care of cleaning up this directory path, and terminating processes.

http://petemoore.tumblr.com/post/113342091558

Mozilla is many things, best defined as a global, non-profit organization dedicated to advancing opportunity and innovation on the internet. But we’re also known as a browser vendor and browser vendors are often perceived by the ad tech community only as inconveniences.  As Gregory Cristal puts it in his book Ad Serving Technology, “The browser remains an unknowable force working by its own rules which the whole industry has learned to adapt to over time.”

In my experience, ad tech doesn’t often celebrate the rapid pace of development in the browser space – something that Mozilla kick-started with Firefox in 2004, by the way. Competition among browsers has lead to advances in the Web that are easily overlooked: advances in performance, in interactive content, in graphics and audio, not to mention in user interface design all of which have grown the digital market.  But for all this common interest, browser vendors and ad tech companies have historically had little collaboration.

We want to change that.

Last month I had the pleasure of attending the Interactive Advertising Bureau’s Annual Leadership Meeting and just last week Denelle, our SVP of Business and Legal Affairs, took the stage with IAB CEO Randall Rothenberg at the IAB’s event at Mobile World Congress.  When I think about some of the biggest issues facing the ad tech industry that came up in these discussions, questions such as the fight against fraud, viewability, the challenge of mobile and of the appropriate use of data, I feel that the Mozilla project is very well placed to make a positive contribution.

Mozilla’s interest in the Web economy is fundamental to what we do.  The Web is free to implement, free to publish on, is cross platform and offers opportunities for many.  No other medium shares these properties.  As Mitchell puts it, “The World Wide Web is the greatest tool for knowledge sharing and collaboration we have ever seen”.   That’s why Mozilla invests in developing open standards, in fighting censorship, and in advancing the Web on mobile devices, and it’s why we are now becoming actively involved in the digital ad space.  Advertising, after all, is the principal way that this great resource is funded.

Although the Web has gone from a novelty to something we cannot imagine our lives without in under two decades (at least, for those of us who can remember a world before the Web!), we should never take it for granted.  Standards, the platforms and formats that govern large parts of the internet economy, are forming very quickly – so quickly that we might not even think of these things as standards.  These “de facto” standards make their owners very rich and create empires.  20 years ago, Microsoft was that empire.  If you wanted to make application software, it had to run on Windows, because that was where the users were.  And if you wanted to buy a computer that had applications available, you had to buy a Windows PC.  Today, similar power rests with Apple and Google.  These companies have created huge markets and delivered great innovations, but they also exercise huge levels of control.

But the Web is not centrally planned, it has grown organically.  It has very low barriers to entry and light regulation which is a perfect formula for innovation.  

Publishing, letting your audience find you and monetizing that audience through advertising has become the dominant way of publishing online.  We’ve become so used to this model that professional online media is almost entirely dependent on advertising.  We exchange our attention and some information about ourselves for access to content.  But fast-moving, unregulated markets often create externalities, costs we all bear, and having spent my career in digital, I can certainly name a lot of them!  Page design can suffer because of adverts, editorial policy may skew to deliver impressions.  Fraud is rife in online advertising.  And advertising has created a huge secondary market in data about users, often without anyone’s explicit consent.

It’s this market for data that is probably most concerning about our industry today.  As Denelle commented last year, trust should be the currency.  This should be a transparent value exchange.  Users should understand how their data is being used, and have control over that usage and understand what they are getting in exchange for it.  This is all too often not the case.

Browser vendors, browser extension makers and privacy activists have responded to the needs of users by delivering many different approaches to protecting their privacy on the Web.  The W3C first recommended P3P back in 2002, and since then we’ve seen ad blocking browser extensions, tracking protection lists, vigorous debate about third party cookies, and the FTC backing for a Do Not Track (DNT) system.  Mozilla was a major contributor to the DNT mechanism, hoping it would give the ad industry a way to understand and honor a consumer’s choice.  Sadly, we’ve yet to see great uptake across publishers.  We will continue to work in this space, finding ways for consumers to express and to enforce their right to privacy online.

Our commitment to protect users and their data, and deliver them ways to opt out of experiences they do not desire will never waver.  As important as such tools are, we cannot expect to incentivize the ad tech industry solely by being, as Gregory Cristal puts it, an “unknowable force”.  There are parts of the industry which are investing in such harmful measures as canvas fingerprinting or super-cookies. We have to offer better alternatives, and set better standards.

And so when I hear privacy advocates saying that it is the role of the browser to deliver tools for the user to protect their privacy, I agree.  And when I hear Randall Rothenberg saying that browser vendors have a responsibility to our culture and to our economy, I agree.  I do not believe that these aims are in direct conflict.  We need advertising experiences that work for advertisers and publishers, but that also respect the wishes – the agency – of the user.  The user needs to be at the center of the experience, and their desires must be respected in the value exchange.

Facilitating this discussion and bridging the gap between these two groups is a job for Mozilla because this is what we do. We fight for the Web and deliver users sovereignty over their experience.  We’ve proven our ability to move markets in helping the open Web break out from the Windows desktop. We’ve implemented and standardized countless Web technologies. We’ve advocated for open Web video codecs while helping groups move away from less secure, closed technologies such as Flash.  And we create impact for our partners, such as our recent deal with Yahoo! that’s creating the first real movement in the US search market share in years.

I believe the future for digital advertising is fascinating.  The first dot-com boom delivered access to millions of consumers through eCommerce, generating huge advances in making signals of supply and demand more efficient.  “Web 2.0” gave us participation online, as individuals put our creative works online, we connected with each other.  The move to mobile has seen this participation commercialised, as mobile services created micro-producers in a variety of industries.

What’s next?  A glance at what the big internet companies are doing all points to a certain direction: Apple’s Siri, Google Now and Amazon’s Echo point to a future where direct response advertising will be more contextual and directed by the user’s control.  A future that is described by some as “intent casting”, where the user is in control of the demand signal they generate.

But the big question is this: will that future be mediated by the vertical integration of Apple or Microsoft, the horizontal ubiquity of Google and Amazon, or the open market of the Web?  Will it be an open market, or a walled garden?  The Mozilla project is at its best when we create products that embody our values and can bring partners into our community.  And we have to do just that in this space: monetization and advertising on the Web must evolve to respect the user.

https://blog.mozilla.org/advancingcontent/2015/03/10/mozillas-mission-in-the-context-of-digital-advertising/

This post is intended to frame the business context that MDN operates in. This is not a product strategy. It is the second in a series of posts begun here.

One of the questions I asked in my introductory post was, “What does solving problems for MDN’s audience accomplish for Mozilla?”. In other words, what opportunities make this investment worthwhile?

It’s not always comfortable to ask such questions, but they’re important. We operate within constraints; everything we do has an opportunity cost. Why MDN? I’m glad to say it is easy to answer.

MDN is a public service sponsored by Mozilla, a mission-driven nonprofit. Mozilla does not measure success by revenue, we measure success by our global impact. Products at Mozilla are expected to deliver impact on Mozilla’s mission and support at least one of Mozilla’s main product lines.

Mission Impact

Mozilla’s mission is to build the internet as a global public resource open and accessible to all. Web developers are critical to the mission. They choose the platforms and technologies they use to build products:

• Deploying to the web is a developer choice.
• Using open web standards is a developer choice.
• Building content that works across a multitude of devices is a developer choice.
• Making content accessible to a broad, global audience is a developer choice.

The success of Mozilla’s mission depends on these developer choices. Developers make choices pragmatically — they choose the possible. MDN makes building open and accessible on the web more possible. MDN empowers all developers to make choices aligned with Mozilla’s mission and thereby create the web the world needs.

How do we measure this impact? Look to future posts for more discussion of this.

Top-line Organizational & Product Support

MDN supports Mozilla’s top-line goal to create meaningful relationships with Mozilla product users worldwide. MDN’s current audience contributes approximately 1-2% toward Mozilla’s overall relationship goals; this number is naturally limited by the size of MDN’s market.

MDN is naturally aligned with Mozilla Learning. Mozilla’s learning products build contributors to the web. MDN empowers expert and professional web makers and is uniquely positioned to address those who aspire to be expert or professional web developers. MDN’s alignment with Mozilla’s learning initiatives is obvious, but only recently intentional; in 2015 we will experiment to learn more about how to directly support Mozilla Learning.

Market

In 2015 MDN will focus on three segments — two of them new.

MDN historically has served web developers who want to build standards-based web sites. After a decade of providing high-quality information about web technologies on its documentation wiki, MDN is considered an authority among these developers. (For instance: Instructors at several “web developer bootcamps” in my town tell me they actively guide students toward MDN, away from MDN’s competitors, because they only trust MDN.) MDN serves more of these developers every month and now serves 25-50% of the global market. These developers are MDN’s core users and the choices they make directly impact Mozilla’s mission.

MDN’s authority, expertise and capabilities position it uniquely to serve web learners who aspire to be web developers. The job market for developers is strong and growing. The number of jobs in both web development and software development is expected to grow by 20% or more in the U.S. by 2020. Global growth is expected to follow a similar trend. MDN can match these new web developers with product features that will help them become web developers building standards-based web sites.

MDN’s authority, scale and unique content position it to serve professional web developers who want to build standards-based web sites professionally. Recent surveys indicate that more than half of MDN’s visitors meet that description. A large number of these professionals say they are motivated to build web products that embody Mozilla values like accessibility, compatibility, and security, but are under-served by tools to make doing so feasible. MDN can build new products and features to fill the gap, increasing these professionals’ ability to build standards-based web sites on deadline.

2015 Goals

Considering those opportunities, in 2015 the MDN team has committed to…

1. “Relationships”: Support Mozilla’s overall goals by continuing the (double digit per year) organic growth of our original segment, web developers who want to build standards-based web sites.
2. “Teaching”: Support Mozilla’s learning initiatives by exploring and implementing new capabilities that will serve a new market and segment, web learners who aspire to be web developers.
3. “Services”: Add a new product, “Services” to serve a new segment, professional web developers who want to build standards-based web sites professionally.

KPIs for these live on the Mozilla wiki with other information about the MDN team’s overall vision, mission and objectives.

Summary

Can you put a TL;DR at the bottom of a post? Let’s find out. After this post and yesterday’s, we can now say…

MDN is a product ecosystem that serves an audience whose choices are critical to the success of Mozilla’s mission. MDN serves them at a scale unique within Mozilla and in the market. In 2015 MDN will continue growing its original segment while building prototypes and experiments to help expand MDN and Mozilla into two new and influential segments.

Next: Products! Stay tuned…

http://hoosteeno.com/2015/03/10/mdn-product-talk-business-context/

I've had some feature requests from subscribers to my premium support package, so everyone will see the benefits in the next release.

The first request was to be able to add a lightweight theme via the CCK2. That ability will be in the next CCK2. You simply give the CCK2 the URL for a theme on AMO and the CCK2 will do the rest.

The second request was for the ability to set the user value of preference versus the default value or locking the preference (the pref() function in Autoconfig). I've added that functionality.

The third request was for better support for software security devices on multiple platforms. I've updated the code so it checks to see if the device is there before trying to add it allowing you to mix multiple platform paths. In addition, I try to add the device at every startup so that if the device is added after the CCK2 is installed, it will still get added to Firefox.

Do you wish that the CCK2 has a feature? Purchasing a support package can make it happen.

Membership has its privileges.

https://mike.kaply.com/2015/03/10/cck2-new-features/

In this beta release, we are coming back to lower volumes in term of number of patches. We landed some more EME patches (but this will stop with this release as decided to stop testing EME in 37). We've also fixed an important issue with Win64 builds.

• 57 changesets
• 92 files changed
• 1132 insertions
• 629 deletions

List of changesets:

http://release.mozilla.org/statistics/37/2015/03/10/fx-37-b3-to-b4.html

Even if it is busy dot release, we are not fixing top critical issues. We mainly fixed some various issues found during the first week of the 36 release.

• 14 changesets
• 27 files changed
• 555 insertions
• 58 deletions

List of changesets:

http://release.mozilla.org/statistics/36/2015/03/10/fx-36-to-36.0.1.html

I was reading Tantek's blog post about Simplifying Standards & Reducing Their Security Surface: Towards A Minimum Viable Web Platform. He mentionned:

While self-reviews are a good start, and will hopefully catch (or indicate the unsureness about) some security and/or privacy issues, I do still think we need a security group, made up of those more experienced in web security and privacy concerns, to review all specifications before they advance to being standards.

I was about to send an email to tantek about it. But then I remembered that if it fits in an email, it's probably worth a blog post with a permanent URI and something people can link to in the future.

Reviews are a difficult exercise. When I was working at W3C, I spent nearly 5 years reviewing every single specification coming out of the press for quality issues. First when we were working on creating Quality Guidelines for Specification editors and then on trying to apply these guidelines. The Quality Assurance Working Group ended up creating the QA Framework: Specification Guidelines. The thing I really like about this document is its format, which is basically for each requirement/good practice.

1. Requirement/Good Practice (concise and imperative sentence)
2. What does it mean? (explain the topic in simple words)
3. Why care? (explain why it's important)
4. Related (give additional resources about the topic)
5. Techniques (give a practical step by step how-to for meeting the requirement)
6. Examples (extract some real examples already published here and there)

This makes the document a very easy piece to cite and cherry pick at will. It's also more interesting to read. I can say that our first version of the QA Framework was really not digestible.

Back to the security review. In the Specification Guidelines, we mentionned

In addition to conformance, there are several other topics that should be addressed when writing a specification, such as accessibility, internationalization, security, and device independence. These topics are not directly in the scope of this document, but are evoked in section 3.3

And then in section 3.3:

First and foremost, W3C specifications need to frame and define technologies that meet the requirements of the particular deliverable, fulfill the charter of the Working Group, and advance W3C's mission to extend the exchange of information through the Web to everyone. Thus, accessibility, internationalization and device independence are general requirements that must be considered in the specification of all Web technologies. (Specification developers should consult the technical reports index for an up-to-date profile of W3C publications in all areas.)

[…]

A Working Group should designate participants to monitor the application of accessibility, internationalization and device independence to their specifications at the earliest point possible. These participants can be the points of contact with the relevant W3C Activities and can seek feedback on their group's adopted solutions.

A good start for the security questions you may want to ask yourself have been published by Mike West. To note that security and privacy are very hard topics because there are strongly tied to contexts and cultural expectations. There are things which seem obvious in a context but put in another context doesn't make sense. Tantek is reaching a point where he says:

Every specification should seek to be as small as possible, even if only for the reasons of reducing and minimizing security/privacy attack surface(s).

Yes and not only for the attack surface but the ability to review and implement itself the specification. Reviewing a giant specification is a daunting task. Been there, done that. Things we can see, hold in your hand, manipulate, break down and put together again are more likely to reveal themselves than a huge pile of characters that you need to read making a graph on the side. I have also the impression that we make security a bigger issue than it should be because of the way we are engineering interactions, services and protocols. If we create giant Web services with single point of communications, we create by design a giant security issue. We give the possibility for example to a company or an organization to monitor all communications. If we design things in a more decentralized way then we greatly reduce the threat and the security still an important topic has less consequences. Or if you prefer, we do not need the same security level for a house and a bank.

Anyway interesting discussions going on about security and reviews.

PS: Oh yes! Completely unrelated, I quit twitter. Yes. 410 Gone. The account has been totally erased.

Otsukare!

http://www.otsukare.info/2015/03/10/security-spec-review

Recently I had the honor of speaking at Mobile Learning Week in Paris, co-hosted by UNESCO and UN Women. The two agencies interwove their agendas to focus on empowering women through mobile learning. It’s a strategic and necessary combo.

I shared a panel with Shelly Esque (Intel), Adele Vrana (Wikimedia), Ingrid Brudvig (World Wide Web Foundation), and Doreen Bogdan (ITU), which was impeccably moderated by Valerie Hannon (Innovation Unit UK).

Here’s a summary of my remarks as well as thoughts from the discussion.

The reason I’m here today is thanks to my mother—and Wikipedia. After some convincing, my mother agreed to join me on the train to the first Wikimania, held in Frankfurt, Germany.

I’d been enraptured by the Wikipedia project. And when I learned that Wikipedians were meeting each other for the first time just an hour away from our home, I had to go.

We spent the day talking with wonderful people. We listened to educational activists from Sub-Saharan Africa and had lunch with Serbian mathematicians. These volunteer Wikipedians were translating untold numbers of articles about math into Serbian. How incredible!

What struck me about the Wikipedians was that each worked in a small part on the project. In their language, in their subject. But together, they were creating something great.

They had a North Star to guide them. The Wikipedians knew there was a greater goal and that gave their individual contributions a direction.

Today, we are at a crossroads.

Billions of people are coming online for the first time. Thanks to low-cost phones, many are gaining access to technology that they never had before.

We know that technology is power. And knowledge is power.

With this new wave of technology, we can repeat the power structures of the past. Or we can change them.

Let’s ask ourselves: what is our North Star?

We represent many countries, many interests. But we’re here today galvanized around shared issues.

I’d like to propose that our North Star is not just equitable access, but access to knowledge. And that knowledge is understood as a literacy — web literacy.

Let’s create a web literate planet.

Literacy has been proven to combat all sorts of inequality: social, economic, political.

To overcome gender inequality, women must fully participate online–in their own language, in their own time, and in their own voice.

This requires knowing how to read, write and participate on the web.

Millions of people think that Facebook is the internet. It is not. We must show the possibilities of an open internet, and impart the skills that lead to empowerment online, beyond the walls of any particular corporation. We have to teach the web.

Importantly, it is not just about what we teach, but how.

The classroom is a microcosm of a society’s power structures. Traditionally, teachers see their students as containers, receptacles of knowledge that the teachers, as experts, must fill.

Instead, teachers should be facilitators. They should help their learners find agency and be empowered. Teachers are there to help their learners take ownership of their own learning.

In this way, we can challenge traditional power structures. Learners must have agency and ownership of their learning. This goes for women as much as for men.

At Mozilla, through our low-cost and open source phones, we’re reducing the barrier to access. Through our teaching and learning campaigns, we mobilize communities in 86 countries to teach web literacy to 130,000 learners. And now we are working to sustain those efforts through local groups meeting and teaching regularly.

But these are small, humble contributions.

We, like all of you here, dream big. We see all of our efforts amplifying each other, guided by a North Star.

Together, we can do it. We can create a web literate planet.

Huge thanks to Jennifer Breslin and Mark West for inviting us and to Anar Simpson helping make the connection!

Images: “Inside the LAN House” by Laura de Reynal available under a Creative Commons BY-NC 2.0 license.. “Now at #mlw2015'' by Ben Moskowitz used with permission. Mobile Learning Week Infographic by UNESCO The Equitable Access Panel by Anar Simpson.

http://michellethorne.cc/2015/03/empowering-women-through-equitable-access-and-web-literacy/

On the occasion of International Women's Day, the WoMoz (Women in Mozilla) community from Pune had decided to celebrate Womanhood and technology by paying tribute to to all the women, who are working towards making a difference in the world of Open Source technology.

As per our planning, we, the organizers did gather at Symbiosis Institute of Computer Studies and Research by 9.30am. It took us less than 20 minutes to arrange the room and put up a few posters around the campus, which could give our participants, the feel of event. The event was scheduled to begin at 10am. While planning the event, we had made a few mistakes (which I have listed at the end of the post) due to which we had a really low crowd turnout. After an hour of waiting, when we were almost about to call the event off and re-schedule it, did we have our guest speaker, Manjusha Joshi walk in. It was she who motivated us to continue with the event, even if we had way less number of participants than expected.

We began with the event an hour late. There are a few events, which often make us realize the fact that number is probably a wrong metric to measure the success of an event. Quality of audience is way more important. And this one was one such rare events. Though we had just 20 people in the room, those 20 people were probably there, cause they all genuinely wanted to take something back home from the session.

We restructured the entire schedule. [The initial event schedule can be found at http://wiki.mozillaindia.org/Celebrating_womanhood_and_technology]. We decided to have only the most important sessions. Diwanshi thus began the day, introducing Mozilla. Following her introduction, we invited Manjusha mam to share her Open Source journey with us. Her story was indeed inspiring. A married woman, belonging to a traditional Indian family, could manage to achieve so much in life, fighting challenges with way less resources than what we are blessed with these days. I salute her for being an icon for all of us!

After her session, I went to the podium, to take a session on Imposter Syndrome. I guess its irony in itself that the speaker of a topic like that, herself suffers from Imposter Symdrome. Thanks to Sumana for being an awesome speaker on this topic at AdaCamp, due to which, I was not only aware of the topic, but also able to share my knowledge, further with others.

After my session, Suchita also took a quick session, introducing a few initiatives by her college clubs, before Diwanshi ended the day with a session on Privacy and security.

Though I have been a co-organizer for this event, I couldn't give the event sufficient time, due a lot of personal work I was stuck with. But, I have learnt a few very important lessons from the event:

[1] Organizing an event on a Sunday is a bad idea. Its tough to get people out of their Sunday mood and get them to do anything constructive.

[2] A lot of research needs to be done before finalizing the dates of any event. Mainly an event targeted at college student needs to be planned carefully, keeping their exam schedules etc in mind. If we are celebrating some national or international days, where ofcourse the dates can't be changed, its probably better to plan it differently.

[3] Event promotion is a big responsibility and ownership needs to be taken for this.

[4] Every event, no matter how small, should follow a RASCI model. This helps every stakeholder be very clear about their responsibilities, so as to have a smooth execution of the event.
   

Yes, we also had cake!

http://priyankaivy.blogspot.com/2015/03/a-well-spent-womens-day.html

• [1138541] Updating lists on Gear Request form
• [1137368] Allow the bug’s assignee to edit attachment fields, even if they do not have editbugs
• [1102428] Custom field for MozReview link, with dynamic info
• [1139939] “BadResponse: ‘Location’ header missing from 201 Created response” when commenting with bztools
• [1140203] Component name adjustment ‘Marketplace:Pre-Installed Apps’
• [1140966] allow cookie+api-token GET REST requests
• [1140458] Allow API authentication with X-Headers
• [1140234] extend review/flag_activity to allow filtering by status and bug_id
• [1140798] Possible client side code injection in “suggested reviewers” menu.
• [1140049] Add a note about MozReview to the Create Attachment page
• [1140215] 3rd Party Applications Issue Form
• [1137080] add an indicator to the user profile page if the user has canconfirm or editbugs rights
• [1003701] add the ability for users to prevent review/feedback/needinfo requests
• [1139749] Bugzilla shouldn’t try to write API tokens into the shadow DB
• [1139872] The URL in bugmail microdata has the ‘#’ URI encoded, causing the links to break

bugzilla now shows the status of mozreview hosted reviews:

it’s now possible to prevent review, feedback, and needinfo requests:

discuss these changes on mozilla.tools.bmo.

https://globau.wordpress.com/2015/03/10/happy-bmo-push-day-130/