Mozilla Nederland LogoDe Nederlandse

The Mozilla Blog: The Bug in Apple’s Latest Marketing Campaign

Mozilla planet - mo, 15/04/2019 - 14:16

Apple’s latest marketing campaign — “Privacy. That’s iPhone” — made us raise our eyebrows.

It’s true that Apple has an impressive track record of protecting users’ privacy, from end-to-end encryption on iMessage to anti-tracking in Safari.

But a key feature in iPhones has us worried, and makes their latest slogan ring a bit hollow.

Each iPhone that Apple sells comes with a unique ID (called an “identifier for advertisers” or IDFA), which lets advertisers track the actions users take when they use apps. It’s like a salesperson following you from store to store while you shop and recording each thing you look at. Not very private at all.

The good news: You can turn this feature off. The bad news: Most people don’t know that feature even exists, let alone that they should turn it off. And we think that they shouldn’t have to.

That’s why we’re asking Apple to change the unique IDs for each iPhone every month. You would still get relevant ads — but it would be harder for companies to build a profile about you over time.

If you agree with us, will you add your name to Mozilla’s petition?

If Apple makes this change, it won’t just improve the privacy of iPhones — it will send Silicon Valley the message that users want companies to safeguard their privacy by default.

At Mozilla, we’re always fighting for technology that puts users’ privacy first: We publish our annual *Privacy Not Included shopping guide. We urge major retailers not to stock insecure connected devices. And our Mozilla Fellows highlight the consequences of technology that makes publicity, and not privacy, the default.

The post The Bug in Apple’s Latest Marketing Campaign appeared first on The Mozilla Blog.

Categorieën: Mozilla-nl planet

The Firefox Frontier: How you can take control against online tracking

Mozilla planet - mo, 15/04/2019 - 10:00

Picture this. You arrive at a website you’ve never been to before and the site is full of ads for things you’ve already looked at online. It’s not a difficult … Read more

The post How you can take control against online tracking appeared first on The Firefox Frontier.

Categorieën: Mozilla-nl planet

Niko Matsakis: More than coders

Mozilla planet - mo, 15/04/2019 - 06:00

Lately, the compiler team has been changing up the way that we work. Our goal is to make it easier for people to track what we are doing and – hopefully – get involved. This is an ongoing effort, but one thing that has become clear immediately is this: the compiler team needs more than coders.

Traditionally, when we’ve thought about how to “get involved” in the compiler team, we’ve thought about it in terms of writing PRs. But more and more I’m thinking about all the other jobs that go into maintaining the compiler. “What kinds of jobs are these?”, you’re asking. I think there are quite a few, but let me give a few examples:

  • Running a meeting – pinging folks, walking through the agenda.
  • Design documents and other documentation – describing how the code works, even if you didn’t write it yourself.
  • Publicity – talking about what’s going on, tweeting about exciting progress, or helping to circulate calls for help. Think steveklabnik, but for rustc.
  • …and more! These are just the tip of the iceberg, in my opinion.

I think we need to surface these jobs more prominently and try to actively recruit people to help us with them. Hence, this blog post.

“We need an open source whenever”

In my keynote at Rust LATAM, I quoted quite liberally from an excellent blog post by Jessica Lord, “Privilege, Community, and Open Source”. There’s one passage that keeps coming back to me:

We also need an open source whenever. Not enough people can or should be able to spare all of their time for open source work, and appearing this way really hurts us.

This passage resonates with me, but I also know it is not as simple as she makes it sound. Creating a structure where people can meaningfully contribute to a project with only small amounts of time takes a lot of work. But it seems clear that the benefits could be huge.

I think looking to tasks beyond coding can be a big benefit here. Every sort of task is different in terms of what it requires to do it well – and I think the more ways we can create for people to contribute, the more people will be able to contribute.

The context: working groups

Let me back up and give a bit of context. Earlier, I mentioned that the compiler has been changing up the way that we work, with the goal of making it much easier to get involved in developing rustc. A big part of that work has been introducing the idea of a working group.

A working group is basically an (open-ended, dynamic) set of people working towards a particular goal. These days, whenever the compiler team kicks off a new project, we create an associated working group, and we list that group (and its associated Zulip stream) on the compiler-team repository. There is also a central calendar that lists all the group meetings and so forth. This makes it pretty easy to quickly see what’s going on.

Working groups as a way into the compiler

Working groups provide an ideal vector to get involved with the compiler. For one thing, they give people a more approachable target – you’re not working on “the entire compiler”, you’re working towards a particular goal. Each of your PRs can then be building on a common part of the code, making it easier to get started. Moreover, you’re working with a smaller group of people, many of whom are also just starting out. This allows people to help one another and form a community.

Running a working group is a big job

The thing is, running a working group can be quite a big job – particularly a working group that aims to incorporate a lot of contributors. Traditionally, we’ve thought of a working group as having a lead – maybe, at best, two leads – and a bunch of participants, most of whom are being mentored:

+-------------+ | Lead(s) | | | +-------------+ +--+ +--+ +--+ +--+ +--+ +--+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +--+ +--+ +--+ +--+ +--+ +--+ | | +--------------------------------+ (participants)

Now, if all these participants are all being mentored to write code, that means that the set of jobs that fall on the leads is something like this:

  • Running the meeting
  • Taking and posting minutes from the meeting
  • Figuring out the technical design
  • Writing the big, complex PRs that are hard to mentor
  • Writing the design documents
  • Writing mentoring instructions
  • Writing summary blog posts and trying to call attention to what’s going on
  • Synchronizing with the team at large to give status updates etc
  • Being a “point of contact” for questions
  • Helping contributors debug problems
  • Triaging bugs and ensuring that the most important ones are getting fixed

Is it any wonder that the vast majority of working group leads have full-time, paid employees? Or, alternatively, is it any wonder that often many of those tasks just don’t get done?

(Consider the NLL working group – there, we had both Felix and I working as full-time leads, essentially. Even so, we had a hard time writing out design documents, and there were never enough summary blog posts.)

Running a working group is really a lot of smaller jobs

The more I think about it, the more I think the flaw is in the way we’ve talked about a “lead”. Really, “lead” for us was mostly a kind of shorthand for “do whatever needs doing”. I think we should be trying to get more precise about what those things are, and then that we should be trying to split those roles out to more people.

For example, how awesome would it be if major efforts had some people who were just trying to ensure that the design was documented – working on rustc-guide chapters, for example, showing the major components and how they communicated. This is not easy work. It requires a pretty detailed technical understanding. It does not, however, really require writing the PRs in question – in fact, ideally, it would be done by different people, which ensures that there are multiple people who understand how the code works.

There will still be a need, I suspect, for some kind of “lead” who is generally overseeing the effort. But, these days, I like to think of it in a somewhat less… hierarchical fashion. Perhaps “organizer” is the right term. I’m not sure.

Each job is different

Going back to Jessica Lord’s post, she continues:

We need everything we can get and are thankful for all that you can contribute whether it is two hours a week, one logo a year, or a copy-edit twice a year.

Looking over the list of tasks that are involved in running a working-group, it’s interesting how many of them have distinct time profiles. Coding, for example, is a pretty intensive activity that can easily take a kind of “unbounded” amount of time, which is something not everyone has available. But consider the job of running a weekly sync meeting.

Many working groups use short, weekly sync meetings to check up on progress and to keep everything progressing. It’s a good place for newcomers to find tasks, or to triage new bugs and make sure they are being addressed. One easy, and self-contained, task in a working group might be to run the weekly meetings. This could be as simple as coming onto Zulip at the right time, pinging the right people, and trying to walk through the status updates and take some minutes. However, it might also get more complex – e.g., it might involve doing some pre-triage to try and shape up the agenda.

