https://github.com/mozilla-bteam/bmo/tree/release-20180803.1

the following changes have been pushed to bugzilla.mozilla.org:

• [1480583] User->match is not paging properly so all user results are not return if more than 100 users

discuss these changes on mozilla.tools.bmo.

https://dlawrence.wordpress.com/2018/08/03/happy-bmo-push-day-45/

It's been another busy week in MR land for the team. We are getting really close to releasing some fun new features.

Browsers

We spent this week fixing more bugs and improving performance in Firefox Reality:

• Completed user studies, resulting in many great recommendations for these products to address a wider base of users.
• Nightly version number is now visible to end users in the"About Firefox Reality" button, and is automatically submitted as part of bug report when user selects "Report an issue" from within FxR
• Focusing on bug fixes, primarily around performance and immersive mode
• Refactor strings.xml to provide better support for l10n
• More UI tweaks to FxR Focus Mode

Check out this video Josh did demoing Firefox Reality and showing how to install it yourself.

Social

Lots of bug fixes to Hubs and prepping to launch some new features for it.

• Pen tool tested at meetup, working on adding drawing expirations, rate limiting, and bugfixes.
• Design pass in prep for user studies, focus on invitations and cleaner/brighter UX for room creation and entry. Visual design for scene landing pages.

Interested in joining our public Friday stand ups? For more details, join our public WebVR Slack #social channel

Content Ecosystem

• A-Frame support for the Oculus Go controller hasn't shipped yet, but you can test it out with these instructions.

Stick around next week for more new features and improvements!

https://blog.mozvr.com/this-week-in-mixed-reality-issue-14/

The Things Gateway from Mozilla lets you directly monitor and control your home over the web, without a middleman.

Today the Mozilla IoT team is excited to announce the 0.5 release of the Things Gateway, which is packed full of new features including customisable devices, a more powerful rules engine, an interactive floorplan and an experimental smart assistant you can talk to.

Customisable Things

Custom Capabilities

A powerful new “capabilities” system means that devices are no longer restricted to a predefined set of Web Thing Types, but can be assembled from an extensible schema-based system of “capabilities” through our new schema repository.

This means that developers have much more flexibility to create weird and wacky devices, and users have more control over how the device is used. So if you have a door sensor which also happens to be a temperature sensor, a smart plug which also has a multi-colour LED ring, or a whole bunch of sensors all in one device, you’re not limited by restrictive device types.

This also provides more flexibility to developers who want to build their own web things using the Things Framework, which now also has support for Rust, MicroPython and Arduino.

Custom Icons

When a user adds a device to the gateway they can now choose what main function they want to use it for and what icon is used to represent it.

You can even upload your own custom icon if you want to.

Custom Web Interface

In addition to the built-in UI the gateway generates for devices, web things can now provide a link to a custom web interface designed specifically for any given device. This is useful for complex or unusual devices like a robot or a “pixel wall” where a custom designed UI can be much more user friendly.

Actions & Events

In addition to properties (like “on/off”, “level” and “color”), the gateway UI can now represent actions like “fade” which are triggered with a button and can accept input via a form.

The UI can also display an event log for a device.

Powerful Rules Engine

The rules engine now supports rules with multiple inputs and multiple outputs. Simple rules are still just as easy to create, but more advanced rules can make use of “if”, “while”, “and”, “or” and “equals” operators to create more sophisticated automations through an intuitive drag and drop interface.

It’s also now possible to set colours and strings as outputs.

Interactive Floorplan

The floorplan view is even more useful now that you can view the status of devices and even control them from directly inside the floorplan. Simply tap things to turn them on and off, or long press to get to their detail view. This provides a helpful visual overview of the status of your whole smart home.

Smart Assistant Experiment

A feature we’re particularly excited about is a new smart assistant you can talk to via a chat style interface, either by typing or using your voice.

You can give it commands like “Turn the kitchen light on” and it will respond to you to confirm the action. So far it can understand a basic set of commands to turn devices on and off, set levels, set colours and set colour temperatures.

The smart assistant is still very experimental so it’s currently turned off by default, but you can enable it through Settings -> Smart Assistant UI.

Other Changes

Other new features include developer settings which allow you to view system logs and enable/disable the gateway’s SSH server so you can log in via the command line.

It’s also now much easier to rename devices and you can now also add devices that require a pin number to be entered during pairing.

How to Get Involved

To try out the latest version of the gateway, download the software image from our website to use on a Raspberry Pi. If you already have a gateway set up, you should notice it automatically update itself to the 0.5 release.

As always, we welcome your contributions to our open source project. You can provide feedback and ask questions on Discourse and file bugs and send pull requests on GitHub.

Happy hacking!

https://hacks.mozilla.org/2018/08/things-gateway-0-5-features-experimental-smart-assistant/

happy bmo push day! This release is rather bigger than typical.

release tag

the following changes have been pushed to bugzilla.mozilla.org:

• [1476288] Replace moz_nick with (new, revised) nick and also attempt to disallow duplicate nicks
• [1472954] Implement one-click component watching on bug modal and component description pages
• [1136271] Make user profile page visible to anyone for easier sharing
• [1475593] Bugzilla Emails received when patches are attached…

View On WordPress

https://mozilla-bteam.tumblr.com/post/176536354858

Pick of the Month: Privacy Possum

by cowlicks
Protect yourself against some of the sneakiest trackers out there.

“Perfect complement for your privacy.”

Featured: Textmarker

by underflyingbirches
If you do a lot of text highlighting on webpages, this is a highly customizable tool with loads of fancy features like bookmarking, shortcut commands, save options, and more.

“This is the best text marker add-on under the new Firefox platform! It’s simple but also powerful, very flexible.”

Featured: Worldwide Radio

by Oleksandr
Enjoy live radio from more 30,000 local stations around the globe.

“Love it! Works as intended and I can listen to my favorite radio station in Australia!”

Featured: Transparent Standalone Images

by Jared W
For a clearer view of digital images, this simple but unique extension renders standalone images on transparent backgrounds.

“Oh my god, thank you. I was getting so tired of the white backgrounds around standalone transparent images. Bless you, works perfectly.”

Featured: ReloadMatic: Automatic Tab Refresh

by pylo
More than just another time-controlled tab reloader, ReloadMatic offers cache control, protection against reloading a page you may be in the midst of interacting with, and other nuanced features.

“I really appreciate the time you’ve spent developing this extension because it has far more functionality than the other reloading extensions I’ve tried since moving to [Firefox] Quantum.”

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

The post August’s Featured Extensions appeared first on Mozilla Add-ons Blog.

https://blog.mozilla.org/addons/2018/08/01/augusts-featured-extensions-2/

