3 ms·
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
by kmeisthax 4y ago
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.
- xg15 4y agoNot 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).
- wmf 4y agoIt's all about guilt-tripping. This header tells you how many indulgences you need to buy.