But note that, however you do it, this task is relatively time-contained – it occurs at a predictable point in the week. It might be a way for someone to get involved who has a fixed hole in their schedule, but can’t afford the more open-ended, coding tasks.

Just as important as code

In my last quote from Jessica Lord’s post, I left out the last sentence from the paragraph. Let me give you the paragraph in full (emphasis mine):

We need everything we can get and are thankful for all that you can contribute whether it is two hours a week, one logo a year, or a copy edit twice a year. You, too, are a first class open source citizen.

I think this is a pretty key point. I think it’s important that we recognize that working on the compiler is more than coding – and that we value those tasks – whether they be organizational tasks, writing documentation, whatever – equally.

I am worried that if we had working groups where some people are writing the code and there is somebody else who is “only” running the meetings, or “only” triaging bugs, or “only” writing design docs, that those people will feel like they are not “real” members of the working group. But to my mind they are equally essential, if not more essential. After all, it’s a lot easier to find people who will spend their free time writing PRs than it is to find people who will help to organize a meeting.

Growing the compiler team

The point of this post, in case you missed it, is that I would like to grow our conception of the compile team beyond coders. I think we should be actively recruiting folks with a lot of different skill sets and making them full members of the compiler team:

  • organizers and project managers
  • documentation authors
  • code evangelists

I’m not really sure what this full set of roles should be, but I know that the compiler team cannot function without them.

Beyond the compiler team

One other note: I think that when we start going down this road, we’ll find that there is overlap between the “compiler team” and other teams in the rust-lang org. For example, the release team already does a great job of tracking and triaging bugs and regressions to help ensure the overall quality of the release. But perhaps the compiler team also wants to do its own triaging. Will this lead to a “turf war”? Personally, I don’t really see the conflict here.

One of the beauties of being an open-source community is that we don’t need to form strict managerial hierarchies. We can have the same people be members of both the release team and the compiler team. As part of the release team, they would presumably be doing more general triaging and so forth; as part of the compiler team, they would be going deeper into rustc. But still, it’s a good thing to pay attention to. Maybe some things don’t belong in the compiler-team proper.


I don’t quite a have a call to action here, at least not yet. This is still a WIP – we don’t know quite the right way to think about these non-coding roles. I think we’re going to be figuring that out, though, as we gain more experience with working groups.

I guess I can say this, though: If you are a project manager or a tech writer, and you think you’d like to get more deeply involved with the compiler team, now’s a good time. =) Start attending our steering meetings, or perhaps the weekly meetings of the meta working group, or just ping me over on the rust-lang Zulip.

Categorieën: Mozilla-nl planet

Alex Gibson: My sixth year working at Mozilla

Mozilla planet - mo, 15/04/2019 - 01:00
Photo of San Fransisco's skyline taken at the Monday night event for Mozilla All-Hands, June 2018. <figcaption>Photo of San Fransisco's skyline taken at the Monday night event for Mozilla All-Hands, June 2018.</figcaption>

This week marks my sixth year working at Mozilla! I’ll be honest, this year’s mozillaversary came by so fast I nearly forgot all about writing this blog post. It feels hard to believe that I’ve been working here for a full six years. I’ve guess grown and learned a lot in that time, but it still doesn’t feel like all that long ago when I first joined full time. Years start to blur together. So, what’s happened in this past 12 months?

Building a design system

Mozilla’s website design system, named Protocol, is now a real product. You can install it via NPM and build on-brand Mozilla web pages using its compenents. Protocol builds on a system of atoms, molecules, and organiams, following the concepts first made popular in Atomic Web Design. Many of the new design system components can be seen in use on the recently redesigned pages.

Sections of the homepage, built using Protocol components. <figcaption>Sections of the homepage, built using Protocol components.</figcaption>

It was fun to help get this project off the ground, and to see it finally in action on a live website. Making a flexible, intuitive design system is not easy, and we learned a lot in the first year of the project that can help us to improve Protocol over the coming months. By the end of the year, our hope is to have fully ported all content to use Protocol. This is not an easy task for a small team and a large website that’s been around for over a decade. It’ll be an interesting challenge!

Measuring clicks to installs

Supporting the needs of experimentation on Firefox download pages is something that our team has been helping to manage and facilitate for several years now. The breadth of data now required in order to fully understand the effectiveness of experiments is a lot more complex today compared to when we first started. Product retention (i.e. how often people actively use Firefox) is now the key metric of success. Measuring how many clicks a download button on a web page receives is relatively straight forward, but understanding how many of those people go on to actually run the installer, and then how often they end up actively using the product for requires a multi-step funnel of measurement. Our team has continued to help build custom tools to facilitate this kind of data in experimentation, so that we can make better informed product decisions.

Publishing systems

One of our team’s main objectives is to enable people at Mozilla to publish quality content to the web quickly and easily, whether that be on, a microsite, or on a official blog. We’re a small team however, and the marketing organisation has a great appetite for wanting new content at a fast pace. This was one of the (many) reasons why we invested in building a design system, so that we can create on-brand web pages at a faster pace with less repetitive manual work. We also invested in building more custom publishing systems, so that other teams can work more independently. We’ve long had publishing systems in place for things like Firefox release notes, and now we also have some initial systems in place for publishing marketing content, such as the what can currently be seen on the homepage.

Individual contributions
  • I made over 167 commits to bedrock this past year.
  • I made over 78 commits to protocol this past year.
  • We moved to GitHub issues for most of our projects over the past year, so my Bugzilla usage has dropped. But I’ve now filed over 534 bugs, made over 5185 comments, and been assigned more than 656 bugs on Bugzilla in total. Yikes.

I got to visit Portland, San Fransisco for Mozilla’s June all-hands event, and also Orlando for December’s all-hands. I brought the family along to Disney World for an end-of-year vacation afterwards, who all had an amazing time. We’re very lucky!

Family fun outside the Disney Swan & Dolphin, December 2018. <figcaption>Family photo outside the Disney Swan & Dolphin, December 2018.</figcaption>
Categorieën: Mozilla-nl planet

Daniel Stenberg: How to curl up 2020?

Mozilla planet - snein, 14/04/2019 - 22:43

We’re running a short poll asking people about where and how we should organize curl up 2020 – our annual curl developers conference. I’m not making any promises, but getting people’s opinions will help us when preparing for next year.

Take the poll

I’ll leave the poll open for a couple of days so please respond asap.

Categorieën: Mozilla-nl planet

Asa Dotzler: My New Role at Mozilla

Mozilla planet - snein, 14/04/2019 - 00:01

Several months ago I took on a new role at Mozilla, product manager for Firefox browser accessibility. I couldn’t be more excited about this. It’s an area I’ve been interested in for nearly my entire career at Mozilla.

It was way back in 2000, after talking with Aaron Leventhal at a Netscape/Mozilla developer event, that I first started thinking about accessibility in Mozilla products and how well the idea of inclusivity fit with some my personal reasons for working on the Mozilla project. If I remember correctly, Aaron was working on a braille reader or similar assistive technologies and he was concerned that the new Mozilla browser, which used a custom UI framework, wasn’t accessible to that assistive technology. Aaron persisted and Mozilla browser technologies became some of the most accessible available.

Thanks in big part to Aaron’s advocacy, hacking, and other efforts over many years, accessibility became “table stakes” for Mozilla applications. The browsers we shipped over the years were always designed for everyone and “accessible to all” came to the Mozilla Mission.

Our mission is to ensure the Internet is a global public resource, open and accessible to all. An Internet that truly puts people first, where individuals can shape their own experience and are empowered, safe and independent.

I’m excited to be working on something so directly tied to Mozilla’s core values. I’m also super-excited to be working with so many great Firefox teams, and in particular the Firefox Accessibility Engineering team, who have been doing amazing work on Firefox’s accessibility features for many years.

