Mozilla Firefox

Today I’d like to talk about passwords. Yes, I know, passwords are the worst, but why? This is the first of a series of posts about passwords, with this one focusing on the origins of our current password systems starting with log in for multi-user ... [More] systems. The conventional story for what’s wrong with passwords goes something like this: Passwords are simultaneously too long for users to memorize and too short to be secure. It’s easy to see how to get to this conclusion. If we restrict ourselves to just letters and numbers, then there are about 26 one character passwords, 212 two character passwords, etc. The fastest password cracking systems can check about 236 passwords/second, so if you want a password which takes a year to crack, you need a password of 10 characters long or longer. The situation is actually far worse than this; most people don’t use randomly generated passwords because they are hard to generate and hard to remember. Instead they tend to use words, sometimes adding a number, punctuation, or capitalization here and there. The result is passwords that are easy to crack, hence the need for password managers and the like. This analysis isn’t wrong, precisely; but if you’ve ever watched a movie where someone tries to break into a computer by typing passwords over and over, you’re probably thinking “nobody is a fast enough typist to try billions of passwords a second”. This is obviously true, so where does password cracking come into it? How to design a password system The design of password systems dates back to the UNIX operating system, designed back in the 1970s. This is before personal computers and so most computers were shared, with multiple people having accounts and the operating system being responsible for protecting one user’s data from another. Passwords were used to prevent someone else from logging into your account. The obvious way to implement a password system is just to store all the passwords on the disk and then when someone types in their password, you just compare what they typed in to what was stored. This has the obvious problem that if the password file is compromised, then every password in the system is also compromised. This means that any operating system vulnerability that allows a user to read the password file can be used to log in as other users. To make matters worse, multiuser systems like UNIX would usually have administrator accounts that had special privileges (the UNIX account is called “root”). Thus, if a user could compromise the password file they could gain root access (this is known as a “privilege escalation” attack). The UNIX designers realized that a better approach is to use what’s now called password hashing: instead of storing the password itself you store what’s called a one-way function of the password. A one-way function is just a function H that’s easy to compute in one direction but not the other.1 This is conventionally done with what’s called a hash function, and so the technique is known as “password hashing” and the stored values as “password hashes” In this case, what that means is you store the pair: (Username, H(Password)). [Technical note: I’m omitting salt which is used to mitigate offline pre-computation attacks against the password file.] When the user tries to log in, you take the password they enter P and compute H(P). If H(P) is the same as the stored password, then you know their password is right (with overwhelming probability) and you allow them to log in, otherwise you return an error. The cool thing about this design is that even if the password file is leaked, the attacker learns only the password hashes.2 Problems and countermeasures This design is a huge improvement over just having a file with cleartext passwords and it might seem at this point like you didn’t need to stop people from reading the password file at all. In fact, on the original UNIX systems where this design was used, the /etc/passwd file was publicly readable. However, upon further reflection, it has the drawback that it’s cheap to verify a guess for a given password: just compute H(guess) and compare it to what’s been stored. This wouldn’t be much of an issue if people used strong passwords, but because people generally choose bad passwords, it is possible to write password cracking programs which would try out candidate passwords (typically starting with a list of common passwords and then trying variants) to see if any of these matched. Programs to do this task quickly emerged. The key thing to realize is that the computation of H(guess) can be done offline. Once you have a copy of the password file, you can compare your pre-computed hashes of candidate passwords against the password file without interacting with the system at all. By contrast, in an online attack you have to interact with the system for each guess, which gives it an opportunity to rate limit you in various ways (for instance by taking a long time to return an answer or by locking out the account after some number of failures). In an offline attack, this kind of countermeasure is ineffective. There are three obvious defenses to this kind of attack: Make the password file unreadable: If the attacker can’t read the password, they can’t attack it. It took a while to do this on UNIX systems, because the password file also held a lot of other user-type information that you didn’t want kept secret, but eventually that got split out into another file in what’s called “shadow passwords” (the passwords themselves are stored in /etc/shadow. Of course, this is just the natural design for Web-type applications where people log into a server. Make the password hash slower: The cost of cracking is linear in the cost of checking a single password, so if you make the password hash slower, then you make cracking slower. Of course, you also make logging in slower, but as long as you keep that time reasonably short (below a second or so) then users don’t notice. The tricky part here is that attackers can build specialized hardware that is much faster than the commodity hardware running on your machine, and designing hashes which are thought to be slow even on specialized hardware is a whole subfield of cryptography. Get people to choose better passwords: In theory this sounds good, but in practice it’s resulted in enormous numbers of conflicting rules about password construction. When you create an account and are told you need to have a password between 8 and 12 characters with one lowercase letter, one capital letter, a number and one special character from this set — but not from this other set — what they’re hoping you will do is create a strong passwords. Experience suggests you are pretty likely to use Passw0rd!, so the situation here has not improved that much unless people use password managers which generate passwords for them. The modern setting At this point you’re probably wondering what this has to do with you: almost nobody uses multiuser timesharing systems any more (although a huge fraction of the devices people use are effectively UNIX: MacOS is a straight-up descendent of UNIX and Linux and Android are UNIX clones). The multiuser systems that people do use are mostly Web sites, which of course use usernames and passwords. In future posts I will cover password security for Web sites and personal devices. Strictly speaking we need the function not just to be one-way but also to be preimage resistant, meaning that given H(P) it’s hard to find any input p such that H(p) == H(P). ↩ For more information on this, see Morris and Thompson for quite readable history of the UNIX design. One very interesting feature is that at the time this system was designed generic hash functions didn’t exist, and so they instead used a variant of DES. The password was converted into a DES key and then used to encrypt a fixed value. This is actually a pretty good design and even included a feature designed to prevent attacks using custom DES hardware. However, it had the unfortunate property that passwords were limited to 8 characters, necessitating new algorithms that would accept a longer password. ↩ The post A look at password security, Part I: history and background appeared first on The Mozilla Blog. [Less]

Highlights We’ve added a new section to about:preferences to opt-in to experimental features! Go to about:preferences, and look for “Experiments” on the left-hand side. Feeling experimental? Check these options out! Firefox Lockwise ... [More] (about:logins) now supports Login Export to a .csv file Your data is yours – so take your passwords and do what you will with them. There’s a new WebRTC global sharing indicator enabled on Nightly! This indicator can be dragged anywhere on screen and minimized, and works on all desktop platforms. Noticed any issues? File bugs against this metabug for us to triage. We need more Nightly users to help us test Fission! Original announcement requesting testers on dev-platform The team will soon add Fission to the about:preferences Experiments section, but in the meantime, you can opt-in to trying it by going to about:config and setting fission.autostart to true, and restarting The DevTools team has merged the Messages side panel into the Response side panel (bug) in the Network tool. So, WebSocket frames are now displayed in the Response panel Friends of the Firefox team Resolved bugs (excluding employees) Fixed more than one bug ariasuni Farooq AR Itiel kenrick95 Kriyszig Kyle Knaggs manas Mark Smith [:mcs] petcuandrei Richard Sherman :rich :richorrichard Sebastian Zartner [:sebo] Sonia Stepan Stava [:stepan] New contributors (🌟 = first patch) 🌟 a.park0324 got rid of a leftover console.log statement in our search service code Alex J Garcia fixed a bug in how panel widths are persisted and restored in the debugger Arash Fotouhi made it so that about:telemetry shows labels for categorical keyed histograms Harsh made it so that WebExtensions can observer and modify network requests made when using the downloads API Riley Byrd, one of our MSU capstone students, ported the migration wizard code to Fluent 🌟 Deepika Karanji improved an error message when using the tabs.query WebExtension API 🌟 Richard Sherman :rich :richorrichard Added some helpful tooltips to the debugger Improved some of the language in the debugger Jerome Fray greatly improved the dark mode support for the Library window Krystle Salazar added a new icon when viewing pages that have no identity information associated with them Kyle Knaggs Moved the icon in the debugger “paused” indicator from the right to the left side Cleaned up some of the debugger paused indicator code Marinella made the code that updates the Protections panel more efficient 🌟 Surya Balakrishnan [:surya_b] made more of our DevTools UI respect the “prefers reduced motion” user preference Project Updates Add-ons / Web Extensions WebExtensions Framework As part of the Fission-related changes to the WebExtensions internals, the extension messaging APIs have been completely ported to the new Fission-aware WebExtension internals (Bug 1583484, and follow up fixes Bug 1643214, Bug 1642967, Bug 1643896) New rkv-based ExtensionPermissions backend (Bug 1637680, Bug 1646181). Thanks Agi! New rust-based storage.sync implementation enabled by default in Firefox 79 (Bug 1634615, Bug 1629127, Bug 1645598) WebExtension APIs Fixed regressions: Mak fixed a regression in the downloads API that would make valid downloads to fail (Bug 1637973, originally regressed by Bug 1598216) Rob fixed a regression related to webRequest API listeners ability to modify CSP headers on the requests intercepted (Bug 1635781, regressed by Bug 1462989) Contributions: Starting from Firefox 79, a new browser.tabs.warmup API method is available to the WebExtensions (Bug 1402256). The WebExtensions will be able to use this method to improve user perceived performance on switching between tabs). Thanks to ariasuni for contributing this enhancement! In Firefox 79, browser.tabs.duplicate API method does now ensure that duplicated tabs are created as active, as in Chrome (Bug 1376088). Thanks ariasuni dpk contributed a patch to improve error messages when invalid patterns are used in browser.tabs.query (Bug 1637431) Sonia Singla contributed a patch to not show the WebExtensions contextMenu related to bookmarks on entries without a bookmarkGuid (Bug 1638360) Myeongjun Go contributed a patch to allow localhost’s http urls as search providers defined in a WebExtensions manifest Harsh contributed a patch to allow extensions to observe and modify requests created using the browser.downloads.download API (Bug 1579911) Addon Manager & about:addons Removed built-in certificate requirement for addon updates and installs when signed extensions are required (Bug 1308251) other issues and/or regressions fixed in AOM and about:addons: error logged when non-extension add-ons or the browser are being updated (Bug 1643854, regressed by Bug 1618500) addon install cancellation ignored when the addon has been already downloaded (Bug 1559683) addon details page not loaded as expected when clicking the add-on title in the about:addons list view (Bug 1645286) missing select dropdown in extensions options_ui page when embedded into a about:addons page (Bug 1647727) Developer Tools Remote Debugging Added forward, back, and refresh buttons to remote debugging experience (bug) Console Panel – 4XX and 5XX requests are now displayed as error in the console, and don’t need the Request/XHR filter to be enabled (bug) Accessibility – Several improvements for a11y contributed by MarcoZ. More parts of the DevTools UI is now accessible to screen readers (bug, bug, bug, bug) Console Panel – Blocked requests have a distinct style in the console (bug) Debugger Panel – Debugger shows also sources cleaned up by GC (bug) Network Panel – slow requests are marked with a turtle icon. Slow = Waiting for the response from the server is > 500 ms (bug). Default value stored in devtools.netmonitor.audits.slow Network Panel – support for Server Side Events (SSE) coming in 80. Visualization for text/event-stream content types (bug, test page). Hidden behind a pref: devtools.netmonitor.features.sse Fission about:certificate now uses the JSWindowActor powered RemotePageManager Follow the teams progress by checking out Are We Fission Yet? Password Manager Create a backup of logins.json upon writing to it. Other consumers of JSONFile.jsm can opt-in to backups with the `backupTo` option. Add event telemetry for when logins.json.corrupt is created Stop migrating logins from SQLite to JSON via LoginImport.jsm Landing this week CSV Login Import Automatically restoring from logins.json backups PDFs & Printing Added a context menu item in the Downloads Panel to “Open in system viewer” and “Always open in system viewer” Performance emalysz and Gijs have converted a number of panels to be lazily loaded emalysz landed a patch to make it so that the new DLL preloading behaviour can be controlled with a preference, which we’re going to use to power an experiment in July. This experiment should allow us to estimate the impact of improving startup performance on user retention. dthayer has finished a patch that will allow more things to be read from the startupcache which should improve startup – should land shortly now that the soft-freeze is over mconley landed automated tests for the about:home startup cache, and also landed some improvements to how it invalidates. bigiri has a working version of porting the ASRouter module to JSWindowActors, which is needed for the about:home startup cache. Now working on migrating tests. dthayer fixed the last blocker preventing us from moving Nightly to Fast Shutdown stage 3, which should happen shortly now that the soft freeze is over dthayer advanced Beta and Release to Fast Shutdown stage 1, which should improve shutdown on those channels starting in Firefox 79. Performance Tools More detailed IPC marker tooltips, showing latency, so that we can differentiate between IPC overhead and event loop delays. Disabled animations if ui.prefersReducedMotion is set in about:config. Added profiler markers for Telemetry Stopwatch Example startup profile: https://share.firefox.dev/3dnKw2B Replaced Services.profiler.AddMarker with ChromeUtils.addProfilerMarker. Remote Protocol (Chrome DevTools Protocol subset) When navigating to web pages with iframes included, all relevant page navigation events are sent out for each and every frame now. To get this finished various other small fixes were necessary too. The formerly added preference remote.frames.enabled is no longer necessary because frame handling is enabled by default now. For the next while, the team will be focused on making Marionette Fission compatible. In the meantime, we’ll be gathering feedback from Puppeteer users and anyone else experimenting with Remote Protocol before we resume our work in that area. Search and Navigation Search: Some reliability fixes for modern configuration. Post-modern cleanup is now underway and is currently reworking how the search engine cache and initialization routines are handled. Region detection We’re now experimenting with doing regular checks for your region and updating it if you’ve changed location for more than a couple of weeks (before Region used to be static all the time, unless we explicitly reset it) – Bug 1627555 Better support to customize params depending on the region – Bug 1634580 Experiment will run in Beta to check reliability Address Bar: Address bar expansion on focus now obeys prefers-reduced-motion – Bug 1629303 On Windows it’s now possible to close the results panel by clicking on the toolbox draggable space – Bug 1628948 Fixed a regression where search suggestions were not provided anymore when restricting to search (with “?” or an alias) – Bug 1648385 Search suggestions will now be shown for a broader range of search strings (But not when the typed string looks like a url) – Bug 1628079 Search history is enabled by default in Firefox 78 and obeys the same preference as normal search suggestions – Bug 1643475 Fixed a bug where certain domains (like “pserver”) may be transformed into others when typed and confirmed without a protocol – Bug 1646928 A new browser.urlbar.dnsResolveSingleWordsAfterSearch preference allows to disable post-facto DNS resolution of single word searches that may be valid intranet names – Bug 1642943 Restriction tokens at the end of the search string are considered only if they are preceded by a space (Searching for “c++” now works correctly) – Bug 1636961 Tail search suggestions are enabled in EARLY_BETA_OR_EARLIER; release enabling is pending a Firefox 78 experiment – Bug 1645059 (demo: search for “hobbit holes for sale in i”) WebRTC UI The new sharing indicator works on every desktop platform and can be minimized and moved anywhere on the screen. Starting work on a feature to show a highlight around shared browser windows or screens, to make it easier to know what’s been shared. [Less]

