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

First, I love the idea of providing transparency for purposes of sustainability.

That having been said, three questions:

Is tracking CO2 the right unit?  Is CO2 the only thing we care about?
Is it something that any server can reasonably answer with any degree of accuracy? That is, do we have a good handle on the accounting required, particularly as part of back pressure into other components in the system?
Are there security considerations to be considered if either CO2 can be used as a proxy for power consumption / whether other components of the number can be probabilistically factored out during, say, authentication operations?

Thanks,

Eliot

> On 11 Apr 2023, at 23:21, Tim Bray <tbray@textuality.com> wrote:
> 
> Roy, I can't bring myself to agree. For two reasons.
> 
> First, I know, as a former public-cloud employees, that those operations already do quite a bit of work on tracking their carbon-loading, and take into account all that stuff, including amortizing cost of construction and so on.  So I bet that calls to individual Web services could produce useful data, and if you're running a lift-and-shift application on a fleet of a couple hundred of some instance type, you could produce a useful value too.
> 
> Second, these days, there are certain classes of requests, for example those to crypto exchanges and generative-AIs, which have freakishly huge compute costs, with plausibly-computable carbon-emissions.
> 
> So I think this is a useful affordance to provide. Not smart enough to predict the uptake though. Dependencies include politics.
> 
> On Tue, Apr 11, 2023 at 1:31 PM Roy T. Fielding <fielding@gbiv.com <mailto:fielding@gbiv.com>> wrote:
>> 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.
>> 
>> ....Roy
>> 
>>