The Rust team is happy to announce a new version of Rust, 1.28.0. Rust is a systems programming language focused on safety, speed, and concurrency.

If you have a previous version of Rust installed via rustup, getting Rust 1.28.0 is as easy as:

$ rustup update stable

If you don’t have it already, you can get rustup from the appropriate page on our website, and check out the detailed release notes for 1.28.0 on GitHub.

What’s in 1.28.0 stable

Global Allocators

Allocators are the way that programs in Rust obtain memory from the system at runtime. Previously, Rust did not allow changing the way memory is obtained, which prevented some use cases. On some platforms, this meant using jemalloc, on others, the system allocator, but there was no way for users to control this key component. With 1.28.0, the #[global_allocator] attribute is now stable, which allows Rust programs to set their allocator to the system allocator, as well as define new allocators by implementing the GlobalAlloc trait.

The default allocator for Rust programs on some platforms is jemalloc. The standard library now provides a handle to the system allocator, which can be used to switch to the system allocator when desired, by declaring a static and marking it with the #[global_allocator] attribute.

use std::alloc::System;

#[global_allocator]
static GLOBAL: System = System;

fn main() {
    let mut v = Vec::new();
    // This will allocate memory using the system allocator.
    v.push(1);
}

However, sometimes you want to define a custom allocator for a given application domain. This is also relatively easy to do by implementing the GlobalAlloc trait. You can read more about how to do this in the documentation.

Improved error message for formatting

Work on diagnostics continues, this time with an emphasis on formatting:

format!("{_foo}", _foo = 6usize);

Previously, the error message emitted here was relatively poor:

error: invalid format string: expected `'}'`, found `'_'`
  |
2 |     format!("{_foo}", _foo = 6usize);
  |             ^^^^^^^^

Now, we emit a diagnostic that tells you the specific reason the format string is invalid:

error: invalid format string: invalid argument name `_foo`
  |
2 |     let _ = format!("{_foo}", _foo = 6usize);
  |                       ^^^^ invalid argument name in format string
  |
  = note: argument names cannot start with an underscore

See the detailed release notes for more.

Library stabilizations

We’ve already mentioned the stabilization of the GlobalAlloc trait, but another important stabilization is the NonZero number types. These are wrappers around the standard unsigned integer types: NonZeroU8, NonZeroU16, NonZeroU32, NonZeroU64, NonZeroU128, and NonZeroUsize.

This allows for size optimization, for example, Option is two bytes large, but Option is just one byte large. Note that this optimization remains even when NonZeroU8 is wrapped inside another struct; the example below illustrates that Door is still 1 byte large despite being placed inside an Option. This optimization applies to user-defined enums as well: Option is not special.

use std::mem;
use std::num::NonZeroU8;

struct Key(NonZeroU8);

struct Door {
    key: Key,
}

fn main() {
    assert_eq!(mem::size_of::<Door>(), 1);
    assert_eq!(mem::size_of::<Option<Door>>(), 1);
}

A number of other libraries have also been stabilized: you can see the more detailed release notes for full details.

Cargo features

Cargo will now no longer allow you to publish crates with build scripts that modify the src directory. The src directory in a crate should be considered to be immutable.

Contributors to 1.28.0

Many people came together to create Rust 1.28. We couldn’t have done it without all of you. Thanks!

https://blog.rust-lang.org/2018/08/02/Rust-1.28.html

Mozilla established one of the first modern security bug bounty programs back in 2004. Since that time, much of the technology industry has followed our lead and bounty programs have become a critical tool for finding security flaws in the software we all use. But even while these programs have reached broader acceptance, the legal protections afforded to bounty program participants have failed to evolve, putting security researchers at risk and possibly stifling that research.

That is why we are announcing changes to our bounty program policies to better protect security researchers working to improve Firefox and to codify the best practices that we’ve been using.

We often hear of researchers who are concerned that companies or governments may take legal actions against them for their legitimate security research. For example, the Computer Fraud and Abuse Act (CFAA) – essentially the US anti-hacking law that criminalizes unauthorized access to computer systems – could be used to punish bounty participants testing the security of systems and software. Just the potential for legal liability might discourage important security research.

Mozilla has criticized the CFAA for being overly broad and for potentially criminalizing activity intended to improve the security of the web. The policy changes we are making today are intended to create greater clarity for our own bounty program and to remove this legal risk for researchers participating in good faith.

There are two important policy changes we are making. First, we have clarified what is in scope for our bounty program and specifically have called out that bounty participants should not access, modify, delete, or store our users’ data. This is critical because, to protect participants in our bug bounty program, we first have to define the boundaries for bug bounty eligibility.

Second, we are stating explicitly that we will not threaten or bring any legal action against anyone who makes a good faith effort to comply with our bug bounty program. That means we promise not to sue researchers under any law (including the DMCA and CFAA) or under our applicable Terms of Service and Acceptable Use Policy for their research through the bug bounty program, and we consider that security research to be “authorized” under the CFAA.

You can see the full changes we’ve made to our policies in the General Eligibility and Safe Harbor sections of our main bounty page. These changes will help researchers know what to expect from Mozilla and represent an important next step for a program we started more than a decade ago. We want to thank Amit Elazari, who brought this safe harbor issue to our attention and is working to drive change in this space, and Dropbox for the leadership it has shown through recent changes to its vulnerability disclosure policy. We hope that other bounty programs will adopt similar policies.

The post Safe Harbor for Security Bug Bounty Participants appeared first on Mozilla Security Blog.

https://blog.mozilla.org/security/2018/08/01/safe-harbor-for-security-bug-bounty-participants/

We commend the Argentine G20 Presidency for continuing to build momentum around the G20 digital process and look forward to seeing the Declaration and the progress made to that end following the Digital Ministerial on August 24.

However, we can’t ignore the lack of transparency and the step back from multistakeholder engagement that was championed under last year’s G20 Presidency by Germany. Mozilla appreciated the invitation to attend the G20-B20 workshops on July 30, which allowed for providing input into the Digital Declaration. But inviting pre-selected organisations to an unofficial side event on comparatively short notice is not sufficient for a meaningfully transparent and inclusive process.

Assuming responsibility in the digital age also means that governments have to cater to the complexities of existing and upcoming challenges by including different stakeholders for their expertise and various experiences.

We cannot reinstate trust in the development of our digital societies if we close the doors to meaningful engagement and inclusive participatory processes.

Faro Digital, ITS Rio, and Mozilla reiterate as part of a much broader coalition of 80 stakeholders from across the world that a positive, forward-looking digital agenda must support a healthy web ecosystem and put people and their individual rights first, by providing meaningful access, strong privacy and data protection rights, freedom of expression, collaborative cybersecurity, and increased competition.