When an add-on is submitted to Firefox for validation, the add-ons linter checks its code and displays relevant errors, warnings, or friendly messages for the developer to review. JavaScript is constantly evolving, and when the linter lags behind the ... [More] language, developers may see syntax errors for code that is generally considered acceptable. These errors block developers from getting their add-on signed or listed on addons.mozilla.org. On July 2, the linter was updated from ESLint 5.16 to ESLint 7.3 for JavaScript validation. This upgrades linter support to most ECMAScript 2020 syntax, including features like optional chaining, BigInt, and dynamic imports. As a quick note, the linter is still slightly behind what Firefox allows. We will post again in this blog the next time we make an update. Want to help us keep the linter up-to-date? We welcome code contributions and encourage developers to report bugs found in our validation process. The post Additional JavaScript syntax support in add-on developer tools appeared first on Mozilla Add-ons Blog. [Less]

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 ... [More] 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 News & Blog Posts Announcing Rustup 1.22.0 Ownership of the standard library implementation Compiler Team 2020-2021 Roadmap Meeting Minutes Back to old tricks ..(or, baby steps in Rust) Small strings in Rust Choosing a Rust web framework, 2020 edition Writing Interpreters in Rust: a Guide Transpiling A Kernel Module to Rust: The Good, the Bad and the Ugly Bad Apple!! and how I wrote a Rust video player for Task Manager!! Boa release v0.9 and make use of Rust's measureme RiB (Rust in Blockchain) Newsletter #13 7 Things I learned from Porting a C Crypto Library to Rust This Month in Rust GameDev #11 (June 2020) AWS Lambda with Rust Writing a winning 4K intro in Rust Ringbahn II: the central state machine Bastion floating on Tide - Part 2 Porting Godot Games To Rust (Part 1) Image decay as a service IntelliJ Rust Changelog #125 Abstracting away correctness Rendering in Rust Super hero Rust fuzzing What Is a Dangling Pointer? Simple Rocket Web Framework Tutorial | POST Request Adventures of OS - System Calls Allocation API, Allocators and Virtual Memory Cargo [features] explained with examples Concurrency Patterns in Embedded Rust Getting started with WebAssembly and Rust How to Write a Stack in Rust Implementing WebSockets in Rust rust-analyzer changelog 32 Rust for JavaScript Developers - Functions and Control Flow Rust: The New LLVM Using Rust and WebAssembly to Process Pixels from a Video Feed WebAssembly with Rust and React (Using create-react-app) [Portuguese] Aprendendo Rust: 01 - Hello World [audio] Mun [audio] Rust and machine learning #3 with Alec Mocatta (Ep. 109) [video] Authentication Service in Actix - Part 1: Configuration [video] Rust FLTK gui tutorial Crate of the Week This week's crate is suckit, a tool to recursively download a website. Thanks to Martin Schmidt 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 308 pull requests were merged in the last week add format_args_capture feature don't implement Fn* traits for #[target_feature] functions fix wasm32 being broken due to a NodeJS version bump handle macro_rules! tokens consistently across crates implement slice_strip feature make likely and unlikely const, gated by feature const_unlikely optimise fast path of checked_ops with unlikely provide more information on duplicate lang item error. remove TypeckTables::empty(None) and make hir_owner non-optional. remove unnecessary release from Arc::try_unwrap serialize all foreign SourceFiles into proc-macro crate metadata stabilize #[track_caller]. use WASM's saturating casts if they are available use Spans to identify unreachable subpatterns in or-patterns Update the rust-lang/llvm-project submodule to include AVR fixes recently merged mir-opt: Fix mis-optimization and other issues with the SimplifyArmIdentity pass added .collect() into String from Box impl From for String linker: create GNU_EH_FRAME header by default when producing ELFs resolve: disallow labelled breaks/continues through closures/async blocks ship rust analyzer chalk: add type outlives goal chalk: allow printing lifetime placeholders chalk: support for ADTs hashbrown: add RawTable::erase and remove hashbrown: expose RawTable::try_with_capacity hashbrown: improve RawIter re-usability libc: add a bunch of constants and functions which were missing on Android libc: add more WASI libc definitions. libc: declare seekdir and telldir for WASI. stdarch: fix or equals integer comparisons cargo: write GNU tar files, supporting long names. crates.io: use default branch alias instead of "master" clippy: added restriction lint: pattern-type-mismatch clippy: suggest Option::map_or(_else) for if let Some { y } else { x } rustfmt: do not duplicate const keyword on parameters rustfmt: do not remove fn headers (e.g., async) on extern fn items rustfmt: pick up comments between trait where clause and open block Rust Compiler Performance Triage 2020-07-07. One unimportant regression on a rollup; six improvements, two on 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: No RFCs were approved 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 RFC: Add a new #[instruction_set(...)] attribute for supporting per-function instruction set changes Inline const expressions and patterns Inline assembly Tracking Issues & PRs [disposition: merge] stabilize const mem::forget [disposition: merge] Stabilize casts and coercions to &[T] in const fn [disposition: merge] mv std libs to std/ [disposition: merge] Stabilize transmute in constants and statics but not const fn [disposition: merge] Stabilize const_type_id feature [disposition: merge] Accept tuple.0.0 as tuple indexing (take 2) New RFCs RFC: IndexGet and IndexSet Upcoming Events Online July 9. Berlin, DE - Rust Hack and Learn July 9. San Diego, CA, US - July 2020 Tele-Meetup July 13. Seattle, WA, US - Seattle Rust Meetup - Monthly Meetup July 16. Turin, IT - Rust Italia - Gruppo di studio di Rust North America July 8. Atlanta, GA, US - Rust Atlanta - Grab a beer with fellow Rustaceans July 9. Lehi, UT, US - Utah Rust - The Blue Pill: Rust on Microcontrollers July 15. Vancouver, BC, CA - Vancouver Rust - Rust Study/Hack/Hang-out night 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 Rust Developer at 1Password, Remote (US or Canada) Security Engineer at 1Password, Remote (US or Canada) Part-time Backend Engineer at Tagnifi, Remote (North America) Tweet us at @ThisWeekInRust to get your job offers listed here! Quote of the Week Rust is like a futuristic laser gun with an almost AI-like foot detector that turns the safety on when it recognises your foot. – u/goofbe on reddit Thanks to Synek317 for the suggestions! Please submit quotes and vote for next week! This Week in Rust is edited by: nellshamrell, llogiq, and cdmistman. Discuss on r/rust [Less]

