HTTP Response Header Field: Carbon-Emissions-Scope-2
ietf.org
ietf.org
Knowing how much a single request is producing carbon emissions tells you immediately which operations are going to be costly to a business.
You could enumerate a site's tree, find the most taxing operation, and then hammer it, because carbon-emission is short-hand for cost.
Might I propose a new header? Total-Emissions-from-Virtue-Signal-Headers
Surely that'll fix it!
I'm all for awareness but I cannot see this being anything other than pointless.
I think the opposite has actually been proposed though, crypto systems where signing is used to authenticate coins as proof of carbon sequestration/zero carbon energy production as a system for cap and trade.
The lack of consideration for how this header should be processed by caches or proxies suggests a corresponding lack of seriousness in terms of thinking through even how it could meet its stated goals. Maybe it did just land a couple days late?
To be fair, if we wanted to increment the value based on the emissions of every node handling the payload, it should live outside of HTTP so as to also be incremented at layers that can't decrypt TLS. But on the other hand, do those outer layers (IP packets?) even offer the ability to have custom headers that don't get discarded? Genuine question, as my protocol expertise is mostly HTTP.
The second request then comes from the cache so is served from the cache for just 10 units.
Does user 2 pay 10, or do they pay 55 and user 1 gets a rebate of 45 units?
Also this is purely just fluff for an http request because anyone can put anything in here regardless of the actual CO2 cost. It’s probably the most useless thing I’ve seen in the last hour, if not all day.
https://lists.w3.org/Archives/Public/ietf-http-wg/2023AprJun...
Some influential folks appear interested. I'm not sure I see the point, but that's just me.
Larger images, higher video bitrates, hell, maybe an AI model with more parameters. Bam, more carbon.
This is generalisable to many contexts. If I'm buying a prepared meal for example, the one with a higher carbon footprint is likely to have more meat content.
If your goal is to reduce emissions, you likely want to hide this detail from people.
Given the current rate at which we're outsourcing calculation to e.g web browsers etc., it sounds like keeping this header value low will only perversely accelerate this trend, where work will be duplicated client-side and draw even more power.
User agents (browsers) tallying up an estimated C02 emissions for a session? That'd require a lot of buy in from sites and I don't expect many to adopt this or give out that info. Also, does google want you to use your browser less? Probably not...
Humans are in deep trouble if this is a serious proposal.
Well.. The evidence shows humans are already in deep trouble.
As a group, humans won't make serious changes until the majority experience an existential crisis.
Unfortunately, by the time this happens with climate change, it will be too late.
Estimating carbon emissions related to a single network request sounds incredibly error prone. Computers don't have nice, linear efficiency curves, they have computational overheads, and they can't reclock perfectly according to incoming demand. So you'd need your web server to check instantaneous CPU power consumption, subtract out CPU utilization from non web server processes, divide by the currently in-flight number of requests, and multiply by the request time. All of that adds error to the process.
I guess the only benefit here is that you could have some middleware somewhere that adds up CO2e figures calculated by backend web services to compute another CO2e figure? But even then this seems like a really fiddly and bad way for an organization to count up carbon.
Furthermore the actual methodology for counting up CO2e is part of a proprietary ISO standard, because I doubt they expected a freely-implementable RFC to actually need to count industrial CO2e emissions.
And that's assuming that no user disables the filter because they really really need to see those cat pictures (like they do with MITM'ed TLS connections) and that servers are always truthful and don't just put a zero everywhere (which would save the CO2 otherwise spent on calculating the estimated CO2 emissions though).
However -- and perhaps to your point -- HTTP/2 still specifies them as case-insensitive, but requires that over the wire, they are converted to lowercase.