Firefox State Partitioning

State Partitioning is an interesting privacy feature shipping with Firefox 86.

With State Partitioning, shared state such as cookies, localStorage, etc. will be partitioned (isolated) by the top-level website you’re visiting. In other words, every first party and its embedded third-party contexts will be put into a self-contained bucket.

Applies to every embedded third-party resource (regardless of whether it is a tracker or not), but some exceptions for Single Sign-On purposes have been made.

Firefox State Partitioning →

As of version 85 a similar feature landed in Chromium. Safari introduced partitioning for Cookies with its Intelligent Tracking Prevention 1.0. Can’t find any mention whether Safari also partitions other 3rd-party content, but I think they do.

☝️ Without these protections, ads follow you around the internet.

How to enable HTTP3 in Chrome / Firefox / Safari

Mattias recently tweeted that his website can now be served over HTTP/3 “even though no browser supports it yet”.

While it’s true that no browser supports it out of the box right now, there are options to enable HTTP/3. Here’s how.

🧪 As with all experimental technolgy/features: things might break! Be warned!

~

Google Chrome

If you search chrome://flags you’ll find an option named “Experimental QUIC Protocol” which you can enable:

That alone however won’t do. You’ll also need to enable a specific HTTP3 version, apparently. This extra change cannot be done through chrome://flags, but only through a command line option.

To fully enable HTTP/3 in Chrome, you must launch it with the command line options --enable-quic --quic-version=h3-27 :

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --enable-quic --quic-version=h3-27

Firefox

Set network.http.http3.enabled to true in about:config

At least Firefox 75 is required.

Safari

Safari Technology Preview Release 104 which was just released has added HTTP3 as an experimental feature. To enable it, you’ll first need to enable the “Develop” menu through its settings.

If you’re running (the unreleased) macOS 10.16 / iOS 14, you can now use the Develop menu and underneath Experimental Features enable it.

🙏 Thanks to Kai for digging up the fact that macOS 10.16 is required.

~

How to test this?

A good site to test your connection is https://www.litespeedtech.com/. Visit that site and open the DevTools of your browser (SHIFT+CMD+I). In the Network tab enable the protocol column and refresh the page.

Here’s an example of Firefox:

quic.rocks is also a good site you can use. I did notice that Firefox for example sometimes loads that site using HTTP/1.1 and sometimes using HTTP/3 … experimental features, right? 😉

~

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Tweet from the Firefox Address Bar by adding a Bookmark

In succession to Tweet from the Chrome Address Bar by adding a Custom Search Engine, you can also do this in Firefox. Simply define a bookmark (containing a %s wildcard) with a linked keyword and you’re good to go:

  • Name: Compose Tweet
  • Location: https://twitter.com/compose/tweet?text=%s
  • Keyword: tweet

You can now use the tweet keyword to start tweeting from the Firefox Address Bar.

~

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Firefox 72: Individual CSS Transform Properties

New in Firefox 72 is the ability to individually define CSS Transform Properties. You can now separately define scale, rotate, and translate CSS properties, instead of having to chuff them all into one single transform property.

The translate, rotate, and scale properties allow authors to specify simple transforms independently, in a way that maps to typical user interface usage, rather than having to remember the order in transform that keeps the actions of transform(), rotate() and scale() independent and acting in screen coordinates.

element {
  scale: 2;
  rotate: 30deg;
  translate: -50% -50%;
}

The order that they are applied is, as per CSS Transforms Level 2 spec, first translate, then rotate, and then scale — not the order which you define them in.

By having individual transform props, this also means that we can animate and transition them separately.

@keyframes individual {
  50% {
    translate: 0 50%;
  }
  75% {
    scale: 1;
  }
}
element {
  transition:
    rotate 200ms ease-in-out,
    scale 500ms linear;
}

element:hover {
  scale: 2;
  rotate: -3deg;
}

Here’s a pen demonstrating its usage:

See the Pen
Individual CSS Transform Properties Demo
by Bramus (@bramus)
on CodePen.