The rustup working group is happy to announce the release of rustup version 1.22.1. Rustup is the recommended tool to install Rust, a programming language that is empowering everyone to build reliable and efficient software. If you have a previous ... [More] version of rustup installed, getting rustup 1.22.1 may be as easy as closing your IDE and running: rustup self update Rustup will also automatically update itself at the end of a normal toolchain update: rustup update If you don't have it already, or if the 1.22.0 release of rustup caused you to experience the problem that 1.22.1 fixes, you can get rustup from the appropriate page on our website. What's new in rustup 1.22.1 When updating dependency crates for 1.22.0, a change in behaviour of the url crate slipped in which caused env_proxy to cease to work with proxy data set in the environment. This is unfortunate since those of you who use rustup behind a proxy and have updated to 1.22.0 will now find that rustup may not work properly for you. If you are affected by this, simply re-download the installer and run it. It will update your existing installation of Rust with no need to uninstall first. Thanks Thanks to Ivan Nejgebauer who spotted the issue, provided the fix, and made rustup 1.22.1 possible, and to Ben Chen who provided a fix for our website. [Less]

Firefox for Android Nightly (formerly known as Firefox Preview) is a sneak peek of the new Firefox for Android experience. The browser is being rebuilt based on GeckoView, an embeddable component for Android, and we are continuing to gradually roll ... [More] out extension support. Including the add-ons from our last announcement, there are currently nine Recommended Extensions available to users. The latest three additions are in Firefox for Android Nightly and will be available on Firefox for Android Beta soon: Decentraleyes prevents your mobile device from making requests to content delivery networks (i.e. advertisers), and instead provides local copies of common libraries. In addition to the benefit of increased privacy, Decentraleyes also reduces bandwidth usage—a huge benefit in the mobile space. Privacy Possum has a unique approach to dealing with trackers. Instead of playing along with the cat and mouse game of removing trackers, it falsifies the information trackers used to create a profile of you, in addition to other anti-tracking techniques. Youtube High Definition gives you more control over how videos are displayed on Youtube. You have the opportunity to set your preferred visual quality option and have it shine on your high-DPI device, or use a lower quality to save bandwidth.If you have more questions on extensions in Firefox for Android Nightly, please check out our FAQ. We will be posting further updates about our future plans on this blog. The post New Extensions in Firefox for Android Nightly (Previously Firefox Preview) appeared first on Mozilla Add-ons Blog. [Less]

