August 01, 2015

The next TenFourFox beta is now available (downloads, release notes, hashes). Officially, the version number is 38.1.1b2 due to the revbump on that ESR branch.

The most important bug this fixes is, of course, our new IonPower JavaScript JIT compiler backend wreaking havoc with Faceblech and Farceboink-derived sites such as Instacrap. Near as I am able to determine, as a conscientious objector to the Zuckerbrat Amalgamated Evil Empire, this fixes all outstanding issues with these sites. Oddly, the edge case responsible for this was not detected by Mozilla's JIT tests, which is probably why most sites were unaffected; the actual problem was diagnosed only by a couple of weird failures while running the strict ECMA conformance suite. Also, as mentioned, the engine has been tuned a bit more for improved overall throughput, and is approximately 4-5% faster than beta 1.

Some of you complained of a quit bug where memory usage would skyrocket while exiting the browser, causing it to crash after exhausting its addressing space instead. I cannot confirm this specific manifestation on any of my test systems. However, I did find another bug in the webfont cache that may be possibly related: if you close a window with webfonts loaded in it that are slated for cleanup, the browser can get stuck in an infinite call loop while freeing those resources, which will exhaust the processor stack. This issue is specific to our Apple Type Services font code. On TenFourFox the stack allocation is an entire gigabyte in size because of ABI stack frame requirements, so completely using it up may well freak out systems with less memory (all of my test machines have at least 1.25GB of RAM). In any case, that bug is fixed. Hopefully that's actually what you're seeing, because I still can't reproduce any problems with exiting.

A Leopard-only crash observed on the New York Times is now fixed by implementing a formal webfont URL blocklist; Tiger users don't crash, but get various weird and annoying font errors. This is caused by yet another underlying ATS bug. Safari on 10.5 is subject to this also, but it (and Leopard WebKit) get around the problem by turning the ATSFontRef into a CGFontRef and seeing if it validates that way (see issue 261). This is clearly a much better general solution, but while these functions exist as undocumented entry points on 10.4 they all call into ATS, so 10.4 users still get the weird messages. The only way to solve this fully on both operating systems is to just block the font entirely. Previously we did this by blocking on the PostScript name, but the New York Times, because it is old and senile, uses webfonts with the supremely unhelpful PostScript name of - and blocking that blocked everything. Fortunately, various reorganizations of the Gecko font system make it easy to wedge in a URL blocker that looks at the source URL and, if it is a known bad font, tells Gecko the font is not supported. The font never loads, Gecko selects the fallback, and the problem is solved. This problem also affects 31.8, but the solution is much different for that older codebase and there won't be another 31 anyway.

In the non-showstopper category, the issues with saved passwords not appearing in preferences and checkmarks not appearing on context or pull-down menus are both corrected. In addition, I reduced window and tab undo limits to hold onto less memory (back to what they were in 31), forced tenured objects to be finalized on the foreground thread to get around various SMP problems (again, as in 31 and in 17 and previous), tweaked media buffering a bit more, fixed a nasty assertion in private browsing mode with saved logins, and turned on colour management for all the things as politely requested by Dan DeVoto. The blank saved passwords list is actually due to the fact we can't yet compile ICU internationalization support into XUL because of issue 266, which also appears to be why Zotero started failing, since it also depends on it. For 38.2 final, both of these issues are worked around using trivial stubs and some minor code changes. Hopefully we can get it to make a shared dylib for a future release of 38.x and remove these hacks.

There are two changes left for final: put the update interval back to every 24 hours, and possibly remove the Marketplace icon from the Start page since we don't really support the webapp runtime. (The Apps option was already removed from the drop-down menus.) No one has complained about the faster/lower quality downscaler, so that will remain as is; about the only place it annoys me personally is favicons. Full MP3 support is being deferred to a feature beta after 38.2.

Builders will want the new versions of strip7 and gdb7. In fact, you'll need the new strip7 to build 38.1.1, because it fixes a crash with setting section flags. Although the gdb7 update to patchlevel 3 is optional, it is much faster than patchlevel 2, and will cause you to go less crazy single-stepping through code. Now that all the known build problems are dealt with, I am hopeful our builder in the land of the Rising Sun can make the jump to Tenfourbird 38 along with us.

Finally, many thanks to our localizers; the current list is English (natch), Spanish, French, Italian, Russian, German, Finnish and now Swedish. We still might need some help with Polish, and I cannot find an old copy of the Japanese language pack, so it is possible that localization will have to be dropped. Please help us with Polish, Japanese, or your own language if you can! Localizations must be complete by midnight August 5 so that I have enough time to upload and write the new page copy ahead of the formal general release of 38.2 on the evening of August 10. See issue 42 if you'd like to assist.

Once 38 launches, we will transition from Google Code to Github (leaving downloads on SourceForge). All of our project activity on Google Code will be frozen on August 5 after the last localization is uploaded. More about that shortly.

by OleksandrGet international weather forecasts from AccuWeather.com and display them in any toolbar or statusbar with this highly customizable and unobtrusive extension.

“After trying the other weather add-ons when this one went obsolete, I give them up, they were simply inadequate. This was the only add-on that we need in a browser. THANK-YOU for bringing it back it is the only one to have PERIOD…..”

Nominate your favorite add-ons

Featured add-ons are selected by a community board made up of add-on developers, users, and fans. Board members change every six months, so there’s always an opportunity to participate. Stayed tuned to this blog for the next call for applications.

If you’d like to nominate an add-on for featuring, please send it to amo-featured@mozilla.org for the board’s consideration. We welcome you to submit your own add-on!

July 31, 2015

Welcome back to the weekly releng Friday update! Here’s what we’ve been up to this week.