In Chrome these new props are still behind the #enable-experimental-web-platform-features feature flag.

~

Did this help you out? Like what you see?
Thank me with a coffee.

I don't do this for profit but a small one-time donation would surely put a smile on my face. Thanks!

☕️ Buy me a Coffee (€3)

To stay in the loop you can follow @bramus or follow @bramusblog on Twitter.

Mozilla Hacks: Designing the Flexbox Inspector

With the upcoming release of Firefox 65 (due January 29tgh), its DevTools will sport a new shiny Flexbox Inspector.

The new Flexbox Inspector, created by Firefox DevTools, helps developers understand the sizing, positioning, and nesting of Flexbox elements.

Victoria Wang details how they UX challenges that came with this tool were tackled.

Built on the basic concepts of the CSS Grid Inspector, we sought to expand on the possibilities of what a design tool could be. I’m excited to share a behind-the-scenes look at the UX patterns and processes that drove our design forward.

Designing the Flexbox Inspector →

On “Secure Contexts” in Firefox, HTTPS for local development, and a potential nice gesture by Chrome

👋 This post also got published on Medium. If you like it, please give it some love a clap over there.

Earlier today, in a post entitled Secure Contexts Everywhere, it was announced on the Mozilla Security Blog that Firefox from now on will only expose new features such as new CSS properties to secure contexts:

Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. A feature can be anything from an extension of an existing IDL-defined object, a new CSS property, a new HTTP response header, to bigger features such as WebVR. In contrast, a new CSS color keyword would likely not be restricted to secure contexts.

Whilst I somewhat applaud this move, especially in the age of data theft and digital espionage, it’s – pardon my French – quite a ballsy thing to do. CSS Properties, really?

You might not be entirely aware of it, but features like Geolocation, the Payment Request API, Web Bluetooth, Service Workers, etc. are already locked down to secure contexts only.

But what is this secure context they speak of exactly? Is it HTTPS? Or is it more than that?

Let’s take a look at the MDN Web Docs on Secure Contexts:

A context will be considered secure when it’s delivered securely (or locally), and when it cannot be used to provide access to secure APIs to a context that is not secure. In practice, this means that for a page to have a secure context, it and all the pages along its parent and opener chain must have been delivered securely.

Roughly translated: http://localhost/ is considered to be a secure context, so that one will have the latest and greatest. However, the docs aren’t that clear on whether the definition of “local” involves actual DNS resolving or not:

Locally delivered files such as http://localhost and file:// paths are considered to have been delivered securely.

What about development domains – think project.local or project.test – pointing to 127.0.0.1? Right now we’re left in the blue here …

Do note however that Mozilla “will provide developer tools to ease the transition to secure contexts and enable testing without an HTTPS server”, but the related bug is still unassigned.

~

It’s best to have your local web development stack mimic the production environment as closely as possible. Over the years we’ve seen the rise of tools like Vagrant and Docker to easily allow us to do so: you can run the same OS and version with the exact same Apache version with the exact same PHP version with the exact same MySQL version with … oh you get the point.

One of the things that’s still not really frictionless right now for your local development domains is the use of certificates.

Yes, you could use self-signed certificates for this, but that’s:

  • Not always possible: The Fetch API for example doesn’t allow the ignoring of self signed certificates.
  • Asking for potential security problems the moment you go into production: I once read a post about some production code that still had the --insecure flag enabled on the curl requests 🤦‍♂️. It was put there in the first place because of to the self-signed certificates used during development.

Another approach – and one that I am taking – is to use an actual domain for your dev needs. Each project I build is reachable via a subdomain on that dedicated domain, all pointing to 127.0.0.1 thanks to a an entry in my hosts file. Since it’s an actual domain I am using, I can use an actual and correctly signed certificate along with that when it comes to HTTPS.

At the cost of only a domain name (you can get your certificates for free via Let’s Encrypt, which now support wildcards too) that’s quite a nice solution I think.

~