In this article, we’ll walk through the design and implementation of the prefers-contrast media query in Firefox. We’ll start by defining high contrast mode, then we’ll cover the importance of prefers-contrast. Finally, we’ll walk through the media ... [More] query implementation in Firefox. By the end, you’ll have a greater understanding of how media queries work in Firefox, and why the prefers-contrast query is important and exciting. When we talk about the contrast of a page we’re assessing how the web author’s color choices impact readability. For visitors with low vision web pages with low or insufficient contrast can be hard to use. The lack of distinction between text and its background can cause them to “bleed” together. The What of prefers-contrast Though the WCAG (Web Content Accessibility Guidelines) set standards for contrast that authors should abide by, not all sites do. To keep the web accessible, many browsers and OSes offer high-contrast settings to change how web pages and content looks. When these settings are enabled we say that a website visitor has high contrast mode enabled. High contrast mode increases the contrast of the screen so that users with low vision have an easier time getting around. Depending on what operating system is being used, high contrast mode can make a wide variety of changes. It can reduce the visual complexity of the screen, force high contrast colors between text and backgrounds, apply filters to the screen, and more. Doing this all automatically and in a way that works for every application and website is hard. For example, how should high contrast mode handle images? Photos taken in high or low light may lack contrast, and their subjects may be hard to distinguish. What about text that is set on top of images? If the image isn’t a single color, some parts may have high contrast, but others may not. At the moment, Firefox deals with text on images by drawing a backplate on the text. All this is great, but it’s still not quite ideal. Ideally, webpages could detect when high contrast mode is enabled and then make themselves more accessible. To do that we need to know how different operating systems implement high contrast mode. OS-level high-contrast settings Most operating systems offer high-contrast settings. On macOS, users can indicate that they’d prefer high contrast in System Preferences → Accessibility → Display. To honor this preference, macOS applies a high contrast filter to the screen. However, it won’t do anything to inform applications that high contrast is enabled or adjust the layout of the screen. This makes it hard for apps running on macOS to adjust themselves for high-contrast mode users. Furthermore, it means that users are completely dependent on the operating system to make the right modifications. Windows takes a very different approach. When high contrast mode is enabled, Windows exposes this information to applications. Rather than apply a filter to the screen, it forces applications to use certain high contrast (or user-defined) colors. Unlike macOS, Windows also tells applications when high-contrast settings are enabled. In this way, applications can adjust themselves to be more high-contrast friendly. Similarly, Firefox lets users customize high contrast colors or apply different colors to web content. This option can be enabled via the colors option under “Language and Appearance” in Firefox’s “Preferences” settings on all operating systems. When we talk about colors set by the user instead of by the page or application, we describe them as forced. Forced colors in Firefox As we can see, different operating systems handle high-contrast settings in different ways. This impacts how prefers-contrast works on these platforms. On Windows, because Firefox is told when a high-contrast theme is in use, prefers-contrast can detect both high contrast from Windows and forced colors from within Firefox. On macOS, because Firefox isn’t told when a high-contrast theme is in use, prefers-contrast can only detect when colors are being forced from within the browser. Want to see what something with forced colors looks like? Here is the Google homepage on Firefox with the default Windows high-contrast theme enabled: Notice how Firefox overrides the background colors (forced) to black and overrides outlines to yellow. Some things are left to be desired by this forced colors approach. On the Google homepage above, you’ll notice that the profile image no longer appears next to the sign-in button. Here’s the Amazon homepage, also in Firefox, with the same Windows high-contrast theme enabled: The images under “Ride electric” and “Current customer favorites” have disappeared, and the text in the “Father’s Day deals” section has not increased in contrast. The Why of prefers-contrast We can’t fault Google and Amazon for the missing images and other issues in the appearance of these high-contrast homepages. Without the prefers-contrast media query, there is no standardized way to detect a visitor’s contrast preferences. Even if Google and Amazon wanted to change their webpages to make them more accessible for different contrast preferences, they couldn’t. They have no way of knowing when a user has high-contrast mode enabled, even though the browser can tell. That’s why prefers-contrast is so important. The prefers-contrast media query allows website authors to determine a visitor’s contrast preferences and update the website accordingly. Using prefers-contrast, a website author can differentiate between low and high contrast and detect when colors are being forced like this: @media (prefers-contrast: forced) { /* some awesome, accessible, high contrast css */ } This is great because well-informed website designers are much better at making their webpages accessible than automatic high contrast settings. The How of prefers-contrast This section covers how something like prefers-contrast actually gets implemented in Firefox. It’s an interesting dive into the internals of a browser, but if you’re just interested in the what and why of perfers-contrast then you’re welcome to move on to the conclusion. Parsing We’ll start our media query implementation journey with parsing. Parsing handles turning CSS and HTML into an internal representation that the browser understands. Firefox uses a browser engine called Servo to handle this. Luckily for us, Servo makes things pretty straightforward. To hook up parsing for our media query, we’ll head over to media_features.rs in the Servo codebase and we’ll add an enum to represent our media query. /// Possible values for prefers-contrast media query. /// https://drafts.csswg.org/mediaqueries-5/#prefers-contrast #[derive(Clone, Copy, Debug, FromPrimitive, PartialEq, Parse, ToCss)] #[repr(u8)] #[allow(missing_docs)] enum PrefersContrast { High, Low, NoPreference, Forced, } Because we use #[derive(Parse)], Stylo will take care of generating the parsing code for us using the name of our enum and its options. It is seriously that easy. :-) Evaluating the media query Now that we’ve got our parsing logic hooked up, we’ll add some logic for evaluating our media query. If prefers-contrast only exposed low, no-preference, and high, then this would be as simple as creating some function that returns an instance of our enum above. That said, the addition of a forced option adds some interesting gotchas to our media query. It’s not possible to simultaneously prefer low and high-contrast. However, it’s quite common for website visitors to prefer high contrast and have forced colors. Like we discussed earlier if a visitor is on Windows enabling high contrast also forces colors on webpages. Because enums can only be in one of their states at a time (i.e., the prefers-contrast enum can’t be high-contrast and fixed simultaneously) we’ll need to make some modifications to a single function design. To properly represent prefers-contrast, we’ll split our logic in half. The first half will determine if colors are being forced and the second will determine the website visitor’s contrast preference. We can represent the presence or absence of forced colors with a boolean, but we’ll need a new enum for contrast preference. Let’s go ahead and add that to media_features.rs: /// Represents the parts of prefers-contrast that explicitly deal with /// contrast. Used in combination with information about rather or not /// forced colors are active this allows for evaluation of the /// prefers-contrast media query. #[derive(Clone, Copy, Debug, FromPrimitive, PartialEq)] #[repr(u8)] pub enum ContrastPref { /// High contrast is preferred. Corresponds to an accessibility theme /// being enabled or firefox forcing high contrast colors. High, /// Low contrast is prefered. Corresponds to the /// browser.display.prefers_low_contrast pref being true. Low, /// The default value if neither high nor low contrast is enabled. NoPreference, } Voila! We have parsing and enums to represent the possible states of the prefers-contrast media query and a website visitor’s contrast preference done. Adding functions in C++ and Rust Now we add some logic to make prefers-contrast tick. We’ll do that in two steps. First, we’ll add a C++ function to determine contrast preferences, and then we’ll add a Rust function to call it and evaluate the media query. Our C++ function will live in Gecko, Firefox’s layout engine. Information about high contrast settings is also collected in Gecko. This is quite handy for us. We’d like our C++ function to return our ContrastPref enum from earlier. Let’s start by generating bindings from Rust to C++ for that. Starting in ServoBindings.toml we’ll add a mapping from our Stylo type to a Gecko type: cbindgen-types = [ # ... { gecko = "StyleContrastPref", servo = "gecko::media_features::ContrastPref" }, # ... ] Then, we’ll add a similar thing to Servo’s cbindgen.toml: include = [ # ... "ContrastPref", # ... ] And with that, we’ve done it! cbindgen will generate the bindings so we have an enum to use and return from C++ code. We’ve written a C++ function that’s relatively straightforward. We’ll move over to nsMediaFeatures.cpp and add it. If the browser is resisting fingerprinting, we’ll return no-preference. Otherwise, we’ll return high- or no-preference based on whether or not we’ve enabled high contrast mode (UseAccessibilityTheme). StyleContrastPref Gecko_MediaFeatures_PrefersContrast(const Document* aDocument, const bool aForcedColors) { if (nsContentUtils::ShouldResistFingerprinting(aDocument)) { return StyleContrastPref::NoPreference; } // Neither Linux, Windows, nor Mac has a way to indicate that low // contrast is preferred so the presence of an accessibility theme // implies that high contrast is preferred. // // Note that MacOS does not expose whether or not high contrast is // enabled so for MacOS users this will always evaluate to // false. For more information and discussion see: // https://github.com/w3c/csswg-drafts/issues/3856#issuecomment-642313572 // https://github.com/w3c/csswg-drafts/issues/2943 if (!!LookAndFeel::GetInt(LookAndFeel::IntID::UseAccessibilityTheme, 0)) { return StyleContrastPref::High; } return StyleContrastPref::NoPreference; } Aside: This implementation doesn’t have a way to detect a preference for low contrast. As we discussed earlier neither Windows, macOS, nor Linux has a standard way to indicate that low contrast is preferred. Thus, for our initial implementation, we opted to keep things simple and make it impossible to toggle. That’s not to say that there isn’t room for improvement here. There are various less standard ways for users to indicate that they prefer low contrast — like forcing low contrast colors on Windows, Linux, or in Firefox. Determining contrast preferences in Firefox Finally, we’ll add the function definition to GeckoBindings.h so that our Rust code can call it. mozilla::StyleContrastPref Gecko_MediaFeatures_PrefersContrast( const mozilla::dom::Document*, const bool aForcedColors); Now that parsing, logic, and C++ bindings are set up, we’re ready to add our Rust function for evaluating the media query. Moving back over to media_features.rs, we’ll go ahead and add a function to do that. Our function takes a device with information about where the media query is being evaluated. It includes an optional query value, representing the value that the media query is being evaluated against. The query value is optional because sometimes the media query can be evaluated without a query. In this case, we evaluate the truthiness of the contrast-preference that we normally would compare to the query. This is called evaluating the media query in the “boolean context”. If the contrast preference is anything other than no-preference, we go ahead and apply the CSS inside of the media query. Contrast preference examples That’s a lot of information, so here are some examples: @media (prefers-contrast: high) { } /* query_value: Some(high) */ @media (prefers-contrast: low) { } /* query_value: Some(low) */ @media (prefers-contrast) { } /* query_value: None | "eval in boolean context" */ In the boolean context (the third example above) we first determine the actual contrast preference. Then, if it’s not no-preference the media query will evaluate to true and apply the CSS inside. On the other hand, if it is no-preference, the media query evaluates to false and we don’t apply the CSS. With that in mind, let’s put together the logic for our media query! fn eval_prefers_contrast(device: &Device, query_value: Option) -> bool { let forced_colors = !device.use_document_colors(); let contrast_pref = unsafe { bindings::Gecko_MediaFeatures_PrefersContrast(device.document(), forced_colors) }; if let Some(query_value) = query_value { match query_value { PrefersContrast::Forced => forced_colors, PrefersContrast::High => contrast_pref == ContrastPref::High, PrefersContrast::Low => contrast_pref == ContrastPref::Low, PrefersContrast::NoPreference => contrast_pref == ContrastPref::NoPreference, } } else { // Only prefers-contrast: no-preference evaluates to false. forced_colors || (contrast_pref != ContrastPref::NoPreference) } } The last step is to register our media query with Firefox. Still in media_features.rs, we’ll let Stylo know we’re done. Then we can add our function and enum to the media features list: pub static MEDIA_FEATURES: [MediaFeatureDescription; 54] = [ // ... feature!( atom!("prefers-contrast"), AllowsRanges::No, keyword_evaluator!(eval_prefers_contrast, PrefersContrast), // Note: by default this is only enabled in browser chrome and // ua. It can be enabled on the web via the // layout.css.prefers-contrast.enabled preference. See // disabled_by_pref in media_feature_expression.rs for how that // is done. ParsingRequirements::empty(), ), // ... ]; In conclusion And with that, we’ve finished! With some care, we’ve walked through a near-complete implementation of prefers-contrast in Firefox. Triggered updates and tests are not covered, but are relatively small details. If you’d like to see all of the code and tests for prefers-contrast take a look at the Phabricator patch here. prefers-contrast is a powerful and important media query that makes it easier for web authors to create accessible web pages. Using prefers-contrast websites can adjust to high and forced contrast preferences in ways that they were entirely unable to before. To get prefers-contrast, grab a copy of Firefox Nightly and set layout.css.prefers-contrast.enabled to true in about:config. Now, go forth and build a more accessible web! Mozilla works to make the internet a global public resource that is open and accessible to all. The prefers-contrast media query, and other work by our accessibility team, ensures we uphold that commitment to our low-vision users and other users with disabilities. If you’re interested in learning more about Mozilla’s accessibility work you can check out the accessibility blog or the accessibility wiki page. The post Adding prefers-contrast to Firefox appeared first on Mozilla Hacks - the Web developer blog. [Less]