I’m still just getting my feet wet, and I’ve got a lot more to learn. Stay tuned to this space for the occasional post around my new role with a focus on our efforts to ensure that Firefox is the best experience possible for people with disabilities. I expect to write at least monthly updates as we prioritize, fix, test and ship improvements to our core accessibility features like keyboard navigation, screen reader support, high contrast mode, narration, and the accessibility inspector and auditors, etc.

Categorieën: Mozilla-nl planet

François Marier: Secure ssh-agent usage

Mozilla planet - sn, 13/04/2019 - 15:43

ssh-agent was in the news recently due to the compromise. The main takeaway from that incident was that one should avoid the ForwardAgent (or -A) functionality when ProxyCommand can do and consider multi-factor authentication on the server-side, for example using libpam-google-authenticator or libpam-yubico.

That said, there are also two options to ssh-add that can help reduce the risk of someone else with elevated privileges hijacking your agent to make use of your ssh credentials.

Prompt before each use of a key

The first option is -c which will require you to confirm each use of your ssh key by pressing Enter when a graphical prompt shows up.

Simply install an ssh-askpass frontend like ssh-askpass-gnome:

apt install ssh-askpass-gnome

and then use this to when adding your key to the agent:

ssh-add -c ~/.ssh/key Automatically removing keys after a timeout

ssh-add -D will remove all identities (i.e. keys) from your ssh agent, but requires that you remember to run it manually once you're done.

That's where the second option comes in. Specifying -t when adding a key will automatically remove that key from the agent after a while.

For example, I have found that this setting works well at work:

ssh-add -t 10h ~/.ssh/key

where I don't want to have to type my ssh password everytime I push a git branch.

At home on the other hand, my use of ssh is more sporadic and so I don't mind a shorter timeout:

ssh-add -t 4h ~/.ssh/key Making these options the default

I couldn't find a configuration file to make these settings the default and so I ended up putting the following line in my ~/.bash_aliases:

alias ssh-add='ssh-add -c -t 4h'

so that I can continue to use ssh-add as normal and have not remember to include these extra options.

Categorieën: Mozilla-nl planet

Daniel Stenberg: Test servers for curl

Mozilla planet - sn, 13/04/2019 - 11:39

curl supports some twenty-three protocols (depending on exactly how you count).

In order to properly test and verify curl’s implementations of each of these protocols, we have a test suite. In the test suite we have a set of handcrafted servers that speak the server-side of these protocols. The more used a protocol is, the more important it is to have it thoroughly tested.

We believe in having test servers that are “stupid” and that offer buttons, levers and thresholds for us to control and manipulate how they act and how they respond for testing purposes. The control of what to send should be dictated as much as possible by the test case description file. If we want a server to send back a slightly broken protocol sequence to check how curl supports that, the server must be open for this.

In order to do this with a large degree of freedom and without restrictions, we’ve found that using “real” server software for this purpose is usually not good enough. Testing the broken and bad cases are typically not easily done then. Actual server software tries hard to do the right thing and obey standards and protocols, while we rather don’t want the server to make any decisions by itself at all but just send exactly the bytes we ask it to. Simply put.

Of course we don’t always get what we want and some of these protocols are fairly complicated which offer challenges in sticking to this policy all the way. Then we need to be pragmatic and go with what’s available and what we can make work. Having test cases run against a real server is still better than no test cases at all.


“SOCKS is an Internet protocol that exchanges network packets between a client and server through a proxy server. Practically, a SOCKS server proxies TCP connections to an arbitrary IP address, and provides a means for UDP packets to be forwarded.

(according to Wikipedia)

Recently we fixed a bug in how curl sends credentials to a SOCKS5 proxy as it turned out the protocol itself only supports user name and password length of 255 bytes each, while curl normally has no such limits and could pass on credentials with virtually infinite lengths. OK, that was silly and we fixed the bug. Now curl will properly return an error if you try such long credentials with your SOCKS5 proxy.

As a general rule, fixing a bug should mean adding at least one new test case, right? Up to this time we had been testing the curl SOCKS support by firing up an ssh client and having that setup a SOCKS proxy that connects to the other test servers.

curl -> ssh with SOCKS proxy -> test server

Since this setup doesn’t support SOCKS5 authentication, it turned out complicated to add a test case to verify that this bug was actually fixed.

This test problem was fixed by the introduction of a newly written SOCKS proxy server dedicated for the curl test suite (which I simply named socksd). It does the basic SOCKS4 and SOCKS5 protocol logic and also supports a range of commands to control how it behaves and what it allows so that we can now write test cases against this server and ask the server to misbehave or otherwise require fun things so that we can make really sure curl supports those cases as well.

It also has the additional bonus that it works without ssh being present so it will be able to run on more systems and thus the SOCKS code in curl will now be tested more widely than before.

curl -> socksd -> test server

Going forward, we should also be able to create even more SOCKS tests with this and make sure to get even better SOCKS test coverage.

Categorieën: Mozilla-nl planet

Firefox UX: Paying Down Enterprise Content Debt: Part 3

Mozilla planet - sn, 13/04/2019 - 01:17
Paying Down Enterprise Content DebtPart 3: Implementation & governance

Summary: This series outlines the process to diagnose, treat, and manage enterprise content debt, using Firefox add-ons as a case study. Part 1 frames the Firefox add-ons space in terms of enterprise content debt. Part 2 lists the eight steps to develop a new content model. This final piece describes the deliverables we created to support that new model.

<figcaption>@neonbrand via Unsplash</figcaption>Content guidelines for the “author experience”“Just as basic UX principles tell us to help users achieve tasks without frustration or confusion, author experience design focuses on the tasks and goals that CMS users need to meet — and seeks to make it efficient, intuitive, and even pleasurable for them to do so.” — Sara Wachter-Boettcher, Content Everywhere

A content model is a useful tool for organizations to structure, future-proof, and clean up their content. But that content model is only brought to life when content authors populate the fields you have designed with actual content. And the quality of that content is dependent in part on how the content system supports those authors in their endeavor.

We had discovered through user research that developers create extensions for a great variety of reasons — including as a side hobby or for personal enjoyment. They may not have the time, incentive, or expertise to produce high-quality, discoverable content to market their extensions, and they shouldn’t be expected to. But, we can make it easier for them to do so with more actionable guidelines, tools, and governance.

An initial review of the content submission flow revealed that the guidelines for developers needed to evolve. Specifically, we needed to give developers clearer requirements, explain why each content field mattered and where that content showed up, and provide them with examples. On top of that, we needed to give them writing exercises and tips when they hit a dead end.

So, to support our developer authors in creating our ideal content state, I drafted detailed content guidelines that walked extension developers through the process of creating each content element.

<figcaption>Draft content guidelines for extension elements, mocked up in a rough Google Site for purposes of feedback and testing.</figcaption>

Once a draft was created, we tested it with Mozilla extension developer, Dietrich Ayala. Dietrich appreciated the new guidelines, and more importantly, they helped him create better content.

<figcaption>Sample of previous Product Page content</figcaption><figcaption>Sample of revised Product Page content</figcaption><figcaption>Sample of revised Product Page content: New screenshots to illustrate how extension works</figcaption>

We also conducted interviews with a cohort of developers in a related project to redesign the extensions submission flow (i.e., the place in which developers create or upload their content). As part of that process, we solicited feedback from 13 developers about the new guidelines:

  • Developers found the guidelines to be helpful and motivating for improving the marketing and SEO of their extensions, thereby better engaging users.
  • The clear “do this/not that” section was very popular.
  • They had some suggestions for improvement, which were incorporated into the next version.