Read more: https://g20openletter.org

Mitchell Baker, Executive Chairwoman, Mozilla

Ronaldo Lemos, Director, ITS Rio

Ezequiel Passeron, Executive Director, Faro Digital

The post G20 digital process: Trust requires more transparency and inclusion appeared first on The Mozilla Blog.

https://blog.mozilla.org/blog/2018/08/01/g20-digital-process-trust-requires-more-transparency-and-inclusion/

Phabricator supports multi-commit patch series, but it's not yet obvious how to do it using Mercurial. So this the "hg" equivalent of this blog post for git users.

Note that other people have written tools and plugins to do the same thing and that an official client is coming soon.

Initial setup

I'm going to assume that you've setup arcanist and gotten an account on the Mozilla Phabricator instance. If you haven't, follow this video introduction or the excellent documentation for it (Bryce also wrote additionnal instructions for Windows users).

Make a list of commits to submit

First of all, use hg histedit to make a list of the commits that are needed:

pick ee4d9e9fcbad 477986 Bug 1461515 - Split tracking annotations from tracki...
pick 5509b5db01a4 477987 Bug 1461515 - Fix and expand tracking annotation tes...
pick e40312debf76 477988 Bug 1461515 - Make TP test fail if it uses the wrong...

Create Phabricator revisions

Now, create a Phabricator revision for each commit (in order, from earliest to latest):

~/devel/mozilla-unified (annotation-list-1461515)$ hg up ee4d9e9fcbad
5 files updated, 0 files merged, 0 files removed, 0 files unresolved
(leaving bookmark annotation-list-1461515)

~/devel/mozilla-unified (ee4d9e9)$ arc diff --no-amend
Linting...
No lint engine configured for this project.
Running unit tests...
No unit test engine is configured for this project.
 SKIP STAGING  Phabricator does not support staging areas for this repository.
Created a new Differential revision:
        Revision URI: https://phabricator.services.mozilla.com/D2484

Included changes:
  M       modules/libpref/init/all.js
  M       netwerk/base/nsChannelClassifier.cpp
  M       netwerk/base/nsChannelClassifier.h
  M       toolkit/components/url-classifier/Classifier.cpp
  M       toolkit/components/url-classifier/SafeBrowsing.jsm
  M       toolkit/components/url-classifier/nsUrlClassifierDBService.cpp
  M       toolkit/components/url-classifier/tests/UrlClassifierTestUtils.jsm
  M       toolkit/components/url-classifier/tests/mochitest/test_trackingprotection_bug1312515.html
  M       xpcom/base/ErrorList.py

~/devel/mozilla-unified (ee4d9e9)$ hg up 5509b5db01a4
3 files updated, 0 files merged, 0 files removed, 0 files unresolved

~/devel/mozilla-unified (5509b5d)$ arc diff --no-amend
Linting...
No lint engine configured for this project.
Running unit tests...
No unit test engine is configured for this project.
 SKIP STAGING  Phabricator does not support staging areas for this repository.
Created a new Differential revision:
        Revision URI: https://phabricator.services.mozilla.com/D2485

Included changes:
  M       toolkit/components/url-classifier/tests/UrlClassifierTestUtils.jsm
  M       toolkit/components/url-classifier/tests/mochitest/test_trackingprotection_bug1312515.html
  M       toolkit/components/url-classifier/tests/mochitest/trackingRequest.html

~/devel/mozilla-unified (5509b5d)$ hg up e40312debf76
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

~/devel/mozilla-unified (e40312d)$ arc diff --no-amend
Linting...
No lint engine configured for this project.
Running unit tests...
No unit test engine is configured for this project.
 SKIP STAGING  Phabricator does not support staging areas for this repository.
Created a new Differential revision:
        Revision URI: https://phabricator.services.mozilla.com/D2486

Included changes:
  M       toolkit/components/url-classifier/tests/mochitest/classifiedAnnotatedPBFrame.html
  M       toolkit/components/url-classifier/tests/mochitest/test_privatebrowsing_trackingprotection.html

Link all revisions together

In order to ensure that these commits depend on one another, click on that last phabricator.services.mozilla.com link, then click "Related Revisions" then "Edit Parent Revisions" in the right-hand side bar and then add the previous commit (D2485 in this example).

Then go to that parent revision and repeat the same steps to set D2484 as its parent.

Amend one of the commits

As it turns out my first patch wasn't perfect and I needed to amend the middle commit to fix some test failures that came up after pushing to Try. I ended up with the following commits (as viewed in hg histedit):

pick ee4d9e9fcbad 477986 Bug 1461515 - Split tracking annotations from tracki...
pick c24f4d9e75b9 477992 Bug 1461515 - Fix and expand tracking annotation tes...
pick 1840f68978a7 477993 Bug 1461515 - Make TP test fail if it uses the wrong...

which highlights that the last two commits changed and that I would have two revisions (D2485 and D2486) to update in Phabricator.

However, since the only reason why the third patch has a different commit hash is because its parent changed, theres's no need to upload it again to Phabricator. Lando doesn't care about the parent hash and relies instead on the parent revision ID. It essentially applies diffs one at a time.

The trick was to pass the --update DXXXX argument to arc diff:

~/devel/mozilla-unified (annotation-list-1461515)$ hg up c24f4d9e75b9
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
(leaving bookmark annotation-list-1461515)

~/devel/mozilla-unified (c24f4d9)$ arc diff --no-amend --update D2485
Linting...
No lint engine configured for this project.
Running unit tests...
No unit test engine is configured for this project.
 SKIP STAGING  Phabricator does not support staging areas for this repository.
Updated an existing Differential revision:
        Revision URI: https://phabricator.services.mozilla.com/D2485

Included changes:
  M       browser/base/content/test/general/trackingPage.html
  M       netwerk/test/unit/test_trackingProtection_annotateChannels.js
  M       toolkit/components/antitracking/test/browser/browser_imageCache.js
  M       toolkit/components/antitracking/test/browser/browser_subResources.js
  M       toolkit/components/antitracking/test/browser/head.js
  M       toolkit/components/antitracking/test/browser/popup.html
  M       toolkit/components/antitracking/test/browser/tracker.js
  M       toolkit/components/url-classifier/tests/UrlClassifierTestUtils.jsm
  M       toolkit/components/url-classifier/tests/mochitest/test_trackingprotection_bug1312515.html
  M       toolkit/components/url-classifier/tests/mochitest/trackingRequest.html

Note that changing the commit message will not automatically update the revision details in Phabricator. This has to be done manually in the Web UI if required.

http://feeding.cloud.geek.nz/posts/mercurial-commit-series-phabricator-using-arcanist/

