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.
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 :
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!
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.
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.
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?
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:
Imho Google should have opened it up, pointing all domains to 127.0.0.1 / ::1 (and more, cfr. xip.io), and providing free SSL certs for all.
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:
(Chrome) Us developers can keep using the .dev TLD for projects in development.
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)
(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!
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.
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 🙂
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.