Excerpts from developer interviews:“If all documentation was like this, the world would be a better place…It feels very considered. The examples of what to do, what not do is great. This extra mile stuff is, frankly, something I don’t see on developer docs ever: not only are we going to explain what we want in human language, but we are going to hold your hand and give you resources…It’s [usually] pulling teeth to get this kind of info [for example, icon sizes] and it’s right here. I don’t have to track down blogs or inscrutable documentation.”“…be more upfront about the stuff that’s possible to change and the stuff that would have consequences if you change it.”

Finally, to deliver the guidelines in a useful, usable format, we partnered with the design agency, Turtle, to build out a website.

<figcaption>Draft content guidelines page</figcaption><figcaption>Draft writing exercise on the subtitle content guidelines page</figcaption>Bringing the model to life

Now that the guidelines were complete, it was time to develop the communication materials to accompany the launch.

To bring the content to life, and put a human face on it, we created a video featuring our former Director of Firefox UX, Madhava Enros, and an extension developer. The video conveys the importance of creating good content and design for product pages, as well as how to do it.

<figcaption>Product Page Content & Design Video</figcaption>Preliminary results

Our content model had a tall order to fill, as detailed in our objectives and measurements template.

So, how did we do against those objectives? While the content guidelines have not yet been published by the time of this blog post, here’s a snapshot of preliminary results:

<figcaption>Snapshot of preliminary results</figcaption>

And, for illustration, some examples in action:

1. Improved Social Share Quality

<figcaption>Previous Facebook Share example</figcaption><figcaption>New Facebook Share example</figcaption>

2. New Google search snippet model reflective of SEO best practices and what we’d learned from user research — such as the importance of social proof via extension ratings.

<figcaption>Previous Google “search snippet”</figcaption><figcaption>New Google “search snippet”</figcaption>

3. Promising, but early, SEO findings:

  • Organic search traffic decline slowed down by 2x compared to summer 2018.
  • Impressions in search for the AMO site are much higher (30%) than before. Shows potential of the domain.
  • Overall rankings are stable, and top 10 rankings are a bit up.
  • Extension/theme installs via organic search are stable after previous year declines.
  • Conversion rate to installs via organic search are growing, from 42% to 55%.
Conclusion & resources

There’s isn’t a quick or easy fix to enterprise content debt, but investing the time and energy to think about your content as structured data, to cultivate a content model based upon your business goals, and develop the guidance and guardrails to realize that model with your content authors, pays dividends in the long haul.

Hopefully this series has provided a series of steps and tools to figure out your individual payment plan. For more on this topic:

And, if you need more help, and you’re fortunate enough to have a content strategist on your team, you can always ask that friendly content nerd for some content credit counseling.

Thank you to Michelle Heubusch, Jennifer Davidson, Emanuela Damiani, Philip Walmsley, Kev Needham, Mike Conca, Amy Tsay, Jorge Villalobos, Stuart Colville, Caitlin Neiman, Andreas Wagner, Raphael Raue, and Peiying Mo for their partnership in this work.

Paying Down Enterprise Content Debt: Part 3 was originally published in Firefox User Experience on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

Firefox UX: Paying Down Enterprise Content Debt: Part 2

Mozilla planet - sn, 13/04/2019 - 01:14
Paying Down Enterprise Content DebtPart 2: Developing Solutions

Summary: This series outlines the process to diagnose, treat, and manage enterprise content debt, using Firefox add-ons as a case study. In Part 1 , I framed the Firefox add-ons space in terms of an enterprise content debt problem. In this piece, I walk through the eight steps we took to develop solutions, culminating in a new content model. See Part 3 for the deliverables we created to support that new model.

<figcaption>Source: Sam Truong Dan</figcaption>
  • Step 1: Stakeholder interviews
  • Step 2: Documenting content elements
  • Step 3: Data analysis — content quality
  • Step 4: Domain expert review
  • Step 5: Competitor compare
  • Step 6: User research — What content matters?
  • Step 7: Creating a content model
  • Step 8: Refine and align
Step 1: Stakeholder interviews

To determine a payment plan for our content debt, we needed to first get a better understanding of the product landscape. Over the course of a couple of weeks, the team’s UX researcher and I conducted stakeholder interviews:

Who: Subject matter experts, decision-makers, and collaborators. May include product, engineering, design, and other content folks.

What: Schedule an hour with each participant. Develop a spreadsheet with questions that get at the heart of what you are trying to understand. Ask the same set of core questions to establish trends and patterns, as well as a smaller set specific to each interviewee’s domain expertise.

<figcaption>Sample question template, including content-specific inquiries below</figcaption>

After completing the interviews, we summarized the findings and walked the team through them. This helped build alignment with our stakeholders around the issues and prime them for the potential UX and content solutions ahead.

Stakeholder interviews also allowed us to clarify our goals. To focus our work and make ourselves accountable to it, we broke down our overarching goal — improve Firefox users’ ability to discover, trust, install, and enjoy extensions — into detailed objectives and measurements using an objectives and measurements template. Our main objectives fell into three buckets: improved user experience, improved developer experience, and improved content structure. Once the work was done, we could measure our progress against those objectives using the measurements we identified.

Step 2: Documenting content elements

Product environment surveyed, we dug into the content that shaped that landscape.

Extensions are recommended and accessed not only through AMO, but in a variety of places, including the Firefox browser itself, in contextual recommendations, and in external content. To improve content across this large ecosystem, we needed to start small…at the cellular content level. We needed to assess, evolve, and improve our core content elements.

By “content elements,” I mean all of the types of content or data that are attached to an extension — either by developers in the extension submission process, by Mozilla on the back-end, or by users. So, very specifically, these are things like description, categories, tags, ratings, etc. For example, the following image contains three content elements: icon, extension name, summary:

Using Excel, I documented existing content elements. I also documented which elements showed up where in the ecosystem (i.e., “content touchpoints”):

<figcaption>Excerpt of content elements documentation</figcaption><figcaption>Excerpt of content elements documentation: content touchpoints</figcaption>

The content documentation Excel served as the foundational document for all the work that followed. As the team continued to acquire information to shape future solutions, we documented those learnings in the Excel, evolving the recommendations as we went.

Step 3: Data analysis — content quality

Current content elements identified, we could now assess the state of said content. To complete this analysis, we used a database query (created by our product manager) that populated all of the content for each content element for every extension and theme. Phew.

We developed a list of queries about the content…

<figcaption>Sample selection of data questions</figcaption>

…and then answered those queries for each content element field.

<figcaption>Sample data analysis for “Extension Name”</figcaption>
  • For quantitative questions (like minimum/maximum content length per element), we used Excel formulas.
  • For questions of content quality, we analyzed a sub-section of the data. For example, what’s the content quality state of extension names for the top 100 extensions? What patterns, good and bad, do we see?
Step 4: Domain expert review

I also needed input from domain experts on the content elements, including content reviewers, design, and localization. Through this process, we discovered pain points, areas of opportunity, and considerations for the new requirements.

For example, we had been contemplating a 10-character minimum for our long description field. Conversations with localization expert, Peiying Mo, revealed that this would not work well for non-English content authors…while 10 characters is a reasonable expectation in English, it’s asking for quite a bit of content when we are talking about 10 Chinese characters.

Because improving search engine optimization (SEO) for add-ons was a priority, review by SEO specialist, Raphael Raue, was especially important. Based on user research and analytics, we knew users often find extensions, and make their way to the add-ons site, through external search engines. Thus, their first impression of an add-on, and the basis upon which they may assess their interest to learn more, is an extension title and description in Google search results (also called a “search snippet”). So, our new content model needed to be optimized for these search listings.

<figcaption>Sample domain expert review comments for “Extension Name”</figcaption>Step 5: Competitor compare

A picture of the internal content issues and needs was starting to take shape. Now we needed to look externally to understand how our content compared to competitors and other successful commercial sites.