Introducing the Dweb

The web is the most successful programming platform in history, resulting in the largest open and accessible collection of human knowledge ever created. So yeah, it’s pretty great. But there are a set of common problems that the web is not able to address.

Have you ever…

• Had a website or app you love get updated to a new version, and you wished to go back to the old version?
• Tried to share a file between your phone and laptop or tv or other device while not connected to the internet? And without using a cloud service?
• Gone to a website or service that you depend on, only to find it’s been shut down? Whether it got bought and enveloped by some internet giant, or has gone out of business, or whatever, it was critical for you and now it’s gone.

Additionally, the web is facing critical internet health issues, seemingly intractable due to the centralization of power in the hands of a few large companies who have economic interests in not solving these problems:

• Hate speech, harassment and other attacks on social networks
• Repeated attacks on Net Neutrality by governments and corporations
• Mass human communications compromised and manipulated for profit or political gain
• Censorship and whole internet shutdowns by governments

These are some of the problems and use-cases addressed by a new wave of projects, products and platforms building on or with web technologies but with a twist: They’re using decentralized or distributed network architectures instead of the centralized networks we use now, in order to let the users control their online experience without intermediaries, whether government or corporate. This new structural approach gives rise to the idea of a ‘decentralized web’, often conveniently shortened to ‘dweb’.

You can read a number of perspectives on centralization, and why it’s an important issue for us to tackle, in Mozilla’s Internet Health Report, released earlier this year.

What’s the “D” in Dweb?!

The “d” in “dweb” usually stands for either decentralized or distributed.
What is the difference between distributed vs decentralized architectures? Here’s a visual illustration:

(Image credit: Openclipart.org, your best source for technical clip art with animals)

In centralized systems, one entity has control over the participation of all other entities. In decentralized systems, power over participation is divided between more than one entity. In distributed systems, no one entity has control over the participation of any other entity.

Examples of centralization on the web today are the domain name system (DNS), servers run by a single company, and social networks designed for controlled communication.

A few examples of decentralized or distributed projects that became household names are Napster, BitTorrent and Bitcoin.

Some of these new dweb projects are decentralizing identity and social networking. Some are building distributed services in or on top of the existing centralized web, and others are distributed application protocols or platforms that run the web stack (HTML, JavaScript and CSS) on something other than HTTP. Also, there are blockchain-based platforms that run anything as long as it can be compiled into WebAssembly.

Here We Go

Mozilla’s mission is to put users in control of their experiences online. While some of these projects and technologies turn the familiar on its head (no servers! no DNS! no HTTP(S)!), it’s important for us to explore their potential for empowerment.

This is the first post in a series. We’ll introduce projects that cover social communication, online identity, file sharing, new economic models, as well as high-level application platforms. All of this work is either decentralized or distributed, minimizing or entirely removing centralized control.

You’ll meet the people behind these projects, and learn about their values and goals, the technical architectures used, and see basic code examples of using the project or platform.

So leave your assumptions at the door, and get ready to learn what a web more fully in users’ control could look like.

https://hacks.mozilla.org/2018/07/introducing-the-d-web/

Firefox 60 (the current release) displays an “untrusted connection” error for any website using a TLS/SSL certificate issued before June 1, 2016 that chains up to a Symantec root certificate. This is part of the consensus proposal for removing trust in Symantec TLS certificates that Mozilla adopted in 2017. This proposal was also adopted by the Google Chrome team, and more recently Apple announced their plan to distrust Symantec TLS certificates. As previously stated, DigiCert’s acquisition of Symantec’s Certification Authority has not changed these plans.

In early March when we last blogged on this topic, roughly 1% of websites were broken in Firefox 60 due to the change described above. Just before the release of Firefox 60 on May 9, 2018, less than 0.15% of websites were impacted – a major improvement in just a few months’ time.

The next phase of the consensus plan is to distrust any TLS certificate that chains up to a Symantec root, regardless of when it was issued (note that there is a small exception for TLS certificates issued by a few intermediate certificates that are managed by certain companies, and this phase does not affect S/MIME certificates). This change is scheduled for Firefox 63, with the following planned release dates:

• Beta – September 5
• Release – October 23

We have begun to assess the impact of the upcoming change to Firefox 63. We found that 3.5% of the top 1 million websites are still using Symantec certificates that will be distrusted in September and October (sooner in Firefox Nightly)! This number represents a very significant impact to Firefox users, but it has declined by over 20% in the past two months, and as the Firefox 63 release approaches, we expect the same rapid pace of improvement that we observed with the Firefox 60 release.

We strongly encourage website operators to replace any remaining Symantec TLS certificates immediately to avoid impacting their users as these certificates become distrusted in Firefox Nightly and Beta over the next few months. This upcoming change can already be tested in Firefox Nightly by setting the security.pki.distrust_ca_policy preference to “2” via the Configuration Editor.

The post Update on the Distrust of Symantec TLS Certificates appeared first on Mozilla Security Blog.

https://blog.mozilla.org/security/2018/07/30/update-on-the-distrust-of-symantec-tls-certificates/

Say “Firefox” and most people think of a web browser on their laptop or phone, period. TL;DR, there’s more to the story now, and our branding needs to evolve.

With the rapid evolution of the internet, people need new tools to make the most of it. So Firefox is creating new types of browsers and a range of new apps and services with the internet as the platform. From easy screen-shotting and file sharing to innovative ways to access the internet using voice and virtual reality, these tools will help people be more efficient, safer, and in control of their time online. Firefox is where purpose meets performance.

Firefox Quantum Browser Icon

As an icon, that fast fox with a flaming tail doesn’t offer enough design tools to represent this entire product family. Recoloring that logo or dissecting the fox could only take us so far. We needed to start from a new place.

A team made up of product and brand designers at Mozilla has begun imagining a new system to embrace all of the Firefox products in the pipeline and those still in the minds of our Emerging Technologies group. Working across traditional silos, we’re designing a system that can guide people smoothly from our marketing to our in-product experiences.

Today, we’re sharing our two design system approaches to ask for your feedback.

How this works.

For those who recall the Open Design process we used to craft our Mozilla brand identity, our approach here will feel familiar:

• We are not crowdsourcing the answer.
• There’ll be no voting.
• No one is being asked to design anything for free.

Living by our open-source values of transparency and participation, we’re reaching out to our community to learn what people think. You can make your views known by commenting on this blog post below.

Extreme caveat: Although the products and projects are real, these design systems are still a work of fiction. Icons are not final. Each individual icon will undergo several rounds of refinement, or may change entirely, between now and their respective product launches. Our focus at this point is on the system.

We’ll be using these criteria to evaluate the work:

