Re: Introduction and internet draft proposal for HTTP response 420 Requester Impaired

Yes, to both points as the answer to #2 will tie into the answer to #1: the server will need a way to "redeem" itself if it gets a 420.  I suppose this will require some trust between the server and the client.  I will have to think about this one.  Something along the lines of a server assertion of "I've been reset" or "I'm OK now" with a security consideration that such a response must come from outside of the AI.  If the AI could create the response, it could simply send it and go on its merry way causing havoc.
________________________________
From: Rory Hewitt <rory.hewitt@gmail.com>
Sent: Monday, December 11, 2023 12:03 PM
To: Richard Roda <richard_roda@hotmail.com>
Cc: ietf-http-wg@w3.org <ietf-http-wg@w3.org>
Subject: Re: Introduction and internet draft proposal for HTTP response 420 Requester Impaired

Hey Richard,

First off, I like this idea!

I have some concerns that it might be seen as an April Fool's joke (as was its original genesis!) such that people won't take it seriously.

A couple of questions:

1. From a purely technical POV, how does this differ from 400 Bad Request, which is currently used for this sort of thing - clearly it's up to the server to make the decision that the client is 'impaired' rather than just sending an invalid request, but how does it do that? Different servers might consider different sorts of requests as invalid based on the request content ("Does this sound like the request someone who's stoned out of their gourd might make?") but that's a per-server decision, so we have a lack of standardization.

2. I assume that the point of this is to signal to the client that it is not making sense, and should maybe stop asking questions until it's no longer impaired. But in Section 4 (Security Considerations) you say "If the impaired requesters are identifiable because they have been authenticated, their requests SHOULD be denied until they have been determined not to be impaired.". How would a server determine that a client is no longer impaired unless it starts accepting requests from it again, to gauge its impairment (or lack thereof)?

Rory

On Mon, Dec 11, 2023 at 4:00 AM Richard Roda <richard_roda@hotmail.com<mailto:richard_roda@hotmail.com>> wrote:
My name is Richard Roda.  I am a Sr. Developer at USANA<https://www.usana.com/ux/dotcom/enu-US/home>.  I have been developing using HTTP long enough to remember transitioning from 1.0 to 1.1.  My most relevant vendor certification is Security+ ce<https://www.credly.com/badges/931df564-c412-4bca-bef5-f75e3a49c106/linked_in_profile>.  My details may be found on my LinkedIn page<https://www.linkedin.com/in/richardroda/>.  I am proposing an HTTP status code for 420 as a Requester Impaired code.  The original idea for this was an April Fool's RFC.  420 is an available client error response code, and the number 420 is associated with marijuana use.   However, as I was writing and drafting it occurred to me that this is a legitimate need.  With AI systems being given more operational autonomy and the fact that Large Language Models (LLMs) can "hallucinate" responses, non-human as well as human requesters can be impaired.  If impaired requestors are attached to something like remote-operated heavy equipment the results could be catastrophic.  Dedicating an HTTP response code to this will allow for better visibility and remediation of impaired requesters.

Any feedback on this would be appreciated.  I am also on the #httpbiz stream on Zulip.  I might not respond immediately to messages because of my day job.

https://datatracker.ietf.org/doc/draft-richardroda-420requesterimpaired/

An HTTP Status Code to Report Requester Impairment<https://datatracker.ietf.org/doc/draft-richardroda-420requesterimpaired/>
This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when an operation or resource is denied due to requester impairment.
datatracker.ietf.org<http://datatracker.ietf.org>




--
Rory Hewitt

https://www.linkedin.com/in/roryhewitt