HTTP Response Header Field: Carbon-Emissions-Scope-2(ietf.org)
ietf.org
HTTP Response Header Field: Carbon-Emissions-Scope-2
https://www.ietf.org/archive/id/draft-martin-http-carbon-emissions-scope-2-00.html
40 comments
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.
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.
How do we calculate the carbon emissions generated by all the discarded carbon emissions fields?
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.
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.
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!
May I suggest also having a link to a unique video of a few burning tires to make sure the proof of pollution is trustable?
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.
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.
This is just virtue signaling and the IETF shouldn’t play along with some company’s business needs… sad to see.
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?
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?
> processed by caches or proxies
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.
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.
So the first request costs 100 units of carbon and is cached, user 1 pays 100 units.
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?
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?
More concerned that if I’m returning a precached response, I ought to be able to claim some sort of carbon credit :)
[deleted](1)
This is one hundred percent going to generate more carbon than it saves.
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.
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.
Is that before or after the extra CPU & network required for the new header? :)
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...
There is some ongoing discussion on this document in httpbis:
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.
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.
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)
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.
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.
I think this was posted 2 days late.
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.
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.
Of all the things you could specify about the resource cost of a request, is carbon the most important, or only one?
What's the use case for such a header?
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...
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...
Is this a delayed April fools joke?
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.
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.
Anyone can submit these.
https://datatracker.ietf.org/doc/draft-omar-ipv10/
https://datatracker.ietf.org/doc/draft-omar-ipv10/
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.
Related IETF Krazam video: https://www.youtube.com/watch?v=NAkAMDeo_NM
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.
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).
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).
It's all about guilt-tripping. This header tells you how many indulgences you need to buy.
HTTP headers are lowercase.
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.
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.
Shame on https://sentry.io
The author is not from sentry.io, but from "Sentry Software" (https://www.sentrysoftware.com/). They do not seem to be related.
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.