• Do these two systems still feel like Firefox?
• How visually cohesive is each of them? Does each hold together?
• Can the design logic of these systems stretch to embrace new products in the future?
• Do these systems reinforce the speed, safety, reliability, wit, and innovation that Firefox stands for?
• Do these systems suggest our position as a tech company that puts people over profit?

All the details.

The brand architecture for both systems is made up of four levels.

Each system leads with a new Firefox masterbrand icon — an umbrella under which our product lines will live.

The masterbrand icon will show up in our marketing, at events, in co-branding with partners, and in places like the Google Play store where our products can be found. Who knows? Someday this icon may be what people think of when they hear the word “Firefox.”

At the general-purpose browser level, we’re proposing to update our Firefox Quantum desktop icon. We continue to simplify and modernize this icon, and people who use Firefox tell us they love it. Firefox Developer Edition and Firefox Nightly are rendered as color variants of the Quantum icon.

Browsers with a singular focus, such as our Firefox Reality browser for VR applications and our privacy-driven Firefox Focus mobile browser, share a common design approach for their icons. These are meant to relate most directly to the master brand as peers to the Firefox Quantum browser icon.

Finally, the icons for new applications and services signal the unique function of each product. Color and graphic treatment unite them and connect them to the master brand. Each icon shape is one of a kind, allowing people to distinguish among choices seen side by side on a screen.

Still in the works are explorations of typography, graphic patterns, motion, naming, events, partnerships, and other elements of the system that, used together with consistency in the product, will form the total brand experience.

Read along as we refine our final system over the next few months. What we roll out will be based on the feedback we receive here, insights we’re gathering from formal user testing, and our product knowledge and design sensibilities.

With your input, we’ll have a final system that will make a Firefox product recognizable out in the world even if a fox is nowhere in sight. And we’ll deliver a consistent experience from an advertisement to a button on a web page. Thanks for joining us on this new journey.

Madhava Enros, Sr. Director, Firefox User Experience

Tim Murray, Creative Director, Mozilla

The post Evolving the Firefox Brand appeared first on Mozilla Open Design.

https://blog.mozilla.org/opendesign/evolving-the-firefox-brand/

As part of our Screenshots release on July 26, 2018, we thought we’d update you on a few new features that we think you’ll find especially useful.

We shipped a simple image editor a few months ago to enable users to annotate and crop their shots. Now we are expanding the editor with three more features: undo, redo, and text.

Undo and Redo

Drawing anything freehand with a mouse can be difficult, and while the editor previously provided an undo via the reset feature, that wiped out everything since the beginning of the editing session. With the new undo feature, users now can undo a single edit action at a time. The accompanying redo feature is there when users change their minds and want to undo their undos.

Text Tool

Writing text freehand with a mouse is difficult. The ability to add text to an image, however, is a very useful annotation feature. In the latest update to the Screenshots editor, users can insert text with the new text tool. To keep things simple, it is currently limited to one line of text per edit.

Users can drag to move text to their desired location by clicking and holding their left mouse button on the outside edge of the inserted text. You can also choose the font size and font color! With the new text tool, you can create and share your own meme in just few minutes! And isn’t that why the internet exists?

What’s next?

We welcome your contributions and would like Screenshots to provide best user experience. If you come across any issues or have new feature requests, you can log them on Github or Bugzilla.

Screenshots was originally an experiment from the Firefox Test Pilot team. Have a look at our current experiments, and let us know what you think!

New Features in Screenshots was originally published in Firefox Test Pilot on Medium, where people are continuing the conversation by highlighting and responding to this story.

https://medium.com/firefox-test-pilot/new-features-in-screenshots-38580f24a0e3?source=rss----46b1a2ddb811---4

When you’re in the zone, be it creative or analytical, anything you can do to stay there is an asset. It’s part of why we build and design Firefox to … Read more

The post Free your mind and move your biggest files with the WeTransfer extension for Firefox appeared first on The Firefox Frontier.

https://blog.mozilla.org/firefox/wetransfer-extension-firefox/

