Language Selection

English French German Italian Portuguese Spanish

Mozilla

Syndicate content
Planet Mozilla - https://planet.mozilla.org/
Updated: 1 hour 3 min ago

Hacks.Mozilla.Org: Changes to SameSite Cookie Behavior – A Call to Action for Web Developers

5 hours 15 min ago

We are changing the default value of the SameSite attribute for cookies from None to Lax. This will greatly improve security for users. However, some web sites may depend (even unknowingly) on the old default, potentially resulting in breakage for those sites. At Mozilla, we are slowly introducing this change. And we are strongly encouraging all web developers to test their sites with the new default.

Background

SameSite is an attribute on cookies that allows web developers to declare that a cookie should be restricted to a first-party, or same-site, context. The attribute can have any of the following values:

  • None – The browser will send cookies with both cross-site and same-site requests.
  • Strict – The browser will only send cookies for same-site requests (i.e., requests originating from the site that set the cookie).
  • Lax – Cookies will be withheld on cross-site requests (such as calls to load images or frames). However, cookies will be sent when a user navigates to the URL from an external site; for example, by following a link.

Currently, the absence of the SameSite attribute implies that cookies will be attached to any request for a given origin, no matter who initiated that request. This behavior is equivalent to setting SameSite=None. However, this “open by default” behavior leaves users vulnerable to Cross-Site Request Forgery (CSRF) attacks. In a CSRF attack, a malicious site attempts to use valid cookies from legitimate sites to carry out attacks.

Making the Web Safer

To protect users from CSRF attacks, browsers need to change the way cookies are handled. The two primary changes are:

  • When not specified, cookies will be treated as SameSite=Lax by default
  • Cookies that explicitly set SameSite=None in order to enable cross-site delivery must also set the Secure attribute. (In other words, they must require HTTPS.)

Web sites that depend on the old default behavior must now explicitly set the SameSite attribute to None. In addition, they are required to include the Secure attribute. Once this change is made inside of Firefox, if web sites fail to set SameSite correctly, it is possible those sites could break for users.

Introducing the Change

The new SameSite behavior has been the default in Firefox Nightly since Nightly 75 (February 2020). At Mozilla, we’ve been able to explore the implications of this change. Starting with Firefox 79 (June 2020), we rolled it out to 50% of the Firefox Beta user base. We want to monitor the scope of any potential breakage.

There is currently no timeline to ship this feature to the release channel of Firefox. We want to see that the Beta population is not seeing an unacceptable amount of site breakage—indicating most sites have adapted to the new default behavior. Since there is no exact definition of “breakage” and it can be difficult to determine via telemetry, we are watching for reports of site breakage in several channels (e.g. Bugzilla, social media, blogs).

Additionally, we’d like to see the proposal advance further in the IETF. As proponents of the open web, it is important that changes to the web ecosystem are properly standardized.

Industry Coordination

This is an industry-wide change for browsers and is not something Mozilla is undertaking alone. Google has been rolling this change out to Chrome users since February 2020, with SameSite=Lax being the default for a certain (unpublished) percentage of all their channels (release, beta, canary).

Mozilla is cooperating with Google to track and share reports of website breakage in our respective bug tracking databases. Together, we are encouraging all web developers to start explicitly setting the SameSite attribute as a best practice.

Call to Action for Web Developers

Testing in the Firefox Nightly and Beta channels has shown that website breakage does occur. While we have reached out to those sites we’ve encountered and encouraged them to set the SameSite attribute on their web properties, the web is clearly too big to do this on a case-by-case basis.

It is important that all web developers test their sites against this new default. This will prepare you for when both Firefox and Chrome browsers make the switch in their respective release channels.

Test your site in Firefox

To test in Firefox:

  1. Enable the new default behavior (works in any version past 75):
    1. In the URL bar, navigate to about:config. (accept the warning prompt, if shown).
    2. Type SameSite into the “Search Preference Name” bar.
    3. Set network.cookie.sameSite.laxByDefault to true using the toggle icon.
    4. Set network.cookie.sameSite.noneRequiresSecure to true using the toggle icon.
    5. Restart Firefox.
  2. Verify the browser is using the new SameSite default behavior:
    1. Navigate to https://samesite-sandbox.glitch.me/.
    2. Verify that all rows are green.

At this point, test your site thoroughly. In particular, pay attention to anything involving login flows, multiple domains, or cross-site embedded content (images, videos, etc.). For any flows involving POST requests, you should test with and without a long delay. This is because both Firefox and Chrome implement a two-minute threshold that permits newly created cookies without the SameSite attribute to be sent on top-level, cross-site POST requests (a common login flow).

Check your site for breakage

To see if your site is impacted by the new cookie behavior, examine the Firefox Web Console and look for either of these messages:

  • Cookie rejected because it has the “sameSite=none” attribute but is missing the “secure” attribute.
  • Cookie has “sameSite” policy set to “lax” because it is missing a “sameSite” attribute, and “sameSite=lax” is the default value for this attribute.

Seeing either of these messages does not necessarily mean your site will no longer work, as the new cookie behavior may not be important to your site’s functionality. It is critical, therefore, that each site test under the new conditions. Then, verify that the new SameSite behavior does not break anything. As a general rule, explicitly setting the SameSite attribute for cookies is the best way to guarantee that your site continues to function predictably.

Additional Resources

SameSite cookies explained

SameSite Cookies – Are you Ready?

MDN – SameSite Cookies and Common Warnings

Tracking Chrome’s rollout of the SameSite change

 

The post Changes to SameSite Cookie Behavior – A Call to Action for Web Developers appeared first on Mozilla Hacks - the Web developer blog.

Support.Mozilla.Org: New platform milestone completed: Python upgrade

5 hours 53 min ago

In 2020 a lot of the SUMO platform’s team work is focused on modernizing our support platform (Kitsune) and performing some foundational work that will allow us to grow and expand the platform. We have started this in H1 with the new Responsive and AAQ redesign. Last week we completed a new milestone: the Python/Django upgrade.

Why was this necessary

Support.mozilla.org was running on Python 2.7, meaning our core technology stack was running on a no longer supported version. We needed to upgrade to at least 3.7 and, at the same time, upgrade to the latest Django Long Term Support (LTS) version 2.2.

What have we focused on

During the last couple of weeks our work focused on upgrading the platform’s code-base from Python 2.7 to Python 3.8. We have also upgraded all the underlying libraries to their latest version compatible with Python 3.8 and replaced non compatible Python libraries with a compatible library with equivalent functionality. Furthermore we upgraded Django to the latest LTS version, augmented testing coverage and improved developer tooling.

What’s next

In H2 2020, we’re continuing the work on platform modernization, our next milestone being the full redesign of our search architecture (including the upgrade of the ElasticSearch service from and re implementation of the search functionality from scratch). With this we are also looking into expanding our Search UI and adding new features to offer a better internal search experience to our users.

The Mozilla Blog: Latest Firefox rolls out Enhanced Tracking Protection 2.0; blocking redirect trackers by default

6 hours 56 min ago

Today, Firefox is introducing Enhanced Tracking Protection (ETP) 2.0, our next step in continuing to provide a safe and private experience for our users. ETP 2.0 protects you from an advanced tracking technique called redirect tracking, also known as bounce tracking. We will be rolling out ETP 2.0 over the next couple of weeks.

Last year we enabled ETP by default in Firefox because we believe that understanding the complexities and sophistication of the ad tracking industry should not be required to be safe online. ETP 1.0 was our first major step in fulfilling that commitment to users. Since we enabled ETP by default, we’ve blocked 3.4 trillion tracking cookies. With ETP 2.0, Firefox brings an additional level of privacy protection to the browser.

Since the introduction of ETP, ad industry technology has found other ways to track users: creating workarounds and new ways to collect your data in order to identify you as you browse the web. Redirect tracking goes around Firefox’s built-in third-party cookie-blocking policy by passing you through the tracker’s site before landing on your desired website. This enables them to see where you came from and where you are going.

Firefox deletes tracking cookies every day

With ETP 2.0, Firefox users will now be protected against these methods as it checks to see if cookies and site data from those trackers need to be deleted every day. ETP 2.0 stops known trackers from having access to your information, even those with which you may have inadvertently visited. ETP 2.0 clears cookies and site data from tracking sites every 24 hours.

