Client hint reliability for requests with side effects, and under deployment constraints

[untitaker]

Hi, I'm currently looking into implementing Client Hints for Sentry.io. Sentry has a POST endpoint that is used to submit crash reports and other debugging data. We need the Platform-Version to make crash reports more useful (and potentially throw them out if they stem from a too old os).

Our submission endpoint has side effects, so it's not possible to use the Accept-CH/Critical-CH headers to make the client send Platform-Version. So patching our TLS stack it is (haven't looked into what that would take). Okay.

For most of the deployment scenarios we have, patching the TLS stack probably works. However, we cannot actually go with that solution for two reasons:

• Sometimes it's not the browser client who is sending User-Agent in the first place. If a Sentry user instruments the backend, and the app crashes due to a http request, we still extract the User-Agent header from the HTTP requests and attach this data to the crash report.

  There we have neither control over any response headers such as Critical-CH (which is a non-option for anything but GET requests anyway), nor do we control the TLS stack of the backend app that is instrumented by Sentry.

  Yes, in such situations, knowing the os version is still potentially useful.

• People are self-hosting Sentry. Sentry does not terminate TLS, it runs behind any http reverse proxy.

What do you suggest we do in such situations?

The first thing that comes to mind would be to allow defining "critical hints" in JS code running in the browser before the network is being hit.

[arichiv]

When you say 'defining critical hints' in JS code, are you saying you want a way for the per-origin client hints cache to be updated for any future requests or just requests from the page the JS ran in?

[untitaker]

@arichiv in the case of sentry we would be interested in requesting critical client hints for future requests going to sentry.io independently of the origin of the document itself. I am not sure about whether it makes sense to store this permission for the sentry.io origin though rather than the document's origin, that's just where the HTTP requests go.

[Sora2455]

This sounds like something Origin Policy would have been good at if it hadn't stalled in the spec phase.

[arichiv]

If the document is integrating sentry by including some script, could the setup steps include an ask to include the following tag: <meta http-equiv="delegate-ch" value="Sec-CH-UA-Platform-Version https://sentry.io/"> That would cause the inclusion of Platform-Version in all requests from that document to sentry.io/.

[untitaker]

That's much better than what I thought was the status quo, but ideally it would be possible to drive this from JS code. My understanding of the client hint spec is that the user agent is free to implement a permission prompt for high-entropy values, and we wouldn't want to unconditionally "ask for permission" on pageload.

[Sora2455]

Does the meta tag have to be present during page load, or could a JS script add it?

[arichiv]

Unfortunately it must be present on page load. We don't permit JavaScript to inject the tag as we want to be sure the first party is in control/aware.

[Sora2455]

That's fair. Could Sentry then require that this tag be used alongside their JS script @untitaker?

[untitaker]

I think being able to request critical client hints (being sent as headers) from JS would still be nice but it's probably not going to be a real blocker for us

[untitaker]

BTW what I actually could get to work was this:

<meta name="accept-ch" content="Sec-CH-UA-Platform-Version=(https://sentry.io/)">

the example by @arichiv did nothing in chrome

[arichiv]

Sorry, that syntax is launching in M105, what you're using is the older one (still supported in M105).