Hi there, WebRender’s newsletter is here, delayed again by some vacation time sprinkled with a fair amount of the traditional “I’m busy” excuse. It’s been a while so there is a lot below (without counting the items I probably missed in the overwhelming amount of stuff that went into WebRender and Gecko since the last newsletter.

One of the highlights this time is something I have been focusing on for a while, building on the async scene building infrastructure to move blob image rasterization off of the render backend thread. Instead of lazily rasterizing blob images in the critical path we now eager rasterize a subset of the blobs asynchronously during scene building. This makes sure expensive blob rasterization never prevent us from producing 60 frames per second during scrolling.
The other highlight is that we started gathering telemetry numbers on the nightly population that opted into WebRender, and these numbers are very positive, even in areas that we haven’t spent any time optimizing yet.

Notable WebRender changes

• Kvark prevented segmentation of tiled images.
• Glenn reduced the size of scroll nodes in memory and introduced transform palettes.
• Lee added configurable angles for synthetic italics.
• Martin added vertical scrolling in wrench.
• Glenn refactored the clip scroll tree to reduce the amount of transforms sent to teh GPU.
• Andrew fixed a panic in the texture cache.
• Andrew fixed the tiling and dirty rect information for external images.
• Martin implemented nine-patch support for border gradients.
• Nical moved the rasterization of blob images off of the critical path.
• Glenn reduced the size of the per-instance data in GPU memory.
• Glenn cached the font instance in text runs primitives to avoid querying it during batching.
• Zakor Gyula moved the device module into a folder in preparation for supporting more backends and fixed various issues with the portability of the shaders.
• Kvark fixed an issue with forced texture uploads and dirty rects.
• Nical fixed the scene building debug indicator to work with async scene building.
• Lee snapped text run offsets and glyph offsets separately.
• Glenn changed the data structure used to store clip sources.
• Kvark improved the chasing infrastructure to debug batches.
• Glenn avoided building frames when not necessary, improving CPU and power usage.
• Jeff fixed a bug causing blob images to be transferred to the GPU every frame.
• Nical avoided a crash if the debug shaders fail to build.
• Kvark improved the way we handle non-inertible transforms in some cases.
• s-panferov fixed the framebuffer size of the examples on hidpi screens.
• Glenn decoupled batching from the clip-scroll-tree.
• Glenn removed a redundant matrix transformation per primitive per frame.
• Glenn decoupled some of the primitive code from spacial nodes.
• Martin worked around a bug with out-of-sequence clip ids.
• Lee added custom gamma and contrast for DWrite fonts.
• Kvark reduced the glyph key size to 32 bits.
• Sotaro fixed a bug in the FPS counter.
• ekicyou made some tweaks to the direct composition exmaple.
• Kvark fixed a bug with the clipping of iframes.
• Kvark worked around an OSX Intel shader compiler bug (again).
• Martin prevented segmenting clips with different positioning nodes.
• Andrew improved the way we track dirty rects for images.

Notable Gecko changes

• Sotaro fixed an issue with the display list generation in some cases.
• Kats added some telemetry probes.
• Sotaro fixed a crash in the memory management of textures during real device resets and during simulated ones.
• Sotaro removed extraneous WebRender threads created when the GPU process is enabled on Windows.
• Sotaro adjusted DXGI texture synchronization timeouts on Windows.
• Lee added scaled font hooks on Android.
• Sotaro added a check that an EGL extension is supported before using it.
• Gankro fixed a crash in the displaylist building code.
• Kats added telemetry probes to gather some number on the performance of webrender in the small population of nightly users currently using it.
• Kats fixed a crash in the blob image recording code.
• Kats made QR test jobs tier-1 by default.
• Kats fixed a bug in the way rendering commands are flushed.
• Lee cached DWrite rendering params (yielding a nice perf boost).
• Lee fixed a font-related crash
• Nical removed the possibility to disable async scene building.
• Sotaro fixed a resource tracking issue when moving tabs between windows.
• Sotaro fixed the redundant scheduling of frames that caused 30fps videos to refresh the window at 60fps.
• Sotaro reused the external image ids across video frames.
• Kats better handled invalid clip-path URIs.
• Kats fixed a crash in the blob image layerization code.
• Kats fixed a bug in the displaylist building code.
• Nical implemented the new async blob rendering hooks on the gecko side.
• Sotaro implemented a WebRender code path for when the pres shell has no frame avoiding a very costly fallback.
• Gankro optimized away fully transparent blob images.
• Andrew prevented slow things from happening when an image takes a long time to decode.
• Sotaro avoided re-building the scene in more video playback cases.

Enabling WebRender in Firefox Nightly

In about:config:
– just set “gfx.webrender.all” to true
– restart Firefox

Reporting bugs

The best place to report bugs related to WebRender in Gecko is the Graphics :: WebRender component in bugzilla.
Note that it is possible to log in with a github account.

https://mozillagfx.wordpress.com/2018/07/30/webrender-newsletter-21/

http://mozillamarciaknous.wixsite.com/mozcommunity/single-post/2018/07/30/Farewell-Gerv

Also, for those of you who may be unaware, long-time Mozillian Gervase Markham passed away, surrounded by his family. He was ever a professional to the end. I didn't know him as well as some, but I'll always remember him, not least of which for his unwavering faith in the face of adversity and leaving us far too soon. Go with God.

TenFourFox Feature Parity Release 9 beta 1 is now available (downloads, hashes, release notes). There are several new features and many bug fixes in this version. FPR9 is also the first TenFourFox release to pull from the new extended support release, Firefox 60ESR, and we have updated the extended validation certificate roots and our certs'n'pins import script to pull from that source instead of the shortly-to-be-decommissioned 52ESR. All relevant security and stability patches on 60ESR so far have also been backported.

On the bug fix side, there is a crash fix for media tracks from Raphael, updates to the ATSUI font blacklist (mostly for certain Japanese fonts) that can now block incompatible fonts through the CSS Font Loading API as well, updated timezone data for the ICU internationalization library, ICU security fixes, fixes for button sensing in events which should get around some weird glitchy things where the mouse buttons get ignored, and a dumb old bug with WiFi scanning. I also added a layout fix for button subelements that keep getting split apart, fixing problems on sites like Twitch and GoDaddy.

There are also a number of performance related changes. First, the idle observer minimal interval has been increased to be a better fit for our old machines, since doing this every second (potentially) robs CPU time and possibly instruction cache space away from user interaction. Do note, however, that while this reduces work being run while you use the browser the work is only delayed and not eliminated, meaning improvements in responsiveness and animation will be at the cost of memory being occasionally held longer and taking longer to release, and possibly longer GC pauses (though less often), so advise if you don't think the tradeoff is worth it (this is adjustable, though it's hardcoded within TenFourFox and is not a pref). This release also has some tuning to Cocoa events handling to slightly reduce scroll wheel latency and reduce some overhead with custom events, and additional code in JavaScript to make it more nimble about cancelling and recompiling since most of our systems are uniprocessor.

The other big change is to array handling. I backported a number of changes that landed in Firefox 55 which increase the performance of certain array operations such as splices and shifts by anywhere from 35 to 80 times. This does not translate into as dramatic a boost as you might think because in small numbers these types of operations were already reasonably swift, nor are they typically executed in large numbers or in tight loops back to back, but for those sites that do, they will run quite a bit quicker.

Of the new features, CSS column properties are now unprefixed and tested, which will help improve site compatibility. Unfortunately one big new feature that I planned for FPR9 won't make this release: deferred idle callbacks. The requestIdleCallback DOM API was enabled in Firefox in Fx55 and allows browsers to schedule work in the idle time between animation frames. Rarely do any of our old systems have such idle time available, and the 50ms or less usually granted (and actually checked for by the W3C test suite) isn't much time to do much work anyway. However, we can also infer from the timeout that is (optionally) passed that the website is able to tolerate the work being deferred up to that long, so deferred idle callbacks deferred the work up to that long. For example, on YouTube this would delay comments and other pieces of the UI so that the CPU could concentrate more on decoding and blitting frames. My initial thought was to try to run the callback when the system was not under load, but it turned out to be simpler and more reliable to just run it at the maximum timeout interval (or after a default interval if one was not specified). Unfortunately, after a lot of idle callbacks had run test builds started suffering random stalls even after the callbacks had completed, indicating something wasn't getting cleaned up, so it is pref'ed off in this version while I try to figure out what I did wrong. You can play with it by turning tenfourfox.dom.requestIdleCallback.enabled to true, but you'll have to restart the browser if you change that setting, so remember that any assessment you make about performance should keep in mind whether the browser is "fresh" or not. This is something I want to get working but it's not a major issue right now because most of the sites that depend on it (including YouTube) have polyfills.

However, the other big new feature I wanted in FPR9 did land: native HTML5 time and date input controls. On my list of future features likely to be used by sites, these scored very high because for those sites that don't need custom clock/calendar UIs this can eliminate them having to load and maintain one of their own just to select intervals. Date and time input controls were not implemented in Firefox until Fx60, and the implementation Firefox uses is a cross-platform one with a fair bit of JavaScript and other support code for vagaries in date handling and localization. I really didn't want to backport all of that because it would be slower and bloatier and especially because we already have all of this special handling built into Mac OS X itself through NSDate. So I took a tip from the Android version and, in a like manner to the colour picker and file picker, which use native Cocoa widgets, implemented date and time pickers using the built-in NSDatePicker widget. This, in turn, handles all the calendar and date manipulations so we don't have to, displays the calendar and time and date using the user's own locale, and does it all at native speed to boot. Genius!