Modernize infrastructure: Rob checked in code to integrate Windows with our AWS cloud-tools software so that we now have userdata for deploying spot instances (https://bugzil/la/1166448) as well as creating the golden AMI for those instances.

Mark checked in code to update our puppet-managed Windows machines with a newer version of mecurial, working around some installation oddities (https://bugzil.li/1170588).

Now that Windows 10 has been officially released, Q can more easily tackle the GPOs that configure our test machines, verifying which don’t need changes, and which will need an overhaul (https://bugzil.la/1185844). Callek is working to get buildbot setup on Windows 10 so we can start figuring out which suites are failing and engage developers for help.

Improve CI pipeline: With the last security blockers resolved and a few weeks of testing under his belt, Rail is planning to enable Funsize on mozilla-central next Tuesday (https://bugzil.la/1173452)

Release: Uplift starts next week, followed by the official go-to-build for Firefox 40. Beta 9 is out now.

Operational: Buildduty contractors started this week! Alin (aselagea) and Vlad (vladC) from Softvision are helping releng with buildduty tasks. Kim and Coop are trying to get them up-to-speed as quickly as possible. They’re finding lots of undocumented assumptions built into our existing release engineering documentation.

Dustin has migrated our celery backend for relengapi to mysql since we were seeing reliability issues on the rabbit cluster we had been using (https://bugzil.la/1185507).

Amy has finished replacing the two DeployStudio servers with newer hardware, OS, and deployment software, and we are now performing local Timemachine backups of the their data (https://bugzil.la/1186197). Offsite backups will follow once Bacula releases a new version of their software that correctly supports TLS 1.2.

The new Windows machines we setup last week are now in production, increasing capacity by 10 machines each in the Windows XP, Windows 7, and Windows 8 test pools (https://bugzil.la/1151591).

Lately I've been involved in discussions in the W3C's Web Payments Interest
Group about chartering a new working group to work on payment APIs
for the Web. I certainly don't have the resources to implement this
work in Firefox by myself, but I'm hoping to at least help the
standardization activity get started in an effective way, and, if it
does, to help others from Mozilla get involved.

From a high-level perspective, I'd like to see the working group
produce a technology that allows payments in the browser, involving some
trusted UI in the browser (like for in-app payments on mobile operating
systems) that says what payment is going to happen, and involving tokenization
in the browser or on a server or application with which the browser
communicates, with only the tokens being sent from the browser to
the website.

I think this has two big benefits. First, it improves security
by avoiding sending the user's credit card details to every site that
the user wants to pay. It sends tokens that contain the information
needed to make a single payment of a particular amount, instead of
information that can be reused to make additional payments in the
future. This makes payments on the Web more secure.

Second, if we can design the user interface in a way that users
understand these improvements in security, we can hopefully make users
more comfortable making small payments on the Web, in some cases to
parties that they don't know very well. This could make business models
other than advertizing more realistic for some providers of Web content
or applications.

There are certainly risks here. One is that the effort might fail,
as other efforts to do payments have failed in the past. There are also
others, some of which I want to discuss in a future blog post.

Last Monday’s SUMO Community meeting

Reminder: the next SUMO Community meeting…

If you want to add a discussion topic to upcoming the live meeting agenda:

Start a thread in the Community Forums, so that everyone in the community can see what will be discussed and voice their opinion here before Monday (this will make it easier to have an efficient meeting).

Please do so as soon as you can before the meeting, so that people have time to read, think, and reply (and also add it to the agenda).

Firefox

The only plugin Win64 Firefox 40 will support is the 64-bit Flash Player.

More 64-bit plugin support will come in future releases.

Thunderbird

One final reminder: as of July 1st, Thunderbird is 100% Community powered and owned! You can still +needinfo Roland in Bugzilla or email him if you need his help as a consultant. He will also hang around in #tb-support-crew.

It has been a month since I started my Mozilla internship in San Francisco, but it feels like I had just started yesterday. I have been interning with the Automation and Tools team this summer and it has been a wonderful experience. As an intern in Mozilla, one gets goodies, new laptop, free food, and there are various intern events in which one gets to take part in. My mentor @chmanchester also gave me the freedom to decide what I wanted to work on which is quite unlike some other companies.

I chose to work on tools to improve developer productivity and making libraries that I have worked on in the past, more relevant. In the past month, I have been working on getting various triggering options inside Treeherder, which is a reporting dashboard for checkins to Mozilla projects. This involved writing AngularJS code for the front-end UI and python code for the backend. The process involved publishing the “triggering actions” to pulse, listening to those actions and then use the mozci library on the backend to trigger jobs. Currently if developers, particularly the sheriffs, want to trigger a lot of jobs, they have to do it via command line, and it involves context switching plus typing out the syntax. To improve that, this week we have deployed three new options in Treeherder that will hopefully save time and make the process easier. They are:

* Trigger_Missing_Jobs: This button is to ensure that there is one job for every build in a push. The problem is that on integration branches we coalesce jobs to minimize load during peak hours, but many times there is a regression and sheriffs need to trigger all jobs for the push. That is when this button will come in handy, and one will be able to trigger jobs easily.

* Trigger_All_Talos_Jobs: As the name suggests, this button is to trigger all the talos jobs on a particular push. Being a perf sheriff, I need to trigger all talos jobs a certain number of times for a regressing push to get more data, and this button will aid me and others in doing that.

* Backfill_Job: This button is to trigger a particular type of job till the last known push on which that job was run. Due to coalescing certain jobs are not run on a series of pushes, and when an intermittent or bustage is detected, sheriffs need to find the root cause and thus manually trigger those jobs for the pushes. This button should aid them in narrowing down the root regressing revision for a job that they are investigating.

Fig: shows “Backfill this job” button in the Treeherder UI

All of the above features right now only work for jobs that are on buildapi, but when mozci will have the ability to trigger tasks on taskcluster, they will be able to work on those jobs too. Also, right now all these buttons trigger the jobs which have a completed build, in future I plan to make these buttons to also trigger jobs which don’t have an existing build. These features are in beta and have been released for sheriffs, I would love to hear your feedback! A big shout out to all the people who have reviewed, tested and given feedback on these features.

I’ve been working in distributed teams, as well as talking, presenting, coaching and blogging about “remoties”‚ in one form or another for 8?9? years now. So, I’m excited to announce that I recently signed a contract with O’Reilly to write a book about how to successfully work in, and manage in, a geo-distributed world. Yes, I’m writing a “we are all remoties” book. If you’ve been in one of my ever-evolving “we are all remoties” sessions, you have an idea of what will be included.

If you’ve ever talked with me about the pros (and cons!) of working as a remote employee or of working in a distributed team, you already know how passionate I am about this topic. I care deeply about people being able to work well together, and having meaningful careers, while being physically or somehow otherwise remote from each other. Done incorrectly, this situation can be frustrating and risky to your career, as well as risky to employers. Done correctly, however, this could be a global change for good, raising the financial, technical and economic standards across all sorts of far flung places around the globe. Heady game-changing stuff indeed.

There are many “advocacy books” out there, explaining why working remote is a good / reasonable thing to do – typically written from the perspective of the solo person who is already remote. There are also many different tools becoming available to help people working in distributed teams – exciting to see. However, I found very few books, or blogposts, talking about the practical mechanics of *how* to use a combination of these tools and some human habits to allow humans to work together effectively in distributed teams, especially at any scale or over a sustained amount of time. Hence, my presentations, and now, this upcoming book.

Meanwhile,

if you are physically geo-distributed from the people you work with, I’d like to hear what does or doesn’t work for you. If you know someone who is in this situation, please share this post with them.

If you have experience working in distributed teams, is there something that you wish was already explained in a book? Something that you had to learn the hard way, but which you wish was clearly signposted to make it easier for others following to start working in distributed teams? Do you have any ideas that did / didn’t work for you?

If you have published something on the internet about remoties, please be tolerant of any questions I might ask. If you saw any of my “we are all remoties” presentations, is there anything that you would like to see covered in more/less detail? Anything that you wish was written up in a book to help make the “remote” path easier for those following behind?

…you can reach me on twitter (“@joduinn”) or on email (john at my-domain-name – and be sure to include “remoties” in the subject, to get past spam filters.)

Mercurial 3.5 was released today (following Mercurial's time-based
schedule of releasing a new version every 3 months).

There were roughly 1000 commits between 3.4 and 3.5, making this a
busy version. Although, 1000 commits per release has become the new
norm, as development on Mercurial has accelerated in the past few
years.

In my mind, the major highlight of Mercurial 3.5 is that the new
bundle2 wire protocol for transferring data during hg push
and hg pull is now enabled by default on the client. Previously,
it was enabled by default only on the server.
hg.mozilla.org is running Mercurial 3.4,
so clients that upgrade to 3.5 today will be speaking to it using
the new wire protocol.

The bundle2 wire protocol succeeds the existing protocol
(which has been in place for years) and corrects many of its
deficiencies. Before bundle2, pull and push operations were not
atomic because Mercurial was performing a separate API call for
each piece of data. It would start by transferring changeset data
and then have subsequent transfers of metadata like bookmarks
and phases. As you can imagine, there were race conditions and
scenarios where pushes could be incomplete (not atomic). bundle2
transfers all this data in one large chunk, so there are much
stronger guarantees for data consistency and for atomic operations.

Another benefit of bundle2 is it is a fully extensible data exchange
format. Peers can add additional parts to the payload. For
extensions that wish to transfer additional metadata (like
Mozilla's pushlog
data), they can simply add this directly into the data
stream without requiring additional requests over the wire protocol.
This translates to fewer network round trips and faster push and pull
operations.

The progress extension has been merged into Mercurial's core and
is enabled by default. It is now safe to remove the
extensions.progress config option from your hgrc.

Mercurial 3.5 also (finally) drops support for Python 2.4 and 2.5.
Hopefully nobody reading this is still running these ancient and
unsupported versions of Python. This is a win for Mercurial developers,
as we were constantly having to work around deficiencies with these old
Python releases. There were dozens of commits removing hacks and
workarounds for Python 2.4 and 2.5. Dropping 2.4 and 2.5 also
means Python 3 porting can begin in earnest. However, this isn't a high
priority for anyone, so don't hold your breath.

parts of phases calculation are now performed in C. The not public()
revset should be much faster.

hg status and things walking the filesystem are faster (Mozillians
should be using hgwatchman to make hg status insanely fast)

A ui.allowemptycommit config option was introduced to control whether
empty commits are allowed. Mozillians manually creating trychooser
commits may run into problems creating empty commits without this
option (a better solution is to use mach push-to-try).

Work is progressing on per-directory manifests. Currently, Mercurial
stores the mapping of files to content in a giant list called the
manifest. For repositories with tens or hundreds of thousands of
files, decoding and reading large manifests is very CPU intensive.
Work is being done to enable Mercurial to split manifests by directory.
So instead of a single manifest, there are several. This is a prequisite
to narrow clone, which is the ability to clone history for a subset
of files (like how Subversion works). This work will eventually enable
repositories with millions of files to exist without significant
performance loss. It will also allow
monolithic repositories
to exist without the common critique that they are too unwieldy to
use because they are so large.

hgignore files now have an include: and subinclude: syntax that
can be used to include other files containing ignore rules. This
feature is useful for a number of reasons. First, it makes sense for
ignore rules to live in the directory hierarchy next to paths they
impact. Second, for people working with monolithic repositories, it
means you can export a sub-directory of your monorepo (to e.g. a
Git repository) and its ignore rules - being defined in local
directories - can still work. (I'm pretty sure Facebook is using this
approach to make its syncing of directories/projects from its Mercurial
monorepo to GitHub easier to manage.)

Significant work has been done on the template parser. If you have
written custom templates, you may find that Mercurial 3.5 is more
strict about parsing certain syntax.

Revsets with chained or no longer result in stack exhaustion. Before,
programmatically generated revsets like 1 or 2 or 3 or 4 or 5 or 6...
would likely fail.

Interactions with servers over SSH should now display server output in
real time. Before, server output was buffered and only displayed at the
end of the operation. (You may not see this on hg.mozilla.org until
the server is upgraded to 3.5, which is planned for early September.)

There are now static analysis checks in place to ensure that Mercurial
config options have corresponding documentation in hg help config.
As a result, a lot of formerly undocumented options are now documented.

The Mercurial for Mozillians Installing Mercurial
article provides a Mozilla tailored yet generally applicable guide for
installing or upgrading Mercurial to 3.5. As always, conservative
software users may want to wait until September 1 for the 3.5.1 point
release to fix any issues or regressions from 3.5.

Mercurial 3.5 was released today. I contributed some small
improvements to this version that I thought I'd share with the world.

The feature I'm most proud of adding to Mercurial 3.5 is what I'm
referring to as auto share. The existing hg share extension/command
enables multiple checkouts of a repository to share the same backing
repository store. Essentially the .hg/store directory is a symlink
to shared directory. This feature has existed in Mercurial for years
and is essentially identical to the git worktree feature just
recently added in Git 2.5.

My addition to the share extension is the ability for Mercurial to
automatically perform an hg clone + hg share in the same operation.
If the share.pool config option is defined, hg clone
will automatically clone or pull the repository data somewhere inside
the directory pointed to by share.pool then create a new working copy
from that shared location. But here's the magic: Mercurial can
automatically deduce that different remotes are the same logical
repository (by looking at the root changeset) and automatically have
them share storage. So if you first hg clone the canonical
repository then later do a hg clone of a fork, Mercurial will
pull down the changesets unique to the fork into the previously
created shared directory and perform a checkout from that. Contrast
with performing a full clone of the fork. If you are cloning multiple
repositories that are logically derived from the same original one,
this can result in a significant reduction of disk space and network
usage. I wrote this feature with automated consumers in mind,
particularly continuous integration systems. However, there is also
mode more suitable for humans where repositories are pooled not by their
root changeset but by their URL. For more info, see hg help -e share.

For Mercurial 3.4, I contributed changes that refactored how Mercurial's
tags cache works. This cache was a source of performance problems at
Mozilla's scale for many years. Since upgrading to Mercurial 3.4,
Mozilla has not encountered any significant performance problems with
the cache on either client or server as far as I know.

Building on this work, Mercurial 3.5 supports transferring tags cache
entries from server to client when clients clone/pull. Before, clients
would have to recompute tags cache entries for pulled changesets. On
repositories that are very large in terms of number of files (over 50,000)
or heads (hudreds or more), this could take several dozen seconds or
even minutes. This would manifest as a delay either during or after
initial clone. In Mercurial 3.5 - assuming both client and server
support the new bundle2 wire protocol - the cache entries are
transferred from server to client and no extra computation needs to
occur. The client does pay a very small price for transferring this
additional data over the wire, but the payout is almost always worth it.
For large repositories, this feature means clones are usable sooner.

A few weeks ago, a coworker told me that connections to a Mercurial
server were timing out mid clone. We investigated and discovered a
potential for a long CPU-intensive pause during clones where Mercurial
would not touch the network. On this person's under-powered EC2
instance, the pause was so long that the server's inactivity timeout
was triggered and it dropped the client's TCP connection. I refactored
Mercurial's cloning code so there is no longer a pause. There should
be no overall change in clone time, but there is no longer a perceivable
delay between applying changesets and manifests where the network could
remain idle. This investigation also revealed some potential follow-up
work for Mercurial to be a bit smarter about how it interacts with
networks.

Finally, I contributed hg help scripting to Mercurial's help database.
This help topic covers how to use Mercurial from scripting and other
automated environments. It reflects knowledge I've learned from seeing
Mercurial used in automation at Mozilla.

Of course, there are plenty of other changes in Mercurial 3.5. Stay
tuned for another blog post.

Hi there, I want to let you know that thisFriday, July 31st, we’ll be hosting the Firefox 41.0 Aurora Testday. The main focus of this event is going to be set on NPAPI Flash and Hello Chat. Detailed participation instructions are available in this etherpad.

No previous testing experience is required so feel free to join us on the #qa IRC channel and our moderators will make sure you’ve got everything you need to get started.

In response to strong user uptake of Mozilla’s new Sync service powered by Firefox Accounts, earlier this year we announced a plan to transition users off of our legacy Sync infrastructure and onto the new product. With this migration now well under way, it is time to settle the details of a graceful end-of-life for the old service.

We will shut down the legacy Sync service on September 30th 2015.

We encourage all users of the old service to upgrade to a Firefox Account, which offers a simplified setup process, improved availability and reliability, and the possibility of recovering your data even if you lose all of your devices.

Users on Firefox 37 or later are currently being offered a guided migration process to make the experience as seamless as possible. Users on older versions of Firefox will see a warning notice and will be able to upgrade manually. Users running their own Sync server, or using a Sync service hosted by someone other than Mozilla, will not be affected by this change.

We are committed to making this transition as smooth as possible for Firefox users. If you have any questions, comments or concerns, don’t hesitate to reach out to us on sync-dev@mozilla.org or in #sync on Mozilla IRC.

FAQ

What will happen on September 30th 2015?

After September 30th, we will decommission the hardware hosting the legacy Sync service and discard all data stored therein. The corresponding DNS names will be redirected to static error pages, to ensure that appropriate messaging is provided for users who have yet to upgrade to the new service.

What’s the hurry? Can’t you just leave it running in maintenance mode?

Unfortunately not. While we want to ensure as little disruption as possible for our users, the legacy Sync service is hosted on aging hardware in a physical data-center and incurs significant operational costs. Maintaining the service beyond September 30th would be prohibitively expensive for Mozilla.

What about Extended Support Release (ESR)?

Users on the ESR channel have support for Firefox Accounts and the new Sync service as of Firefox 38. Previous ESR versions reach end-of-life in early August and we encourage all users to upgrade to the latest version.

Will my data be automatically migrated to the new servers?

No, the strong encryption used by both Sync systems means that we cannot automatically migrate your data on the server. Once you complete your account upgrade, Firefox will re-upload your data to the new system (so if you have a lot of bookmarks, you may want to ensure you’re on a reliable network connection).

Are there security considerations when upgrading to the new system?

Both the new and old Sync systems provide industry-leading security for your data: client-side end-to-end encryption of all synced data, using a key known only to you.

In legacy Sync this was achieved by using a complicated pairing flow to transfer the encryption key between devices. With Firefox Accounts we have replaced this with a key securely derived from your account password. Pick a strong password and you can remain confident that your synced data will only be seen by you.

Does Mozilla use my synced data to market to me, or sell this data to third parties?

No. Our handling of your data is governed by Mozilla’s privacy policy which does not allow such use. In addition, the strong encryption provided by Sync means that we cannot use your synced data for such purposes, even if we wanted to.

Is the new Sync system compatible with Firefox’s master password feature?

Yes. There was a limitation in previous versions of Firefox that prevented Sync from working when a master password was enabled, but this has since been resolved. Sync is fully compatible with the master password feature in the latest version of Firefox.

What if I am running a custom or self-hosted Sync server?

This transition affects only the default Mozilla-hosted servers. If you are using a custom or self-hosted server setup, Sync should continue to work uninterrupted and you will not be prompted to upgrade.

However, the legacy Sync protocol code inside Firefox is no longer maintained, and we plan to begin its removal in 2016. You should consider migrating your server infrastructure to use the new protocols; see below.

“I am writing to you about a very disturbing aspect of Windows 10. Specifically, that the update experience appears to have been designed to throw away the choice your customers have made about the Internet experience they want, and replace it with the Internet experience Microsoft wants them to have.”

Right, but what about the experiences that Mozilla chooses to default for users like switching to Yahoo and making that the default upon upgrade and not respecting their previous settings ?What about baking Pocket and Tiles into the experience? Did users want these features? All I have seen is opposition to them.

“When we first saw the Windows 10 upgrade experience that strips users of their choice by effectively overriding existing user preferences for the Web browser and other apps, we reached out to your team to discuss this issue. Unfortunately, it didn’t result in any meaningful progress, hence this letter.”

Again see above and think about the past year or two where Mozilla has overridden existing user preferences in Firefox. The big difference here is Mozilla calls it acting on behalf of the user as its agent, but when Microsoft does the same it is taking away choice?

July 30, 2015

This workshop has been really intense days so far and this last and forth Workshop day did not turn out differently. We started out the morning with the presentation: Caching, Intermediation and the Modern Web by Martin Thomson (Mozilla) describing his idea of a “blind cache” and how it could help to offer caching in a HTTPS world. It of course brought a lot of discussions and further brainstorming on the ideas and how various people in the room thought the idea could be improved or changed.

Immediately following that, Martin continued with a second presentation describing for us a suggested new encryption format for HTTP based on the JWE format and how it could possible be used.

The room then debated connection coalescing (with HTTP/2)for a while and some shared their experiences and thoughts on the topic. It is an area where over-sharing based on the wrong assumptions certainly can lead to tears and unhappiness but it seems the few in the room who actually have implemented this seemed to have considered most of the problems people could foresee.

Support of Trailers in HTTP was brought up and we discussed its virtues for a while vs the possible problems with supporting it and what possible caveats could be, and we also explored the idea of using HTTP/2 push instead of trailers to allow servers to send meta-data that way, and that then also doesn’t necessarily have to follow after the transfer but can in fact be sent during transfer!

Resumed uploads is a topic that comes back every now and then and that has some interest. (It is probably one of the most frequently requested protocol features I get asked about.) It was brought up as something we should probably discuss further, and especially when discussing the next generation HTTP.

At some point in the future we will start talking about HTTP/3. We had a long discussion with the whole team here on what HTTP/3 could entail and we also explored general future HTTP and HTTP/2 extensions and more. A massive list of possible future work was created. The list ended up with something like 70 different things to discuss or work on, but of course most of those things will never actually become reality.

With so much possible or potential work ahead, we need to involve more people that want to and can consider writing specs and to show how easy it apparently can be, Martin demoed how to write a first I-D draft using the fancy Internet Draft Template Repository. Go check it out!

Poul-Henning Kamp brought up the topic of “CO2 usage of the Internet” and argued for that current and future protocol work need to consider the environmental impact and how “green” protocols are. Ilya Grigorik (Google) showed off numbers from http archive.org’s data and demoed how easy it is to use the big query feature to extract useful information and statistical info out of the vast amount of data they’ve gathered there. Brad Fitspatrick (Google) showed off his awesome tool h2i and how we can use it to poke on and test HTTP/2 server implementations in a really convenient and almost telnet-style command line using way.

Finally, Mark Nottingham (Akamai) showed off his redbot.org service that runs HTTP against a site, checks its responses and reports with details exactly what it responds and why and provide a bunch of analysis and informational based on that.

Such an eventful day really had to be rounded off with a bunch of beers and so we did. The HTTP Workshop of the summer 2015 ended. The event was great. The attendees were great. The facilities and the food were perfect. I couldn’t ask for more. Thanks for arranging such a great happening!

I’ll round off showing off my laptop lid after the two new stickers of the week were applied. (The HTTP Workshop one and an Apache one I got from Roy):

Heather Bloomer started contributing to Mozilla in November 2014, initially on SUMO. There, she saw a link to MDN, and realized she could contribute there as well. So, she is a “crossover” who contributes to helping both end-users and developers. She has been heavily involved in the Learning Area project, writing and editing Glossary entries and tutorials. She describes her contributions as “a continuing journey of enlightenment and an overall awesome experience.”

Here’s more from Heather:

I feel what I do on MDN has personally enhanced my writing skills and expanded my technical knowledge. I also feel I am making a positive impact in the MDN community and for developers that refer to MDN from beginners to advanced. That is an amazing feeling to be part of something bigger than yourself and grow and nurture not only ones self, but others as well.

My advice for new contributors is to just reach out and connect with the MDN community. Join the team and just dig in. If you need help on getting started, we are more than happy to point you in the right direction. We are friendly, supportive, encouraging and a team driven bunch of folks!

We are calling on Microsoft to “undo” its aggressive move to override user choice on Windows 10

Mozilla exists to bring choice, control and opportunity to everyone on the Web. We build Firefox and our other products for this reason. We build Mozilla as a non-profit organization for this reason. And we work to make the Internet experience beyond our products represent these values as much as we can.

Sometimes we see great progress, where consumer products respect individuals and their choices. However, with the launch of Windows 10 we are deeply disappointed to see Microsoft take such a dramatic step backwards. It is bewildering to see, after almost 15 years of progress bolstered by significant government intervention, that with Windows 10 user choice has now been all but removed. The upgrade process now appears to be purposefully designed to throw away the choices its customers have made about the Internet experience they want, and replace it with the Internet experience Microsoft wants them to have.

On the user choice benchmark, Microsoft’s Windows 10 falls woefully short, even when compared to its own past versions. While it is technically possible for people to preserve their previous settings and defaults, the design of the new Windows 10 upgrade experience and user interface does not make this obvious nor easy. We are deeply passionate about our mission to ensure people are front, center and squarely in the driver’s seat of their online experience, so when we first encountered development builds of Windows 10 that appeared would override millions of individual decisions people have made about their experience, we were compelled to immediately reach out to Microsoft to address this. And so we did. Unfortunately this didn’t result in any meaningful change.

Today we are sending an open letter to Microsoft’s CEO to again insist that Windows 10 make it easy, obvious and intuitive for people to maintain the choices they have already made — and make it easier for people to assert new choices and preferences.

In the meantime, we’re rolling out support materials and a tutorial video to help guide everyone through the process of preserving their choices on Windows 10.

I am writing to you about a very disturbing aspect of Windows 10. Specifically, that the update experience appears to have been designed to throw away the choice your customers have made about the Internet experience they want, and replace it with the Internet experience Microsoft wants them to have.

When we first saw the Windows 10 upgrade experience that strips users of their choice by effectively overriding existing user preferences for the Web browser and other apps, we reached out to your team to discuss this issue. Unfortunately, it didn’t result in any meaningful progress, hence this letter.

We appreciate that it’s still technically possible to preserve people’s previous settings and defaults, but the design of the whole upgrade experience and the default settings APIs have been changed to make this less obvious and more difficult. It now takes more than twice the number of mouse clicks, scrolling through content and some technical sophistication for people to reassert the choices they had previously made in earlier versions of Windows. It’s confusing, hard to navigate and easy to get lost.

Mozilla exists to bring choice, control and opportunity to everyone. We build Firefox and our other products for this reason. We build Mozilla as a non-profit organization for this reason. And we work to make the Internet experience beyond our products represent these values as much as we can.

Sometimes we see great progress, where consumer products respect individuals and their choices. However, with the launch of Windows 10 we are deeply disappointed to see Microsoft take such a dramatic step backwards.

These changes aren’t unsettling to us because we’re the organization that makes Firefox. They are unsettling because there are millions of users who love Windows and who are having their choices ignored, and because of the increased complexity put into everyone’s way if and when they choose to make a choice different than what Microsoft prefers.

We strongly urge you to reconsider your business tactic here and again respect people’s right to choice and control of their online experience by making it easier, more obvious and intuitive for people to maintain the choices they have already made through the upgrade experience. It also should be easier for people to assert new choices and preferences, not just for other Microsoft products, through the default settings APIs and user interfaces.

Please give your users the choice and control they deserve in Windows 10.

Let’s get straight to the biscuits. From now on, you only need one tool to localize Mozilla stuff. That’s it. Single user interface, single translation memory, single permission management, single user account. Would you like to give it a try? Keep on reading!

A little bit of background.
Mozilla software and websites are localized by hundreds of volunteers, who give away their free time to put exciting technology into the hands of people across the globe. Keep in mind that 2 out of 3 Firefox installations are non-English and we haven’t shipped a single Firefox OS phone in English yet.

Considering the amount of impact they have and the work they contribute, I have a huge respect for our localizers and the feedback we get from them. One of the most common complaints I’ve been hearing is that we have too many localization tools. And I couldn’t agree more. At one of our recent l10n hackathons I was even introduced to a tool I never heard about despite 13 years of involvement with Mozilla localization!

So I thought, “Let’s do something about it!”

9 in 1.
I started by looking at the tools we use in Slovenian team and counted 9(!) different tools:

Eating my own dog food, I had already integrated all 3 terminology services into Pontoon, so that suggestions from these sources are presented to users while they translate. Furthermore, Pontoon syncs with repositories, sometimes even more often that the dashboards, practically eliminating the need to look at them.

So all I had to do is migrate projects from the rest of the editors into Pontoon. Not a single line of code needed to be written for Verbatim migration. Pootle and the text editor were slightly more complicated. They were used to localize Firefox, Firefox for Android, Thunderbird and Lightning, which all use the huge mozilla-central repository as their source repository and share locale repositories.

Nevertheless, a few weeks after the team agreed to move to Pontoon, Slovenian now uses Pontoon as the only tool to localize all (31) of our active projects!

Who wants to join the party?
Slovenian isn’t the only team using Pontoon. In fact, there are 2 dozens of locales with at least 5 projects enabled in Pontoon. Recently, Ukranian (uk) and Portugese Brasil (pt-BR) have been especially active, not only in terms of localization but also in terms of feedback. A big shout out to Artem, Marco and Marko!

There are obvious benefits of using just one tool, namely keeping all translations, attributions, contributor stats, etc. in one place. To give Pontoon a try, simply select a project and request your locale to be enabled. Migrating projects from other tools will of course preserve all the translations. Starting today, that includes attributions and submission dates (who translated what, and when it was translated) if you’re moving projects from Verbatim.

And, as you already know, Pontoon is developed by Mozilla, so we invite you to report problems and request new features. We also accept patches. We have many exciting things coming up by the end of the summer, so keep an eye out for updates!

Sometimes when you have several tabs open, and one of them starts to make some noise, you may wonder where the noise is coming from. Other times, you may want to quickly mute a tab without figuring out if the web page provides its own UI for muting the audio. On Wednesday, I landed the user facing bits of a feature to add an audio indicator to the tabs that are playing audio, and enable muting them. You can see a screenshot of what this will look like in action below.

Tab audio indicators in action

As you can see in the screenshot, my Soundcloud tab is playing audio, and so is my Youtube tab, but the Youtube tab has been muted. Muting and unmuting a tab is easy by clicking on the tab audio indicator icon. You can now test this out yourself on Firefox Nightly tomorrow!

This feature should work with all APIs that let you play audio, such as HTML5 <audio> and <video>, and Web Audio. Also, it works with the latest Flash beta. Note that you actually need to install the latest Flash beta, that is, version 19.0.0.124 which was released yesterday. Earlier versions of Flash won’t work with this feature.

We’re interested in your feedback about this feature, and especially about any bugs that you may encounter. We hope to iron out the rough edges and then let this feature ride the trains. If you are curious about this progress, please follow along on the tracking bug.

If you have been wanting to use Marionette but couldn't because you only work on Windows, now is your chance to do so! All the latest downloads are available from our development github repository releases page

There is also a new page on MDN that walks you through the process of setting up Marionette and using it. I have only updated the python bindings so I can get a fell for how people are using it

Since you are awesome early adopters it would be great if we could raise bugs.

I am not expecting everything to work but below is a quick list that I know doesn't work.

No support for self-signed certificates

No support for actions

No support logging endpoint

getPageSource not available. This will be added in at a later stage, it was a slightly contentious part in the specification.

I am sure there are other things we don't remember

Switching of Frames needs to be done with either a WebElement or an index. Windows can only be switched by window handles. This is currently how it has been discussed in the specification.

Flagged properties have another issue: they don't solve the problem of proprietary extensions to CSS that become mainstream. If a given vendor implements for its own usage a proprietary feature that is so important to them, internally, they have to "unflag" it, you can be sure some users will start using it if they can. The spread of such a feature remains a problem, because it changes the delicate balance of a World Wide Web that should be readable and usable from anywhere, with any platform, with any browser.

I think the solution is in the hands of browser vendors: they have to consider that experimental features are experimental whetever their spread in the wild. They don't have to care about the web sites they will break if they change, update or even ditch an experimental or proprietary feature. We have heard too many times the message « sorry, can't remove it, it spread too much ». It's a bad signal because it clearly tells CSS Authors experimental features are reliable because they will stay forever as they are. They also have to work faster and avoid letting an experimental feature alive for more than two years.

Emphasis is mine on this last part. Yes it's a very bad signal. And check what was said yesterday.

@AlfonsoML And we will always support them (unlike some vendors that remove things at will). So what is the issue?

This is the issue in terms of Web Compatibility. It's what I was precisely saying that implementers do not understand the impact it has.

Decoding Hashed known_hosts Files

Modern ssh comes with the option to obfuscate the hosts it can connect
to, by enabling the HashKnownHosts option. Modern server installs
have that as a default. This is a good thing.

The obfuscation occurs by hashing the first field of the known_hosts
file - this field contains the hostname,port and IP address used to
connect to a host. Presumably, there is a private ssh key on the host
used to make the connection, so this process makes it harder for an
attacker to utilize those private keys if the server is ever
compromised.

Super! Nifty! Now how do I audit those files? Some services have
multiple IP addresses that serve a host, so some updates and changes are
legitimate. But which ones? It’s a one way hash, so you can’t decode.

Well, if you had an unhashed copy of the file, you could match host keys
and determine the host name & IP. [1] You might just have such a file on
your laptop (at least I don’t hash keys locally). [2] (Or build a
special file by connecting to the hosts you expect with the options “-oHashKnownHosts=no-oUserKnownHostsFile=/path/to/new_master”.)

I through together a quick python script to do the matching, and it’s at
this gist. I hope it’s useful - as I find bugs, I’ll keep it updated.

I have read everything and its contrary about CSS vendor prefixes in the last 48 hours. Twitter, blogs, Facebook are full of messages or articles about what are or are supposed to be CSS vendor prefixes. These opinions are often given by people who were not members of the CSS Working Group when we decided to launch vendor prefixes. These opinions are too often partly or even entirely wrong so let me give you my own perspective (and history) about them. This article is with my CSS Co-chairman's hat off, I'm only an old CSS WG member in the following lines...

In order to allow vendors to add private properties using the CSS syntax and
avoid collisions with future CSS versions, we need to define a convention for
private properties. Here is my proposal (slightly different than was talked
about at the meeting).
Any vendors that defines a property that is not specified in this spec must
put
a prefix on it. That prefix must start with a '-', followed by a vendor
specific abbreviation, and another '-'. All property names that DO NOT start
with a '-' are RESERVED for using by the CSS working group.

The CSS Working Group slowly evolved from that to « vendor prefixes indicate proprietary features OR experimental features under discussion in the CSS Working Group ». In the latter case, the vendor prefixes were supposed to be removed when the spec stabilized enough to allow it, i.e. reaching an official Call for Implementation.

Unfortunately, some of those prefixed properties took a lot, really a lot, of time to reach a stable state in a Standard and everyone started relying on prefixed properties in production web sites...

Unfortunately again, some vendors did not apply the rules they decided themselves: since the prefixed version of some properties was so widely used, they maintained them with their early implementation and syntax in parallel to a "more modern" implementation matching, or not, what was in the Working Draft at that time.

Vendor prefixes were not a complete failure. They allowed the release to the masses of innovative products and the deep adoption of HTML and CSS in products that were not originally made for Web Standards (like Microsoft Office). They allowed to ship experimental features and gather priceless feedback from our users, CSS Authors. But they failed for two main reasons:

The CSS Working Group - and the Group is really made only of its Members, the vendors - took faaaar too much time to standardize critical features that saw immediate massive adoption.

Some vendors did not update nor "retire" experimental features when they had to do it, ditching themselves the rules they originally agreed on.

From that perspective, putting experimental features behind a flag that is by default "off" in browsers is a much better option. It's not perfect though. I'm still under the impression the standardization process becomes considerably harder when such a flag is "turned on" in a major browser before the spec becomes a Proposed Recommendation. A Standardization process is not a straight line, and even at the latest stages of standardization of a given specification, issues can arise and trigger more work and then a delay or even important technical changes. Even at PR stage, a spec can be formally objected or face an IPR issue delaying it. As CSS matures, we increasingly deal with more and more complex features and issues, and it's hard to predict when a feature will be ready for shipping. But we still need to gather feedback, we still need to "turn flags on" at some point to get real-life feedback from CSS Authors. Unfortunately, you can't easily remove things from the Web. Breaking millions of web sites to "retire" an experimental feature is still a difficult choice...

Flagged properties have another issue: they don't solve the problem of proprietary extensions to CSS that become mainstream. If a given vendor implements for its own usage a proprietary feature that is so important to them, internally, they have to "unflag" it, you can be sure some users will start using it if they can. The spread of such a feature remains a problem, because it changes the delicate balance of a World Wide Web that should be readable and usable from anywhere, with any platform, with any browser.

I think the solution is in the hands of browser vendors: they have to consider that experimental features are experimental whetever their spread in the wild. They don't have to care about the web sites they will break if they change, update or even ditch an experimental or proprietary feature. We have heard too many times the message « sorry, can't remove it, it spread too much ». It's a bad signal because it clearly tells CSS Authors experimental features are reliable because they will stay forever as they are. They also have to work faster and avoid letting an experimental feature alive for more than two years. That requires taking the following hard decisions:

if a feature does not stabilize in two years' time, that's probably because it's not ready or too hard to implement, or not strategic at that moment, or that the production of a Test Suite is a too large effort, or whatever. It has then to be dropped or postponed.

Tests are painful and time-consuming. But testing is one of the mandatory steps of our Standardization process. We should "postpone" specs that can't get a Test Suite to move along the REC track in a reasonable time. That implies removing the experimental feature from browsers, or at least turning the flag they live behind off again. It's a hard and painful decision, but it's a reasonable one given all I said above and the danger of letting an experimenal feature spread.

Today I learned of some of the worst kind of news, my friend and a valuable contributor to the great open source community Nóirín Plunkett passed away. They (this is their preferred pronoun per their twitter profile) was well regarded in the open source community for contributions.

I had known them for about four years now, having met them at OSCON and seen them regularly at other events. They were always great to have a discussion with and learn from and they always had a smile on their face.

It is very sad to lose them as they demonstrated an unmatchable passion and dedication to open source and community and surely many of us will spend many days, weeks and months reflecting on the sadness of this loss.

Highlights

Treeherder: We’ve added to mozlog the ability to create error summaries which will be used as the basis for automatic starring. The Treeherder team is working on implementing database changes which will make it easier to add support for that. On the front end, there’s now a “What’s Deployed” link in the footer of the help page, to make it easier to see what commits have been applied to staging and production. Job details are now shown in the Logviewer, and a mockup has been created of additional Logviewer enhancements; see bug 1183872.

MozReview and Autoland: Work continues to allow autoland to work on inbound; MozReview has been changed to carry forward r+ on revised commits.

Bugzilla: The ability to search attachments by content has been turned off; BMO documentation has been started at https://bmo.readthedocs.org.

Perfherder/Performance Testing: We’re working towards landing Talos in-tree. A new Talos test measuring tab-switching performance has been created (TPS, or Talos Page Switch); e10s Talos has been enabled on all platforms for PGO builds on mozilla-central. Some usability improvements have been made to Perfherder – https://treeherder.mozilla.org/perf.html#/graphs.

TaskCluster: Successful OSX cross-compilation has been achieved; working on the ability to trigger these on Try and sorting out details related to packaging and symbols. Work on porting Linux tests to TaskCluster is blocked due to problems with the builds.

Developer Workflow: A kill_and_get_minidump method has been added to mozcrash, which allows us to get stack traces out of Windows mochitests in more situations, particularly plugin hangs. Linux xpcshell debug tests have been split into two chunks in buildbot in order to reduce E2E times, and chunks of mochitest-browser-chrome and mochitest-devtools-chrome have been re-normalized by runtime across all platforms. Now that mozharness lives in the tree, we’re planning on removing the “in-tree configs”, and consolidating them with the previously out-of-tree mozharness configs (bug 1181261).

Tools: We’re testing an auto-backfill tool which will automatically retrigger coalesced jobs in Treeherder that precede a failing job. The goal is to reduce the turnaround time required for this currently manual process, which should in turn reduce tree closure times related to test failures

Next steps: sorting out blockers to be able to trigger builds on Try, start working on packaging/symbols

Mobile Automation

Continued work on porting android talos tests to autophone, remaining work is to figure out posting results and ensuring it runs on a regular basis and reliable.

Support for the Android stock browser and Dolphin has been added to mozbench (bug 1103134)

Dev Workflow

Created patch that replaces mach’s logger with mozlog. Still several rough edges and perf issues to iron out

Media Automation

The new MSE rewrite is now enabled by default on Nightly and we’re replacing a few tests in response: bug 1186943 – detection of video stalls has to repond to new internal strings from new MSE implementation by :jya.

firefox-media-tests mozharness log is now parsed into steps for Treeherder’s Log Viewer

Fixed a problem with automation scripts for WebRTC tests for Windows 64.

General Automation

Moved mozlog.structured to top-level mozlog, and released mozlog 3.0

Added a kill_and_get_minidump method to mozcrash (bug 890026). As a result we’re getting minidumps out of Windows mochitests under more circumstances (in particular, plugin hangs in certain intermittently failing tests).

July 29, 2015

This week on Lost in Data, we tackle yet another pile of alerts. This time we have a set of changes which landed together and we push to try for bisection. In addition we have an e10s only failure which happened when we broke talos uploading to perfherder. See how I get one step closer to figuring out the root cause of the regressions.

I’ve met a bunch of new faces and friends here at the HTTP Workshop in Münster. Several who I’ve only seen or chatted with online before and some that I never interacted with until now. Pretty awesome really.

Out of the almost forty HTTP fanatics present at this workshop, five persons are from Google, four from Mozilla (including myself) and Akamai has three employees here. Those are the top-3 companies. There are a few others with 2 representatives but most people here are the only guys from their company. Yes they are all guys. We are all guys. The male dominance at this event is really extreme and we’ve discussed this sad circumstance during breaks and it hasn’t gone unnoticed.

This particular day started out grand with Eric Rescorla (of Mozilla) talking about HTTP Security in his marvelous high-speed style. Lots of talk about how how the HTTPS usage is right now on the web, HTTPS trends, TLS 1.3 details and when it is coming and we got into a lot of talk about how HTTP deprecation and what can and cannot be done etc.

Next up was a presentation about HTTP Privacy and Anonymity by Mike Perry (from the Tor project) about lots of aspects of what the Tor guys consider regarding fingerprinting, correlation, network side-channels and similar things that can be used to attempt to track user or usage over the Tor network. We got into details about what recent protocols like HTTP/2 and QUIC “leak” or open up for fingerprinting and what (if anything) can or could be done to mitigate the effects.

Evolving HTTP Header Fields by Julian Reschke (of Green Bytes) then followed, discussing all the variations of header syntax that we have in HTTP and how it really is not possible to write a generic parser that can handle them, with a suggestion on how to unify this and introduce a common format for future new headers. Julian’s suggestion to use JSON for this ignited a discussion about header formats in general and what should or could be done for HTTP/3 and if keeping support for the old formats is necessary or not going forward. No real consensus was reached.

Willy Tarreau (from HAProxy) then took us into the world of HTTP Infrastructure scaling and Load balancing, and showed us on the microsecond level how fast a load balancer can be, how much extra work adding HTTPS can mean and then ending with a couple suggestions of what he thinks could’ve helped his scenario. That then turned into a general discussion and network architecture brainstorm on what can be done, how it could be improved and what TLS and other protocols could possibly be do to aid. Cramming out every possible gigabit out of load balancers certainly is a challange.

Talking about cramming bits, Kazuho Oku got to show the final slides when he showed how he’s managed to get his picohttpparser to parse HTTP/1 headers at a speed that is only slightly slower than strlen() – including a raw dump of the x86 assembler the code is turned into by a compiler. What could possibly be a better way to end a day full of protocol geekery?

Google graciously sponsored the team dinner in the evening at a Peruvian place in the town! Yet another fully packed day has ended.

I’ll top off today’s summary with a picture of the gift Mark Nottingham (who’s herding us through these days) was handing out today to make us stay keen and alert (Mark pointed out to me that this was a gift from one of our Japanese friends here):

Once a month, web developers from across the Mozilla Project get together to develop an encryption scheme that is resistant to bad actors yet able to be broken by legitimate government entities. While we toil away, we find time to talk about our side projects and drink, an occurrence we like to call “Beer and Tell”.

Osmose: Moseamp

Osmose (that’s me!) was up first, and shared Moseamp, an audio player. It’s built using HTML, CSS, and JavaScript, but acts as a native app thanks to the Electron framework. Moseamp can play standard audio formats, and also can load plugins to add support for extra file formats, such as Moseamp-Audio-Overload for playing PSF files and Moseamp-GME for playing NSF and SPC files. The plugins rely on libraries written in C that are compiled via Emscripten.

Peterbe: Activity

Next was Peterbe with Activity, a small webapp that displays the events relevant to a project, such as pull requests, PR comments, bug comments, and more, and displays the events in a nice timeline along with the person related to the action. It currently pulls data from Bugzilla and Github.

The project was born from the need to help track a single individual’s activities related to a project, even if they have different usernames on different services. Activity can help a project maintainer see what contributors are doing and determine if there’s anything they can do to help the contributor.

New One: MXR to DXR

New One was up next with a Firefox add-on called MXR to DXR. The add-on rewrites all links to MXR viewed in Firefox to point to the equivalent page on DXR, the successor to MXR. The add-on also provides a hotkey for switching between MXR and DXR while browsing the sites.

bwalker: Liturgiclock

Last was bwalker who shared liturgiclock, which is a webpage showing a year-long view of what religious texts that Lutherans are supposed to read throughout the year based on the date. The site uses a Node.js library that provides the data on which text belongs to which date, and the visualization itself is powered by SVG and D3.js.

We don’t actually know how to go about designing an encryption scheme, but we’re hoping to run a Kickstarter to pay for the Udacity cryptography course. We’re confident that after being certified as cryptologists we can make real progress towards our dream of swimming in pools filled with government cash.

If you’re interested in attending the next Beer and Tell, sign up for the dev-webdev@lists.mozilla.org mailing list. An email is sent out a week beforehand with connection details. You could even add yourself to the wiki and show off your side-project!

Exploring the wilds of the internets, I stumble upon a brand new site that allows me to turn cat images into ASCII art.

No way. Cats? In text form?! Text messages full of kitties!

This is amaze. How do I get started?

Says here, “Just create an account.” Ok.

“What’s your username?” seanmonstar.

“Pick a p͏a̵ss–”arrgghHHHa̵ąz͏z͝ef́w͟qa̛a̸s̕s̡;. WHAT! NO! What did you just call me?1 I will not!. I don’t care how amaze textual kitties might be.

Sorry, I’m fine now. It’s just… you know. It is downright irresponsible at this point to require a user to enter a password to login to your site. It’s pretty easy to properly hash some passwords, but DON’T DO IT!. Instead, you should let a secure identity provider provide the user’s credentials.

Good idea! Er, which do you pick? There’s several, and each has its own peculiarities regarding its API. Sigh.

Persona?

I had hoped Persona would move us away from these dark ages, but it struggled to gain support. The user experience was disruptive.

Most often, users had to create a new Persona account. Oh hey, another password!

Additionally, they would need to go through email verification, which while it helps to make it secure, is another step that may cause a user to bail out. Even if they went through the whole process, web developers needed to properly use navigator.id.watch() to keep state. It was very easy to mess that up.

The popup would confuse users. We’ve been teaching users forever to distrust popups, but saying this one was okay.

++

At this point, most browsers have user account information already. Chrome has a Google account, Firefox has a Firefox account, Safari has iCloud, and Edge has a Microsoft account. How about we just move websites to asking the User Agent for credentials, instead of the User directly?

This was what I originally assumed BrowserID would work, when I first heard about it. A user can sign into a browser, using whichever way that browser supports. The website (and thus web developer) isn’t required to care what account system the user wants to use. They just want to know “who are you” and “how can I be sure?”2The problem this solves now is passing and storing passwords.

navigator.auth.get()

A website could ask for credentials from the navigator, and the browser can show its own trusted UI asking the user if and which ID to share to the website. The API could return a Promise<JWT>, with the JWT being signed by the browser. There’s already standards in place for verifying a signed JWT, so the web developer can be confident that the user owns the data include in the token. An example usage:

Using a Promise and using the already-logged-in accounts of the browser, the website won’t need to reload. It therefore doesn’t need to store state, and doesn’t need the wonkiness of Persona’s watch(). This is simply an authentication requesting mechanism, so there’s no confusion about who manages the session: the website does.

Additionally, an HTML element could be used for sites that wish to support NoScript:

<auth method="POST" action="/verify" label="Login" />

This could render like a <div>, and a website could style it to their spleen’s content. Another pain point of Persona solved.

We can do this!

The Identity team at Mozilla is interested in exploring this, and being that the scope is low, working towards consensus and a standard is the goal, as opposed to Persona’s hope of adoption before standardization. To a less-passwords web!

“Password” should be a curse word. Hey! Did you see that little password? Too busy texting to its passwording buddies, and almost hit me!↩

Federation of an account system should certainly be possible, but out of scope for this article. The points is that any browser maker can explore how to log into the browser, and pass a JWT to a website that includes a way to verify it. Firefox and others would then be free to explore de-centralized accounts and profiles, while web developers can happily log users in without evil passwords. ↩

A lot has happened in the world of Raptor in the last couple of months. The Raptor tool itself has been migrated out of Gaia, and is now available as it’s own Raptor CLI Tool installed as a global NPM package. The new Raptor tool has several improvements including the addition of Marionette, allowing Raptor tests to use Marionette to drive the device UI, and in turn spawn performance markers.

The automation running Raptor on Gaia-ci has now been updated to use the new Raptor CLI tool. Not only has the tool itself been upgraded, but how the Raptor suite is running on Gaia-ci has also been completely refactored, for the better.

In order to reduce test variance, the coldlaunch test is now run on the base Gaia version and then on the patch Gaia version, all on the same taskcluster worker/machine instance. This has the added benefit of just having a single Raptor app launch test task per Gaia application that the test is supported on.

New Raptor Tasks on Treeherder

The Raptor tasks are now visible by default on Treeherder for Gaia and Gaia-master, and appear in a new Raptor group as seen here:

New Raptor Tasks on Gaia Treeherder

All of the applications that the coldlaunch performance test were performed on are listed (currently 12 apps). The Raptor suite is run once by default now (on both base and patch Gaia revisions) and results calculated and compared all in the same task, per app. If an app startup time regression is detected, the test is automatically retried up to 3 more times. The app task is marked as an orange failure if all 4 runs show a 15% or greater regression in app startup time.

To view the coldlaunch test results for any app, click on the corresponding app task symbol on Treeherder. Then on the panel that appears towards the bottom, click on “Job details”, and then “Inspect Task”. The Task Inspector opens in a new tab. Scroll down and you will see the console output which includes the summary table for the base and patch Gaia revs, and the overall result (if a regression has been detected or not). If a regression has been detected, the regression percentage is displayed; this represents the increase in application launch time.

Retriggering the Launch Test

If you wish to repeat the app launch test again for an individual app, perhaps to further confirm a launch regression, it can be easily retriggered. To retrigger the coldlaunch test for a single app, simply click the task representing the app and retrigger the task how you normally would on Treeherder (login and click on the retrigger job button). This will start the Raptor coldlaunch test again just for the selected app, on both the gaia base and patch revisions as before. The versions of Gaia and the emulator (gecko) will remain the same as they were in the original suite run, when the test is retriggered on an individually-selected app.

If you wish to repeat the coldlaunch test on ALL of the apps instead of just one, then you can retrigger the entire Raptor suite. Select the Raptor decision task (the green “R“, as seen below) and click the retrigger button:

Raptor Decision Task

Note: Retriggering the entire Raptor suite will cause the emulator (gecko) version to be updated to the very latest before running the test, so if a new emulator build has been completed since the Raptor suite was originally run, then that new emulator (gecko) build will be used. The Gaia base and patch revisions used in the tests will be the same revisions used on the original suite run.

For more information drop by the #raptor channel on Mozilla IRC, or send me a message via the contact form on the About page of this blog. Happy coding!

Mozilla Location Service (MLS) is an open source service to determine location based on network infrastructure like WiFi access points and cell towers. The project has released an client applications to collect the large dataset of GSM, Cellphone, WiFi data using crowd sourcing. In this blog post I'll explore an idea to re-purpose an old Android mobile phone as an autonomous MozStumbling device that could be easily deployed in public transport, taxis or your friend who is driving across the country.

Bill of Materials

Android Mobile phone.

Mozstumbler Android App.

Taskbomb Android App.

Mini-USB cable.

GSM SIM (With mobile data).

Car lighter socket power adapter.

Powerbank (optional).

Putting it together

In this setup, I am using a rugged Android phone running Android Gingerbread. It can take a lot punishment. Leaving a phone in overheated car is recipe for disaster.

From the Android settings I enabled allow installation of non-market applications 'Unknown Sources'. Connected the phone to my computer using the Mini-USB cable. Transferred the previous downloaded apps(.apk) packages to phone and installed the Mozstumbler and Taskbomb applications.

Configured the Mozstumbler application to start on boot with Taskbomb app. Also configured Mozstumbler to upload using mobile data connection. The phone has GSM SIM card with data connection. Made sure both WiFi, GPS and Cellular data is enabled.

To prevent phone from downloading software updates and using up all the data. I disabled all software updates. Disabled all notifications both audio and LED notifications. Finally locked by phone by setting a secret code. Now the device is ready for deployment. The phone is plugged into car's lighter charging unit to keep it powered up. You can also use a power bank in case where charging options are not available.

Planning to use this autonomous Mozstumbler hack soon. Perhaps I should ask Thejesh to use on his epic trip across India.

If you’re interested in a pair of custom Firefox logo cufflinks for $25 plus postage then please get in touch. I’ve been in contact with CuffLinks.com, and if I can place an initial order of at least 25 pairs then the mold and tooling fee will be waived. Check out their website for examples of their work. The Firefox cufflinks would be contoured to the outline of the logo, and the logo itself would be screen printed in full colour. If these go well, I’d also love a pair of dino head cufflinks to complement them!

Unless I can organise with CuffLinks.com to ship to multiple recipients and take payments separately, I will accept payments via Paypal and take care of sending the cufflinks out. As an example of postage costs, sending to USA would cost me approximately $12 per parcel. Let me know if you’re interested via a comment on this post, e-mail (find me in the phonebook), or IRC (:davehunt).

Going to Apple blog post before reading the rest of the thread gives a bit more background.

Web content is sometimes designed to fit in with the overall aesthetic of the underlying platform which it is being rendered on. One of the ways to achieve this is by using the platform’s system font, which is possible on iOS and OS X by using the “-apple-system” CSS value for the “font-family” CSS property. On iOS 9 and OS X 10.11, doing this allows you to use Apple’s new system font, San Francisco. Using “-apple-system” also correctly interacts with the font-weight CSS property to choose the correct font on Apple’s latest operating systems.

Here I understand the desire to use the system font, but I don't understand the new -apple-system, specifically when the next paragraph says:

On platforms which do not support “-apple-system” the browser will simply fall back to the next item in the font-family fallback list. This provides a great way to make sure all your users get a great experience, regardless of which platform they are using.

I wonder what the cascade of font-family is not already doing so they need a new prefix. They explain later on by providing this information:

Going beyond the system font, iOS has dynamic type behavior, which can provide an additional level of fit and finish to your content.

What I smell here is pushing the semantics of a text into the font-face, I believe it will not end well. But that's not what I want to talk about here.

Vendor Prefixes Principle

The vendor prefixes have been created for providing a safe place for vendors to experiment with new features. It's a good idea on paper. It can work well, specifically when the technology is not yet really mature and details need to be ironed. This would be perfectly acceptable if the feature was only available on beta and alpha versions of rendering engines. That would stop de facto the proliferation of these properties in common Web sites. And that would give space for experimenting.

Here the feature is not proposed as an experiment but as a way for Web developers, designers to use a new feature on Apple platform. It's proposed as a competitive advantage and a marketing tool for enticing developers to the cool new thing. And before I'm being targeted for blaming Apple only, all vendors in some fashion do that.

Let's assume that Apple is of good will. The real issue is not easy to understand, except if you are working daily on Web Compatibility across the world.

Enter the market reality field.

Flexbox And Gradients In China And Japan

With the Web Compat team, we have been working lately a lot on Chinese and Japanese mobile Web site compatibility issues. The current market in China and Japan on Mobile is a smartphone ecosystem largely dominated by iOS and Android. It means that if you use in your site -webkit- and WebKit vendor prefixes, you are basically on the safe side for most of the users, but not all users.

What is happening here is interesting. Gradients and flexbox went through syntax changes and the standard syntax is really different from the original -webkit- syntax. These are two features of the Web platform which are very useful and very powerful, specifically flexbox. In a monopolistic market such as China and Japan, the end result was Web developers jumping on the initial version of the feature for creating their Web sites (shiny new and useful features).

Fast forward a couple of years and the economic reality of the Web starts playing its cards. Other vendors have caught up with the features, the standard process took place, and the new world of interoperability is all pink with common implementations in all rendering engines, except a couple of minor details.

Web developers should all jump on adjusting their Web sites to add the standard properties at least. This is not happening. Why? Because the benefits are not perceived by Web developers, project managers and site owners. Indeed adjusting the Web site will have a cost in editing and testing. Who bears this cost and for which reasons?

When mentioning it will allow other users with different browsers to use the Web site, the answer is straightforward: "This browser X is not in our targeted list of browsers." or "This browser Y doesn't appear in our stats." We all know that the browser Y can't appear in the stats because it's not usable on the site (A good example of that is MBGA).

Dropping Vendor Prefixes

Adding prefixless version of properties in the implementation of rendering engines help, but do not magically fix everything for improving the Web Compatibility story. That's the mistake that Timothy Hatcher (WebKit Developer Experience Manager at Apple.) is making in:

This is cool and I applaud Apple for this. I wish it happened a bit earlier. Why doesn't it solve the Web Compatibility issue? Because the prefixed version of properties still exists and is supported. Altogether, we then sing the tune "Yeah, Apple (and Google), let's drop the prefixed version of these properties!" Ooooh, hear me, I so wish it would be possible. But Apple and Google can't do that for the exact same reason that other non-WebKit browsers can't exist in Chinese and Japanese markets. They would instantly break a big number of high profiles Web sites.

We have reached the point where browser vendors have to start implementing or aliasing these WebKit prefixes just to allow their users to browse the Web, see Mozilla in Gecko and Microsoft in Edge. The same thing is happening over again. In the past, browser vendors had to implement the quirks of IE to be compatible with the Web. As much as I hate it, we will have to specify the current -webkit- prefixes to implement them uniformly.

Web Compatibility Responsibility

Microsoft is involved in the Web Compatibility project. I would like Apple and Google to be fully involved and committed in this project. The mess we are all involved is due to WebKit prefixes and the leader position they have on the mobile market can really help. This mess killed Opera Presto on mobile, which had to switch to Blink.

Let's all create a better story for the Web and understand fully the consequences of our decisions. It's not only about technology, but also economic dynamics and market realities.

I had to keep these fuzzers private for a long time because of the frequency with which they found security holes in Firefox. But three things have changed that have tipped the balance toward openness.

First, each area of Firefox has been through many fuzz-fix cycles. So now I'm mostly finding regressions in the Nightly channel, and the severe ones are fixed well before they reach most Firefox users. Second, modern Firefox is much less fragile, thanks to architectural changes to areas that once oozed with fuzz bugs. Third, other security researchers have noticed my success and demonstrated that they can write similarly powerful fuzzers.

My fuzzers are no longer unique in their ability to find security bugs, but they are unusual in their ability to churn out reliable, reduced testcases. Each fuzzer alternates between randomly building a JS string and then evaling it. This construction makes it possible to make a reproduction file from the same generated strings. Furthermore, most DOMFuzz modules are designed so their functions will have the same effect even if other parts of the testcase are removed. As a result, a simple testcase reduction tool can reduce most testcases from 3000 lines to 3-10 lines, and I can usually finish reducing testcases in less than 15 minutes.

The ease of getting reduced testcases lets me afford to report less severe bugs. Occasionally, one of these turns out to be a security bug in disguise. But most importantly, these bug reports help me establish positive relationships with Firefox developers, by frequently saving them time.

A JavaScript engine developer can easily spend a day trying to figure out why a web site doesn't work in Firefox. If instead I can give them a simple testcase that shows an incorrect result with a new JS optimization enabled, they can quickly find the source of the bug and fix it. Similarly, they much prefer reliable assertion testcases over bug reports saying "sometimes, Google Maps crashes after a while".

Developers working on the JavaScript engine have been especially helpful. First, they ensured I could test their code directly, apart from the rest of the browser. They already had a JavaScript shell for running regression tests, and they added a --fuzzing-safe option to disable the more dangerous testing functions.

Finally, the JS team has supported differential testing, a form of fuzzing where output is checked for correctness against some oracle. In this case, the oracle is the same JavaScript engine with most of its optimizations disabled. By fixing inconsistencies quickly and supporting --enable-more-deterministic, they've ensured that differential testing doesn't get stuck finding the same problems repeatedly.

People favouriting quite agressive tweets leaves you puzzled as to the reasons

People retweeting parts of the conversation out of context leads to wrong messages and questionable quotes

140 characters are great to throw out truisms but not to make a point.

People consistenly copying you in on their arguments floods your notifications tab without really wanting to weigh in any longer

This morning was a great example: Peter Paul Koch wrote yet another incendiary post asking for a one year hiatus of browser innovation. I tweeted about the post saying it has some good points. Paul Kinlan of the Chrome team disagreed strongly with the post. I opted to agree with some of it, as a lot of features we created and thought we discarded tend to linger longer on the web than we want to.

@Paul_Kinlan: good news is that @ppk has articulated clearly how attractive failure can be. @codepo8 seems to agree. Now we can call it out.

Now, I am annoyed about that. It is accusing, calling me reactive and calls out criticism of innovation a failure. It also very aggressively hints that Alex will now always quote that to show that PPK was wrong and keeps us from evolving. Maybe. Probably. Who knows, as it is only 140 characters. But I am keeping my mouth shut, as there is no point at this agressive back and forth. It results in a lot of rushed arguments that can and will be quoted out of context. It results in assumed sub-context that can break good relationships. It – in essence – is not helpful.

If you truly disagree with something – make your point. Write a post, based on research and analysis. Don’t throw out a blanket approval or disapproval of the work of other people to spark a “conversation” that isn’t one.

Well-written thoughts lead to better quotes and deeper understanding. It takes more effort to read a whole post than to quote a tweet and add your sass.

In many cases, whilst writing the post you realise that you really don’t agree or disagree as much as you thought you did with the author. This leads to much less drama and more information.

And boy do we need more of that and less drama. We are blessed with jobs where people allow us to talk publicly, research and innovate and to question the current state. We should celebrate that and not use it for pithy bickering and trench fights.

All 37 of us gathered again on the 3rd floor in the Factory hotel here in Münster. Day two of the HTTP Workshop.

Jana Iyengar (from Google) kicked off this morning with his presentations on HTTP and the Transport Layer and QUIC. Very interesting area if you ask me – if you’re interested in this, you really should check out the video recording from the barbof they did on this topic in the recent Prague IETF. It is clear that a team with dedication, a clear use-case, a fearless approach to not necessarily maintaining “layers” and a handy control of widely used servers and clients can do funky experiments with new transport protocols.

I think there was general agreement with Jana’s statement that “Engagement with the transport community is critical” for us to really be able to bring better web protocols now and in the future. Jana’s excellent presentations were interrupted a countless number of times with questions, elaborations, concerns and sub-topics from attendees.

Gaetano Carlucci followed up with a presentation of their QUIC evaluations, showing how it performs under various situations like packet loss etc in comparison to HTTP/2. Lots of transport related discussions followed.

We rounded off the afternoon with a walk through the city (the rain stopped just minutes before we took off) to the town center where we tried some of the local beers while arguing their individual qualities. We then took off in separate directions and had dinner in smaller groups across the city.

I can see FindChar, Substring, ToInteger and even atoi, strchr, strstr and sscanf craziness all over the Mozilla code base. There are though much better and, more importantly, safer ways to parse even a very simple input.

I wrote a parser class with API derived from lexical analyzers that helps with simple inputs parsing in a very easy way. Just include mozilla/Tokenizer.h and use class mozilla::Tokenizer. It implements a subset of features of a lexical analyzer. Also nicely hides boundary checks of the input buffer from the consumer.

To describe the principal briefly: Tokenizer recognizes tokens like whole words, integers, white spaces and special characters. Consumer never works directly with the string or its characters but only with pre-parsed parts (identified tokens) returned by this class.

There are two main methods of Tokenizer:

bool Next(Token& result);

If there is anything to read from the input at the current internal read position, including the EOF, returns true and result is filled with a token type and an appropriate value easily accessible via a simple variant-like API. The internal read cursor is shifted to the start of the next token in the input before this method returns.

bool Check(const Token& tokenToTest);

If a token at the current internal read position is equal (by the type and the value) to what has been passed in the tokenToTest argument, true is returned and the internal read cursor is shifted to the next token. Otherwise (token is different than expected) false is returned and the read cursor is left unaffected.

#include "mozilla/Tokenizer.h"
using namespace mozilla;
{
// A simple list of key:value pairs delimited by commas
nsCString input("message:parse me,result:100");
// Initialize the parser with an input string
Tokenizer p(input);
// A helper var keeping type and value of the token just read
Tokenizer::Token t;
// Loop over all tokens in the input
while (p.Next(t)) {
if (t.Type() == Tokenizer::TOKEN_WORD) {
// A 'key' name found
if (!p.CheckChar(':')) {
// Must be followed by a colon
return; // unexpected character
}
// Note that here the input read position is just after the colon
// Now switch by the key string
if (t.AsString() == "message") {
// Start grabbing the value
p.Record();
// Loop until EOF or comma
while (p.Next(t) && !t.Equals(Tokenizer::Token::Char(',')))
;
// Claim the result
nsAutoCString value;
p.Claim(value);
MOZ_ASSERT(value == "parse me");
// We must revert the comma so that the code bellow recognizes the flow correctly
p.Rollback();
} else if (t.AsString() == "result") {
if (!p.Next(t) || t.Type() != Tokenizer::TOKEN_INTEGER) {
return; // expected a value and that value must be a number
}
// Get the value, here you know it's a valid number
uint32_t number = t.AsInteger();
MOZ_ASSERT(number == 100);
} else {
// Here t.AsString() is any key but 'message' or 'result', ready to be handled
}
// On comma we loop again
if (p.CheckChar(',')) {
// Note that now the read position is after the comma
continue;
}
// No comma? Then only EOF is allowed
if (p.CheckEOF()) {
// Cleanly parsed the string
break;
}
}
return; // The input is not properly formatted
}
}

Currently works only with ASCII inputs but can be easily enhanced to also support any UTF-8/16 coding or even specific code pages if needed.

Yesterday I decided to diff the export tables of some core Win32 DLLs to see what’s
changed between Windows 8.1 and the Windows 10 technical preview. There weren’t
many changes, but the ones that were there are quite exciting IMHO. While
researching these new APIs, I also stumbled across some others that were
added during the Windows 8 timeframe that we should be considering as well.

Volatile Ranges

While my diff showed these APIs as new exports for Windows 10, the MSDN docs
claim that these APIs are actually new for the Windows 8.1 Update. Using the
OfferVirtualMemory
and ReclaimVirtualMemory
functions, we can now specify ranges of virtual memory that are safe to
discarded under memory pressure. Later on, should we request that access be
restored to that memory, the kernel will either return that virtual memory to us
unmodified, or advise us that the associated pages have been discarded.

A couple of years ago we had an intern on the Perf Team who was working on
bringing this capability to Linux. I am pleasantly surprised that this is now
offered on Windows.

madvise(MADV_WILLNEED) for Win32

For the longest time we have been hacking around the absence of a madvise-like
API on Win32. On Linux we will do a madvise(MADV_WILLNEED) on memory-mapped
files when we want the kernel to read ahead. On Win32, we were opening the
backing file and then doing a series of sequential reads through the file to
force the kernel to cache the file data. As of Windows 8, we can now call
PrefetchVirtualMemory
for a similar effect.

Operation Recorder: An API for SuperFetch

The OperationStart
and OperationEnd
APIs are intended to record access patterns during a file I/O operation.
SuperFetch will then create prefetch files for the operation, enabling prefetch
capabilities above and beyond the use case of initial process startup.

Memory Pressure Notifications

This API is not actually new, but I couldn’t find any invocations of it in the
Mozilla codebase. CreateMemoryResourceNotification
allocates a kernel handle that becomes signalled when physical memory is running
low. Gecko already has facilities for handling memory pressure events on other
platforms, so we should probably add this to the Win32 port.

Securing our communications and our data is hard. Every month seems to bring new stories of mistakes and attacks resulting in our personal information being made available – bit by bit harming trust online, and making ordinary Internet users feel fear. Yet, cybersecurity public policy often seems stuck in yesterday’s solution space, focused exclusively on well known terrain, around issues such as information sharing, encryption, and critical infrastructure protection. These “elephants” of cybersecurity policy are significant issues – but too much focus on them eclipses other solutions that would allow us to secure the Internet for the future.

So, working with Camille François & DHM Research we’ve spent the past year engaging the panel of cybersecurity experts through a tailored research process to try to extract public policy ideas and see what consensus can be found around them. We weren’t aiming for full consensus (an impossible task within the security community!). Our goal was to foment ideation and exchange, to develop a user-focused and holistic cybersecurity policy agenda.

Our experts collectively generated 36 distinct policy suggestions for government action in cybersecurity. We then asked them to identify and rank their top choices of policy options by both feasibility and desirability. The result validated the importance of the “cyberelephants.” Privacy-respecting information sharing policies, effective critical infrastructure protection, and widespread availability and understanding of secure encryption programs are all important goals to pursue: they ranked high on desirability, but were generally viewed as hard to achieve.

More important are the ideas that emerged that aren’t on the radar screens of policymakers today. First and foremost was a proposal that stood out above the others as both highly desirable and highly feasible: increased funding to maintain the security of free and open source software. Although not high on many security policy agendas, the issue deserves attention. After all, 2014’s major security incidents around Poodle, Heartbleed, and Shellshock all centered on vulnerabilities in open source software. Moreover, open source software libraries are built into countless noncommercial and commercial products.

Many other good proposals and priorities surfaced through the process, including: developing and deploying alternative authentication mechanisms other than passwords; improving the integrity of public key infrastructure; and making secure communications tools easier to use. Another unexpected policy priority area highlighted by all segments of our expert panel as highly feasible and desirable was norm development, including norms concerning governments’ and corporations’ behavior in cyberspace, guided by human rights and communicated with maximum clarity in national and international contexts.

This report is not meant to be a comprehensive analysis of all cybersecurity public policy issues. Rather, it’s meant as a first, significant step towards a broader, collaborative policy conversation around the real security problems facing Internet users today.

At Mozilla, we will build on the ideas that emerged from this process, and hope to work with policymakers and others to develop a holistic, effective, user-centric cybersecurity public policy agenda going forward.

This research was made possible by a generous grant from the John D. and Catherine T. MacArthur Foundation.

Good times

People sometimes say “morning” or “evening” on IRC for a time zone unlike my
own. Here’s a bash one-liner that emits the correct time-of-day generalization
based on the datetime settings of the machine you run it on.

July 27, 2015

This post is aimed at Firefox Nightly users who also use the Tree Style Tab extension. Bug 909154 landed last week. It removed support for the prefixed mozRequestionAnimationFrame function, and broke Tree Style Tab. The GitHub repository that hosts Tree Style Tab’s code has been updated, but that has not yet made it into the latest Tree Style Tab build, which has version number 0.15.2015061300a003855.

Fortunately, it’s fairly easy to modify your installed version of Tree Style Tab to fix this problem. (“Fairly easy”, at least, for the technically-minded users who run Firefox Nightly.)

Find the Tree Style Tabs .xpi file. On my Linux machine, it’s at ~/.mozilla/firefox/ndbcibpq.default-1416274259667/extensions/treestyletab@piro.sakura.ne.jp.xpi. Your profile name will not be exactly the same. (In general, you can find your profile with these instructions.)

That file is a zip file. Edit the modules/lib/animationManager.js file within that file, and change the two occurrences of mozRequestAnimationFrame to requestAnimationFrame. Save the change.

I did the editing in vim, which was easy because vim has the ability to edit zip files in place. If your editor does not support that, it might work if you unzip the code, edit the file directly, and then rezip, but I haven’t tried that myself. Good luck.

Buildduty is the Mozilla release engineering (releng) equivalent of front-line support. It’s made up of a multitude of small tasks, none of which on their own are particulary complex or demanding, but taken in aggregate can amount to a lot of work.

It’s also non-deterministic. One of the most important buildduty tasks is acting as information brokers during tree closures and outages, making sure sheriffs, developers, and IT staff have the information they need. When outages happen, they supercede all other work. You may have planned to get through the backlog of buildduty tasks today, but congratulations, now you’re dealing with a network outage instead.

Releng has struggled to find a sustainable model for staffing buildduty. The struggle has been two-fold: finding engineers to do the work, and finding a duration for a buildduty rotation that doesn’t keep the engineer out of their regular workflow for too long.

I’m a firm believer that engineers *need* to be exposed to the consequences of the software they write and the systems they design:

DevOpsSupport - You write the software, you get a shift carrying the pager for it, and you get a shift answering customer calls about it.

I also believe that it’s a valuable skill to be able to design a system and document it sufficiently so that it can be handed off to someone else to maintain.

Starting this week, we’re trying something new. We’re shifting at least part of the burden to management: I am now managing a pair of contractors who will be responsible for buildduty for the rest of 2015.

Alin and Vlad are our new contractors, and are both based in Romania. Their offset from Mozilla Standard Time (aka PST) will allow them to tackle the asynchronous activities of buildduty, namely slave loans, non-urgent developer requests, and maintaining the health of the machine pools.

It will take them a few weeks to find their feet since they are unfamiliar with any of the systems. You can find them on IRC in the usual places (#releng and #buildduty). Their IRC nicks are aselagea and vladC. Hopefully they will both be comfortable enough to append |buildduty to those nicks soon. :)

While Alin and Vlad get up to speed, buildduty continues as usual in #releng. If you have an issue that needs buildduty assistance, please ask in #releng, and someone from releng will assist you as quickly as possible. For less urgent requests, please file a bug.

So we started today. I won’t get into any live details or quotes from the day since it has all been informal and we’ve all agreed to not expose snippets from here without checking properly first. There will be a detailed report put together from this event afterwards.

The most critical peace of information is however how we must not walk on the red parts of the sidewalks here in Münster, as that’s the bicycle lane and they can be ruthless there.

We’ve had a bunch of presentations today with associated Q&A and follow-up discussions. Roy Fielding (HTTP spec pioneer) started out the series with a look at HTTP full of historic details and views from the past and where we are and what we’ve gone through over the years. Patrick Mcmanus (of Firefox HTTP networking) took us through some of the quirks of what a modern day browser has to do to speak HTTP and topped it off with a quiz regrading Firefox metrics. Did you know 31% of all Firefox HTTP requests get fulfilled by the cache or that 73% of all Firfox HTTP/2 connections are used more than once but only 7% of the HTTP/1 ones?

Poul-Henning Kamp (author of Varnish) brought his view on HTTP/2 from an intermediary’s point of view with a slightly pessimistic view, not totally unlike what he’s published before. Stefan Eissing (from Green Bytes) entertained us by talking about his work on writing mod_h2 for Apache Httpd (and how it might be included in the coming 2.4.x release) and we got to discuss a bit around timing measurements and its difficulties.

We spent the evening having a 5-course (!) meal at a nice Italian restaurant while trading war stories about HTTP, networking and the web. Now it is close to midnight and it is time to reload and get ready for another busy day tomorrow.

I’ll round off with a picture of where most of the important conversations were had today:

As promised, the FTP Migration team is following up from the 7/20 Monday Project Meeting where Sean Rich talked about a project that is underway to make our Product Delivery System better.

As a part of this project, we are migrating content out of our data centers to AWS. In addition to storage locations changing, namespaces will change and the FTP protocol for this system will be deprecated. If, after reading this post, you have any further questions, please email the team.

Action: The ftp protocol on ftp.mozilla.org is being turned off.Timing: Wednesday, 5th August 2015.Impacts:

After 8/5/15, ftp protocol support for ftp.mozilla.org will be completely disabled and downloads can only be accessed through http/https.

Users will no longer be able to just enter “ftp.mozilla.org” into their browser, because this action defaults to the ftp protocol. Going forward, users should start using archive.mozilla.org. The old name will still work but needs to be entered in your browser as https://ftp.mozilla.org/

Action: The contents of ftp.mozilla.org are being migrated from the NetApp in SCL3 to AWS/S3 managed by Cloud Services.Timing: Migrating ftp.mozilla.org contents will start in late August and conclude by end of October. Impacted teams will be notified of their migration date.Impacts:

Those teams that currently manually upload to these locations have been contacted and will be provided with S3 API keys. They will be notified prior to their migration date and given a chance to validate their upload functionality post-migration.

All existing download links will continue to work as they do now with no impact.

Developing a long term Mozilla Learning strategy has been my big focus over the last three months. Working closely with people across our community, we’ve come up with a clear, simple goal for our work:universal web literacy. We’ve also defined ‘leadership’ and ‘advocacy’ as our two top level strategies for pursuing this goal. The use of ‘partnerships and networks’ will also be key to our efforts. These are the core elements that will make up the Mozilla Learning strategy.

Over the last month, I’ve summarized our thinking on Mozilla Learning for the Mozilla Board and a number of other internal audiences. This video is based on these presentations:

As you’ll see in the slides, our goal for Mozilla Learning is an ambitious one: make sure everyone knows how to read, write and participate on the web. In this case, everyone = the five billion people who will be online by 2025.

Mozilla can’t create universal web literacy on its own. All of our leadership and advocacy work will involve ‘open source’ partners with whom we’ll create a global network committed to universal web literacy.

Process-wise: we arrived at this high level strategy by looking at our existing programs and assets. We’ve been working on web literacy, leadership development and open internet advocacy for about five years now. So, we already have a lot in play. What’s needed right now is a way to focus all of our efforts in a way that will increase their impact — and that will build a real snowball of people, organizations and governments working on the web literacy agenda.

The next phase of Mozilla Learning strategy development will dig deeper on ‘how’ we will do this. I’ll provide a quick intro post on that next step in the coming days.

> Hello all,>> We are planning to turn on a service that automatically backfills> failed test jobs on m-i. If there are no concerns, we would like to> turn this on experimentally for a couple of hours on [Tuesday]. We> hope this will make it easier to identify which revision broke a> test. Suggestions are welcome.>> The backfilling works like this: - It triggers the job that failed> one extra time - Then it looks for a successful run of the job on the> previous 5 revisions. If a good run is found, it triggers the job> only on revisions up to this good run. If not, it triggers the job on> every one of the previous 5 revisions. Previous jobs will be> triggered one time.>> The tracking bug is:> https://bugzilla.mozilla.org/show_bug.cgi?id=1180732>> Best, Alice

Being part of the Reps Council is a great experience, it is at the same time an honour and a challenge and it comes with a lot of responsibility, hard work, but also lessons and growth.

We want to thank and recognize our most recent former Reps Council members for serving their one year term bringing all the their passions, knowledge and dedication to the program and making it more powerful.

Emma Irwin

Emma was a great inspiration not only for Reps, but specially for mentors and the Council. Her passion for education and empowering volunteers allowed her to push the program to be much more centered towards education and growth, marking a new era for Reps.

She was not only advocating for it, but also rolling up her sleeves and running different trainings, creating curriculum and working towards improving the mentorship culture. She was also extremely helpful helping us navigate some conflicts and getting Reps to grow and put aside differences.

Arturo Martinez

Arturo’s unchallenged energy and drive were great additions to the Council. Specially during his term as Council Chair he set the standard for effectively driving initiatives, helping everyone to achieve their goals and pushing us to be excellent. Thank you for the productivity boost!

Gauthamraj Elango

Raj’s passion for Web literacy and for empowering everyone to take part of the open web helped him lead Reps program to work more closely with Webmaker team, showcasing an example on how Reps can bring much more value to initiatives. He drove efforts to innovate our initiatives both in terms of local organization and funding.

These are just a few examples of their exemplary work as Council members, that not only helped Reps all around the world to step up and have more impact, but also inspired new Mozillians and all the Reps around the world on how to lead change for the open Web.

Once again, thank you so much for your time, effort and your passion, you left an outstanding mark in the program.

Hello and welcome to another issue of This Week in Rust!
Rust is a systems language pursuing the trifecta:
safety, concurrency, and speed. This is a weekly summary of its progress and
community. Want something mentioned? Tweet us at @ThisWeekInRust or send us an
email!
Want to get involved? We love
contributions.

This is a short introduction to mach try, a mach command that simplifies the process of selecting tests and pushing them to the try server.

To follow along at home you’ll either need to be using git cinnabar or have a modern mercurial and the hg “push-to-try” extension (available from |mach mercurial-setup|). Append —no-push to commands to keep them from pushing to the try server, and -n to see verbose messages associated with the results of commands.

# mach try is a command that takes try syntax and automates the steps
# to push the current tree to try with that syntax.
# For instance:
$ ./mach try -p win32 -u mochitest-bc
# ... will result in pushing "try: -b do -p win32 -u mochitest-bc -t none"
# to try. This saves dealing with mq or other ways of generating the try
# message commit. (An in-memory commit is generated with the appropriate
# message -- mq is not invoked at any stage).
# The more novel feature exposed by mach try is the ability to select
# specific test directories containing xpcshell, mochitests or reftests
# to run on the try server.
# For instance, if I've just made a change to one of the python libraries
# used by our test harnesses, and I'd like to quickly check that this
# feature works on windows. I can run:
$ ./mach try -p win64 testing/xpcshell testing/mochitest/tests
# This will result in the small number of xpcshell and mochitest tests
# that live next to their harnesses being run (in a single chunk) on
# try, so I can get my results without waiting for the entire suite,
# and I don't need to sift through logs to figure out which chunk a
# test lives in when I only care about running certain tests.

For more details run ./mach help try. As the command will inform you, this feature is under development — bugs should be filed blocking bug 1149670).

July 26, 2015

I produce a fair amount of open source code. I make that code available online. curl is probably the most popular package.

People ask me how they can trust that they are actually downloading what I put up there. People ask me when my source code can be retrieved over HTTPS. Signatures and hashes don’t add a lot against attacks when they all also are fetched over HTTP…

HTTPS

I really and truly want to offer HTTPS (only) for all my sites. I and my friends run a whole busload of sites on the same physical machine and IP address (www.haxx.se, daniel.haxx.se, curl.haxx.se, c-ares.haxx.se, cool.haxx.se, libssh2.org and many more) so I would like a solution that works for all of them.

I can do this by buying certs, either a lot of individual ones or a few wildcard ones and then all servers would be covered. But the cost and the inconvenience of needing a lot of different things to make everything work has put me off. Especially since I’ve learned that there is a better solution in the works!

Let’s Encrypt will not only solve the problem for us from a cost perspective, but they also promise to solve some of the quirks on the technical side as well. They say they will ship certificates by September 2015 and that has made me wait for that option rather than rolling up my sleeves to solve the problem with my own sweat and money. Of course there’s a risk that they are delayed, but I’m not running against a hard deadline myself here.

HTTP/2

Related, I’ve been much involved in the HTTP/2 development and I host my “http2 explained” document on my still non-HTTPS site. I get a lot of questions (and some mocking) about why my HTTP/2 documentation isn’t itself available over HTTP/2. I would really like to offer it over HTTP/2.

Since all the browsers only do HTTP/2 over HTTPS, a prerequisite here is that I get HTTPS up and running first. See above.

Once HTTPS is in place, I want to get HTTP/2 going as well. I still run good old Apache here so it might be done using mod_h2 or perhaps with a fronting nghttp2 proxy. We’ll see.

I’ve traveled to a rainy and gray Münster, Germany, today and checked in to my hotel for the coming week and the HTTP Workshop. Tomorrow is the first day and I’m looking forward to it probably a little too much.

There is a whole bunch of attendees coming. Simply put, most of the world’s best brains and the most eager implementers of the HTTP stacks that are in use today and will be in use tomorrow (with a bunch of notable absentees of course but you know you’ll be missed). I’m happy and thrilled to be able to take part during this coming week.

MIG is a distributed forensics framework we built at Mozilla to keep an eye on our infrastructure. MIG can run investigations on thousands of servers very quickly, and focuses on providing low-level access to remote systems, without giving the investigator access to raw data.

As I was recently presenting MIG at the DFIR Summit in Austin, someone in the audience asked if it could be used to detect unknown or rogue systems inside a network. The best way to perform that kind of detection is to watch the network, particularly for outbound connections rogue hosts or malware would establish to a C&C server. But MIG can also help the detection by inspecting ARP tables of remote systems and cross-referencing the results with local mac addresses on known systems. Any MAC address not configured on a known system is potentially a rogue agent.

First, we want to retrieve all the MAC addresses from the ARP tables of known systems. The netstat module can perform this task by looking for neighbor MACs that match regex "^[0-9a-f]", which will match anything hexadecimal.

$ mig netstat -nm "^[0-9a-f]" > /tmp/seenmacs

We store the results in /tmp/seenmacs and pull a list of unique MACs using some bash.

We now want to check that every single one of the seen MAC addresses is configured on a known agent. Again, the netstat module can be used for this task, this time by querying local mac addresses with the -lm flag.

Now the list of MACs may be quite long, so instead of running one MIG query per MAC, we group them 50 by 50 using the following script:

The script will build MIG netstat command with 50 arguments max. Invoke it with /tmp/seenmacs as argument 1, and an output file as argument 2.

$ bash /tmp/makemigmac.sh /tmp/seenmacs /tmp/migsearchmacs

/tmp/migsearchmacs now contains a number of MIG netstat commands that will search seen MAC addresses across the configured interfaces of known hosts. Run the commands and pipe the output to a results file.

We now have a file with seen MAC addresses, and another one with MAC addresses configured on known systems. Doing the delta of the two is fairly easy in bash:

$ for seenmac in $(awk '{print tolower($5)}' /tmp/seenmacs|sort|uniq); do hasseen=""; hasseen=$(grep $seenmac /tmp/migfoundmacs) if [ "$hasseen" == "" ]; then echo "$seenmac is not accounted for" fidone00:21:59:96:75:7f is not accounted for00:21:59:98:d5:bf is not accounted for00:21:59:9c:c0:bf is not accounted for00:21:59:9e:3c:3f is not accounted for00:22:64:0e:72:71 is not accounted for00:23:47:ca:f7:40 is not accounted for00:25:61:d2:1b:c0 is not accounted for00:25:b4:1c:c8:1d is not accounted for

Automating the detection

It's probably a good idea to run this procedure on a regular basis. The script below will automate the steps and produce a report you can easily email to your favorite security team.

#!/usr/bin/env bashSEENMACS=$(mktemp)SEARCHMACS=$(mktemp)FOUNDMACS=$(mktemp)echo "seen mac addresses are in $SEENMACS"echo "search commands are in $SEARCHMACS"echo "found mac addresses are in $FOUNDMACS"

The list of unknown MACs can then be used to investigate the endpoints. They could be switches, routers or other network devices that don't run the MIG agent. Or they could be rogue endpoints that you should keep an eye on.

I had an exhausting but fun weekend at the Athens Startup Weekend a few days ago. Along with Christos I joined Yannis, Panagiotis Christakos and Babis Makrinikolas on the Newspeek project. When Yannis pitched the idea on Friday night, the main concept was to create a mobile phone application that would provide a better way to view news on the go. I don't believe it was very clear in his mind then, what would constitute a "better" experience, but after some chatting about it we all defined a few key aspects, which we refined later with lots of useful feedback and help from George. Surprisingly, for me at least, in only two days we managed to design, build and present a working prototype in front of the judges and the other teams. And even though the demo wasn't exactly on par with our accomplishments, I'm still amazed at what can be created in such a short time frame.

Newspeek, our product, had a server-side component that periodically collected news items from various news feeds, stored them and provided them to clients through a simple REST API. It also had an iPhone client that fetched the news items and presented them to the user in a way that respected the UI requirements and established UX norms for that device.

So, in the interest of informing future participants about what works and what doesn't work in Startup Weekend, here are the lessons I learned:

If you plan to win, work on the business aspect, not on the technology. Personally, I didn't go to ASW with plans to create a startup, so I didn't care that much about winning. I mostly considered the event as a hackathon, and tried my best to end up with a working prototype. Other teams focused more on the business side of things, which is understandable, given the prize. Investors fund teams that have a good chance to return a profit, not the ones with cool technology and (mostly) working demos. Still, the small number of actual working prototypes was a disappointment for me. Even though the developers were the majority in the event, you obviously can't have too many of them in a Startup Weekend.

For quick server-side prototyping and hosting, Google App Engine is your friend. Since everyone in the team had Java experience, we could have gone with a JavaEE solution and set up a dedicated server to host the site. But, since I've always wanted to try App Engine for Java and the service architecture mapped nicely to it, we tried a short experiment to see if it could fly. We built a stub service in just a few minutes, so we decided it was well worth it. Building our RESTful service was really fast, scalability was never a concern and the deployment solution was a godsend, since the hosting service provided for free by the event sponsors was evidently overloaded. We're definitely going to use it again for other projects.

jQTouch rocks! Since our main deliverable would be an iPhone application, and there were only two of us who had ever built an iPhone application (of the Hello World variety), we knew we had a problem. Fortunately, I had followed the jQTouch development from a reasonable distance and had witnessedthegoodthings people had to say, so I pitched the idea of a web application to the team and it was well received. iPhone applications built with web technologies and jQTouch can be almost indistinguishable from native ones. We all had some experience in building web applications, so the prospect of having a working prototype in only two days seemed within the realm of possibility again. The future option of packaging the application with PhoneGap and selling it in the App Store was also a bonus point for our modest business plan.

For ad-hoc collaboration, Mercurial wins. Without time to set up central repositories, a DVCS was the obvious choice, and Mercurial has both bundles and a standalone server that make collaborative coding a breeze. If we had zeroconf/bonjour set up in all of our laptops, we would have used the zeroconf extension for dead easy machine lookup, but even without it things worked flawlessly.

You can write code with a netbook. Since I haven't owned a laptop for the last three years, my only portable computer is an Asus EEE PC 901 running Linux. Its original purpose was to allow me to browse the web from the comfort of my couch. Lately however, I'm finding myself using it to write software more than anything else. During the Startup Weekend it had constantly open Eclipse (for server-side code), Firefox (for JavaScript debugging), Chrome (for webkit rendering), gedit (for client-side code) and a terminal, without breaking a sweat.

When demoing an iPhone application, whatever you do, don't sweat. Half-way through our presentation, tapping the buttons didn't work reliably all the time, so anxiety ensued. Since we couldn't make a proper presentation due to a missing cable, we opted for a live demo, wherein Yannis held the mic and made the presentation, and I posed as the bimbo that holds the product and clicks around. After a while we ended up both touching the screen, trying to make the bloody buttons click, which ensured the opposite effect. In retrospect, using a cloth occasionally would have made for a smoother demo, plus we could have slipped a joke in there, to keep the spirit up.

All in all it was an awesome experience, where we learned how far we can stretch ourselves, made new friends and caught up with old ones. Next year, I'll make sure I have a napkin, too.

Planet Mozilla

Collected here are the most recent blog posts from all over the Mozilla community.
The content here is unfiltered and uncensored, and represents the views of individual community members.
Individual posts are owned by their authors -- see original source for licensing information.