mconley livehacks on real Firefox bugs while thinking aloud.

https://air.mozilla.org/the-joy-of-coding-episode-137/

This is the SUMO weekly call

https://air.mozilla.org/weekly-sumo-community-meeting-20180425/

Each talk should be 10 to 15 minutes and there will be student questions after. The entire timeline is an hour to an hour and...

https://air.mozilla.org/nyu-mspn-webinar-series-product-management/

Each talk should be 10 to 15 minutes and there will be student questions after. The entire timeline is an hour to an hour and...

https://air.mozilla.org:443/nyu-mspn-webinar-series-product-management/

Last year, Mozilla ran a survey to find out top enterprise requirements for Firefox. Policy management (especially Windows Group Policy) was at the top of that list.

For the past few months we’ve been working to build that support into Firefox in the form of a policy engine. The policy engine adds desktop configuration and customization features for enterprise users to Firefox. It works with any tool that wants to set policies including Windows Group Policy.

I’m excited to announce that our work on the policy engine has reached a major milestone and is available in the latest Firefox 60 beta.

We’d really like for folks to take a look at what we’ve done and provide feedback. We would especially like to know what kinds of things folks are doing that require AutoConfig, so we can investigate adding those things to the policy engine. This is important because we are planning to sandbox AutoConfig to only its original API in Rapid Release, probably in version 62. You can get more detail about that in bug 1455601.

We’ve set up a survey to get a lot more details about requirements. Click here for that. (Yes, I know we’ve been doing lots of surveys. We appreciate your help as we define requirements.)

If you run into specific problems you can opens bugs Github or in Bugzilla.

For a detailed list of all the policies that are available and how to use them in a policies.json file, you can check out the README.

It also includes information on which policies only work on the ESR.

If you’re using Windows, you can download the ADMX templates.

We’re currently in the process of standing up more documentation and a support forum on support.mozilla.org.

In the meantime, we have some initial documentation.

Folks are also asking what this means for the future of CCK2. I’m planning to make as much CCK2 functionality as I can available for Firefox 60. I’ll be doing another blog post soon about that.

https://mike.kaply.com/2018/04/24/enterprise-policy-support-in-firefox/

As we’ve argued on many occasions, effective government vulnerability disclosure (GVD) review processes can greatly enhance cybersecurity for governments, citizens, and companies, and help mitigate risk in an ever-broadening cyber threat landscape.  In Europe, the EU is currently discussing a new legislative proposal to enhance cybersecurity across the bloc, the so-called ‘EU Cybersecurity Act’. In that context, we’ve just published our policy recommendations for lawmakers, in which we call on the EU to seize the opportunity to set a global policy norm for government vulnerability disclosure.  

Specifically, our policy recommendations for lawmakers focus predominantly on the elements of the legislative proposal that concern the enhanced mandate for ENISA (the EU Cybersecurity agency), namely articles three to eleven. Therein, we recommend the EU co-legislators to include within ENISA’s reformed responsibilities a mandate to assist Member States in establishing and implementing  policies and practices for the responsible management and coordinated disclosure of vulnerabilities in ICT products and services that are not publicly known.

As the producer of one of the world’s most popular web browsers, it is essential for us that vulnerabilities in our software are quickly identified and patched. Simply put, the safety and security of our users depend on it. More broadly, as witnessed in the recent Petya, and WannaCry cyberattacks, vulnerabilities can be exploited by cybercriminals to cause serious damage to citizens, enterprises, public services, and governments.

Vulnerability disclosure (and the processes that underpin it) is particularly important with respect to governments. Governments often have unique knowledge of vulnerabilities, and learn about vulnerabilities in many ways: through their own research and development, by purchasing them, through intelligence work, or by reports from third parties. Crucially, governments can face conflicting incentives as to whether to disclose the existence of such vulnerabilities to the vendor immediately, or to delay disclosure in order to support offensive intelligence-gathering and law enforcement activities (so-called government hacking).

In both the US and the EU, Mozilla has long led calls for governments to codify and improve their policies and processes for handling vulnerability disclosure, including speaking out strongly in favor of the Protecting Our Ability to Counter Hacking Act (PATCH Act) in the United States. Mozilla is also a member of the Centre for European Policy Studies’ Task Force on Software Vulnerability Disclosure, a multistakeholder effort dedicated to advancing thinking on this important topic, including mapping current practices and developing a model for government vulnerability disclosure review. We strongly believe that by putting in place such frameworks, governments can contribute to greater cybersecurity for their citizens, their businesses, and even themselves.