For simplicity I chose to implement this as a modal window rather than the drop-down Firefox 60 uses, which solved a lot of synchronization issues even though it's not as slick. Ordinarily you'd implement a simple modal window in Cocoa with an NSAlert, and if you want to add something to the alert box, you do so by creating an NSView with the widgets you want to splice in and inserting it as an accessory view.

There's just one problem: NSAlert didn't implement setAccessoryView: until 10.5, so you can't do that in Tiger. Or can you?

When looking for undocumented functionality in Cocoa, the best tools are either class-dump (3.1.2 works with Tiger), or my personal favourite GUI tool, MagicHat. Let's see what MagicHat comes up with for NSAlert:

// Framework:      AppKit
// Header:        NSAlert.h
// Documentation: Unknown

@interface NSAlert : NSObject
{
 int             _alertStyle;
 float           _buttonPadding;
 float           _buttonSpacing;
 float           _buttonSpacingMaxX;
 float           _buttonSpacingY;
 NSArray*        _buttons;
 NSSize          _defaultPanelSize;
 id              _delegate;
 SEL             _didDismissSelector;
 SEL             _didEndSelector;
 NSWindow*       _docWindow;
 id              _first;
 id              _helpAnchor;
 id              _helpButton;
 id              _imageView;
 NSTextField*    _informationField;
 id              _messageField;
 float           _messagePadding;
 NSSize          _minButtonSize;
 id              _modalDelegate;
 NSPanel*        _panel;
 id              _second;
 char            _showsHelp;
 id              _third;
 NSImage*        _unbadgedImage;
 char            _useNSLayout;
 [?]             reserved;
 id              reserved1;
 id              reserved2;
}

Most of these are documented. Unfortunately there is no obvious analogue to setAccessoryView:, so there's no easy way that way. However, there is an interesting selector called buildAlertStyle:. This is not documented, but the name suggests that it gets called at some point to construct the NSAlert, presumably out of a generic NSWindow. Unfortunately because it's undocumented it's not at all clear what those parameters actually do.

I ruminated over this for a couple of days until by dumb luck I ran across an old library called NSAlertCheckbox. This library, though fragmentary and appearing to hail from around the days of Jaguar 10.2, does exactly what the name implies: it adds a checkbox control to an NSAlert. Well, said I, if it can add an NSButton, it can add a NSDatePicker. I cleaned up and expanded the library and wrote a little model (modal?) application to test my theory. It looked like this:

(Here is the source code for this example. You can compile it with Xcode 2.5 and the Mac OS X 10.4 SDK. Note in this and the below examples, because the model is being run from the command line and not within a regular NSApplication, it cannot intercept keystrokes. Just roll with this for the explanations below.)

The way the library works is by hooking those mysterious functions, which do indeed get called during window construction. Happily it turns out we don't need to know anything about what those opaque parameters are; we can modify the window without them (and just pass them along) by iterating through the components within the NSWindow that makes up the NSAlert. Once the code finds the second text field (the explanatory text, here articulately represented by the deep and meaningful words "Blah blah"), it then inserts a subview after that containing the date picker, et voil'a.

This is not enough, however. While we can easily select the date and emit it (using NSDateFormatter), we can't type it, so selecting years and arbitrary months can sometimes require a lot of mousing around. Indeed, if you go to System Preferences to set the date and time, you have the choice of either using a stepper to manually enter a date or selecting one off the calendar. We can support that here too ... by adding another NSDatePicker!

(Source code for this example.)

The trick here was to keep them in sync so that you could type a date and have the calendar widget reflect it. By using a delegate on each date picker's cell, we can make modifications in one picker be synchronized to the other.

That suffices for dates. How about times? Straightforward enough: we just change the style to make the twin NSDatePickers into a clock and time stepper instead, and alter our template to NSDateFormatter to emit the time (in hours and minutes, and optionally seconds). Since the HTML spec also requires that we allow sites to specify minimums and maximums, let's implement that here too:

(Source code for this example.)

Because of the time interval constraint we implemented, when you run it you can only pick a time between 7:30am and 5:45pm; the pickers won't let you select anything else. Exactly what we want.

Before you upgrade to the beta, open either the MDN time or date picker pages and click in one of the demonstration input fields. In FPR8, this is just a text box, and you just enter text. (Same for Safari.) In FPR9, however, when you click or select that field the appropriate picker will pop open and the field will be autofilled for you in the proper format. If you press delete in the field, the date or time will be cleared. If you click Cancel, no change will occur. All of the standard constraints are supported, along with defaults (if no default is specified, the current time and/or date is used). Easy. As a safety measure, though, I implemented a basic filter to prevent NSDateFormatter from being exposed directly to web content since who knows what crap is lurking in there; it's only used as a secondary validator once the web-provided date is known to be in a non-pathological format.

Still to be implemented are month (easily done by just returning the month, not the full date), local date and time (needing a quadruple date picker) and week (harder, but possible). With the exception of local date'n'time, however, these are much less likely to be common and I'll defer those to later versions of the browser.

FPR9 will come out officially parallel to Firefox 62 and 60.2 on September 4, but I wanted a nice long beta test period since there is a lot of stuff in this release and to provide a sufficient timeframe for additional betas if required, so you're getting what I've got now. Bang on it and post your impressions in the comments.

http://tenfourfox.blogspot.com/2018/07/tenfourfox-fpr9b1-available.html

I'm sad that Gerv is no longer with us, but I'm also glad because I'm confident he is in the presence of Jesus, awaiting the final resurrection.

I never spent very much time with him, but I really appreciated getting together at Mozilla events with Gerv and a small group of other Mozilla Christians to pray every morning. That tradition continues, and long may it do so!

I have always been inspired by the way Gerv and his family lived their lives to the full, to the glory of God, in the face of his long illness. I've had a sheltered life of little contact with sickness and death, but that will probably not last, and I expect in times to come I will treasure Gerv's example.

http://robert.ocallahan.org/2018/07/gerv.html

Gerv Markham, a friend and mentor to many in the Mozilla community, passed away last night surrounded by his family.

Gerv worked at Mozilla for many years working in a variety of capacities including being a lead developer of Bugzilla and most recently working on special projects under the Mozilla Chairwoman.

I had the pleasure of working with Gerv in the Thunderbird community and most recently on the MOSS Grants Committee as one of the inaugural members. Between these two areas, I often sought Gerv’s mentoring and advice, as he always had wisdom to share.

