[HN Gopher] HTTP Response Header Field: Carbon-Emissions-Scope-2
___________________________________________________________________
HTTP Response Header Field: Carbon-Emissions-Scope-2
Author : alexzeitler
Score : 34 points
Date : 2023-04-11 17:53 UTC (5 hours ago)
(HTM) web link (www.ietf.org)
(TXT) w3m dump (www.ietf.org)
| ezekg wrote:
| I think this was posted 2 days late.
| err4nt wrote:
| Of all the things you could specify about the resource cost of a
| request, is carbon the most important, or only one?
| xg15 wrote:
| 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.
| schroeding wrote:
| 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.
| igetspam wrote:
| 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.
| ryan-c wrote:
| Anyone can submit these.
|
| https://datatracker.ietf.org/doc/draft-omar-ipv10/
| causi wrote:
| This is one hundred percent going to generate more carbon than it
| saves.
| samtho wrote:
| 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.
| peanut-walrus wrote:
| HTTP headers are lowercase.
| racingmars wrote:
| 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.
| ucarion wrote:
| 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.
| chunk_waffle wrote:
| 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...
| mgax wrote:
| This is just virtue signaling and the IETF shouldn't play along
| with some company's business needs... sad to see.
| secondcoming wrote:
| 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.
| kmeisthax wrote:
| 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 wrote:
| 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).
| wmf wrote:
| It's all about guilt-tripping. This header tells you how many
| indulgences you need to buy.
| w_for_wumbo wrote:
| "The use of the "Carbon-Emissions-Scope-2" header field does not
| introduce any new security risks" - I think this is just
| incorrect.
|
| 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.
| paddw wrote:
| Shame on https://sentry.io
| quenix wrote:
| The author is not from sentry.io, but from "Sentry Software"
| (https://www.sentrysoftware.com/). They do not seem to be
| related.
| jameshart wrote:
| 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?
| hunter2_ wrote:
| > 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.
| jameshart wrote:
| More concerned that if I'm returning a precached response, I
| ought to be able to claim some sort of carbon credit :)
| iso1631 wrote:
| 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?
| [deleted]
| [deleted]
| bradfitz wrote:
| Is that before or after the extra CPU & network required for the
| new header? :)
| 6c696e7578 wrote:
| 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...
| foota wrote:
| 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!
| speedgoose wrote:
| 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?
| foota wrote:
| 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.
| eganist wrote:
| 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.
___________________________________________________________________
(page generated 2023-04-11 23:02 UTC)