SVG favicons in Chrome

A commit that landed in Chromium (and which will be available in Chrome 80) is support for SVG favicons. 🎉

🦊 Firefox already has support for SVG favicons, ever since version 41

Since most (all?) browsers always make a request to favicon.ico you can also serve an SVG at that location with the image/svg+xml MIME Type – As per tip by Mathias

Above that it’s also possible to use prefers-color-scheme in your SVG icon, thus supporting Light/Dark Mode:

🐛 There’s on small bug though: you need to refresh the page after changing to/from Dark Mode for the favicon to change.

Dark Mode Favicon Demo →

Ungoogled Chromium is Google Chrome, but without Google

If you’re not too fond of Google but do want a Chromium-based browser that is as close to Google Chrome as it can be (along with some extras), be sure to check out Ungoogled Chromium:

ungoogled-chromium is Google Chromium, sans dependency on Google web services. It also features some tweaks to enhance privacy, control, and transparency (almost all of which require manual activation or enabling).

ungoogled-chromium retains the default Chromium experience as closely as possible. Unlike other Chromium forks that have their own visions of a web browser, ungoogled-chromium is essentially a drop-in replacement for Chromium.

Ungoogled Chromium Source (GitHub) →
Ungoogle Chromium Binaries →

How to publish your PWA onto the Google Play Store

Thanks to the Trusted Web Activity feature in Chrome 72 on Android, the Google Play Store is now open for Progressive Web Apps.

Chrome 72 for Android is now shipping from the Play Store to all users and this version included Trusted Web Activity (TWA), that in a nutshell is a way to open Chrome in standalone mode (without any toolbar or Chrome UI) within the scope of our own native Android package.

The easiest way to get your PWA published onto the Google Play Store is to clone the example repository and adjust the manifestPlaceholders settings in app/build.gradle.

Additionally you’ll also need to set up Digital Assets Links in /.well-known/assetlinks.json which is hosted on the website also hosting the PWA.

UPDATE 2019-02-12: Thanks to PWA2APK you can now automatically generate a .apk for you to upload to the Play Store.

Google Play Store now open for Progressive Web Apps 😱 →
SVGOMG / Trusted Web Activity Example (GitHub) →
Google Digital Assets Links →

Let’s play with Chrome’s Face Detection API

Recently Wes Bos sent out this tweet:

Sparked by that tweet, João Miguel Cunha set out to play with it. The code itself is pretty simple: create an instance of FaceDetector and call .detect() on it. That promise eventually resolves with an array of detected faces.

var faceDetector = new FaceDetector();
faceDetector.detect(image)
  .then(faces => faces.forEach(face => console.log(face)))
  .catch(e => {
    console.error("Boo, Face Detection failed: " + e);
  });

Let’s play with Chrome’s Face Detection API →

Chrome 66 to Untrust Symantec-issued Certificates

Chrome is really tightening up the security game here. In Chrome 66 it will untrust Symantec-issued SSL/TLS certificates, after Symantec has repeatedly screwed up by wrongly issuing certificates for domains, including google.com itself.

Thanks to a decision in September by Google to stop trusting Symantec-issued SSL/TLS certs, from mid-April Chrome browser users visiting websites using a certificate from the security biz issued before June 1, 2016 or after December 1, 2017 will be warned that their connection is not private and someone may be trying to steal their information. They will have to click past the warning to get to the website.

This will also affect certs that use Symantec as their root of trust even if they were issued by an intermediate organization. For example, certificates handed out by Thawte, GeoTrust, and RapidSSL that rely on Symantec will be hit by Google’s crackdown. If in doubt, check your cert’s root certificate authority to see if it’s Symantec or not.

Arkadiy Tetelman has recently done an experiment and made an inventory of how many sites in the Alexa Top 1 Million that will be affected by this.

Included in the 100,000 affected sites we find/found (some have gotten a new certificate by now) icloud.com, tesla.com, wechat.com, etc.

Quantifying Untrusted Symantec Certificates →
Chrome’s Plan to Distrust Symantec Certificates →
Beware the looming Google Chrome HTTPS certificate apocalypse! →

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)

Why does Chrome show a T-Rex when it’s offline?

With touching the topic “offline” in the previous post, I was reminded of the T-Rex that Chrome shows when it’s offline.

Most of us think it’s just a fun little pixel dinosaur which acts as facade for a game you can play whilst there’s no active internet connection, but there’s more to it.

The T-Rex is a reference to a scene from the 2007 film Meet the Robinsons. In it a T-Rex tries snapping up a boy, but fails at it due to his big head an little arms:

So the T-Rex in Chrome is there not because it’s a fun little pixel dinosaur, but BECAUSE IT CANNOT REACH THE BOY PAGE.

My inner geek rejoices 🙂

Show Facebook Computer Vision Tags Chrome Extension

Since April 2016, Facebook has been automatically adding alt tags to images you upload that are populated with keywords representing the content of your images.

This Chrome Extension visualizes the tags (which can be found in the markup)

<img src="https://facebook.com/some-url.jpg"
alt="Image may contain: golf, grass, outdoor and nature"
width="316" height="237">

Show Facebook Computer Vision Tags Source (GitHub) →
Show Facebook Computer Vision Tags on the Chrome Webstore →

Redesigning Chrome desktop

1-lnwjbpaofmearexl1ixkea

In the beginning of this month of September, the new Chrome Core UI redesign, or so called “Chrome MD” (for Material design), rolled out on Windows as part of our 53rd update. It is the last step of a three phase deployment of the new design,which started in 51 with Chrome OS and Linux, followed by macOS in 52. Windows is the culmination of that process and while Chrome is never finished, it felt to me like the right time to take a look back and reflect on this process that almost took 2 years, hopefully delivering some details and experiences that might be useful to you.

Extensive and detailed write-up. Be sure to read the “Lessons learned” closing note too.

Redesigning Chrome desktop →