As our policy recommendation contends, the proposed EU Cybersecurity Act offers a unique opportunity to advance the norm that Member States should have robust, accountable, and transparent government vulnerability disclosure review processes, thereby fostering greater cybersecurity in Europe. Indeed, through its capacity to assist and advise on the development of policy and practices, a reformed ENISA is well-placed to support the EU Member States in developing government vulnerability disclosure review mechanisms and sharing best practices.

Over the coming months, we’ll be working closely with EU lawmakers to explain this issue and highlight its importance for cybersecurity in Europe.

If you’re interested in reading our recommendations in full, you can access them

Thanks to Ms2ger web-platform-tests is now even more awesome (not in the American sense). To avoid writing HTML boilerplate, web-platform-tests supports .window.js, .worker.js, and .any.js resources, for writing JavaScript that needs to run in a window, dedicated worker, or both at once. I very much recommend using these resource formats as they ease writing and reviewing tests and ensure APIs get tested across globals.

Ms2ger extended .any.js to also cover shared and service workers. To test all four globals, create a single your-test.any.js resource:

// META: global=window,worker
promise_test(async () => {
  const json = await new Response(1).json()
  assert_equals(json, 1);
}, "Response object: very basic JSON parsing test");

And then you can load it from your-test.any.html, your-test.any.worker.html, your-test.any.sharedworker.html, and your-test.https.any.serviceworker.html (requires enabling HTTPS) to see the results of running that code in those globals.

The default globals for your-test.any.js are a window and a dedicated worker. You can unset the default using !default. So if you just want to run some code in a service worker:

// META: global=!default,serviceworker

Please give this a try and donate some tests for your favorite API annoyances.

https://annevankesteren.nl/2018/04/wpt-any-js

        
        $ sudo pip3 install configman
        $ sudo pip3 install webthing
        $ git clone https://github.com/twobraids/pywot.git
        $ cd pywot
        $ export PYTHONPATH=$PYTHONPATH:$PWD
        $ cd demo

When the Firefox Add-ons team ported addons.mozilla.org to a single page app backed by an API, we chose React and Redux for powerful state management, delightful developer tools, and testability. Achieving the testability part isn’t completely obvious since there are competing tools and techniques.

Below are some testing strategies that are working really well for us.

Testing must be fast and effective

We want our tests to be lightning fast so that we can ship high-quality features quickly and without discouragement. Waiting for tests can be discouraging, yet tests are crucial for preventing regressions, especially while restructuring an application to support new features.

Our strategy is to only test what’s necessary and only test it once. To achieve this we test each unit in isolation, faking out its dependencies. This is a technique known as unit testing and in our case, the unit is typically a single React component.

Unfortunately, it’s very difficult to do this safely in a dynamic language such as JavaScript since there is no fast way to make sure the fake objects are in sync with real ones. To solve this, we rely on the safety of static typing (via Flow) to alert us if one component is using another incorrectly — something a unit test might not catch.

A suite of unit tests combined with static type analysis is very fast and effective. We use Jest because it too is fast, and because it lets us focus on a subset of tests when needed.

Testing Redux connected components

The dangers of testing in isolation within a dynamic language are not entirely alleviated by static types, especially since third-party libraries often do not ship with type definitions (creating them from scratch is cumbersome). Also, Redux-connected components are hard to isolate because they depend on Redux functionality to keep their properties in sync with state. We settled on a strategy where we trigger all state changes with a real Redux store. Redux is crucial to how our application runs in the real world so this makes our tests very effective.

As it turns out, testing with a real Redux store is fast. The design of Redux lends itself very well to testing due to how actions, reducers, and state are decoupled from one another. The tests give the right feedback as we make changes to application state. This also makes it feel like a good fit for testing. Aside from testing, the Redux architecture is great for debugging, scaling, and especially development.

Consider this connected component as an example: (For brevity, the examples in this article do not define Flow types but you can learn about how to do that here.)

import { connect } from 'react-redux';
import { compose } from 'redux';

// Define a functional React component.
export function UserProfileBase(props) {
  return (
    {props.user.name}
  );
}

// Define a function to map Redux state to properties.
function mapStateToProps(state, ownProps) {
  return { user: state.users[ownProps.userId] };
}

// Export the final UserProfile component composed of
// a state mapper function.
export default compose(
  connect(mapStateToProps),
)(UserProfileBase);

You may be tempted to test this by passing in a synthesized user property but that would bypass Redux and all of your state mapping logic. Instead, we test by dispatching a real action to load the user into state and make assertions about what the connected component rendered.

