I appreciate the idea of fighting climate change with a virtue-signalling HTTP header that will be promptly thrown away by endpoints, but still has to be carried along by every intermediary on the network path.
Estimating the climate impact of the additional traffic caused by the Carbon-Emissions-Scope-2 headers and calculation of the Scope 2 values vs. caused change of behaviour (if there is any) is a paper / thesis waiting to happen, should this ever become a standard.
Logically this is correct because by the time a header is received by the user agent, all the work to create that request and send it down the wire is done, but now we’ve asked for an additional workload, however small, to be performed in this computation thus causing more energy to be consumed per request. If we did not have this header, the computation will not be necessary.
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.
You can entirely forget the computational side of it. The carbon footprint of the man-hours related to implementation is going to be an order of magnitude larger.
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...
This is two days off of being an April Fools' RFC, but it's hard not to consider it to be one.
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.
Not to mention, what are they expecting the client to do with the header? Block every request that exceeds some particular CO2 budget? (after it already happened of course). Have fun with a broken, partially loaded site because a random fraction of the requests don't come through.
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).
Publishing an RFC like this in early April seems risky, given IETF traditions…
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.
HTTP header names are case-insensitive, and traditionally (e.g. HTTP/1.1) I've always seen them encoded in title-case.
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.
As I understand it, this doesn't factor in whether the response contains a payload that'll force the client to churn through power.
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.
We can't trust the value of the header. It needs to be proof of work (none of that unreliable proof of stake) signed with origin information to be reliable!
PoC (proof of carbon) coins, coming soon to a pump and dump near you!
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.
IMO the security considerations should suggest that it is now easy to locate pages that will burn the CPU, this making DDoS much less complex. To be fair you reduce the DDoS attackers CO2...
It would be a better idea to formally deprecate the Date header. It’s such a stupid header with respect to both the waste of bytes and the CPU time spent formatting the information.
Couldn't it also potentially be a side-channel for crypto breaks, depending on how it's implemented? If I'm reading it right they're advising that it should be as accurate as possible, which is also what makes a good side channel.
Assuming that companies aren't just pissing away money on electricity, hardware, cooling etc. for the sake of it, this is essentially just going to be a marker of quality.
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.
These people need to just stop. Not only is it absurdly dumb it can't ever be accurate because there is no way for the server to know the real cost (including any load balancers, delivery via transport etc)
40 comments
[ 3.8 ms ] story [ 99.7 ms ] threadMight 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.
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.
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...
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).
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?
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.
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.
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.
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.
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.
https://datatracker.ietf.org/doc/draft-omar-ipv10/
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.
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.