Over the last twelve months, we’ve been posting about our work leading on the development of SCI for Web, a new standard for measuring the carbon emissions from using digital services. This will eventually become an ISO standard, as a more focussed version of the parent ISO standard, Software Carbon Intensity, from the Green Software Foundation. Earlier in July, we posted the latest snapshot of how the spec for this standard is developing, and in this post Director of Policy and Technology Chris Adams, outlines the latest changes, how to stay up to date, and how you can respond.
A recap, what is this SCI for Web thing and why does it matter?
Put simply, while it’s useful to be able to make calculations about the environmental impact of digital services, if you want laws or contracts to require monitoring and reporting on them, it really helps to have standard you can refer to. This is helpful because it demonstrates that different groups, with different points of view agree how things should be measured, so there’s some degree of comparability, and consistency about what the calculations mean, and what should be included when making them.
The Software Carbon Intensity standard from the Green Software Foundation, or if you prefer, ISO/IEC 21031:2024, is an internationally accepted standard for calculating the rate of carbon emissions from a software system.
Here’s the thing though – lots of things can be software systems, so it’s by necessity very flexible.
This flexibility can make it hard to use, so while there are quite a few tools out there that calculate carbon emissions from software – particularly for web sites and web applications – very few of them use this standard.
So, the idea behind a Software Carbon Intensity for Web (SCI for Web) is to create a tighter, more focussed version that is still compatible with the existing Software Carbon Intensity standard, but is easier to use in existing software and services.
To be more specific, it will still take into account:
- the amount of electricity used to run software
- the carbon intensity of that electricity
- the embodied carbon in the hardware that software runs on
- the functional unit (i.e. visiting a web page, performing a search, and so on)
However, where the original is emphasises flexibility, it emphasises conventions and sensible defaults – so is more tightly focussed on the majority of use-cases found on the web, and clearer guidance what information ought to be used in calculations. This might include things like the age of a device connecting to use a web application, how powerful it is, what kind of data to use for carbon intensity, and so on.
It also provides more guidance on what a physical measuring setup to might need to look like for making credible claims about the carbon footprint of software, based on lessons learned with other standards in use around the world for measuring the environmental impacts of software.
How is the standard developing?
It might make sense for an organisation called the Green Web Foundation to work with one called the Green Software Foundation – you can see from the name where there might be shared interests – but there are existing organisations who have been developing standards for the web for decades too.
So with that in mind, this standard is being developing in consultation with the World Wide Web Consortium, and in an earlier post in May, we went into more detail about the prior work, and how updates to standard are being shared, as well how governance is being managed, across the three organisations.
The short version is that every few weeks, while the development of the SCI for Web is being managed in a closed group, the Green Web Foundation shares a snapshot of the latest draft, for folks in the W3C’s Sustainable Web Interest Group to review, and provide feedback that gets taken into account during the next few rounds of deliberation. However because the W3C works in public, it’s available for the world to see too – huzzah!
Earlier in July, we shared the latest snapshot, as a pull request on Github, with a summary of the latest changes to review, and took W3C’s Sustainable Web group through the changes.
Here’s the recording on zoom, where the 5 minute walkthrough begins at 00:39:57, and here are the minutes from the meeting.
What’s changed this time?
Since the last snapshot there are a few specific things that people who care about measuring a sustainable web might care about.
They’re detailed in the pull request, but for convenience here’s the summary:
- A tier based system for progressive levels of precision – in the spec there are progressively more detailed ways of measuring energy and emissions, starting at something that can ideally be used in a small software library (like maybe… CO2.js for example) and added to existing software and tooling, right the way up to full-on physical device measurements in a dedicated lab.
- Minimum measurement requirements – there are now some clearer minimum measurement requirements. You need to at least provide these in any tooling and calculations, and be explicit about the functional unit (ie. are you measuring someone visiting web page, carrying out a multi stage transaction to buy something, and so on).
- Guidance on where to get carbon data – there is a clear hierarchy for referring to the carbon intensity of electricity, based on the availability of public data, and the existence of commercial operators who might provide higher resolution. For example, our library CO2.js, contains this for free since release v18, but for more detailed, but still-compatible measurements, you might want to use a company like Electricity Maps who give you real time figures and forecasts.
- Support for time-based network measurement – there is an alternative way to measure network energy supported based on recent peer reviewed work from Mytton, Lundén & Malmodin (2024), Network energy use not directly proportional to data volume. If you’re curious, this toy app gives an interactive way to explore of some of the calculations using this approach, as it’s different to the transfer-only based approaches in the more common Sustainable Web Design Model (which, by the way, is also in CO2.js as the default since v18). This is intended to more closely reflect how network energy consumption changes in response to changes in web traffic, because while some parts of the network might use more power when sending more data, other parts do not.
I’m building measurement software, this looks really interesting, and I want to make my software follow this standard when it is live.
If you’re building software that tracks the environmental impact of web applications, websites and digital services, and want private, commercial help, the fastest way to get in touch is via our contact form.
Otherwise, if you are in a non-profit or academic institution, joining the Green Software Foundation is free, and there is a process for joining W3C Sustainable Web Interest group as an invited expert, which is also free, if you meet the criteria.
Otherwise please see the organisation’s respective membership pages for joining and taking part. Here’s the W3C, and here’s the GSF.
I’m interested and want to give feedback, or stay up to date.
While the first draft of the Software Carbon Intensity for Web standard is being developed in a closed group, these snapshots are being shared every few weeks, and will continue to be shared likely until Q4 this year, when a finished first draft should be publicly available.
You can follow this blog, our monthly newsletter, or the W3C Sustainable Web Group meetings linked above to see the latest public snapshot we have put into the public domain (and even add your own feedback to the PR). But bear in mind that is all still being developed and subject to change – please don’t spend huge amounts of time and money building software on this just yet.
As ever, if you have other queries relating to this, the fastest way to get in touch is via our contact form. Thanks!