Philip Walmsley, UX designer, identified those sites and audited their content elements, identifying surplus, gaps, and differences from Firefox. We discussed the findings and determined what to add, trim, or tweak in Firefox’s content element offerings depending on value to the user.

<figcaption>Excerpt of competitive analysis</figcaption>Step 6: User research — what content matters?

A fair amount of user research about add-ons had already been done before we embarked on this journey, and Jennifer Davidson, our UX researcher, lead additional, targeted research over the course of the year. That research informed the content element issues and needs. In particular, a large site survey, add-ons team think-aloud sessions, and in-person user interviews identified how users discover and decide whether or not to get an extension.

Regarding extension product pages in particular, we asked:

  • Do participants understand and trust the content on the product pages?
  • What type of information is important when deciding whether or not to get an extension?
  • Is there content missing that would aid in their discovery and comprehension?

Through this work, we deepened our understanding of the relative importance of different content elements (for example: extension name, summary, long description were all important), what elements were critical to decision making (such as social proof via ratings), and where we had content gaps (for example, desire for learning-by-video).

Step 7: Creating a content model“…content modeling gives you systemic knowledge; it allows you to see what types of content you have, which elements they include, and how they can operate in a standardized way — so you can work with architecture, rather than designing each one individually.” — Sara Wachter-Boettcher, Content Everywhere, 31

Learnings from steps 1–6 informed the next, very important content phase: identifying a new content model for an add-ons product page.

A content model defines all of the content elements in an experience. It details the requirements and restrictions for each element, as well as the connections between elements. Content models take diverse shapes and forms depending on project needs, but the basic steps often include documentation of the content elements you have (step 2 above), analysis of those elements (steps 3–6 above), and then charting new requirements based on what you’ve learned and what the organization and users need.

Creating a content model takes quite a bit of information and input upfront, but it pays dividends in the long-term, especially when it comes to addressing and preventing content debt. The add-ons ecosystem did not have a detailed, updated content model and because of that, developers didn’t have the guardrails they needed to create better content, the design team didn’t have the content types it needed to create scalable, user-focused content, and users were faced with varying content quality.

A content model can feel prescriptive and painfully detailed, but each content element within it should provide the flexibility and guidance for content creators to produce content that meets their goals and the goals of the system.

<figcaption>Sample content model for “Extension Name”</figcaption>Step 8: Refine and align

Now that we had a draft content model — in other words, a list of recommended requirements for each content element — we needed review and input from our key stakeholders.

This included conversations with add-ons UX team members, as well as partners from the initial stakeholder interviews (like product, engineering, etc.). It was especially important to talk through the content model elements with designers Philip and Emanuela, and to pressure test whether each new element’s requirements and file type served design needs across the ecosystem. One of the ways we did this was by applying the new content elements to future designs, with both best and worst-case content scenarios.

[caption id=”attachment_4182" align=”aligncenter” width=”820"]

<figcaption>Re-designed product page with new content elements (note — not a final design, just a study). Design lead: Philip Walmsley</figcaption><figcaption>Draft “universal extension card” with new content elements (note — not a final design, just a study). This card aims to increase user trust and learnability when user is presented with an extension offering anywhere in the ecosystem. Design lead: Emanuela Damiani</figcaption>

Based on this review period and usability testing on, we made adjustments to our content model.

Okay, content model done. What’s next?

Now that we had our new content model, we needed to make it a reality for the extension developers creating product pages.

In Part 3, I walk through the creation and testing of deliverables, including content guidelines and communication materials.

Thank you to Michelle Heubusch, Jennifer Davidson, Emanuela Damiani, Philip Walmsley, Kev Needham, Mike Conca, Amy Tsay, Jorge Villalobos, Stuart Colville, Caitlin Neiman, Andreas Wagner, Raphael Raue, and Peiying Mo for their partnership in this work.

Paying Down Enterprise Content Debt: Part 2 was originally published in Firefox User Experience on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

Firefox UX: Paying Down Enterprise Content Debt: Part 1

Mozilla planet - sn, 13/04/2019 - 01:01
Paying Down Enterprise Content DebtPart 1: Framing the problem

Summary: This series outlines the process to diagnose, treat, and manage enterprise content debt, using Firefox add-ons as a case study. This first part frames the enterprise content debt issue. Part 2 lists the eight steps to develop a new content model. Part 3 describes the deliverables we created to support that new model.

<figcaption>QuinceMedia via Wikimedia</figcaption>Background

If you want to block annoying ads or populate your new tab with sassy cats, you can do it…with browser extensions and themes. Users can download thousands of these “add-ons” from Firefox’s host site, (“AMO”), to customize their browsing experience with new functionality or a dash of whimsy.

<figcaption>The Tabby Cat extension takes over your new tab with adorable cats</figcaption>

Add-ons can be a useful and delightful way for people to improve their web experience — if they can discover, understand, trust, and appreciate their offerings. Over the last year, the add-ons UX pod at Firefox, in partnership with the larger add-ons team, worked on ways to do just that.

One of the ways we did this was by looking at these interconnected issues through the lens of content structure and quality. In this series, I’ll walk you through the steps we took to develop a new content model for the add-ons ecosystem.

Understanding the problem

Add-ons are largely created by third-party developers, who also create the content that describes the add-ons for users. That content includes things like extension name, icon, summary, long, description, screenshots, etcetera:

<figcaption>Sample developer-provided content for the Momentum extension</figcaption>

With 10,000+ extensions and 400,000+ themes, we are talking about a lot of content. And while the add-ons team completely appreciated the value of the add-ons themselves, we didn’t really understand how valuable the content was, and we didn’t use it to its fullest potential.

The first shift we made was recognizing that what we had was enterprise content — structured content and metadata stored in a formal repository, reviewed, sometimes localized, and published in different forms in multiple places.

Then, when we assessed the value of it to the enterprise, we uncovered something called content debt.

Content debt is the hidden cost of not managing the creation, maintenance, utility, and usability of digital content. It accumulates when we don’t treat content like an asset with financial value, when we value expediency over the big picture, and when we fail to prioritize content management. You can think of content debt like home maintenance. If you don’t clean your gutters now, you’ll pay in the long term with costly water damage.

AMO’s content debt included issues of quality (missed opportunities to communicate value and respond to user questions), governance (varying content quality with limited organizational oversight), and structure (the need for new content types to evolve site design and improve social shares and search descriptions).

A few examples of content debt in action:<figcaption>Facebook social share experience: Confusing image accompanied by text describing how to report an issue with the extension</figcaption><figcaption>Google Search results example for an extension. Lacks description of basic functionality and value proposition. No SEO-optimized keywords or social proof like average rating.</figcaption><figcaption>A search for “Investing” doesn’t yield the most helpful results</figcaption>

All of this equals quite a bit of content debt that prevents developers and users from being as successful as they could be in achieving their interconnected goals: offering and obtaining extensions. It also hinders the ecosystem as a whole when it comes to things like SEO (Search Engine Optimization), which the team wanted to improve.

Given the AMO site’s age (15 years), and the amount of content it contains, debt is to be expected. And it’s rare for a content strategist to be given a content challenge that doesn’t involve some debt because it’s rare that you are building a system completely from scratch. But, that’s not the end of the story.

When we considered the situation from a systems-wide perspective, we realized that we needed to move beyond thinking of the content as something created by an individual developer in a vacuum. Yes, the content is developer-generated — and with that a certain degree of variation is to be expected — but how could we provide developers with the support and perspective to create better content that could be used not only on their product page, but across the content ecosystem? While the end goal is more users with more extensions by way of usable content, we needed to create the underpinning rules that allowed for that content to be expressed across the experience in a successful way.

In part 2, I walk through the specific steps the team took to diagnose and develop solutions for our enterprise content debt. Meanwhile, speaking of the team…