Sometimes trackers do more than just track. They may also offer services you engage with, such as a search engine or social network. If Firefox cleared cookies for these services we’d end up logging you out of your email or social network every day, so we don’t clear cookies from sites you have interacted with in the past 45 days, even if they are trackers. This way you don’t lose the benefits of the cookies that keep you logged in on sites you frequent, and you don’t open yourself up to being tracked indefinitely based on a site you’ve visited once. To read the technical details about how this works, visit our Security Blog post.

What does this all mean for you? You can simply continue to browse the web with Firefox. We are doing more to protect your privacy, automatically. Without needing to change a setting or preference, this new protection deletes cookies that use workarounds to track you so you can rest easy.

Check out and download the latest version of Firefox available here.

The post Latest Firefox rolls out Enhanced Tracking Protection 2.0; blocking redirect trackers by default appeared first on The Mozilla Blog.

Mozilla Security Blog: Firefox 79 includes protections against redirect tracking

7 hours 24 sec ago

A little over a year ago we enabled Enhanced Tracking Protection (ETP) by default in Firefox. We did so because we recognize that tracking poses a threat to society, user safety, and the autonomy of individuals and we’re committed to protecting users against these threats by default. ETP was our first step in fulfilling that commitment, but the web provides many covert avenues trackers can use to continue their data collection.

Today’s Firefox release introduces the next step in providing a safer and more private experience for our users with Enhanced Tracking Protection 2.0, where we will block a new advanced tracking technique called redirect tracking, also known as bounce tracking. ETP 2.0 clears cookies and site data from tracking sites every 24 hours, except for those you regularly interact with. We’ll be rolling ETP 2.0 out to all Firefox users over the course of the next few weeks.

What is “redirect” tracking?

When we browse the web we constantly navigate between websites; we might search for “best running shoes” on a search engine, click a result to read reviews, and finally click a link to buy a pair of shoes from an online store. In the past, each of these websites could embed resources from the same tracker, and the tracker could use its cookies to link all of these page visits to the same person. To protect your privacy ETP 1.0 blocks trackers from using cookies when they are embedded in a third party context, but still allows them to use cookies as a first party because blocking first party cookies causes websites to break. Redirect tracking takes advantage of this to circumvent third-party cookie blocking.

Redirect trackers work by forcing you to make an imperceptible and momentary stopover to their website as part of that journey. So instead of navigating directly from the review website to the retailer, you end up navigating to the redirect tracker first rather than to the retailer. This means that the tracker is loaded as a first party and therefore is allowed to store cookies. The redirect tracker associates tracking data with the identifiers they have stored in their first-party cookies and then forwards you to the retailer.

A step-by-step explanation of redirect tracking: 

Let’s say you’re browsing a product review website and you click a link to purchase a pair of shoes from an online retailer. A few seconds later Firefox navigates to the retailer’s website and the product page loads. Nothing looks out of place to you, but behind the scenes you were tracked using redirect tracking. Here’s how it happened:

  • Step 1: On the review website you click a link that appears to take you to the retail site. The URL that was visible when you hovered over the link belonged to the retail site.
  • Step 2: A redirect tracker embedded in the review site intercepts your click and sends you to their website instead. The tracker also saves the intended destination—the retailer’s URL that you actually thought you were visiting when you clicked the link.
  • Step 3: When the redirect tracker is loaded as a first party, the tracker will be able to access its cookies. It can associate information about which website you’re coming from (and where you’re headed) with identifiers stored in those cookies. If a lot of websites redirect through this tracker, the tracker can effectively track you across the web.
  • Step 4: After it finishes saving its tracking data, it automatically redirects you to the original destination.
How does Firefox protect against redirect tracking?

Once every 24 hours ETP 2.0 will completely clear out any cookies and site data stored by known trackers. This prevents redirect trackers from being able to build a long-term profile of your activity.

When you first visit a redirect tracker it can store a unique identifier in its cookies. Any redirects to that tracker during the 24 hour window will be able to associate tracking data with that same identifying cookie. However, once ETP 2.0’s cookie clearing runs, the identifying cookies will be deleted from Firefox and you’ll look like a fresh user the next time you visit the tracker.

This only applies to known trackers; cookies from non-tracking sites are unaffected. Sometimes trackers do more than just track; trackers may also offer services you engage with, such as a search engine or social network. If Firefox cleared cookies for these services we’d end up logging you out of your email or social network every day. To prevent this, we provide a 45 day exception for any trackers that you’ve interacted with directly, so that you can continue to have a good experience on their websites. This means that the sites you visit and interact with regularly will continue to work as expected, while the invisible “redirect” trackers will have their storage regularly cleared. A detailed technical description of our protections is available on MDN.

ETP 2.0 is an upgrade to our suite of default-on tracking protections. Expect to see us continue to iterate on our protections to ensure you stay protected while using Firefox.

The post Firefox 79 includes protections against redirect tracking appeared first on Mozilla Security Blog.

The Mozilla Blog: Fast Company Recognizes Katharina Borchert as one of the Most Creative Business People

8 hours 1 min ago

We are proud to share that Katharina Borchert, Mozilla’s Chief Open Innovation Officer, has been named one of the Most Creative People by Fast Company. The award recognizes her leadership on Common Voice and helping to collect and diversify open speech data to build and train voice-enabled applications. Katharina was recognized not just for a groundbreaking idea, but because her work is having a measurable impact in the world.

Among the 74 receiving this award are leaders such as Kade Crockford of the American Civil Liberties Union of Massachusetts, for work leading to banning face surveillance in Boston, and Stina Ehrensvärd, CEO of Yubikey, for the building of WebAuthn, a heightened set of security protocols, a collaboration with Google, Mozilla and Microsoft. The full list also includes vintner Krista Scruggs, dancer and choreographer Twyla Tharp, and Ryan Reynolds: “for delivering an honest message, even when it’s difficult”.

“‘This is a real honor,” said Katharina, “which also reflects the contributions of an incredible alliance of people at Mozilla and beyond. We have a way to go before the full promise of Common Voice is realized. But I’m incredibly inspired by the different communities globally building it together with Mozilla, because language is so important for our identities and for keeping cultural diversity alive in the digital age. Extending the reach of voice recognition to more languages can only open the doors to more innovation and make tech more inclusive.”

Common Voice is Mozilla’s global crowdsourcing initiative to build multilingual open voice datasets that help teach machines how real people speak. Since 2017, we’ve made unparalleled progress in terms of language representation. There’s no comparable initiative, nor any open dataset, that includes as many (also under-resourced) languages. This makes it the largest multilingual public domain voice dataset. In June this year we released an updated edition with more than 7,200 total hours of contributed voice data in 54 languages, including English, German, Spanish, and Mandarin Chinese (Traditional), but also, Welsh, Kabyle, and Kinyarwanda.

The growing Common Voice dataset is unique not only in its size and licence model, but also in its diversity. It is powered by a global community of voice contributors, who want to help build inclusive voice technologies in their own languages, and allow for local value creation.

This is the second award for Mozilla from Fast Company in as many years, and the second time Common Voice has been recognized, after it was honored as a finalist in the experimental category in the Innovation by Design Awards in 2018. To keep up with future developments in Common Voice, follow the project on our Discourse forum.

(Photo Credit: Nick Leoni Photography)

The post Fast Company Recognizes Katharina Borchert as one of the Most Creative Business People appeared first on The Mozilla Blog.

The Firefox Frontier: Moth wants you to design a Firefox Theme for San Francisco Shock

Monday 3rd of August 2020 08:45:26 PM

This summer we partnered with Overwatch League’s San Francisco Shock to help the fans at home cheer on their 2019 Grand Finals Champions. This included Firefox Protection Plays and giving … Read more

The post Moth wants you to design a Firefox Theme for San Francisco Shock appeared first on The Firefox Frontier.

The Rust Programming Language Blog: Announcing Rust 1.45.2

Monday 3rd of August 2020 12:00:00 AM

The Rust team is announcing a new version of Rust, 1.45.2. Rust is a programming language that is empowering everyone to build reliable and efficient software.

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

rustup update stable

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

What's in 1.45.2 stable

1.45.2 contains two fixes, one to 1.45.1 and the other to 1.45.0.

#[track_caller] on trait objects