import { mount } from 'enzyme';
import UserProfile from 'src/UserProfile';

describe('', () => {
  

Reuni'on bi-semanal para hablar sobre el estado de Mozilla, la comunidad y sus proyectos. Bi-weekly meeting to talk (in Spanish) about Mozilla status, community and...

https://air.mozilla.org:443/martes-mozilleros-20180424/

Firefox 60 will introduce support for the same-site cookie attribute, which allows developers to gain more control over cookies. Since browsers will include cookies with every request to a website, most sites rely on this mechanism to determine whether users are logged in.

Attackers can abuse the fact that cookies are automatically sent with every request to force a user to perform unwanted actions on the site where they are currently logged in. Such attacks, known as cross-site request forgeries (CSRF), allow attackers who control third-party code to perform fraudulent actions on the user’s behalf. Unfortunately current web architecture does not allow web applications to reliably distinguish between actions initiated by the user and those that are initiated by any of the third-party gadgets or scripts that they rely on.

To compensate, the same-site cookie attribute allows a web application to advise the browser that cookies should only be sent if the request originates from the website the cookie came from. Requests triggered from a URL different than the one that appears in the URL bar will not include any of the cookies tagged with this new attribute.

The same-site attribute can take one of two values: ‘strict’ or ‘lax’. In strict mode, same-site cookies will be withheld for any kind of cross-site usage. This includes all inbound links from external sites to the application. Visitors clicking on such a link will initially be treated as ‘not being logged in’ whether or not they have an active session with the site.

The lax mode caters to applications which are incompatible with these restrictions. In this mode, same-site cookies will be withheld on cross-domain subrequests (e.g. images or frames), but will be sent whenever a user navigates safely from an external site, for example by following a link.

For the Mozilla Security Team:
Christoph Kerschbaumer, Mark Goodwin, Francois Marier

The post Supporting Same-Site Cookies in Firefox 60 appeared first on Mozilla Security Blog.

https://blog.mozilla.org/security/2018/04/24/same-site-cookies-in-firefox-60/

https://quality.mozilla.org/2018/04/firefox-devedition-60-beta-14-testday-results/

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

This Week in Rust is openly developed on GitHub. If you find any errors in this week's issue, please submit a PR.

Updates from Rust Community

News & Blog Posts

• Announcing cargo src (beta).
• Hello wasm-pack - a tool for assembling and packaging Rust crates that targets WebAssembly.
• Dev-tools team: Goals for 2018.
• [pdf] Rust case study: Chucklefish taps Rust to bring safe concurrency to video games.
• Facebook announces fastmod, a code refactoring tool written in Rust.
• Reports from the Madrid Rust+GNOME Hackfest.
• GLib/GIO async operations and Rust futures + async/await.
• Announcing the Network Services Working Group (WG-Net).
• Small WebAssembly binaries with Rust + Emscripten.
• This week in Rust docs 102.
• [podcast] Rusty Spike Podcast - episode 26. wasm-pack, SIMD, IntelliJ, VSCode, cargo src, hackfests, rustfmt, and redox.

Crate of the Week

This week's crate is human-panic, a crate to make Rust's error handling usable to end users. Thanks to Vikrant for the suggestion!

Submit your suggestions and votes for next week!

Call for Participation

Always wanted to contribute to open-source projects but didn't know where to start? Every week we highlight some tasks from the Rust community for you to pick and get started!

Some of these tasks may also have mentors available, visit the task page for more information.

• [hard] tarpaulin: Link error with undefined reference to main on Arch. Tarpaulin is a code coverage tool for Rust projects.
• Clippy has a lot of good first issues to get started.
• Get started with these beginner-friendly issues.

If you are a Rust project owner and are looking for contributors, please submit tasks here.

Updates from Rust Core

132 pull requests were merged in the last week

• stabilize x86/x86_64 SIMD (WOOT!)
• wasm: increase default stack size to 1MB
• std: minimize size of panicking on wasm

This is the second in a series of posts about Rust compiler errors. Each one will talk about a particular error that I got recently and try to explain (a) why I am getting it and (b) how I fixed it. The purpose of this series of posts is partly to explain Rust, but partly just to gain data for myself. I may also write posts about errors I’m not getting – basically places where I anticipated an error, and used a pattern to avoid it. I hope that after writing enough of these posts, I or others will be able to synthesize some of these facts to make intermediate Rust material, or perhaps to improve the language itself.

Other posts in this series:

• Rooting an rc handle

The error: closures capture too much

In some code I am writing, I have a struct with two fields. One of them (input) contains some data I am reading from; the other is some data I am generating (output):

use std::collections::HashMap;

struct Context {
  input: HashMap<String, u32>,
  output: Vec<u32>,
}

I was writing a loop that would extend the output based on the input. The exact process isn’t terribly important, but basically for each input value v, we would look it up in the input map and use 0 if not present:

impl Context {
  fn process(&mut self, values: &[String]) {
    self.output.extend(
      values
        .iter()
        .map(|v| self.input.get(v).cloned().unwrap_or(0)),
    );
  }
}

However, this code will not compile:

error[E0502]: cannot borrow `self` as immutable because `*self.output` is also borrowed as mutable
  --> src/main.rs:13:22
     |
  10 |         self.output.extend(
     |         ----------- mutable borrow occurs here
 ...
  13 |                 .map(|v| self.input.get(v).cloned().unwrap_or(0)),
     |                      ^^^ ---- borrow occurs due to use of `self` in closure
     |                      |
     |                      immutable borrow occurs here
  14 |         );
     |         - mutable borrow ends here

As the various references to “closure” in the error may suggest, it turns out that this error is tied to the closure I am creating in the iterator. If I rewrite the loop to not use extend and an iterator, but rather a for loop, everything builds:

impl Context {
  fn process(&mut self, values: &[String]) {
    for v in values {
      self.output.push(
        self.input.get(v).cloned().unwrap_or(0)
      );
    }
  }
}

What is going on here?

Background: The closure desugaring

The problem lies in how closures are desugared by the compiler. When you have a closure expression like this one, it corresponds to deferred code execution:

|v| 

Due to lots of news coming out of the Thunderbird project, I’ve decided to combine three different blog posts I was working on into one news update that gives people an idea of what has been happening in the Thunderbird community this month. Enjoy and comment to let me know if you like or dislike this kind of post!

Enigmail GSoC Student Selected

Great news! A student has been selected for the Enigmail/Thunderbird Google Summer of Code (GSoC) project. Enigmail, the OpenPGP privacy extension for Thunderbird, submitted its project to GSoC seeking a student to help update user interface elements and assist with other design work.

Thunderbird 60, Beta 4 Released

A new version of the Thunderbird 60 Beta is out, with version four beginning to roll out. Users of the Beta are testing what will ultimately be the next Extended Support Release (ESR), which acts as our stable release and is what most of our users see. There are a lot of changes between Thunderbird 52, that last ESR, and this release. Some of these changes include: An updated “Photon” UI (like that seen in Firefox), various updates to Thunder’s “Lightning” calendar, a new “Message from Template” command, and various others. You can find a full list here.

As with every Beta, but especially this one given it will become the new stable release, we hope that you will download it and give us feedback on your experience.

A New Thunderbird Council

A new Thunderbird Council was elected this month. This new council of seven members will serve for a year. The members of the new council are as follows:

• Philipp Kewisch
• Magnus Melin
• Patrick Cloke
• Wayne Mery
• Philippe Lieser
• Jorg Knobloch
• Ryan Sipes

This blog will try to lay out the new council’s visions and priorities in future posts.

https://blog.mozilla.org/thunderbird/2018/04/thunderbird-april-news-update/

The Monday Project Meeting

https://air.mozilla.org/mozilla-weekly-project-meeting-20180423/

“Today marks the ostensible effective date for the FCC’s net neutrality repeal order, but it does not mark the end of net neutrality,” says Denelle Dixon, Mozilla COO. “And not just because some procedural steps remain before the official overturning of the rules — but because Mozilla and other supporters of net neutrality are fighting to protect it in the courts and in Congress.”

Also today: Mozilla is publishing results from a nationwide poll that reveals where Americans stand on the issue. Our survey reinforces what grassroots action has already demonstrated: The repeal contradicts most Americans’ wishes. The nation wants strong net neutrality rules.

“The new Mozilla and Ipsos poll shows once again that Americans across the political spectrum overwhelmingly want strong net neutrality protections, and that they don’t trust their ISPs to provide it for them without oversight,” says Gigi Sohn, Mozilla Fellow and former FCC counselor.

“What should make policymakers stand up and take notice is that 78% of Americans, including 84% of adults under the age of 35, believe that equal access to the internet is a right, and not a luxury,” Sohn continues.

~

Mozilla and Ipsos conducted this public opinion poll in February of 2018, surveying 1,007 American adults from across 50 states. Among our key findings:

Outside of Washington, D.C., net neutrality isn’t a partisan issue. Americans from red and blue states alike agree that equal access to the internet is a right, including: 79% of Colorado residents, 81% of Arizona residents, and 80% of North Carolina residents.

91% of Americans believe consumers should be able to freely and quickly access their preferred content on the internet. Support for net neutrality is growing: When Mozilla and Ipsos asked this same question in 2017, 86% of Americans believed this.

78% of Americans believe equal access to the internet is a right. This opinion is most common among younger Americans (84% of adults under the age of 35).

76% of Americans believe internet service providers (ISPs) should treat all consumer data the same, and not speed up or slow down specific content. This opinion is most common among older Americans (80% of adults ages 55+) and Americans with a college degree (81%).

63% of Americans do not think that ISPs will voluntarily look out for consumers’ best interests, compared to 32% who agree with this statement. Faith in ISPs is declining: When Mozilla and Ipsos asked this same question in 2017, 37% of Americans trusted ISPs.

See the full results from our poll here. See results from the 2017 Mozilla/Ipsos net neutrality poll here.

~

What’s ahead?

“Today could be the start of a shift away from freedom and innovation,” adds Denelle Dixon. “Some opponents of net neutrality will say our concerns are misplaced, and that when April 24 fails to see a wave of blocking, throttling, and fast lanes, that they were right in their claims. But that’s not how the world without net neutrality will develop. The impact won’t be immediate, like a lightswitch. Instead, we’ll see more of a gradual chipping away — an erosion into a discriminatory internet, with ultimately a far worse experience for any users and businesses who don’t pay more for special treatment.”

“There is an active lawsuit on this matter in the case titled ‘Mozilla v. FCC’ — and today is also the last day that others can file additional challenges against the FCC, following Mozilla’s lead,” Dixon concludes. “We’ve been encouraged by the support we’ve seen with allies filing suit in the industry, and we hope to see more organizations joining us in the fight to protect net neutrality.”

At some point in the coming months, the Senate will likely vote whether to undo the FCC’s repeal of net neutrality. Per the Congressional Review Act,

SUMO - 04.13.2018

https://air.mozilla.org/sumo-community-meeting/

https://atlee.ca/blog/posts/migration-status-3.html

“I wanted people to feel the whole story with their bodies, not just with their minds. Once I discovered virtual reality was the place to do that, it was transformative.”
– Nonny de la Pe~na, CEO of Emblematic

Great creators can do more than just tell a story. They can build entirely new worlds for audiences to experience and enjoy.

From rich text to video to podcasts, the Internet era offers an array of new ways for creators to build worlds. Here at Mozilla, we are particularly excited about virtual reality. Imagine moving beyond watching or listening to a story; imagine also feeling that story. Imagine being inside it with your entire mind and body. Now imagine sharing and entering that experience with something as simple as a web URL. That’s the potential before us.

To fully realize that potential, we need people who think big. We need artists and developers and engineers who are driven to push the boundaries of the imagination. We need visionaries who can translate that imagination into virtual reality.

The sky is the limit with virtual reality, and we’re driven to serve as the bridge that connects artists and developers. We are also committed to providing those communities with the tools and resources they need to begin building their own worlds. Love working with Javascript? Check out the A-Frame framework. Do you prefer building with Unity? We have created a toolkit to bring your VR Unity experience to the web with WebVR.

We believe browsers are the future of virtual and augmented reality. The ability to click on a link and enter into an immersive, virtual world is a game-changer. This is why we held our ‘VR the People’ panel at the Sundance Film Festival, and why we will be at the Tribeca Film Festival in New York next week. We want to connect storytellers with this amazing technology. If you’re at Tribeca (or just in the area), please reach out. We’d love to chat.

This concludes our four part series about virtual reality, storytelling, and the open web. It’s our mission to empower creators, and we hope these posts have left you inspired. If you’d like to watch our entire VR the People panel. Check out the video below.

Be sure to visit https://mixedreality.mozilla.org/ to learn more about the tools and resources Mozilla offers to help you build new worlds from your imagination.

Read more on VR the People

• An Open Call to Filmmakers: Make Something Amazing With Virtual Reality and the Open Web
• Virtual Reality at the Intersection of Art & Technology
• Nonny de la Pe~na & the Power of Immersive Storytelling

The post Building Bold New Worlds With Virtual Reality appeared first on The Mozilla Blog.

https://blog.mozilla.org/blog/2018/04/20/building-bold-new-worlds-with-virtual-reality/