Meet our ‘UX supergroup’“A harmonious interface is the product of functional, interdisciplinary communication and clear, well-informed decision making.” — Erika Hall, Conversational Design, 108

While the problem space is framed in terms of content strategy, the diagnosis and solutions were very much interdisciplinary. For this work, I was fortunate to be part of a “UX supergroup,” i.e., an embedded project team that included a user researcher (Jennifer Davidson), a designer with strength in interaction design (Emanuela Damiani), a designer with strength in visual design (Philip Walmsley), and a UX content strategist (me).

We were able to do some of our best work by bringing to bear our discipline-specific expertise in an integrated and deeply collaborative way. Plus, we had a mascot — Pusheen the cat — inspired in part by our favorite tab-changing extension, Tabby Cat.

<figcaption>Left to right: Jennifer, Emanuela, Philip, Meridel #teampusheen</figcaption>

See Part 2, Paying Down Enterprise Content Debt: Developing Solutions

Thank you to Michelle Heubusch, Jennifer Davidson, Emanuela Damiani, Philip Walmsley, Kev Needham, Mike Conca, Amy Tsay, Jorge Villalobos, Stuart Colville, Caitlin Neiman, Andreas Wagner, Raphael Raue, and Peiying Mo for their partnership in this work.

Paying Down Enterprise Content Debt: Part 1 was originally published in Firefox User Experience on Medium, where people are continuing the conversation by highlighting and responding to this story.

Categorieën: Mozilla-nl planet

Mozilla VR Blog: Firefox Reality 1.1.3

Mozilla planet - sn, 13/04/2019 - 00:17
Firefox Reality 1.1.3

Firefox Reality 1.1.3 will soon be available for all users in the Viveport, Oculus, and Daydream app stores.

This release includes some major new features including support for 6DoF controllers, new environments, option for curved browser window, greatly improved YouTube support, and many bug fixes.


  • Improved support for 6DoF Oculus controllers and user height.
  • Added support for 6DoF VIVE Focus (WaveVR) controllers.
  • Updated the Meadow environment and added new Offworld, Underwater, and Winter environments (Settings > Environments).
  • Added new option for curved browser window (Settings > Display).
  • Improved default playback quality of YouTube videos (defaults to 1440p HD or next best).

Improvements/Bug Fixes:

  • Fixed User-Agent override to fix Delight-VR video playback.
  • Changed the layout of the Settings window so it’s easier and faster to find the option you need to change.
  • Performance improvements, including dynamic clock levels and Fixed Foveated Rendering on Oculus.
  • Improved resolution of text rendering in UI widgets.
  • Plus a myriad of web-content handling improvements from GeckoVview 68.
  • … and numerous other fixes

Full release notes can be found in our GitHub repo here.

Looking ahead, we are exploring content sharing and syncing across browsers (including bookmarks), multiple windows, as well as continuing to invest in baseline features like performance. We appreciate your ongoing feedback and suggestions — please keep them coming!

Firefox Reality is available right now.

Download for Oculus
(supports Oculus Go)

Download for Daydream
(supports all-in-one devices)

Download for Viveport (Search for Firefox Reality in Viveport store)
(supports all-in-one devices running VIVE Wave)

Categorieën: Mozilla-nl planet

Mozilla VR Blog: Wrapping up a week of WebVR experiments

Mozilla planet - fr, 12/04/2019 - 23:55
Wrapping up a week of WebVR experiments

Earlier this week, we kicked off a week of WebVR experiments with our friends at Glitch creator and WebVR expert Andrés Cuervo put together seven projects that are fun, unique, and will challenge you to learn advanced techniques for building Virtual Reality experiences on the web.

If you are just getting started with WebVR, we recommend you check out this WebVR starter kit which will walk you through creating your very first WebVR experience.

Today, we launched the final experiment. If you haven't been following along, you can catch up on all of them below:

Motion Capture Dancing in VR

Learn how to use free motion capture data to animate a character running, dancing, or cartwheeling across a floor.

Adding Models and Shaders

Learn about how to load common file types into your VR scene.

Using 3D Shapes like Winding Knots

Learn how to work with the torus knot shape and the animation component that is included with A-frame.

Animated Torus Knot Rings

Learn about template and layout components while you continue to build on the previous Winding Knots example.

Generated Patterns

Create some beautiful patterns using some flat geometry in A-Frame with clever tilting.

Creating Optical Illusions

This is a simple optical optical illusion that is made possible with virtual reality.

Including Dynamic Content

Learn how to use an API to serve random images that are used as textures in this VR scene.

We hope you enjoyed learning and remixing these experiments (We really enjoyed putting them together). Follow Andrés Cuervo on Glitch for even more WebVR experiments.

Categorieën: Mozilla-nl planet

The Firefox Frontier: How to stay safe online while on vacation

Mozilla planet - fr, 12/04/2019 - 17:28

Vacations are a great time to unwind, sip a fruity drink with a tiny umbrella in it and expose your personal information to hackers if you’re traveling with a laptop, … Read more

The post How to stay safe online while on vacation appeared first on The Firefox Frontier.

Categorieën: Mozilla-nl planet

Giorgio Maone: Cross-Browser NoScript hits the Chrome Store

Mozilla planet - fr, 12/04/2019 - 12:59

I'm pleased to announce that, some hours ago, the first public beta of cross-browser NoScript (10.6.1) passed Google's review process and has been published on the chrome web store.
This is a major milestone in NoScript history, started on May the 13th 2005 (next year we will celenbrate our 15th birthday!). NoScript on the chrome web store

Over all these years NoScript has undergone many transformations, porting and migrations:

  • three distinct Android portings (one for Fennec "classic", one for Firefox Mobile, the last as a WebExtension);
  • one partial rewrite, to make it multi-process compatible;
  • one full, long and quite dramatic rewrite, to migrate it to the WebExtensions API (in whose design and implementation Mozilla involved me as a contributor, in order to make this possible).

And finally today we've got an unified code-base compatible both with Firefox and Chromium, and in possibly in future with other browsers supporting the WebExtensions API to a sufficient extent.
One difference Chromium users need to be aware of: on their browser NoScript's XSS filter is currently disabled: at least for the time being they'll have to rely on the browser's built-in "XSS Auditor", which unfortunately over time proved not to be as effective as NoScript's "Injection Checker". The latter could not be ported yet, though, because it requires asynchronous processing of web requests: one of the several capabilities provided to extensions by Firefox only. To be honest, during the "big switch" to the WebExtensions API, which was largely inspired by Chrome, Mozilla involved me in its design and implementation with the explicit goal to ensure that it supported NoScript's use cases as much as possible. Regrettably, the additions and enhancements which resulted from this work have not picked up by Google.

Let me repeat: this is a beta, and I urge early adopters to report issues in the "Support" section of the NoScript Forum, and more development-oriented ones to file technical bug reports and/or contribute patches at the official source code repository. With your help as beta testers, I plan to bless NoScript 11 as a "stable Chromium-compatible release" by the end of June.

I couldn't thank enough the awesome Open Technology Fund folks or the huge support they gave to this project, and to NoScript in general. I'm really excited at the idea that, under the same umbrella, next week Simply Secure will start working on improving NoScript's usability and accessibility. At the same time, integration with the Tor Browser is getting smoother and smoother.

The future of NoScript has never been brigther :)

See also ZDNet's and GHacks' coverage of the announcement.

Categorieën: Mozilla-nl planet

Daniel Stenberg: no more global dns cache in curl

Mozilla planet - to, 11/04/2019 - 22:24

In January 2002, we added support for a global DNS cache in libcurl. All transfers set to use it would share and use the same global cache.

We rather quickly realized that having a global cache without locking was error-prone and not really advisable, so already in March 2004 we added comments in the header file suggesting that users should not use this option.