This blog post has first appeared on the Mozilla Attack & Defense blog and was co-authored with Christoph Kerschbaumer and Tom Ritter In a recent academic publication titled Hardening Firefox against Injection Attacks (to appear at SecWeb – Designing Security for the Web) we describe techniques which we have incorporated into Firefox …

Last year, the accessibility team worked to identify and fix gaps in our screen reader support, as well as on some new areas of focus, like improving Firefox for users with low vision. As a result, we shipped some great features. In addition, we’ve ... [More] begun building awareness across Mozilla and putting in place processes to help ensure delightful accessibility going forward, including a Firefox wide triage process. With a solid foundation for delightful accessibility well underway, we’re looking at the next step in broadening our impact: expanding our engagement with our passionate, global community. It’s our hope that we can get to a place where a broad community of interested people become active participants in the planning, design, development and testing of Firefox accessibility. To get there, the first step is open communication about what we’re doing and where we’re headed. To that end, we’ve created this blog to keep you all informed about what’s going on with Firefox accessibility. As a second step, we’ve published the Firefox Accessibility Roadmap. This document is intended to communicate our ongoing work, connecting the dots from our aspirations, as codified in our Mission and Manifesto, through our near term strategy, right down to the individual work items we’re tackling today. The roadmap will be updated regularly to cover at least the next six months of work and ideally the next year or so. Another significant area of new documentation, pushed by Eitan and Morgan, is around our ongoing work to bring VoiceOver support to Firefox on macOS. In addition to the overview wiki page, which covers our high level plan and specific lists of bugs we’re targeting, there’s also a work in progress architectural overview and a technical guide to contributing to the Mac work. We’ve also transitioned most of our team technical discussions from a closed Mozilla Slack to the open and participatory Matrix instance. Some exciting conversations are already happening and we hope that you’ll join us. And that’s just the beginning. We’re always improving our documentation and onboarding materials so stay tuned to this channel for updates. We hope you find access to the team and the documents useful and that if something in our docs calls out to you that you’ll find us on Matrix and help out, whether that’s contributing ideas for better solutions to problems we’re tackling, writing code for features and fixes we need, or testing the results of development work. We look forward to working with you all to make the Firefox family of products and services the best they can be, a delight to use for everyone, especially people with disabilities. The post Broadening Our Impact appeared first on Mozilla Accessibility. [Less]

