Re: Introducing a new HTTP response header for Carbon Emissions calculation

It's a complete waste of time and energy. Carbon emissions are not relevant on a
per request basis, even if they could be measured by a running process.

The cost of a service is an accumulation of everything that goes into providing it,
including the overhead of unused provisioning for availability. It will depend on
location of server, time of day, source of power, and co-location with other services.
It can be overwhelmed by the cost of design (such as AI model generation) or by
failure to deallocate unused servers. It even depends on the cost of eventual
decommissioning the service when it is no longer wanted.

Only the tiniest possible fraction of that is due to whatever processes happen
to be triggered by a given request. Unless it is mining-as-a-service, which
doesn't seem to be the right audience.

If you want to know the carbon footprint of a service, you need the total cost of
its provision, and then amortize that across time and customer demand. This is an
accounting job, and the information belongs in a resource that a site can provide
to anyone who wants that information (or might cause a government to
demand it be provided). In a standard format, like accountants understand.
In a standard location, like a well-known URL.

This is a resource, not a header field.

Otherwise, it is far more useful to send factual information that can be tested
for accuracy, such as power usage within the server stats field, and let the
recipient project from those facts to some estimate of carbon equivalence.

That guess is going to be far more accurate than anything a service might
advertise on its own, short of accounting laws.


Received on Tuesday, 11 April 2023 20:30:34 UTC