The Participation team, along with a number of stakeholders throughout Mozilla, have been working hard on a program to ignite Firefox OS as a from-the-ground-up project to continue momentum building a first-class mobile platform. In 2015 as we are building out the next phase of Firefox OS, it is a crucial time and we want you to be there to shape the future.

We are really excited to let you know that next week we will be launching a renewed program to support Firefox OS Participation, and we want to give you a sneak peek of what’s coming.

As a way to unify all participation opportunities we will be launching the Firefox OS Participation Hub as a central site where you can discover how to get involved with Firefox OS and install the latest version on your device. The central contribution areas that the hub will be showcasing are Foxfooding (our take on dogfooding), ports to Android and other devices, b2gDroid, Gaia development, and Firefox OS add-ons. The goal is not to displace other sources of information, but to make it more accessible from a central location.

If you have a compatible device (they will be listed on the Hub), we want you to be able to experience, test and hack the latest version of Firefox OS (2.5) along with all the new features that are coming. Just by becoming a Foxfooder, you are helping shape the future of Firefox OS, and deeper opportunities will surface –  from filing bugs, to joining discussions, to developing for the platform and on top of it. Community participation is key in this new phase.

In preparation for launch, get your Flame devices ready. If you don’t have one, there will be a limited number of new Foxfooding devices that you can apply for if you commit to being a regular user. We’ll also be showcasing exciting ports for some existing Android devices on the market. We have opened a new discourse category that will be the central place for discussions about this program, if you are interested we recommend you to log in with your Mozillian account and select “Watching” from the top right blue bubble so you can get email notifications about everything that is happening there.

This truly has been a team effort. We pulled in members from engineering, developer relations, engagement, legal, research, metrics, and other teams who are fully invested in the open evolution of Firefox OS. Join us and you can play an important role in it’s success.

Join the discussion.

http://brian.kingsonline.net/talk/2015/11/foxfooding-preview/

In case any of my colleagues haven’t heard, I no longer work at Mozilla. I apologize for not sending out a company-wide farewell email. I wasn’t expecting my email access to be cut off so promptly.

Hence, this is no longer my work blog, but I still hope to contribute to the Mozilla Project (I am working on some patches as we speak), and I will continue to blog here about tech-related topics (and especially Firefox-related topics) on the occasion that I have something to say.

https://tedclancy.wordpress.com/2015/11/04/rebranding/

Beyond Openhatch

OpenHatch is a wonderful place to help new contributors find their first open source issues to work on. Their training materials are unparalleled, and the “projects submit easy bugs with mentors” model makes their list of introductory issues reliably high-quality.

However, once you know the basics of how to engage with an open source project, you’re no longer in the target audience for OpenHatch’s list. Where should you look for introductory issues when you want to get involved with a new project, but you’re already familiar with open source in general?

An excellent slide deck by Josh Matthews contains several answers to this question:

• issuehub.io scrapes GitHub by labels and language
• up-for-grabs has an opt-in list of projects looking for new contributors, and scrapes their issue trackers for their “jump in”, “up for grabs” or other “new contributors welcome” tags.
• If you’re looking for Mozilla-specific contributions outside of just code, What can I do for Mozilla? can help direct you into any of Mozilla’s myriad opportunities for involvement.

Additionally, the servo-starters page has a custom view of easy issues sorted by Servo’s project-specific tags.

http://edunham.net/2015/11/04/beyond_openhatch.html

To help prevent repetitive stress injury from hitting “refresh” continuously, Mozilla contributor Archaeopteryx built an add-on that puts a counter for end of year fundraising right in the Firefox browser toolbar. Our campaign ramps up November 15 and we’re aiming … Continue reading

https://fundraising.mozilla.org/use-this-firefox-add-on-to-follow-the-eoy-campaign/

View Source is a brand new conference for web developers, presented by Mozilla and friends, produced by the folks who also bring you the Mozilla...

https://air.mozilla.org/view-source-tuesday-pm-session/

This post is entirely my personal opinion.

Linus Torvalds wrote a 541 word abusive rant about two lines of code he didn’t like.