Trait objects with methods annotated with #[track_caller] would be miscompiled. #[track_caller] is not yet stable on 1.45. However, the standard library makes use of this on some traits for better error messages. Trait objects of SliceIndex, Index, and IndexMut were affected by this bug.

Tuple patterns binding .. to an identifier

In 1.45.1, we backported a fix for #74539, but this fix turned out to be incorrect, causing other unrelated breakage. As such, this release reverts that fix.

Contributors to 1.45.2

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

Frederik Braun: Reference Sheet for Principals in Mozilla Code

Sunday 2nd of August 2020 10:00:00 PM

Note: This is the reference sheet version. The details and the big picture are covered in Understanding Web Security Checks in Firefox (Part 1).

Principals as a level of privilege

A security context is always using one of these four kinds of Principals:

  • ContentPrincipal: This principal is used for typical …

Daniel Stenberg: HTTP/3 logo

Saturday 1st of August 2020 03:30:06 PM

Simply because it is so hard to find this resource by googling it. Here’s the official HTTP/3 logo hosted:

https://github.com/httpwg/wg-materials/tree/gh-pages/badge/http3

Firefox UX: Ordering Browser Tabs Chronologically to Support Task Continuity

Friday 31st of July 2020 02:08:59 PM

Product teams working on Firefox at Mozilla have long been interested in helping people get things done, whether that’s completing homework for school, shopping for a pair of shoes, or doing one’s taxes. We are deeply invested in how we can support task continuity, the various steps that people take in getting things done, in our browser products. And we know that in our browsers, tabs play an important role for people carrying out tasks.

Task continuity model

In 2015, Firefox researchers Gemma Petrie and Bill Selman developed a model to explain different types of task continuity strategies, which are represented in the middle of the diagram below.

Passive strategies include behaviors like leaving a tab open, such as a page for a product that one is considering purchasing. Active strategies include actions like emailing a link, for example a link to a recipe to cook at a later time, to oneself. Share strategies might involve using social media to share content, such as a news article, with other people.

Fast forward to this year and the team working on Firefox for iOS was interested in how we might support task continuity involving leaving tabs open. We continued to see in user research the important role that tabs play in task continuity, and we wanted to explore how to make tab retrieval and overall tab management easier.

In most web browsers on smartphones, tabs are ordered based on when a person first opened them, with the oldest tabs on one end of the interface (top, bottom, left, or right) and the newest tabs stacking to the opposite end of the interface. This ordering logic gets more complex if a new tab is prompted to open when someone taps on a link in an existing tab. A site may be designed to launch links in new tabs or a person may choose to open new tabs for links. The new tab, in that case, typically will open immediately next to the tab where the link was tapped, pushing all other later tabs toward the other end of the interface. All of this gets even trickier when managing more than just a few tabs. This brief demonstration illustrates tab ordering logic in Firefox for iOS before chronological tabs using the example of someone shopping for a food processor.

<figcaption class="imageCaption"></figcaption>

Based on a trove of user research, the iOS team raised the following question:

Would ordering tabs chronologically in Firefox for iOS make it easier for people to stay organized and feel more in control of their tabs?

The team conducted user research, led by Elisabeth Klann, in April of this year to understand current tab behaviors and to evaluate a basic prototype of the concept of chronological tabs.

A screenshot of the prototype used for the concept evaluation in April 2020, showing a fictional set of open tabs in Firefox for iOS

We recruited 10 adult participants in the US, half of whom were already using Firefox for iOS and half of whom used either Safari or Chrome as their main browser on their iPhone.

What we learned from the first round of user research

From asking participants about their existing behaviors with browser tabs on their phones, the Firefox for iOS team was pleasantly surprised to hear participants describe the order of their tabs in terms of time. Participants fell into three categories in terms of their tab habits:

  • “I keep it clean” when the participant generally tried to avoid clutter and closed individual tabs often
  • “I keep forgetting” when the participant was not conscious of accumulating tabs and typically closed tabs in batches when the experience became cumbersome
  • “I keep tabs open for reference…short term” when the participant was more strategic in leaving tabs open for a few sessions until a task was complete

All participants were able to discern the chronological ordering of tabs in the prototype and reported that the ordering was helpful, particularly the chronological ordering of the most recent tabs. It was important to participants that they be able to delete single tabs and batches of tabs, and we identified an opportunity for making batch deletion more discoverable in the UI. Following this round of user research, the team made numerous changes to the tab design, led by Nicole Weber, which were incorporated into a beta build of Firefox for iOS.

One change made after the concept evaluation was to attach dates to the “Today” and “Yesterday” categories of open tabs and to change the “Older” label to the more specific “Last Week.”

Another change made after the concept evaluation was to make the functionality for deleting a tab easier to access.

Continuing to learn with a beta build in a diary study

With the beta build, an early version of Firefox for iOS with chronological tabs and only available to research participants, the Mozilla team wanted to do another round of user research to understand the perceptions and utility of chronological tabs, this time in the real-world context with participants using their own devices rather than the pre-designed tabs of a prototype. We recruited 10 new participants, adults in Canada and the US and again a mix of people already using Firefox on their iPhones and people using other browsers.

Participants used the beta build of Firefox for iOS with chronological tabs as their primary iPhone browser for three days and answered a brief survey at the end of each of those days about their experience moving between web pages and of Firefox overall. Survey questions included:

  • Did you use Firefox Beta to visit more than one web page today?
  • Thinking about when you moved between tabs you were using today, was there anything particularly easy, difficult, and/or confusing about that?
  • Did you revisit any tabs from yesterday or before yesterday? If so, can you please describe what you were doing and what it was like to revisit that older tab?

After three days, we interviewed participants to discuss their survey responses and overall experience with chronological tabs.

From the second round of user research, we learned that while the chronological order of tabs did not seem to break any workflows, it was the overall design of the tabs themselves — the thumbnail image, page title and/or URL, and date stamp in a list-like format — that made tabs more helpful than existing designs such as the undated, untitled, deck-like tabs in Safari on iPhone. One participant explained that the formatting of the tabs reminded her of tasks she wanted to complete. She said:

“So is it was this layout that kind of nudged me because I was going back to a page. And I was like, oh yeah, I went to that one, too. That’s right. And then I went back and did that task.”

Another participant also said, in going back to the view of all of his open tabs with the small images, he remembered the shoes he was shopping for the day before and his desire to return to that shopping. He returned to the tab with the shoes during our interview.

Participant C1’s open tabs in Firefox Beta, including a tab with a thumbnail of a shoe

There were instances, however, when the proposed design broke. A bug rendered some tabs unintelligible due to thumbnail images not populating. Also, several participants used enlarged text on their devices, a setting we did not anticipate that resulted in truncated tab titles and URLs. Participants for whom thumbnails were not populating and tab titles were truncated had a particularly difficult time discerning tabs. We also identified an opportunity, which we know is also an opportunity in the desktop browser, to make tabs more discernible in situations when a person has multiple tabs that look similar, particularly at thumbnail scale, like several Amazon pages or pages from different retailers all for the same product.

Participant C3’s open tabs in Firefox Beta with blank thumbnail images and truncated tab titles and URLs

While we are actively working on fixing the bug related to the thumbnail images, it was nevertheless helpful to learn about situations where the design fell short — the key takeaway being that the different parts of the design, the date stamps, the thumbnail image, the page title, and the URL work in concert to help people remember pages they have visited and the context for those visits.

Next: Setting out to understand if iOS findings carry over to other platforms

The team, led by Ashley Thomas, plans to continue work on chronological tabs, such as investigating how we can make tab meta data populate more reliably and planning user research to evaluate the proposed design on Android, tablets, and desktop. Some of the questions the team is excited to pursue in coming weeks include:

  • Are there ways to improve further the accessibility of the proposed design?
  • Will complex workflows common to larger form factors help us uncover new insights about chronological tabs?
  • Is tab functionality most helpful when it is the same across platforms or might platform-specific designs better support task continuity?
  • Are there other ways of sorting tabs that would support people’s workflows?

Thank you to the Firefox for iOS team and the many Mozillians, including people outside of the iOS team, who reviewed and provided valuable feedback on an early draft of this post.

Originally published on medium.com

The Rust Programming Language Blog: Announcing Rust 1.45.1

Thursday 30th of July 2020 12:00:00 AM