Anyone who has been intimately involved with the Mozilla project likely engaged Gerv from time to time, although much of his work was behind the scenes but nonetheless important work.

I think it goes without saying Gerv had a significant impact on the open web through his contributions to Bugzilla and various projects that moved the open web forward and he championed the values of the Mozilla manifesto. All of us who knew him and got the opportunity to collaborate were rewarded with a good friend and valuable wisdom that will be missed.

Thanks Gerv for being a friend of Mozilla and the open web and you will be surely missed.

http://feedproxy.google.com/~r/BenjaminKerensaDotComMozilla/~3/hYXsx_tt2AM/remembering-gerv-markham

 your case is still going through administrative processing and we don't know when that process will be completed.

Last year I was denied to go to the US when I was about to travel to San Francisco. Me and my employer's legal team never got answers as to why this happened so I've personally tried to convince myself it was all because of some human screw-up. Because why would they suddenly block me? I've traveled to the US almost a dozen times over the years.

The fact that there was no reason or explanation given makes any theory as likely as the next. Whatever we think or guess might have happened can be true. Or not. We will probably never know. And I've been told a lot of different theories.

Denied again

In early April 2018 I applied for ESTA again to go to San Francisco in mid June for another Mozilla All Hands conference and... got denied. The craziness continues. This also ruled out some of the theories from last year that it was just some human error by the airline or similar...

As seen on the screenshot, this decision has no expire date... While they don't provide any motivation for not accepting me, this result makes it perfectly clear that it wasn't just a mistake last year. It makes me view last year with different eyes.

Put in this situation, I activated plan B.

Plan B

I then applied for a "real" non-immigrant visa - even though it feels that having been denied ESTA probably puts me in a disadvantage for that as well. Applying for this visa means filling in a 10-something-page "DS-160" form online on a site that sometimes takes minutes just to display the next page in the form where they ask for a lot of personal details. After finally having conquered that obstacle, I paid the 160 USD fee and scheduled an appointment to appear physically at the US embassy in Sweden.

I acquired an "extraction of the population register" ("personbevis" in Swedish) from the Swedish tax authorities - as required (including personal details of my parents and siblings), I got myself a new mugshot printed on photo paper and was lucky enough to find a date for an appointment not too far into the future.

Appointment

I spent the better part of a fine Tuesday morning in different waiting lines at my local US embassy where I eventually was called up to a man at a counter behind a window. I was fingerprinted, handed over my papers and told the clerk I have no idea why I was denied ESTA when asked, and no, I have not been on vacation in Iraq, Iran or Sudan. The clerk game me the impression that's the sort of thing that is the common reason for not getting ESTA.

When I answered the interviewer's question that I work for Mozilla, he responded "Aha, Firefox?" - which brightened up my moment a little.

Apparently the process is then supposed to take "several weeks" until I get to know anything more. I explained that I needed my passport in three weeks (for another trip) and he said he didn't expect them to be done that quickly.  Therefore I got the passport back while they process my application and I'm expected to mail it to them when they ask for it.

The next form

When I got back home again, I got an email from "the visa unit" asking me to fill in another form (in the shape of a Word document). And what a form it is! It might be called "OMB 1405-0226" and has this fancy title:

"SUPPLEMENTAL QUESTIONS FOR VISA APPLICANTS"

Among other things it requires me to provide info about all trips abroad (with dates and duration) I've done over the last 15 years. What aliases I use on social media sites (hello mr US visa agent, how do you like this post so far?), every physical address I've lived at in the last 15 years, information about all my employers the last 15 years and every email address I've used during the last 5 years.

It took me many hours digging through old calendars, archives and memories and asking around in order to fill this in properly. ("hey that company trip we did to Germany back in 2005, can you remember the dates?") As a side-note: it turns out I've been in the US no less than nine times the last fifteen years. In total I managed to list sixty-five different trips abroad for this period.

How do I submit my filled-in form, with all these specific and very private details from my life for the last 15 years, back to "the visa unit"? By email. Good old insecure, easy to snoop on, email! At least I'm using my own mail server (and it is configured to prefer TLS for connections) but that's a small comfort.

Is it worth it?

This is a very time and energy consuming process - I understand why this puts people off and simply make them decide its not worth it to go there. And of course I understand that I'm in a lucky position where I've not had to deal with this much in the past.

I have many friends and contacts in the US in both my personal and professional life. I would be sad if I couldn't go there ever again. It would give me grief personally since it'll limit where I can go on vacation and who out of my friends I can visit, but it will also limit my professional life as interesting Mozilla, Internet, open source and curl related events that I'd like to attend are frequently hosted there.

What's happening?

So the weeks came and went and on May 29th,  six weeks after I was interviewed at the embassy, I checked the online service that allows me to check my application progress. It said "Case Created: April 17" and the following useful addition "Case Last Updated: April 17".

Wat? Did something go fatally wrong here? I emailed the embassy to double-check. I got this single sentence response back:

Dear Sir,

You don't have to do anything, your case is still going through administrative processing and we don't know when that process will be completed.

In my life I've visited a whole series of countries for which I've been required to apply for a visa. None of them have ever taken more than a few weeks, including countries with complicated bureaucracy like India and China. What are they doing all this time?

At the time of this writing, more than 100 days have passed and I have still not heard back from them. I know this is unusually long and I have a strong suspicion this means they will deny me visa, but for some reason they want to keep me unaware for a while more.

No All Hands in the US

I clearly underestimated the time this required so I missed our meeting in SF this year again...

Mozilla has since then announced that a number of the forthcoming All Hands conferences in the coming years will be held outside of the US. Unfortunately several of them are to be held in Canada, and there are indications that having being denied entry to the US means that Canada will deny me as well. But I have yet to test that!

Why they deny me?

Me knowingly, I've never broken a law, rule or regulation that would explain this. Some speculations me and others can think of include...

1. I'm the main author of curl, a tool that is used in a lot of security research and proof of concept exploits of security vulnerabilities
2. I'm the main author of libcurl, a transfer library that is one of the world's most widely used software components. It is subsequently also used extensively by malware and other offensive and undesired software.
3. I use the name haxx.se domain for many of my sites and email address etc. haxx or hacking could be interpreted by some, not as "To program a computer in a clever, virtuosic, and wizardly manner" but as the act to "gain unauthorized access to data in a system or computer".
4. It's been suggested that my presence at multiple conferences in the US over the years could've been a violation of the ESTA rules - but the rules explicitly allow this. I have not violated the ESTA rules.

Administrative Processing

It's been 102 days now. I'm not optimistic.

https://daniel.haxx.se/blog/2018/07/28/administrative-purgatory/