J. David Eisenberg rewrote it to show how the same opinion could be expressed in an equally direct, but non-abusive fashion. At 180 words, it’s almost exactly 1/3 the length of Linus’s original, and much clearer.

As a complementary exercise, I extracted the overtly abusive parts of Linus’s text (103 words) and put them here. (Coarse language alert!)

I consider this kind of abuse indefensible. Nonetheless, I’ve seen multiple people defending and even celebrating it. (One outlet called it an “epic rant”.) Of the many things I could say about this, I will say just one: sadly, I am certain the reaction to this text would be entirely different were it written by a woman.

I will moderate the comment thread below this post with enthusiasm. I won’t hesitate to delete comments that are hurtful, abusive, or otherwise objectionable to me. Please think before commenting.

https://blog.mozilla.org/nnethercote/2015/11/04/abuse-is-indefensible/

Once a month web developers across the Mozilla community get together (in person and virtually) to share what cool stuff we've been working on.

https://air.mozilla.org/webdev-extravaganza-november-2015/

(Continuing from last time).

procedural macros

Also known as syntax extensions or syntax plugins or compiler plugins (which they are just a category of). I'll not get into the naming thing here, but I'll try and stick to 'procedural macro'. Procedural macros are implemented using pure Rust code at the meta level, rather than being written in the 'macro by example' syntax. They are extremely powerful since the output can be anything you can express as an AST. However, they are a bit rough around the edges and you have to use compiler internals (directly or indirectly), so they are subject to breaking changes. Therefore, procedural macros are not yet a stable part of the language (although we're working on it, more in later blog posts).

Unlike macro_rules macros which can only be used in one way, procedural macro uses can look very different. They can appear (like macro_rules macros) as function-like: foo!(...), they can be function-like with an ident: foo! bar (...) (like macro_rules itself, which looks like this), or they can look like attributes: #[foo(...)]. Attribute-like macros are defined by the following grammar:

attribute-like-macro ::= #[item] | #![item]  
item ::= name | name = lit | name(item,*)  

where lit is any Rust literal, e.g., a string, integer, floating point number, etc.

To use a procedural macro, it must be in scope. Rather than using extern crate (which pulls in a crate for runtime use), we use #![plugin(foo)] to load foo for use at compile time. Since procedural macros are unstable, you must also add #![feature(plugin)] to your crate to allow their use (and be using a nightly version of the compiler).

implementing a procedural macro

To implement a procedural macro, you implement a Rust trait, either by writing a function or by providing an expand method. There are several different traits you can implement, corresponding to the different kinds of macro:

• MultiItemModifier an attribute-like macro which modifies the item it is attached to.
• MultiItemDecorator an attribute-like macro which only creates new items. The Multi prefix in these two kinds is an historical artifact and should be removed.
• TTMacroExpander a function-like macro which takes a token tree (basically a list of tokens, more on these in a later blog post).
• IdentMacroExpander a function-like macro which takes an identifier and a token tree.
• MacroRulesTT you shouldn't implement this one, it is just for defining macro_rules, listed here for completeness.

See base.rs for the details of these traits. Also in that file is the SyntaxExtension enum which has a variant for each kind of procedural macro and keeps a trait object and some other details.

You then register the implementation with the plugin registry, which allows users of the macro to access it. To do this you need a function which takes a rustc::plugin::Registry argument and has the #[plugin_registrar] attribute. In this function you register your macros. If the argument is called reg, then you call reg.register_syntax_extension passing an interned string for the name of the macro (e.g., ::syntax::parse::token::intern("foo")) and an instance of the SyntaxExtension enum. To do all this, you'll need the #![feature(plugin_registrar)] feature gate.

constructing code

Attribute-like macros operate on an AST node, given by the Annotatable enum. They also take an ast::MetaItem which contains any data passed to the attribute (see the item category in the little grammar above). They return an Annotatable. Function-like macros operate on a token tree and return an implementation of MacResult, this can return various kinds of AST node. So, macros take either an AST node or tokens and produce AST nodes.

When implementing the macro, you have various choices for constructing the AST output. The simplest way is to do it manually by assembling the various AST nodes (see ast.rs to see what they look like). This is pretty tedious. For most uses, it is quicker to use an AstBuilder, defined in build.rs, the usual implementor is ExtCtxt, which is passed in to your macro function.

The most convenient approach is quasi-quoting, you use the quote_expr, quote_stmt, quote_item, etc. macros which take an ExtCtxt and a bunch of tokens. The quasi-quoter parses the tokens and gives you AST nodes. You can even embed AST nodes you've created elsewhere in the input by using $foo where foo is a variable in scope which contains an AST node. For example,

let arg = ast::Expr { ... };  
let call = quote_expr!(ctxt, foo.m($arg));  

Here, call will be the AST for a an expression calling foo.m() with the actual argument given by the arg AST.

Finally, you could use a third party library. The only one I know of is ASTer which makes heavy use of the builder pattern and is (depending on your use case) usually more ergonomic than Rust's AstBuilder.

Talking of ASTer, it is worth mentioning Syntex, which ASTer can work with. This is a fork of libsyntax which allows you to use procedural macros with stable Rust via a pre-processing step. Note that there are limitations to this approach - the Rust compiler doesn't know about its expansion, so you don't get as much error information, and it does not cooperate with Rust's hygiene mechanism.

error handling

You can emit compile-time errors and warnings from procedural macros if there are errors in the input. There are methods on the ExtCtxt, such as span_err, which issue an error for a given span in the source code. If you cause an error, you must still return some result: function-like macros can return a DummyResult, attribute-like ones can usually just return the input - it won't be used for anything (as far as I know). Issuing an error will mean compilation stops after macro expansion.

You should not panic in a procedural macro, since doing so will cause the compiler to crash (ICE).

examples

For an example of putting all this together, see libhoare. This is a library of procedural macros I wrote for addding pre- and postconditions to functions and methods. The various macros are all MultiItemModifiers since they modify the functions they are attached to in order to add the pre- and postcondition code. Note that part of that code involves inserting macro uses (assert!), which are handled correctly by expansion.

Other examples of procedural macros are compile-time regexes and in HTML5ever.

built-in macros

Built-in macros look like regular macros when you use them, but are implemented inside the compiler, rather than in an external library. They are defined in libsyntax/ext and registered in ext::base::initial_syntax_expander_table. Some, such as include!, are explicitly declared in std::macros::builtin for documentation purposes. Others, such as asm! and #[derive(...)], are not. There is also #[cfg(...)], which acts like a macro but is deeply built-in to the compiler.

other ways to extend the compiler

Although these are not macros in any sense, for completeness I think it is worth mentioning other ways in which the compiler can be extended. These are all registered with the plugin registrar in the same way as procedural macros.

Lints are custom checks that the compiler runs on your code. They can be configured to warn or produce an error, or be ignored. They typically check for style issues or for common gotchas - which are not errors in the usual sense, but usually represent a mistake (such as an unused variable). Many are supplied with the compiler, others can be used from a library, such as Clippy. Lints can also be grouped into lint groups. Lints run later in the compiler than macros, either after expansion and before the analysis phase (operating on the AST), or at the end of the analysis phase, after all type checking is complete, but before we start generating code (operating on the HIR).

You can also register additional LLVM passes for the compiler to run. This has been used to run American Fuzzy Lop. This facility does not seem to be well-documented.

Finally, for the ultimate customisation experience, you can use the compiler as a library. For more information, see this tutorial and demo which collects some simple statistics for Rust programs.

http://www.ncameron.org/blog/macros-in-rust-pt2/

View Source is a brand new conference for web developers, presented by Mozilla and friends, produced by the folks who also bring you the Mozilla...

https://air.mozilla.org/view-source-tuesday-mid-morning-session/

http://danielpocock.com/how-much-of-linux-will-be-illegal-in-the-uk

View Source is a brand new conference for web developers, presented by Mozilla and friends, produced by the folks who also bring you the Mozilla...

https://air.mozilla.org/view-source-tuesday-am-session/

Join us for this showcase of various ways Mozilla is helping users Take Back control of their web experience!

https://air.mozilla.org/rally-for-the-user/

It’s been a while since I wrote anything on my blog about technology or the Web (indeed, the last several posts I’ve written have been my 5-word movie reviews. While fun, these aren’t very informative to the primary audience of my blog: you, the (probably) Web developer, genius type.

A lot has changed in the last few months. We’ve got so many exciting new technologies and APIs to play with. Not to mention ECMAScript 6 (a.k.a. ECMAScript 2015, a.k.a. the latest version of JavaScript). In ES6, the big new toys, for me, are Promises and arrow functions. Both take some getting used to, but once you do, they make a huge difference in code readability and despite feeling alien and weird to my old procedural programming brain, they still make code just plain better.

Add to that all the amazing new APIs, including WebRTC, Web Notifications, Service Workers, the Push API, and so much more, and my mind boggles at the immense power of the Web in this day and age.

I was in college when the Web first exploded into existence. Back then, it was mostly a thing students and researchers played with, but I already knew it was going to change the world. And it has.

I’ll try to get back into the habit of blogging more regularly; there’s far too much exciting stuff to talk about to let my blog stay idle any longer.

http://www.bitstampede.com/2015/11/03/the-web-now-with-500-more-amazing-goodness/

This article has been coauthored by Aislinn Grigas, Senior Interaction Designer, Firefox Desktop

Over the past few months, Mozilla has been improving the user experience of our privacy and security features in Firefox. One specific initiative has focused on the feedback shown in our address bar around a site’s security. The major changes are highlighted below along with the rationale behind each change.

Change to DV Certificate treatment in the address bar

Color and iconography is commonly used today to communicate to users when a site is secure. The most widely used patterns are coloring a lock icon and parts of the address bar green. This treatment has a straightforward rationale given green = good in most cultures. Firefox has historically used two different color treatments for the lock icon – a gray lock for Domain-validated (DV) certificates and a green lock for Extended Validation (EV) certificates. The average user is likely not going to understand this color distinction between EV and DV certificates. The overarching message we want users to take from both certificate states is that their connection to the site is secure. We’re therefore updating the color of the lock when a DV certificate is used to match that of an EV certificate.

Although the same green icon will be used, the UI for a site using EV certificates will continue to differ from a site using a DV certificate. Specifically, EV certificates are used when Certificate Authorities (CA) verify the owner of a domain. Hence, we will continue to include the organization name verified by the CA in the address bar.

Changes to Mixed Content Blocker UI on HTTPS sites

A second change we’re introducing addresses what happens when a page served over a secure connection contains Mixed Content. Firefox’s Mixed Content Blocker proactively blocks Mixed Active Content by default. Users historically saw a shield icon when Mixed Active Content was blocked and were given the option to disable the protection.

Since the Mixed Content state is closely tied to site security, the information should be communicated in one place instead of having two separate icons. Moreover, we have seen that the number of times users override mixed content protection is slim, and hence the need for dedicated mixed content iconography is diminishing. Firefox is also using the shield icon for another feature in Private Browsing Mode and we want to avoid making the iconography ambiguous.

The updated design that ships with Firefox 42 combines the lock icon with a warning sign which represents Mixed Content. When Firefox blocks Mixed Active Content, we retain the green lock since the HTTP content is blocked and hence the site remains secure.

For users who want to learn more about a site’s security state, we have added an informational panel to further explain differences in page security. This panel appears anytime a user clicks on the lock icon in the address bar.

Previously users could click on the shield icon in the rare case they needed to override mixed content protection. With this new UI, users can still do this by clicking the arrow icon to expose more information about the site security, along with a disable protection button.

Loading Mixed Passive Content on HTTPS sites

There is a second category of Mixed Content called Mixed Passive Content. Firefox does not block Mixed Passive Content by default. However, when it is loaded on an HTTPS page, we let the user know with iconography and text. In previous versions of Firefox, we used a gray warning sign to reflect this case.

We have updated this iconography in Firefox 42 to a gray lock with a yellow warning sign. We degrade the lock from green to gray to emphasize that the site is no longer completely secure. In addition, we use a vibrant color for the warning icon to amplify that there is something wrong with the security state of the page.

We also use this iconography when the certificate or TLS connection used by the website relies on deprecated cryptographic algorithms.

The above changes will be rolled out in Firefox 42. Overall, the design improvements make it simpler for our users to understand whether or not their interactions with a site are secure.

Firefox Mobile

We have made similar changes to the site security indicators in Firefox for Android, which you can learn more about here.

https://blog.mozilla.org/security/2015/11/03/updated-firefox-security-indicators-2/

We'll be called into Program Management to be sure all deliverables for the Firefox Fall Campaign GoLive in unison.

https://air.mozilla.org/firefox-fall-campaign-go-live/

With the release of Firefox 42, we are pleased to welcome the 41 developers who contributed their first code change to Firefox in this release, 26 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

• bstoroz: 1173089, 1185005, 1186465
• mkierski: 1135708
• nhughes: 986302, 1136727
• utvar: 1180429
• Aidin Gharibnavaz: 1177871
• Andre Natal: 1051604, 1180113, 1182384
• Aus Lacroix: 1188666, 1188813
• Carsten Book: 1191675
• Chris Rafuse: 1181991
• David Bryant: 1180314
• Dylan Roeh: 1145192, 1153848, 1172567, 1176682
• Eric Tsai: 1184822
• Jamie Nicol: 1176077, 1186911, 1187619
• Jamin Liu: 1190337
• Jan Henning: 1197985
• Jimmy Wang – works on e10s stuff: 653065, 1040947
• Justin Crawford: 1169241, 1184369
• Lin Clark: 976559
• Lydia: 1178120
• Marina Rodr'iguez: 1125181, 1180603, 1183386, 1183576, 1183649
• Melchiorre Alastra: 1116349, 1122329
• Mihai Volmer: 1126330
• Nicholas Rosbrook: 1122977, 1156546
• Peter Elmers: 1183291, 1186896
• Petr Jas'icek: 1160154
• Phil Booth: 1074251
• Phoenix: 617811
• Riadh Chtara: 707044, 1001765, 1134850, 1144856, 1175300, 1178453
• Ritu Kothari: 1167410
• Spenser Andrew Bauman: 1030095, 1176406, 1187511, 1189117
• Steven Englehardt: 1153010, 1179557
• Supradeep T R: 1175968, 1184780
• Thang: 720050
• Trevor Rowbotham: 980943, 984821, 1160780, 1160788, 1161564, 1177845, 1183164, 1185042, 1186739
• Tummala Dhanvi: 1155402
• Tzuhao Kuo: 1044102
• Wei Wu: 1181581
• Wilmer Paulino: 1081362
• Yao Wei: 1183633
• Tracy Walker: 1093756
• othree: 1089363
• sgiles: 1176757, 1177914, 1177991

http://blog.mozilla.org/community/2015/11/03/firefox-42-new-contributors/

We’re releasing a powerful new feature in Firefox Private Browsing called Tracking Protection. We created this feature because we believe in giving you more choice and control over your Web experience. With the release of Tracking Protection in Firefox Private Browsing we are leading the industry by giving you control over the data that third parties receive from you online. No other browser’s Private Browsing mode protects you the way Firefox does—not Chrome, not Safari, not Microsoft Edge or Internet Explorer.

You can learn more about Firefox Private Browsing with Tracking Protection by checking out this video.

Private Browsing with Tracking Protection

We first added Private Browsing to Firefox to give you control over your privacy locally by not saving your browser history and cookies when you close a private window. However, when you browse the Web, you can unknowingly share information about yourself with third parties that are separate from the site you’re actually visiting, even in Private Browsing mode on any browser. Until today.

Private Browsing with Tracking Protection in Firefox for Windows, Mac, Android and Linux actively blocks content like ads, analytics trackers and social share buttons that may record your behavior without your knowledge across sites.

We’re also introducing a new Control Center in Firefox that contains site security and privacy controls in a single place in your address bar. Since some Web pages may appear broken when elements that track behavior are blocked, we’ve made it easy to turn off Tracking Protection in Private Browsing for a particular site using the Control Center.

New Firefox Developer Edition

Today we’re also releasing new visual editing tools in Firefox Developer Edition including Animation Tools that work the same way animators think.

We created a fun, hands-on experience called DevTools Challenger to give designers a deep-dive on how to make the most of these new tools.

We think these new tools in Developer Edition make creating animations less like writing a script and more like creating a movie, but judge for yourself! You can find out more from Director of Engineering Dave Camp about Firefox Developer Edition on the Mozilla Hacks blog here.

We hope you enjoy the new Firefox!

More information:

• Download Firefox for Windows, Mac, Linux
• Release Notes for Firefox for Windows, Mac, Linux
• Download Firefox for Android
• Release Notes for Firefox for Android

https://blog.mozilla.org/blog/2015/11/03/firefox-now-offers-a-more-private-browsing-experience/

Yesterday I recorded a session where I looked at alerts from an uplift.  I did a lot of rambling and not a lot of content, but there are a few interesting differences between uplift alerts and normal alerts:

• a 6 week snapshot
• we try to match them up historically
• there should be pre-existing bugs
• a lot of time there are odd things
• we need to account for differences in build/configs between trunk and aurora/beta.

If you want to take a look at this, the link is on air.mozilla.com.

I do plan to do more episodes soon, a few topics of interest:

• understanding the noisy tests (bi-modal, noise)
• comparing talos on android to the new ported tests to autophone
• running talos locally and interpreting the results
• looking at intermittent failures in general- maybe with a focus on Talos issues.

https://elvis314.wordpress.com/2015/11/03/lost-in-data-episode-3-digging-into-alerts-from-an-uplift/

Some people may have noticed that lately my work has been concentrated on bugs with 'hijacking' in the status whiteboard, but we never really took the time to explain what the goals of this work are, or aren't.

What we call "search hijacking" is when a user's default search engine is changed without the user's intent, typically while the user is installing some other software on his system. Search hijacking is a very common phenomenon, and is causing a severely degraded user experience for the affected users; sometimes leading users to switch to another browser to stop searching with a search engine they never wanted and don't know how to change.

When the search service (the back-end code handling search engines) was initially created about a decade ago, search hijacking wasn't a thing. Things were designed for maximum user customizability. Unfortunately, these days the ease of customization combined with the monetary incentives offered has made search a hijacking target.

The current situation is untenable for Firefox users, so we had to do something. Deciding what to do wasn't obvious, because the difference between the user customizing something and unwanted software writing things to disk isn't always as clear as we would like it to be.

Whatever we do, hijackers will be able to change their code to workaround our changes. In some way, this is an arms race. We can make changes every 6 weeks if needed. We have reasons to believe that it takes most hijackers several months to update their hacks and deploy them, as they need to be bundled with other software for downloads. Our first approach to the problem, especially while our resources to tackle this were very limited, was to do tiny changes every once in a while to breaks some hijacks and help our users for a few months. We didn't want to do pointless changes, but we could find a few things that didn't feel right in our code, and fixed them.

For example, we had some evidence that a significant number of users had modified yahoo.xml files in their application folder. Being able to hijack the default engine by just changing an URL in a plain XML file on the disk was just ridiculous, especially when almost every other non-binary file used by the browser is packed inside the omni.ja file. We fixed this in bug 1162569 for Firefox 40. Similarly, it was possible to change the default engine by dropping in the user's profile a file redefining the same engine. There is no way to end up in this situation 'naturally', because we refuse to install duplicate engines. The logical fix was to ensure that engines in the profile can't override built-in engines. We fixed this in bug 1109354, also for Firefox 40. This was also a good opportunity to add lots of tests about how engines are loaded.

Something seriously limiting our ability to correctly attack the problem was the lack of good data. We found the evidence of modified yahoo.xml files in the wild almost by accident, while looking at incoherent default engine data we received in FHR. In parallel to the fixes mentioned above, we also introduced a better data collection mechanism, with the addition of a telemetry probe recording details about how the current default engine has been loaded.

I haven't been able to look at release-user data collected through this new telemetry probe yet (I intend to do so soon!), but a quick analysis of the early data we got from nightly and aurora users revealed that a non-trivial amount of users had no engine at all, resulting in search features being completely broken for them. This situation can happen if the hijackers removed all the other 'competing' engines to ensure they are the only one, and then got removed themselves, eg. due to one of our previous fixes. We addressed this problem in bug 438599 for Firefox 43, by unhiding automatically the original default engine when no visible engine is left.

A major change that is coming soon to Firefox is required add-on signing. This is a game changer for hijacking, because now anything that lets malware with disk access insert unsigned-code that changes Firefox's behavior is explicitly a bug. This means we are now in a position to close lots of doors that were wide open, to ensure the control is in the hands of our users, not hijackers. There are 2 supported ways to install new engines: either the user does it through the Firefox UI (eg. using OpenSearch discovery on a website), or it's done by a signed add-on. Any other way left to install a search engine and set it as the default is something we need to look into.

In order to better enforce this, we need to be reasonably confident that the data from the user's profile has actually been written due to intentional user actions. The next step of our hijacking remediation work is to cleanup the way search-related data is stored in user profiles. We used to store 2 JSON files (one cache file dismissed after each update, and one file with metadata), in addition to a plain xml file for each user-installed engine. This made it easy to mess either with the xml files (just dropping in the folder an xml file in the open search format was enough to install an engine) or with the metadata. In bug 1203167 (just landed on nightly), I'm changing the profile storage so that everything is in a single file. The data is stored in a JSON format, but the file is written to disk using OS.File's compression feature, which in addition to reducing the file size on disk will also make the file resistant to dumb search & replace attacks. The important data stored in the file (eg. the name of the user-selected default engine) is protected from tampering using verification hashes. While these hashes are by no way meant to be cryptographically secure, they should be unique to each profile, and so make tampering harder. Changing the storage format was also an opportunity to save slightly more data about how users installed engines. For example, if an engine was installed from OpenSearch discovery, we will remember the hostname of the website from which it was downloaded.

We are not done. We have a few more doors to close. We also don't expect to ever be completely resistant to hijacking, as an attacker with local admin access can do whatever. We mostly aim to make hijacking hard enough that it will require some (minimal) engineering skills to do it. Dropping a file on disk or doing a search & replace on the default engine's URL shouldn't be enough. It should require running local code. We can’t protect users from all their mistakes, but we can draw a line between malware-behavior and user-customization that's clear enough for antivirus vendors to enforce it for their users.

We are still working on preventative measures. But a few releases from now, we can expect to start offering curative measures. With Firefox 45 we'll start recording information about engines origin. At some point (currently targeting Firefox 46), we could offer users who have non-default engines of unknown origin an opportunity to check their search settings and revert to the original default if they don't remember changing their default engine themselves. UX is currently thinking this through.

http://blog.queze.net/post/2015/11/02/What-about-search-hijacking

On supporting a loved on with chronic illness

Originally published on Medium

My mother’s disease is like a natural disaster: It’s not always a raging storm, but when it is, it’s incomprehensible, devastating, and random.

For reasons not entirely understood, my mother’s immune system has been slowly destroying her liver for the last 25 years. When she was diagnosed in the early 1990s, she was given eight years to live, but a liver transplant purged the sickness from her body ten years ago. After a few months of unexplained fatigue this summer, we learned that the disease had returned, a relatively rare occurrence in post-transplant patients. I sat and wept on a bench in Central Square when I learned it had taken up residency in her body again, sure and strange as a warm ocean current, ready to wreak havoc.

She’s lived through cancer, a stroke, epilepsy, diabetes, osteoporosis, shattered bones, dental issues, jaundice, a liver that functions at five percent of normal capacity, and a million other ailments I’ve left out because I simply can’t remember anymore. Modern medicine makes human lives seem less fragile, salvageable but broken like the wreckage from a storm. Her body bears scars like Frankenstein’s monster, incisions that run from her ribcage to hipbones, swollen joints and random bruises, brittle hair and teeth.

My mother’s disease, called Primary Biliary Cirrhosis, is not contagious or causal, and it is not strictly genetic, though I have a slightly higher chance of manifesting an autoimmune disorder at some point in my life. 75 percent of people living with autoimmune disease are women, and though the disease category is one of the leading causes of death and disability among women under 65, research into their genesis as a whole remains largely inconclusive. Although autoimmune diseases are fairly common, and are a diverse category of disease that affects every major organ group, Primary Biliary Cirrhosis is officially registered as a “rare disease.” While research into its management has been promising, I doubt there will be a real cure within my lifetime.

The pained, slightly confused expressions of sympathy that cross peoples’ faces when I tell them about my mother are predictable to me now, and I keep a catalog of promised kindnesses in my head I can call when I need them. In the case of chronic illness, the most well-intentioned acts of compassion can become a burden: trying to schedule when dinner can brought to your home, shoving another quiche into the freezer, an “I can’t imagine what you’re going through,” talk. a hug as you inevitably break down when you run into an acquaintance on the street. Then, of course, there are those who don’t know what to say: the friends who disappear, the family members who never come.

I’ve learned that during a long-term illness, most people fall away, slowly becoming unglued from the spine and dropping like pages from an old paperback or moldering like a waterlogged novel. I recognize that most friends have limited experiences with long-term degenerative illness, though I have become acutely aware that each person carries a significant number of individual, hidden traumas. Even the blessed suffer, and mental pain is unquantifiable because it is as systemic and ubiquitous as a chronic illness. Pain is as inevitable and often random as death or natural disaster. It is a primary life experience that binds us to others.

Ten years ago, my mother’s physical pain was assuaged when she received a new liver from a woman I call Linda, though I don’t know her real name. Linda died in a car crash on a Saturday evening outside of New Haven, Connecticut in September of 2005, and by 9AM the next morning, her liver was pumping my mother’s bile. That Sunday, my father bought three copies of the New York Times so we wouldn’t have to share as we sipped black coffee and waited for the nurse to call our names. Transplantation saved her life, but the disease left marks on her body and mind, leaving her scarred, knocked down, and largely adrift. Wandering the landscape of a life shattered by disease, we can only look in the empty windows of what could have been.

In my college entrance essay I compared my mother’s transplant to my own prom: a momentous life event that felt strange, inevitable, and weirdly glamorous. I used the essay to describe how my mother’s fragility underscored my own need to live vibrantly. I wrote,

Had my mother not been ill for most of my life, I would be a different person. Much of my desire to embrace life and connect with people in my own, small way comes from my sense of mortality. This sense of life’s transience propelled me to grow up quickly… Our serendipitous adventures have proven that our relationship is blessed. …However, the greatest impression that she has made on me is that every minute of the day I know there is someone in the world who loves me more than anything. My mother always says that I am “the best thing that ever happened to her.” Her unwavering affection has shaped me as a confident and capable woman who shares her love of life.

This essay remains one of my favorite personal pieces, and I’ve come back to it often in the last few months. Each appointment and emergency room visit brings me back to a childhood spent in hospitals, the long waits when I first understood life and health are tempestuous and unguaranteed. Tim Lawrence wrote in his recent essay “Everything Doesn’t Happen for a Reason,” “Being diagnosed with a debilitating illness cannot be fixed… [It] can only be carried.” Accepting that some things don’t happen for a reason can free our minds to grieve. Carrying the weight of trauma rather than taking responsibility for events beyond our control helps us better understand our pain and the pain of the people we love.

I’ve been thinking lately of a healer I know who told me that if she could be reincarnated as a plant, she would be a wild raspberry. After cataclysmic weather events, the wild raspberry is the first edible plant to return to the area, so that in times of crisis, it provides valuable sustenance. I try to find a wild raspberry in some hidden spot during the darkest times, whether it’s a few uninterrupted hours chatting in a hospital room or a trip home to drive my mother around town and have dinner with my parents. I savor the metaphorical sweetness of the tiny red berries because I know they cannot last forever, but that they allow my mother to live now, for us to live, together.

http://jennierosehalperin.me/body-as-natural-disaster/