The Rust team is happy to announce a new version of Rust, 1.45.1. Rust is a programming language that is empowering everyone to build reliable and efficient software.

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

rustup update stable

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

What's in 1.45.1 stable

1.45.1 contains a collection of fixes, including one soundness fix. All patches in 1.45.1 address bugs that affect only the 1.45.0 release; prior releases are not affected by the bugs fixed in this release.

Fix const propagation with references

In Rust 1.45.0, rustc's const propagation pass did not properly handle encountering references when determining whether to propagate a given constant, which could lead to incorrect behavior. Our releases are run through crater, and we did not detect it, which helps us be fairly confident that this affects a very small set of code in the wild (if any).

The conditions necessary to cause this bug are highly unlikely to occur in practice: the code must have inputs consisting of entirely constant values and no control flow or function calls in between.

struct Foo { x: u32, } fn main() { let mut foo = Foo { x: 42 }; let x = &mut foo.x; *x = 13; let y = foo; println!("{}", y.x); // -> 42; expected result: 13 } Contributors to 1.45.1

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

The Firefox Frontier: ’90s vibes: Fresh themes for Firefox, video calls and more

Wednesday 29th of July 2020 11:28:32 PM

Raise your hand if your watchlists are showing signs of ‘90s reruns. Saved by the Bell, Friends and The Fresh Prince of Bel-Air are making comfort TV comebacks along with … Read more

The post ’90s vibes: Fresh themes for Firefox, video calls and more appeared first on The Firefox Frontier.

Mozilla Addons Blog: Openness and security: a balancing act for the add-ons ecosystem

Wednesday 29th of July 2020 03:15:10 PM

Add-ons offer a powerful way for people to customize their web experience in Firefox. From content blocking and media enhancement to productivity tooling, add-ons allow third-party developers to create, remix, and share new products and experiences for the web. The same extensibility that allows developers to create utility and delight in Firefox, however, can also be used by malicious actors to harvest and sell user data.

With an ecosystem of 20,000+ extensions hosted on addons.mozilla.org (AMO), hundreds of thousands of self-distributed extensions, and millions of users around the world, finding the right balance between openness and security is a key challenge for our small team. Developers need to feel supported on our platform, and users need to feel safe installing add-ons, so we continually make adjustments to balance these interests.

Adapting our review model

Prior to the adoption of a new extensions API in 2017, buggy or malicious add-ons could take nearly full control of Firefox, and in some cases, a user’s device. Because these extensions could do so much potential damage, all add-ons hosted on addons.mozilla.org (AMO) had to pass human review before they could be released to users. This led to long delays where developers sometimes waited weeks, if not months, for their submissions to be reviewed. In some cases, developers waited months for an add-on to be reviewed, only to have it rejected.

The transition to the new extensions API greatly limited the potential for add-ons to cause damage. Reducing the attack surface enabled us to move to a post-submission review model, where extensions undergo automated checks and are prioritized for human review based on certain risk factors before becoming available, usually within a few hours. All add-ons are subject to human review at any time after publication.

Human reviews are still necessary

Since the transition to a post-submission review model, we have continued to make adjustments to our products, systems, and processes to maintain a balance between user safety and developer support. While we’ve made gains in new mechanisms to combat malicious activity, human review remains the most reliable method for verifying the safety of an add-on because of the complex and contextual nature of add-on code written in JavaScript.

However, human code review is a resource-intensive activity. As we weighed our options for how to keep add-ons safe for users in 2019, it became clear that we only possessed the resources to guarantee human reviews for a small number of extensions. Because we already had an editorial program in place for identifying and featuring add-ons, it made sense to build a trusted add-on program off past curatorial efforts. This became the Recommended Extensions program.

Currently, we human-review every version of each of our 100+ Recommended Extensions before publication. Beyond that, our limited review resources are focused on monitoring and stamping out malicious activity that may be lurking in our ecosystem. For a sense of scale, AMO receives 20,000+ new version submissions per month.

Since we can only guarantee human-review for all versions of Recommended Extensions, AMO applies a warning message to the listing pages of all non-Recommended extensions. The intention of this message is to let users know that since a non-Recommended extension may not have been reviewed by a human, we can’t guarantee it’s safe.

Developer feedback and future plans

We’ve heard feedback from developers whose add-ons are not in the Recommended program that they are concerned the warning message can discourage users from installing their add-ons. Some have asked whether it’s possible to request human reviews for their add-ons so they can be badged as safe to install. We are exploring ways to better support these developers and provide more discovery opportunities for them.

During the remainder of 2020, we will experiment with new programs to address these issues and help more extensions become successful. Please stay tuned to this blog for updates on the upcoming experiments and opportunities for participation, and head to our community forum with any questions or feedback.

The post Openness and security: a balancing act for the add-ons ecosystem appeared first on Mozilla Add-ons Blog.

The Talospace Project: Firefox 79 on POWER

Wednesday 29th of July 2020 04:14:43 AM
Firefox 79 is out. There are many new web and developer-facing features introduced in this version, of which only a couple are of note to us in 64-bit PowerPC land specifically. The first is a migration of WebExtensions storage to a new Rust-based implementation; there was a bit of a pause while extension storage migrated, so don't panic if the browser seems to stall out for a few long seconds on first run. The second is a further rollout of WebRender to more Windows configurations, so this seemed like a good time to me to check again how well it's working on this side of the fence. With the Raptor BTO WX7100 installed in this Talos II, I've forced it on with gfx.webrender.enabled and layers.acceleration.force-enabled both set to true (restart the browser after) and worked with it all afternoon with no issues noted, so this time I'm just going to leave it on and see how it goes. Any GCN-based AMD video card from Northern Islands on up (the WX7100 is Polaris) should work. about:support will show you if WebRender and hardware acceleration are enabled, though currently no Linux configuration has it enabled by default.

Unfortunately, it turns out relatively few of us are like me where we build the browser ourselves from source, and it seems some distros are enabling features — most likely higher-level optimizations — that trigger broken builds on ppc64le (Ubuntu was mentioned by at least one user). It would be nice to whittle down the offending feature(s) they enabled, both to get local fixes to the distro package configurations and then look at why they don't work (or make the default not to enable them on our platform, solving the problem in both places). I suspect LTO and PGO are to blame, which have a long history of being troublesome, as well as various defects in gold (use GNU bfd as the linker instead). Meanwhile, the build I'm typing this blog post into locally is still happily running on the same .mozconfigs from Firefox 67.

Daniel Stenberg: curl ootw: –path-as-is

Tuesday 28th of July 2020 10:08:00 PM

Previous options of the week.

--path-as-is is a boolean option that was added in curl 7.42.0.

Path normalization in URLs

I hope it isn’t a surprise to you that curl works on URLs. It’s one of the fundamental pillars of curl. The “URLs” curl work with are actually called “URIs” in the IETF specs and the primary specification for them is RFC 3986. (But also: my URL is not your URL…)

A URL can be split up into several different components, which is typically done by the “URL parser” in a program like curl. For example , we can identify a scheme, a host name and a path.

When a program is given a URL, and the program has identified the path part of that URL – it is supposed to “Remove Dot Segments” (to use the wording from RFC 3986) before that path is used.

Remove Dot Segments

Let me show you this with an example to make it clear. Ponder that you pass this URL to curl: "https://example.org/hello/../to/../your/../file". Those funny dot-dot sequences in there is traditional directory traversal speak for “one directory up”, while a single "./" means in the same directory.

RFC 3986 says these sequences should be removed, so curl will iterate and remove them accordingly. A sequence like "word/../" will effectively evaluate to nothing. The example URL above will be massaged into the final version: "https://example.org/file" and so curl will ask the server for just /file.

Compare the HTTP requests

Seen as pure HTTP 1.1, the result of the command line used without --path-as-is:

GET /file HTTP/1.1
Host: example.org
user-agent: curl/7.71.0
accept: */*

Same command line, with --path-as-is:

GET /hello/../to/../your/../file HTTP/1.1
Host: example.org
user-agent: curl/7.71.1
accept: */* Trick thy server

HTTP servers have over the years been found to have errors and mistakes in how they handle paths and a common way to exploit such flaws has been to pass on exactly this kind of dot-dot sequences to servers.

The very minute curl started removing these sequences (as the spec tells us) security researcher objected and asked for ways to tell curl to not do this. Enter --path-as-is. Use this option to make curl send the path exactly as provided in the URL, without removing any dot segments.

Related options

Other curl options that allow you to customize HTTP request details include --header, --request and --request-target.

Hacks.Mozilla.Org: Firefox 79: The safe return of shared memory, new tooling, and platform updates

Tuesday 28th of July 2020 03:06:39 PM

A new stable version of Firefox brings July to a close with the return of shared memory! Firefox 79 also offers a new Promise method, more secure target=_blank links, logical assignment operators, and other updates of interest to web developers.

This blog post provides merely a set of highlights; for all the details, check out the following:

New in Developer Tools

First, we look at the new additions to the Firefox DevTools in version 79.

JavaScript logging and debugging capabilities Async stack traces everywhere

Modern JavaScript depends on promises, async/await, events, and timeouts to orchestrate complex scheduling between your code, libraries, and the browser. And yet, it can be challenging to debug async code to understand control and data flow. Operations are broken up over time. Async stack traces solve this by combining the live synchronous part of the stack with the part that is captured and asynchronous.

Now you can enjoy detailed async execution chains in the Firefox JavaScript Debugger’s call stack, Console errors, and Network initiators.

To make this work, the JavaScript engine captures the stack when a promise is allocated or when some async operation begins. Then the captured stack is appended to any new stacks captured.

Better debugging for erroneous network responses

Failing server requests can lead to a cascade of errors. Previously, you had to switch between the Console and Network panels to debug, or enable the XHR/Requests filters in the Console. With Firefox 79, the Console shows network requests with 4xx/5xx error status codes by default. In addition, the request/response details can be expanded to inspect the full details. These are also available in the Network Inspector.

Tip: To further debug, retry, or verify server-side changes, use the “Resend Request” context-menu option. It’s available in both the Console and Network panels. You can send a new request with the same parameters and headers. The additional “Edit and Resend” option is only available in the Network panel. It opens an editor to tweak the request before sending it.

Debugger highlights errors in code

Many debugging sessions start by jumping from a logged JavaScript error to the Debugger. To make this flow easier, errors are now highlighted in their corresponding source location in the Debugger. Furthermore, relevant details are shown on hover, in the context of the code, and paused variable state.

We’d like to say thanks to core contributor Stepan Stava, who is already building this feature out, further blurring the line between logging and debugging.

Restart frame in Call Stack

When you restart frames from the Debugger, the call stack moves the execution pointer to the top of the function. With the caveat that the state of variables is not reset, this allows time-traveling within the current call stack.

“Restart Frame” is now available as a context-menu option in the Debugger’s call stack. Again, we have Stepan Stava to thank for this addition, which Debugger users will recognize from Chrome and VS Code.

Faster JavaScript debugging

Performance improvements in this release speed up debugging, particularly for projects with large files. We also fixed a bottleneck that affected eval-heavy code patterns, which will now just work.

Inspector updates Better source map references for SCSS and CSS-in-JS

We’ve improved source map handling across all panels, so that opening SCSS and CSS-in-JS sources from the Inspector now works more reliably. You can quickly jump from the rules definitions in the Inspector side panel to the original file in the Style Editor.

New Inspect accessibility properties context menu

The Accessibility Inspector is now always available in the browser context menu. allows you can open the element in the Accessibility panel directly, to inspect ARIA properties and run audits.

More tooling updates
  • The “Disable Cache” option in the Network panel now also deactivates CORS preflight request caching. This makes it easier to iterate on your web security settings.
  • Contributor KC aligned the styling for blocked requests shown in Console with their appearance in the Network panel.
  • Richard Sherman extended the reach of tooltips, which now describe the type and value for previewed object values across Console and Debugger.
  • To consolidate sidebar tabs, Farooq AR moved Network’s WebSocket “Messages” tab into the “Response” tab.
  • Debugger’s references to “blackbox” were renamed “ignore”, to align wording with other tools and make it more inclusive. Thanks to Richard Sherman for this update too!
Web platform updates Implicit rel=noopener with target=_blank links

To prevent the DOM property window.opener from being abused by untrusted third-party sites, Firefox 79 now automatically sets rel=noopener for all links that contain target=_blank. Previously, you had to set rel=noopener manually to make window.opener = null for every link that uses target=_blank. In case you need window.opener, explicitly enable it using rel=opener.

SharedArrayBuffer returns

At the start of 2018, Shared Memory and high-resolution timers were effectively disabled in light of Spectre. In 2020, a new, more secure approach has been standardized to re-enable shared memory. As a baseline requirement, your document needs to be in a secure context. For top-level documents, you must set two headers to cross-origin isolate your document:

To check if cross-origin isolation has been successful, you can test against the crossOriginIsolated property available to window and worker contexts:

if (crossOriginIsolated) { // use postMessage and SharedArrayBuffer } else { // Do something else }

Read more in the post Safely reviving shared memory.

Promise.any support

The new Promise.any() method takes an iterable of Promise objects and, as soon as one of the promises in the iterable fulfills, returns a single promise resolving to the value from that promise. Essentially, this method is the opposite of Promise.all(). Additionally, Promise.any() is different from Promise.race(). What matters is the order in which a promise is fulfilled, as opposed to which promise settles first.

If all of the promises given are rejected, a new error class called AggregateError is returned. In addition, it indicates the reason for the rejection(s).

const promise1 = Promise.reject(0); const promise2 = new Promise((resolve) => setTimeout(resolve, 100, 'quick')); const promise3 = new Promise((resolve) => setTimeout(resolve, 500, 'slow')); const promises = [promise1, promise2, promise3]; Promise.any(promises).then((value) => console.log(value)); // quick wins Logical assignment operators

JavaScript supports a variety of assignment operators already. The Logical Assignment Operator Proposal specifies three new logical operators that are now enabled by default in Firefox:

These new logical assignment operators have the same short-circuit behavior that the existing logical operations implement already. Assignment only happens if the logical operation would evaluate the right-hand side.

For example, if the “lyrics” element is empty, set the innerHTML to a default value:

document.getElementById('lyrics').innerHTML ||= '<i>No lyrics.</i>'

Here the short-circuit is especially beneficial, since the element will not be updated unnecessarily. Moreover, it won’t cause unwanted side-effects such as additional parsing or rendering work, or loss of focus.

Weakly held references

In JavaScript, references between objects are generally 1-1: if you have a reference to one object so that it cannot be garbage collected, then none of the objects it references can be collected either. This changed with the addition of WeakMap and WeakSet in ES2015, where you now need to have a reference to both the WeakMap and a key in order to prevent the corresponding value from being collected.

Since that time, JavaScript has not provided a more advanced API for creating weakly held references, until now. The WeakRef proposal adds this capability. Now Firefox supports the WeakRef and FinalizationRegistry objects.

Hop over to the MDN docs for example usage of WeakRef. Garbage collectors are complicated, so make sure you also read this note of caution before using WeakRefs.

WebAssembly

Firefox 79 includes new WebAssembly functionality:

  • First off, seven new built-in operations are provided for bulk memory operations. For example, copying and initializing allow WebAssembly to model native functions such as memcpy and memmove in a more efficient, performant way.
  • The reference-types proposal is now supported. It provides a new type, externref, which can hold any JavaScript value, for example strings, DOM references, or objects. The wasm-bindgen documentation includes guidance for taking advantage of externref from Rust.
  • With the return of SharedArrayBuffer objects, we’re now also able to support WebAssembly threads. Thus, it is now possible for WebAssembly Memory objects to be shared across multiple WebAssembly instances running in separate Web Workers. The outcome? Very fast communication between Workers, as well as significant performance gains in web applications.
WebExtensions updates

Starting with Firefox 79, developers of tab management extensions can improve the perceived performance when users switch tabs. The new tabs.warmup() function will prepare the tab to be displayed. Developers can use this function, when they anticipate a tab switch, e.g. when hovering over a button or link.

If you’re an extension developer and your extensions sync items across multiple devices, be aware that we ported storage.sync area to a Rust-based implementation. Extension data that had been stored locally in existing profiles will automatically migrate the first time an installed extension tries to access storage.sync data in Firefox 79. As a quick note, the new implementation enforces client-side quota limits. You should estimate how much data your extension stores locally and test how your extension behaves once the data limit is exceeded. Check out this post for testing instructions and more information about this change.

Take a look at the Add-ons Blog for more updates to the WebExtensions API in Firefox 79!

Summary

As always, feel free to share constructive feedback and ask questions in the comments. And thanks for keeping your Firefox up to date!

The post Firefox 79: The safe return of shared memory, new tooling, and platform updates appeared first on Mozilla Hacks - the Web developer blog.

This Week In Rust: This Week in Rust 349

Tuesday 28th of July 2020 04:00:00 AM

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.

Check out this week's This Week in Rust Podcast

Updates from Rust Community Official Tooling Observations/Thoughts Learn Project Updates Miscellaneous Crate of the Week

This week's crate is polyfuse, a library for writing FUSE file systems using async code.

Thanks to Ivan Kozik 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.

No issues were proposed for CfP.

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

Updates from Rust Core

347 pull requests were merged in the last week

Rust Compiler Performance Triage
  • 2020-07-28. 2 regressions, 1 improvement, none in rollups.
Approved RFCs

Changes to Rust follow the Rust RFC (request for comments) process. These are the RFCs that were approved for implementation this week:

Final Comment Period

Every week the team announces the 'final comment period' for RFCs and key PRs which are reaching a decision. Express your opinions now.

RFCs Tracking Issues & PRs New RFCs Upcoming Events Online North America Asia Pacific

If you are running a Rust event please add it to the calendar to get it mentioned here. Please remember to add a link to the event too. Email the Rust Community Team for access.

Rust Jobs

Tweet us at @ThisWeekInRust to get your job offers listed here!

Quote of the Week

Sadly, we had no quote suggestions this week.

Please submit quotes and vote for next week!

This Week in Rust is edited by: nellshamrell, llogiq, and cdmistman.

Discuss on r/rust

Karl Dubost: A-localized work or distributed work

Monday 27th of July 2020 11:15:00 PM

Jason Fried published Remote work is a platform. After a quick metaphor about the Web and how at the begining of any ecosystem change, he explains how we have a tendency to port what we knew from the old ecosystem into the new ones, before being able to develop its own grammar and language. The case here is work in offices.

In-person office work is a platform. It has its own advantages and disadvantages.

I wrote about the topic in This is not a remote work. While I hear Jason asking for people to create new techniques of working for the specific context of alocalized work (which I agree with), it probably goes deeper than just an « in-person office » versus « remote » work.

The key argument of the post is this one.

They’ll have discovered that remote work means more autonomy, more trust, more uninterrupted stretches of time, smaller teams, more independent, concurrent work (and less dependent, sequenced work).

Yes. Yes. Yes.

I would add a if the type of job allows it. You can not clean the floor of a building being away from it (except being in a SciFi style futuristic view of the future where offices are flawless… and humanless.)

The first steps for thinking about this « new platform » is

  1. probably to stop calling it remote work. The word « remote » makes you think automatically that you are away from the core thing.
  2. when you are the owners/managers of the company to think about this distributed, alocalized way of working as a viable option as much as an in-person office platform.

Otsukare!

Karl Dubost: Formatted console.log lines. Stacktraces export wish.

Monday 27th of July 2020 11:12:00 PM
Firefox Devtools console.log lines

When we select the console.log lines in Firefox devtools, and cut and paste in an editor, there are newline characters added to the output.

For example it looks like this:

pointerdown { target: svg.flickity-button-icon , buttons: 1, clientX: 363, clientY: 450, layerX: 5, layerY: 15 } flickity2.js:1:5293 pointerup { target: svg.flickity-button-icon , buttons: 0, clientX: 363, clientY: 450, layerX: 5, layerY: 15 } flickity2.js:1:5293 mousedown { target: svg.flickity-button-icon , buttons: 0, clientX: 363, clientY: 450, layerX: 5, layerY: 15 } xgemius.js:1030:60 click { target: svg.flickity-button-icon , buttons: 0, clientX: 363, clientY: 450, layerX: 5, layerY: 15 } flickity2.js:1:5293

What I often do is that I put them in vscode where I search

(.*)\n^(.*)\n(.*\d{1,})$

and replace in regex mode with:

* `$1 $2 $3`

to get this, ready to be copied in a comment in github.

* `pointerdown { target: svg.flickity-button-icon , buttons: 1, clientX: 363, clientY: 450, layerX: 5, layerY: 15 } flickity2.js:1:5293` * `pointerup { target: svg.flickity-button-icon , buttons: 0, clientX: 363, clientY: 450, layerX: 5, layerY: 15 } flickity2.js:1:5293` * `mousedown { target: svg.flickity-button-icon , buttons: 0, clientX: 363, clientY: 450, layerX: 5, layerY: 15 } xgemius.js:1030:60` * `click { target: svg.flickity-button-icon , buttons: 0, clientX: 363, clientY: 450, layerX: 5, layerY: 15 } flickity2.js:1:5293` Compare exported stack traces

Silly idea of the day. This is not available right now in devtools, but I wish it was.

  1. Put two breakpoints in devtools.
  2. Run the code as record stacktrace in between these two targets
  3. export the stack trace as a json in a standard format in between these two breakpoints (do the same thing in another browser)
  4. Have a diff tool giving the possibility to explore the differences in between the two stack traces.

Otsukare!

Mozilla Open Policy & Advocacy Blog: Australian watchdog recommends major changes to exceptional access law TOLA

Monday 27th of July 2020 08:22:07 PM

Australia’s Independent National Security Legislation Monitor (INSLM) earlier this month released a 316-page report calling for significant, and much needed, reforms to the nation’s 2018 Telecommunications and Other Legislation Amendment (TOLA) law. The Parliamentary Joint Committee on Intelligence and Security (PJCIS) will meet later this month to consider the INSLM’s recommendations. While we still believe this dangerous law should be repealed, if enacted, these recommendations would go a long way in reducing the risk of this flawed piece of legislation.

This legislation – which Mozilla has continually opposed – allows Australian authorities to force nearly all actors in the digital ecosystem (Designated Communications Providers or DCPs) to do “acts or things” with an explicit goal of weakening security safeguards. For example, under this law, using a Technical Assistance Notice (TAN), Australian authorities could force a company to turn over sensitive security information, or using a Technical Capability Notice (TCN), they could force a company to redesign its software.

In his report, the INSLM offered a wide range of critiques and recommendations to limit the scope of TOLA. Of particular note, the INSLM offered the following key proposals:

  • Judicial review – The INSLM noted that all non-government stakeholders, including Mozilla, raised concerns that expansive new powers granted by TOLA could be used without judicial review or authorization. The most important recommendation in the INSLM’s report is to require TANs and TCNs to be reviewed and approved by the Administrative Appeals Tribunal (AAT). The AAT is a well-respected, quasi-judicial body with the power to conduct classified hearings and adjudications which the INSLM proposes would be led by a new Investigatory Powers Commissioner (IPC). As in the UK, the IPC would be a retired high ranking judge with access to its own independent technical advisors. While implementation of these recommendations will help in limiting the harm of TANs and TCNs, we still do not think Australian authorities should have these powers.
  • Definitions of systemic weakness and target technology – While there is a safeguard in TOLA that orders under this law cannot be used to force the creation of a systemic weakness or vulnerability, these terms are worryingly, vaguely defined: “a systemic vulnerability means a vulnerability that affects a whole class of technology, but does not include a vulnerability that is selectively introduced to one or more target technologies that are connected with a particular person.” The INSLM’s report recommends helpful amendments to the definition of systemic weakness, and recommends the removal of the term “systemic vulnerability” entirely. Furthermore, we’ve previously noted that TOLA is unclear on what constitutes a “class of technology.” Is the Firefox browser a class of technology unto itself? It seems contrary to the spirit of this limitation to allow Australian authorities to compromise the security of the hundreds of millions of Firefox users who have never been under suspicion of any wrongdoing. Crucially, the INSLM clarifies that target technology should refer to “the specific instance used by the intended target,” which would narrow the scope so that targeting is more likely to affect the target alone.
  • Employee protection – Mozilla, among many other DCPs, has been concerned by the risk that the definition of DCP in the law could be read to allow Australian authorities to serve an order on any employee of a DCP. The INSLM recommended that a natural person should only be considered to be a DCP where that natural person is a sole trader. We agree with the INSLM that “it is necessary to put this issue beyond doubt” and urge the PJCIS to amend TOLA to reflect this interpretation.

While the INSLM has suggested a number of positive changes, we were disappointed by his recommendations regarding restrictions on disclosure. As it stands, TOLA limits companies from disclosing the fact that they have been served with these orders. The INSLM’s report suggests that Commonwealth officials be authorized to disclose TAN/TCN info (as well as that of TARs, which are voluntary Technical Assistance Requests) to the public and to government officials when disclosure is in the national or public interest. In our view this is inadequate to address the underlying concern. Companies can’t be transparent with their users nor can there be a robust public debate about the wisdom of certain technical capabilities when companies are still restricted from disclosure. Moreover, such a lack of transparency is at odds with basic open source and security engineering principles.

TOLA also presently lacks crucial restrictions on the ability of foreign authorities to exercise the powers the law grants. The INSLM notes that a large overhaul of the procedural safeguards around mutual legal assistance in criminal matters is likely forthcoming in the International Production Orders (IPO) Bill, which Australia is expected to enact later this year as it pursues acceptance under the U.S. Cloud Act. We continue to advocate for strict limitations on how and when foreign countries can request the assistance of Australian authorities through TOLA.

Mozilla has been involved throughout the legislative process and the development of the INSLM’s report. We filed comments to the PJCIS in late 2018 and early 2019 warning of TOLA’s dangerous effects. Martin Thomson, Mozilla Distinguished Engineer, testified at a hearing held by the INSLM – which ultimately proceeded to quote a portion of Martin’s testimony in his final report. Moreover, our team has provided comments to the Australian Ministry of Communications, Cyber Safety & the Arts relating specifically to the significant security risks posed by TCNs. Our December 2019 cover letter to the INSLM contributing input to his report can be found here. A detailed list of Mozilla’s recommendations alongside related INSLM recommendations can be found here.

The PJCIS will hold a hearing later this month to discuss the recommendations and likely begin the process of discussing amendments to TOLA. This presents the PJCIS with a unique opportunity to demonstrate leadership in defending individuals’ online privacy and security while enabling effective access to justice. The implementation of TOLA continues to pose serious privacy, security, and due process issues for both users and developers, and Mozilla will continue to oppose this law. In the event that the bill is not repealed, we strongly urge the involved MPs and Senators to adopt the INSLM’s recommendations which may help soften the blow of some of the law’s most damaging provisions.

The post Australian watchdog recommends major changes to exceptional access law TOLA appeared first on Open Policy & Advocacy.

More in Tux Machines

Hardware Freedom: 3D Printing, RasPi and RPi CM3 Module

  • Can 3D Printing Really Solve PPE Shortage in COVID-19 Crisis? The Myth, and The Facts!

    Amid COVID-19 crisis, we see severe shortage of Personal Protective Equipment (PPE) worldwide, to the point that a strict organization like FDA is making exceptions for PPE usage, and there are volunteer effors to try to alleviate this shortage like GetUsPPE. Also, Centers for Disease Control and Prevention (CDC) provides an Excel spreadsheet file to help calculate the PPE Burn Rate. There are many blog posts, video tutorials, and guides that teach people how to print their face shields and masks.

  • Raspberry Pi won’t let your watched pot boil
  • Growing fresh veggies with Rpi and Mender

    Some time ago my wife and I decided to teach our kids how to grow plants. We both have experience as we were raised in small towns where it was common to own a piece of land where you could plant home-grown fresh veggies. The upbringing of our kids is very different compared to ours, and we realized we never showed our kids how to grow our own veggies. We wanted them to learn and to understand that “the vegetables do not grow on the shop-shelf”, and that there is work (and fun) involved to grow those. The fact that we are gone for most of the summer and to start our own garden just to see it die when we returned seemed to be pointless. This was a challenge. Luckily, me being a hands-on engineer I promised my wife to take care of it. There were two options: we could buy something that will water our plants when we are gone, or I could do it myself (with a little help from our kids). Obviously I chose the more fun solution…

  • Comfile Launches 15-inch Industrial Raspberry Pi Touch Panel PC Powered by RPi CM3 Module

    Three years ago, we noted Comfile has made 7-inch and 10.2-inch touch panel PC’s powered by Raspberry Pi 3 Compute Module. The company has recently introduced a new model with a very similar design except for a larger 15-inch touchscreen display with 1024×768 resolution. ComfilePi CPi-A150WR 15-inch industrial Raspberry Pi touch panel PC still features the CM3 module, and the same ports including Ethernet, USB ports, RS232, RS485, and I2C interfaces accessible via terminal blocks, and a 40-pin I/O header.

Programming: Vala, Perl and Python

  • Excellent Free Tutorials to Learn Vala

    Vala is an object-oriented programming language with a self-hosting compiler that generates C code and uses the GObject system. Vala combines the high-level build-time performance of scripting languages with the run-time performance of low-level programming languages. Vala is syntactically similar to C# and includes notable features such as anonymous functions, signals, properties, generics, assisted memory management, exception handling, type inference, and foreach statements. Its developers, Jürg Billeter and Raffaele Sandrini, wanted to bring these features to the plain C runtime with little overhead and no special runtime support by targeting the GObject object system. Rather than compiling directly to machine code or assembly language, it compiles to a lower-level intermediate language. It source-to-source compiles to C, which is then compiled with a C compiler for a given platform, such as GCC. Did you always want to write GTK+ or GNOME programs, but hate C with a passion? Learn Vala with these free tutorials! Vala is published under the GNU Lesser General Public License v2.1+.

  • Supporting Perl-related creators via Patreon

    Yesterday I posted about this in the Perl Weekly newsletter and both Mohammad and myself got 10 new supporters. This is awesome. There are not many ways to express the fact that you really value the work of someone. You can send them postcards or thank-you notes, but when was the last time you remembered to do that? Right, I also keep forgetting to thank the people who create all the free and awesome stuff I use. Giving money as a way to express your thanks is frowned upon by many people, but trust me, the people who open an account on Patreon to make it easy to donate them money will appreciate it. In any case it is way better than not saying anything.

  • 2020.31 TwentyTwenty

    JJ Merelo kicked off the special 20-day Advent Blog cycle in honour of the publication of the first RFC that would lay the foundation for the Raku Programming Language as we now know it. After that, 3 blog posts got already published:

  • Supporting The Full Lifecycle Of Machine Learning Projects With Metaflow

    Netflix uses machine learning to power every aspect of their business. To do this effectively they have had to build extensive expertise and tooling to support their engineers. In this episode Savin Goyal discusses the work that he and his team are doing on the open source machine learning operations platform Metaflow. He shares the inspiration for building an opinionated framework for the full lifecycle of machine learning projects, how it is implemented, and how they have designed it to be extensible to allow for easy adoption by users inside and outside of Netflix. This was a great conversation about the challenges of building machine learning projects and the work being done to make it more achievable.

  • Django 3.1 Released

    The Django team is happy to announce the release of Django 3.1.

  • Awesome Python Applications: buku

    buku: Browser-independent bookmark manager with CLI and web server frontends, with integrations for browsers, cloud-based bookmark managers, and emacs.

  • PSF GSoC students blogs: Week 9 Check-in

DRM and Proprietary Software Leftovers

  • Some Photoshop users can try Adobe’s anti-misinformation system later this year

    Adobe pitched the CAI last year as a general anti-misinformation and pro-attribution tool, but many details remained in flux. A newly released white paper makes its scope clearer. The CAI is primarily a more persistent, verifiable type of image metadata. It’s similar to the standard EXIF tags that show the location or date of a photograph, but with cryptographic signatures that let you verify the tags haven’t been changed or falsely applied to a manipulated photo.

    People can still download and edit the image, take a screenshot of it, or interact the way they would any picture. Any CAI metadata tags will show that the image was manipulated, however. Adobe is basically encouraging adding valuable context and viewing any untagged photos with suspicion, rather than trying to literally stop plagiarism or fakery. “There will always be bad actors,” says Adobe community products VP Will Allen. “What we want to do is provide consumers a way to go a layer deeper — to actually see what happened to that asset, who it came from, where it came from, and what happened to it.”

    The white paper makes clear that Adobe will need lots of hardware and software support for the system to work effectively. CAI-enabled cameras (including both basic smartphones and high-end professional cameras) would need to securely add tags for dates, locations, and other details. Photo editing tools would record how an image has been altered — showing that a journalist adjusted the light balance but didn’t erase or add any details. And social networks or other sites would need to display the information and explain why users should care about it.

  •  
  • EFF and ACLU Tell Federal Court that Forensic Software Source Code Must Be Disclosed
           
             

    Can secret software be used to generate key evidence against a criminal defendant? In an amicus filed ten days ago with the United States District Court of the Western District of Pennsylvania, EFF and the ACLU of Pennsylvania explain that secret forensic technology is inconsistent with criminal defendants’ constitutional rights and the public’s right to oversee the criminal trial process. Our amicus in the case of United States v. Ellis also explains why source code, and other aspects of forensic software programs used in a criminal prosecution, must be disclosed in order to ensure that innocent people do not end up behind bars, or worse—on death row.

             

    The Constitution guarantees anyone accused of a crime due process and a fair trial. Embedded in those foundational ideals is the Sixth Amendment right to confront the evidence used against you. As the Supreme Court has recognized, the Confrontation Clause’s central purpose was to ensure that evidence of a crime was reliable by subjecting it to rigorous testing and challenges. This means that defendants must be given enough information to allow them to examine and challenge the accuracy of evidence relied on by the government.

  •                
  • Powershell Bot with Multiple C2 Protocols
                     
                       

    I spotted another interesting Powershell script. It's a bot and is delivered through a VBA macro that spawns an instance of msbuild.exe This Windows tool is often used to compile/execute malicious on the fly (I already wrote a diary about this technique[1]). I don’t have the original document but based on a technique used in the macro, it is part of a Word document. It calls Document_ContentControlOnEnter[2]: [...]

  •      
  • FBI Used Information From An Online Forum Hacking To Track Down One Of The Hackers Behind The Massive Twitter Attack
           
             

    As Mike reported last week, the DOJ rounded up three alleged participants in the massive Twitter hack that saw dozens of verified accounts start tweeting out promises to double the bitcoin holdings of anyone who sent bitcoin to a certain account.

  •                    
  • Twitter Expects to Pay 9-Figure Fine for Violating FTC Agreement
                         
                           

    That means that the complaint is not related to last month’s high-profile [cr]ack of prominent accounts on the service. That security incident saw accounts from the likes of Joe Biden and Elon Musk ask followers to send them bitcoin. A suspect was arrested in the incident last month.

  •                    
  • Twitter Expects to Pay Up to $250 Million in FTC Fine Over Alleged Privacy Violations
                         
                           

    Twitter disclosed that it anticipates being forced to pay an FTC fine of $150 million to $250 million related to alleged violations over the social network’s use of private data for advertising.

                           

    The company revealed the expected scope of the fine in a 10-Q filing with the SEC. Twitter said that on July 28 it received a draft complaint from the Federal Trade Commission alleging the company violated a 2011 consent order, which required Twitter to establish an information-security program designed to “protect non-public consumer information.”

                           

    “The allegations relate to the Company’s use of phone number and/or email address data provided for safety and security purposes for targeted advertising during periods between 2013 and 2019,” Twitter said in the filing.

  •                
  • Apple removes more than 26,000 games from China app store
                     
                       

    Apple pulled 29,800 apps from its China app store on Saturday, including more than 26,000 games, according to Qimai Research Institute.

                       

    The removals are in response to Beijing's crackdown on unlicensed games, which started in June and intensified in July, Bloomberg reported. This brings an end to the unofficial practice of letting games be published while awaiting approval from Chinese censors.

  •                
  • Intuit Agrees to Buy Singapore Inventory Software Maker
                     
                       

    Intuit will pay more than $80 million for TradeGecko, according to people familiar with the matter, marking one of the biggest exits in Singapore since the Covid-19 pandemic. TradeGecko has raised more than $20 million to date from investors including Wavemaker Partners, Openspace Ventures and Jungle Ventures.

  •                      
  • Justice Department Is Scrutinizing Takeover of Credit Karma by Intuit, Maker of TurboTax
           
             

    The probe comes after ProPublica first reported in February that antitrust experts viewed the deal as concerning because it could allow a dominant firm to eliminate a competitor with an innovative business model. Intuit already dominates online tax preparation, with a 67% market share last year. The article sparked letters from Sen. Ron Wyden, D-Ore., and Rep. David Cicilline, D-R.I., urging the DOJ to investigate further. Cicilline is chair of the House Judiciary Committee’s antitrust subcommittee.

Security Leftovers

           
  • DNS configuration recommendations for IPFire users

    If you are familiar with IPFire, you might have noticed DNSSEC validation is mandatory, since it defeats entire classes of attacks. We receive questions like "where is the switch to turn off DNSSEC" on a regular basis, and to say it once and for all: There is none, and there will never be one. If you are running IPFire, you will be validating DNSSEC. Period. Another question frequently asked is why IPFire does not support filtering DNS replies for certain FQDNs, commonly referred to as a Response Policy Zone (RPZ). This is because an RPZ does what DNSSEC attempts to secure users against: Tamper with DNS responses. From the perspective of a DNSSEC-validating system, a RPZ will just look like an attacker (if the queried FQDN is DNSSEC-signed, which is what we strive for as much of them as possible), thus creating a considerable amount of background noise. Obviously, this makes detecting ongoing attacks very hard, most times even impossible - the haystack to search just becomes too big. Further, it does not cover direct connections to hardcoded IP addresses, which is what some devices and attackers usually do, as it does not rely on DNS to be operational and does not leave any traces. Using an RPZ will not make your network more secure, it just attempts to cover up the fact that certain devices within it cannot be trusted. Back to DNSSEC: In case the queried FQDNs are signed, forged DNS replies are detected since they do not match the RRSIG records retrieved for that domain. Instead of being transparently redirected to a fradulent web server, the client will only display a error message to its user, indicating a DNS lookup failure. Large-scale attacks by returning forged DNS replies are frequently observed in the wild (the DNSChanger trojan is a well-known example), which is why you want to benefit from validating DNSSEC and more and more domains being signed with it.

  • Security updates for Tuesday

    Security updates have been issued by Debian (libx11, webkit2gtk, and zabbix), Fedora (webkit2gtk3), openSUSE (claws-mail, ghostscript, and targetcli-fb), Red Hat (dbus, kpatch-patch, postgresql-jdbc, and python-pillow), Scientific Linux (libvncserver and postgresql-jdbc), SUSE (kernel and python-rtslib-fb), and Ubuntu (ghostscript, sqlite3, squid3, and webkit2gtk). 

  •        
  • Official 1Password Linux App is Available for Testing

    An official 1Password Linux app is on the way, and brave testers are invited to try an early development preview. 1Password is a user-friendly (and rather popular) cross-platform password manager. It provides mobile apps and browser extensions for Windows, macOS, Android, iOS, Google Chrome, Edge, Firefox — and now a dedicated desktop app for Linux, too.

  •        
  • FBI Warns of Increased DDoS Attacks

    The Federal Bureau of Investigation warned in a “private industry notification” last week that attackers are increasingly using amplification techniques in distributed denial-of-service attacks. There has been an uptick in attack attempts since February, the agency’s Cyber Division said in the alert. An amplification attack occurs when attackers send a small number of requests to a server and the server responds with numerous responses. The attackers spoof the IP address to make it look like the requests are coming from a specific victim, and the resulting responses overwhelms the victim’s network. “Cyber actors have exploited built-in network protocols, designed to reduce computation overhead of day-to-day system and operational functions to conduct larger and more destructive distributed denial-of-service amplification attacks against US networks,” the FBI alert said. Copies of the alert were posted online by several recipients, including threat intelligence company Bad Packets.

  • NSA issues BootHole mitigation guidance

    Following the disclosure of a widespread buffer-flow vulnerability that could affect potentially billions of Linux and Windows-based devices, the National Security Agency issued a follow-up cybersecurity advisory highlighting the bug and offering steps for mitigation. The vulnerability -- dubbed BootHole -- impacts devices and operating systems that use signed versions of the open-source GRUB2 bootloader software found in most Linux systems. It also affects any system or device using Secure Boot -- a root firmware interface responsible for validating the booting process -- with Microsoft's standard third party certificate authority. The vulnerability enables attackers to bypass Secure Boot to allow arbitrary code execution and “could be used to install persistent and stealthy bootkits,” NSA said in a press statement.