It remained in the code and time passed.

In the autumn of 2018, another fourteen years later, we finally addressed the issue when we announced a plan for this options deprecation. We announced a date for when it would become deprecated and disabled in code (7.62.0), and then six months later if no major incidents or outcries would occur, we said we would delete the code completely.

That time has now arrived. All code supporting a global DNS cache in curl has been removed. Any libcurl-using program that sets this option from now on will simply not get a global cache and instead proceed with the default handle-oriented cache, and the documentation is updated to clearly indicate that this is the case. This change will ship in curl 7.65.0 due to be released in May 2019 (merged in this commit).

If a program still uses this option, the only really noticeable effect should be a slightly worse name resolving performance, assuming the global cache had any point previously.

Programs that want to continue to have a DNS cache shared between multiple handles should use the share interface, which allows shared DNS cache and more – with locking. This API has been offered by libcurl since 2003.

Categorieën: Mozilla-nl planet

Hacks.Mozilla.Org: Developer Roadshow 2019 returns with VR, IoT and all things web

Mozilla planet - to, 11/04/2019 - 16:51

Mozilla Developer Roadshow is a meetup-style, Mozilla-focused event series for people who build the web. In 2017, the Roadshow reached more than 50 cities around the world. We shared highlights of the latest and greatest Mozilla and Firefox technologies. Now, we’re back to tell the story of how the web continues to democratize opportunities for developers and digital creators.

New events in New York and Los Angeles

To open our 2019 series, Mozilla presents two events with VR visionary Nonny de la Peña and the Emblematic Group in Los Angeles (April 23) and in New York (May 20-23). de la Peña’s pioneering work in virtual reality, widely credited with helping create the genre of immersive journalism, has been featured in Wired, Inc., The New York Times, and on the cover of The Wall Street Journal. Emblematic will present their latest project, REACH in WebVR. Their presentation will include a short demo of their product. During the social hour, the team will be available to answer questions and share their learnings and challenges of developing for the web.

Funding and resource scarcity continue to be key obstacles in helping the creative community turn their ideas into viable products. Within the realm of cutting edge emerging technologies, such as mixed reality, it’s especially challenging for women. Because women receive less than 2% of total venture funding, the open distribution model of the web becomes a viable and affordable option to build, test, and deploy their projects.

Upcoming DevRoadshow events

The DevRoadshow continues on the road with eight more upcoming sessions in Europe and the Asia Pacific regions throughout 2019. Locations and dates will be announced soon. We’re eager to invite coders and creators around the world to join us this year. The Mozilla Dev Roadshow is a great way to make new friends and stay up to date on new products. Come learn about services and opportunities that extend the power of the web as the most accessible and inclusive platform for immersive experiences.

Check back to this post for updates, visit our DevRoadshow site for up to date registration opportunities, and follow along our journey on @mozhacks or sign up for the weekly Mozilla Developer Newsletter. We’ll keep you posted!

The post Developer Roadshow 2019 returns with VR, IoT and all things web appeared first on Mozilla Hacks - the Web developer blog.

Categorieën: Mozilla-nl planet

Mozilla Future Releases Blog: Firefox Beta for Windows 10 on Qualcomm Snapdragon Always Connected PCs Now Available

Mozilla planet - to, 11/04/2019 - 15:00

Whether it’s checking the weather forecast or movie times, you can always count on the web to give you the information you’re seeking. Your choice of operating system and computer shouldn’t change your online experience. As part of Mozilla’s mission, we built Firefox as a trusted user agent for people on the web and it’s one of the reasons why we’re always looking to work with companies to optimize Firefox Quantum for their devices.

Last December, we announced our collaboration with Qualcomm, to create an ARM64-native build of Firefox for Snapdragon-powered Windows 10 Always Connected PCs. Today, we’re excited to report its availability in our beta release channel, a channel aimed at developers or early tech adopters to test upcoming features before they’re released to consumers.

Today’s release builds on the performance work done for Firefox Quantum, which uses multiple processes as efficiently as possible. Working with Qualcomm’s Snapdragon compute platform, we’re able to push the multi-core paradigm one step further, offering octa-core CPUs. We’re also taking advantage of Rust’s fearless concurrency to intelligently divide browsing tasks across those cores to deliver a fast, personal, and convenient experience.

Snapdragon powered Always Connected PCs are ideal for the road warrior because they are thin, fanless, lightweight with a long battery life and lightening fast cellular connectivity, and built to seamlessly perform daily work tasks on-the-go. We’re no stranger to optimizing the Firefox browser for any device. From Fire TV to the new iPad, we’ve custom tailored Firefox browsers for a number of different devices, because it shouldn’t matter what device you use.

Test Drive Firefox’s ARM64 for Windows 10 on Snapdragon

Your feedback is valuable for us to fine-tune this experience for a future release. If you have an ARM64 device running Windows 10, you can help by reporting bugs or submitting crash reports or simply sharing feedback. If you have any questions about your experience you can visit here for assistance.

To try the ARM64-native build of Firefox on Windows beta version, you can download it here.

The post Firefox Beta for Windows 10 on Qualcomm Snapdragon Always Connected PCs Now Available appeared first on Future Releases.

Categorieën: Mozilla-nl planet

Mozilla Localization (L10N): Implementing Fluent in a localization tool

Mozilla planet - to, 11/04/2019 - 14:42

In order to produce natural sounding translations, Fluent syntax supports gender, plurals, conjugations, and virtually any other grammatical category. The syntax is designed to be simple to read, but translators without developer background might find more complex concepts harder to deal with.

That’s why we designed a Fluent-specific user interface in Pontoon, which unleashes Fluent powers to localizers who aren’t coders. Any other general purpose Translation Management System (TMS) with support for popular localization formats can follow the example. Let’s have a closer look at Fluent implementation in Pontoon.

Storing Fluent strings in the DB

We store Fluent translations in the Translation table differently compared to other file formats.

In the string column we usually only store the translatable content, which is sufficient for representing the translation across the application. For example, string hello = Hello, world! in the .properties file format is stored as Hello, world! in Translation.string. In Fluent, we store the entire string: hello = Hello, world!.

The main reason for storing full Fluent strings are attributes, which can be present in Fluent Messages and Terms in addition to their values. Having multiple localizable values stored together allows us to build advanced UIs like the ones we use for access keys (see below).

The alternative to storing the serialized string is to store its AST. At the time of implementing Fluent support in Pontoon, the AST wasn’t as stable as the syntax, but today you should be fine with using either of these approaches.

Different presentation formats

Due to their potential complexity, Fluent strings can be presented in 4 different ways in Pontoon:

  1. In simplified form: used in string list, History tab and various other places across Pontoon, it represents the string as it appears to the end-user in the application. We generate it using FluentSerializer.serializeExpression(). For example, hello = Hello, world! would appear simply as Hello, world!.
  2. In read-only form: used to represent the source string.
  3. In editable form: used to represent the translation in the editor.
  4. As source: used to represent the translation in the source editor.
Presentation formats

Where are different presentation formats used.
You can access the source view by clicking on the FTL button.

Example walk-through

The following is a list of various Fluent strings and their appearances in a Pontoon translation interface with source string panel on top and translation editor below. In the first batch are the strings using the existing Pontoon UI, shared with other file formats.

Simple strings Simple strings

title = About Localization

Multiline strings Multiline strings

feedbackUninstallCopy = Your participation in Firefox Test Pilot means a lot! Please check out our other experiments, and stay tuned for more to come!

Strings with a single attribute Strings with a single attribute

emailOptInInput = .placeholder = email goes here :)

Next up are Fluent strings, which have attributes in addition to the value or multiple attributes. A separate text input is available for each of them.

Strings with a value and attributes Strings with a value and an attribute

