Re: New Version Notification for draft-kazuho-httpbis-selftrace-00.txt

On Sat, Aug 14, 2021 at 8:24 PM Kazuho Oku <kazuhooku@gmail.com> wrote:

>
>
>> 3) Relatedly, your POC seems to assume the browser will have just a
>> single connection and a trace request in a second tab will auto map to that
>> connection.
>>
>     That works fine for the POC, but for a real deployment that lets
>> end-users fetch traces, you'd need built-in browser/client support to
>> select a specific connection / fetch traces for all connections to a given
>> origin.
>>      Not a big problem ofc, and things like Chrome's netlog export
>> already do this, but still a practical hurdle.
>>
>
> Right. I would hope that it would be possible to implement this as a
> browser extension at least (with the assumption being that requests from a
> browser extension would be coalesced with other requests going to the same
> authority).
>

Unfortunately, browsers do not guarantee this property, and past efforts in
the IETF to standardize features that assume this property (e.g. Token
Binding) or in other SDOs (e.g. ETSI’s unfortunate design with regards to
QWACs) end up not working in practice.

This is especially true as browsers look to segment connections even
further, in relation to privacy properties unique to browser environments
(e.g. CORS credentialless, as further expanded by COEP, or the fetch()
specifications Network Partition Keys, or security isolation primitives to
restrict extension access).

I don’t have much stake in this, other than flagging that any design that
makes assumptions about connection properties to bits on screen are,
generally, flawed assumptions. That’s not to preclude the possibility of
direct browser integrations, should it prove useful and of demonstrable
value to merit such implementation, although past efforts have failed to
achieve that value relative to the complexities of such coupling.