Two years ago we first brought Mozilla v. FCC in federal court, in an effort to save the net neutrality rules protecting American consumers. Mozilla has long fought for net neutrality because we believe that the internet works best when people ... [More] control their own online experiences. Today is the deadline to petition the Supreme Court for review of the D.C. Circuit decision in Mozilla v. FCC. After careful consideration, Mozilla—as well as its partners in this litigation—are not seeking Supreme Court review of the D.C. Circuit decision. Even though we did not achieve all that we hoped for in the lower court, the court recognized the flaws of the FCC’s action and sent parts of it back to the agency for reconsideration. And the court cleared a path for net neutrality to move forward at the state level. We believe the fight is best pursued there, as well as on other fronts including Congress or a future FCC. Net neutrality is more than a legal construct. It is a reflection of the fundamental belief that ISPs have tremendous power over our online experiences and that power should not be further concentrated in actors that have often demonstrated a disregard for consumers and their digital rights. The global pandemic has moved even more of our daily lives—our work, school, conversations with friends and family—online. Internet videos and social media debates are fueling an essential conversation about systemic racism in America. At this moment, net neutrality protections ensuring equal treatment of online traffic are critical. Recent moves by ISPs to favor their own content channels or impose data caps and usage-based pricing make concerns about the need for protections all the more real. The fight for net neutrality will continue on. The D.C. Circuit decision positions the net neutrality movement to continue on many fronts, starting with a defense of California’s strong new law to protect consumers online—a law that was on hold pending resolution of this case. Other states have followed suit and we expect more to take up the mantle. We will look to a future Congress or future FCC to take up the issue in the coming months and years. Mozilla is committed to continuing our work, with our broad community of allies, in this movement to defend the web and consumers and ensure the internet remains open and accessible to all. The post Next Steps for Net Neutrality appeared first on Open Policy & Advocacy. [Less]