Back in December 2017 version 63 of Google Chrome was released. One of the changes included is that Chrome now requires https for .dev and .foo domains. This was ill-received by quite a lot of developers as most of them – including me before – use(d) the .dev TLD for local development purposes.

And yes, the pain is real … just do a quick search on Twitter on chrome https dev and you’ll see that lots of developer have wasted – and still are wasting – many hours on this breaking change.

Yes, there’s a (lengthy) workaround available to get the green lock in Chrome, but I wouldn’t recommend it really. It would require you to repeat a likewise procedure in all browsers you have running/are testing in, and this per .dev domain you have. Above that it won’t fix any out-of-browser contexts.

Could Google have prevented this .dev debacle? Of course. But I don’t see a reversal of this change coming any time soon though …

Can Google still do something about it? Well … I have an idea about this:

Just imagine if Google were to point all .dev domains to 127.0.0.1, that’d truly be paving the cowpaths! Add free SSL certificates for all .dev domains along with that and we’d jump quite far. With announcements like Secure Contexts Everywhere (referenced at the very top of this page) this idea seems like a real winner:

  1. (Chrome) Us developers can keep using the .dev TLD for projects in development.
  2. Us developers no longer need to use self-signed certificates anymore for projects in development. We could use certificates directly signed by Google’s CA (or by Let’s Encrypt in case Google doesn’t feel like providing certificates)
  3. (Firefox) Domains with the .dev TLD (and with an SSL Certificate) can be considered as a Secure Context, just like any other domain reachable via HTTPS.

One can dream, right?

FIN.

Did this help you out? Like what you see?
Consider donating.

I don’t run ads on my blog nor do I do this for profit. A donation however would always put a smile on my face though. Thanks!

☕️ Buy me a Coffee ($3)

Inside a super fast CSS Engine: Quantum CSS (aka Stylo)

Great writeup on how Firefox’s new CSS Engine “Quantum CSS” works. Also sports a clear and in-depth explanation of the rendering pipeline, with some nice illustrations to go along.

You may have heard of Project Quantum… it’s a major rewrite of Firefox’s internals to make Firefox fast. We’re swapping in parts from our experimental browser, Servo, and making massive improvements to other parts of the engine.

The first major component from Servo – a new CSS engine called Quantum CSS (previously known as Stylo) – is now available for testing in our Nightly version.

Inside a super fast CSS Engine: Quantum CSS (aka Stylo) →

Using Immutable Caching To Speed Up The Web

Firefox shipped with support for Cache-Control: Immutable:

The benefits of immutable mean that when a page is refreshed, which is an extremely common social media scenario, elements that were previously marked immutable with an HTTP response header do not have to be revalidated with the server.

No more 304‘s for those resources, because the browser won’t even re-request them 🙂

Using Immutable Caching To Speed Up The Web →
Cache-Control: immutable introductory post →

Date/Time Input Types coming to Firefox

Date/Time Input Types are coming to Firefox, and I must say they look quite good too (as a reference: here’s how Chrome implemented this):

The implementation also looks familiar, doesn’t it? 😉

The date/timepickers are currently locked behind a flag in Nightly. Change dom.forms.datetime in about:config if you want to try them out already.

Date/Time Input Types →

Google Chrome, Firefox Address Bar Spoofing Vulnerability

CqGfgXGWcAEjG6R

Turns out one single right-to-left character in a URL can make the omnibox (Address Bar) freak out, and render it wrongly:

Placing neutral characters such as “/”, “ا” in filepath causes the URL to be flipped and displayed from Right To Left. In order for the URL to be spoofed the URL must begin with an IP address followed by neutral characters […] what matters is that the first strong character (generally, alphabetic character) in the URL must be an RTL character.

When typing in 127.0.0.1/ا/http://google.com into the omnibox, it will be displayed as http://google.com/‭ا/127.0.0.1, which is obviously not google.com … let this be a reminder to check also check for the green padlock being present when visiting well known sites.

Google Chrome, Firefox Address Bar Spoofing Vulnerability →