shotIndexNoExpirationSymbol = ∞ .title = This shot does not expire

Since Fluent lets you combine labels and access keys within the same string, we designed a dedicated UI that lists all the allowed access keys as you translate the label. You can also type in a custom key if none of the candidates meets your criteria.

Access keys Access keys

file-menu = .label = File .accesskey = F

Terms are similar to regular messages but they can only be used as references in other messages. Hence, they are best used to define vocabulary and glossary items which can be used consistently across the localization of the entire product. Terms can have multiple variants, and Pontoon makes it easy to add/remove them.

Terms Terms

# Translated string -brandShortName = { $case -> [nominative] Firefox Račun *[genitive] Firefox Računa }

Selectors are a powerful feature of Fluent. They are used when there’s a need for multiple variants of the string based on an external variable. In the case case, PLATFORM().

Selectors Selectors

platform = { PLATFORM() -> [win] Options *[other] Preferences }

A common use case of selectors are plurals. When you translate a pluralized source string, Pontoon renders empty CLDR plural categories used in the target locale, each accompanied by an example number.

Plurals Plurals

delete-all-message = { $num -> [one] Delete this download? *[other] Delete { $num } downloads? }

Selectors can also be used in attributes. Pontoon hides most of the complexity.

Selectors in attributes Selectors in attributes

download-choose-folder = .label = { PLATFORM() -> [macos] Choose… *[other] Browse… } .accesskey = { PLATFORM() -> [macos] e *[other] o }

If a value or an attribute contains multiple selectors, Pontoon indents them for better readability.

Strings with multiple selectors Strings with multiple selectors

selector-multi = There { $num -> [one] is one email *[other] are many emails } for { $gender -> *[masculine] him [feminine] her }

Strings with nested selectors are not supported in Fluent editor, in which case Pontoon falls back to the source editor. The source editor is always available, and you can switch to it by clicking on the FTL button.

Unsupported strings Unsupported strings

Next steps

The current state of the Fluent UI in Pontoon allows us to use Fluent to localize Firefox and various other projects. We don’t want to stop here, though. Instead, we’re looking to improve the Fluent experience further and make it the best among available localization formats. You can track the list of Fluent-related Pontoon bugs in Bugzilla. Some of the highlights include:

  • Ability to change default variant
  • Ability to add/remove variants
  • Ability to add selectors to simple messages
  • Making machinery usable with more complex strings
  • Prefilling complex message skeleton in source editor
Categorieën: Mozilla-nl planet

Wladimir Palant: Bogus security mechanisms: Encrypting localhost traffic

Mozilla planet - to, 11/04/2019 - 13:07

Nowadays it is common for locally installed applications to also offer installing browser extensions that will take care of browser integration. Securing the communication between extensions and the application is not entirely trivial, something that Logitech had to discover recently for example. I’ve also found a bunch of applications with security issues in this area. In this context, one has to appreciate RememBear password manager going to great lengths to secure this communication channel. Unfortunately, while their approach isn’t strictly wrong, it seems to be based on a wrong threat assessment and ends up investing far more effort into this than necessary.

The approach

It is pretty typical for browser extensions and applications to communicate via WebSockets. In case of RememBear the application listens on port 8734, so the extension creates a connection to ws://localhost:8734. After that, messages can be exchanged in both directions. So far it’s all pretty typical. The untypical part is RememBear using TLS to communicate on top of an unencrypted connection.

So the browser extension contains a complete TLS client implemented in JavaScript. It generates a client key, and on first connection the user has to confirm that this client key is allowed to connect to the application. It also remembers the server’s public key and will reject connecting to another server.

Why use an own TLS implementation instead of letting the browser establish an encrypted connection? The browser would verify TLS certificates, whereas the scheme here is based on self-signed certificates. Also, browsers never managed to solve authentication via client keys without degrading user experience.

The supposed threat

Now I could maybe find flaws in the forge TLS client they are using. Or criticize them for using 1024 bit RSA keys which are deprecated. But that would be pointless, because the whole construct addresses the wrong threat.

According to RememBear, the threat here is a malicious application disguising as RememBear app towards the extension. So they encrypt the communication in order to protect the extension, making sure that it only talks to the real application.

Now the sad reality of password managers is: once there is a malicious application on the computer, you’ve lost already. Malware does things like logging keyboard input and should be able to steal your master password this way. Even if malware is “merely” running with user’s privileges, it can go as far as letting a trojanized version of RememBear run instead of the original.

But hey, isn’t all this setting the bar higher? Like, messing with local communication would have been easier than installing a modified application? One could accept this line argumentation of course. The trouble is: messing with that WebSocket connection is still trivial. If you check your Firefox profile directory, there will be a file called browser-extension-data/ Part of this file: the extension’s client key and RememBear application’s public key, in plain text. A malware can easily read out (if it wants to connect to the application) or modify these (if to wants to fake the application towards the extension). With Chrome the data format is somewhat more complicated but equally unprotected.

Rusty lock not attached to anything
Image by Joybot

The actual threat

It’s weird how the focus is on protecting the browser extension. Yet the browser extension has no data that a malicious application could steal. If anything, malware might be able to trick the extension into compromising websites. Usually however, malware applications manage to do this on their own, without help.

In fact, the by far more interesting target is the RememBear application, the one with the passwords data. Yet protecting it against malware is a lost cause, whatever a browser extension running in the browser sandbox can do – malware can easily do the same.

The realistic threat here are actually regular websites. You see, same-origin policy isn’t enforced for WebSockets. Any website can establish a connection to any WebSocket server. It’s up to the WebSocket server to check the Origin HTTP header and reject connections from untrusted origins. If the connection is being established by a browser extension however, the different browsers are very inconsistent about setting the Origin header, so that recognizing legitimate connections is difficult.

In the worst case, the WebSocket server doesn’t do any checks and accepts any connection. That was the case with the Logitech application mentioned earlier, it could be reconfigured by any website.

Properly protecting applications

If the usual mechanisms to ensure connection integrity don’t work, what do you do? You can establish a shared secret between the extension and the application. I’ve seen extensions requiring you to copy a secret key from the application into the extension. Another option would be the extension generating a secret and requiring users to approve it in the application, much like RememBear does it right now with the extension’s client key. Add that shared secret to every request made by the extension and the application will be able to identify it as legitimate.

Wait, no encryption? After all, somebody called out 1Password for sending passwords in cleartext on a localhost connection (article has been removed since). That’s your typical bogus vulnerability report however. Data sent to localhost never leaves your computer. It can only be seen on your computer and only with administrator privileges. So we would again be either protecting against malware or a user with administrator privileges. Both could easily log your master password when you enter it and decrypt your password database, “protecting” localhost traffic wouldn’t achieve anything.

But there is actually an even easier solution. Using WebSockets is unnecessary, browsers implement native messaging API which is meant specifically to let extensions and their applications communicate. Unlike WebSockets, this API cannot be used by websites, so the application can be certain: any request coming in originates from the browser extension.

Conclusion and outlook

There is no reasonable way to protect a password manager against malware. With some luck, the malware functionality will be too generic to compromise your application. Once you expect it to have code targeting your specific application, there is really nothing you can do any more. Any protective measures on your end are easily circumvented.

Security design needs to be guided by a realistic threat assessment. Here, by far the most important threat is communication channels being taken over by a malicious website. This threat is easily addressed by authenticating the client via a shared secret, or simply using native messaging which doesn’t require additional authentication. Everything else is merely security theater that doesn’t add any value.

This isn’t the only scenario where bogus vulnerability reports prompted an overreaction however. Eventually, I want to deconstruct research scolding password managers for leaving passwords in memory when locked. Here as well, a threat scenario has been blown out of proportion.

Categorieën: Mozilla-nl planet