Position on User-Agent Client Hints

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Position on User-Agent Client Hints

Yoav Weiss
Hey WebKit folks,

I'd like to ask for your official position on the User Agent Client Hints specification.

[hidden email] has been providing great feedback on the proposal, as well as to the underlying Client Hints Infrastructure (in its former iterations), which helped shape those proposals, but that obviously doesn't count as endorsement.

There's an intent to ship for the feature over at blink-dev, and your position would be appreciated as input into that process.

Thanks :)
Yoav



_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: Position on User-Agent Client Hints

Michael Catanzaro-2
My personal $0.02: I'm mildly supportive of this spec. It's certainly
an improvement on existing HTTP user agent headers. I appreciate that
you worked to incorporate feedback into the spec and considered the
concerns of small browsers.

Is it going to solve all the problems caused by user agent headers? No.
If WebKit implements the spec, we're surely going to eventually need a
quirks list for user agent client hints to decide which websites to lie
to, just like we already have quirks for the user agent header. And as
long as Chrome sends a user agent header that includes the string
"Chrome", it's unlikely we'll be able to get rid of the existing quirks
list. But I think client hints will probably reduce the amount of
websites that *accidentally* break WebKit, by replacing wild west UA
header parsing with well-defined APIs, and adding some GREASE for good
measure. The promise of freezing Chrome's UA header sounds nice, as it
makes quirks easier to maintain. And being able to ration entropy by
revealing details about the platform on an active rather than passive
basis is quite appealing.

The spec attracted some misplaced concern about negative impact to
small browsers, which I've rebutted in [1]. I'm not quite so
enthusiastic about this spec as I was initially, especially after I was
convinced that the GREASE is never going to be enough to remove our
quirks list, but it's certainly not going to *hurt* small browsers.

This spec has received some pretty harsh criticism from the user
tracking industry (some call it the "ad industry"). Not historically a
friend of WebKit, so sounds good to me. ;)

One concern I haven't mentioned elsewhere is that frozen UA header
might encourage deeper levels of fingerprinting than are currently
used, e.g. for ad fraud prevention. caddy has started blocking
WebKitGTK users based on TLS handshake fingerprint (yes, really!) [1].
If techniques like that take off as a result of this, that could
potentially backfire on us quite badly. But websites could choose to do
such things today anyway, client hints or no, and if so, the solution
will be for us to just try even harder to look more like Chrome.

Seems like a net positive overall. I don't work for Apple and can't say
whether it might be implemented by WebKit.

Michael

[1]
https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002
[2] https://mitm.watch/


_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: Position on User-Agent Client Hints

Haelwenn (lanodan) Monnier
[2020-05-07 18:22:10-0500] Michael Catanzaro:

> My personal $0.02: I'm mildly supportive of this spec. It's certainly
> an improvement on existing HTTP user agent headers. I appreciate that
> you worked to incorporate feedback into the spec and considered the
> concerns of small browsers.
>
> Is it going to solve all the problems caused by user agent headers? No.
> If WebKit implements the spec, we're surely going to eventually need a
> quirks list for user agent client hints to decide which websites to lie
> to, just like we already have quirks for the user agent header. And as
> long as Chrome sends a user agent header that includes the string
> "Chrome", it's unlikely we'll be able to get rid of the existing quirks
> list. But I think client hints will probably reduce the amount of
> websites that *accidentally* break WebKit, by replacing wild west UA
> header parsing with well-defined APIs, and adding some GREASE for good
> measure. The promise of freezing Chrome's UA header sounds nice, as it
> makes quirks easier to maintain. And being able to ration entropy by
> revealing details about the platform on an active rather than passive
> basis is quite appealing.
>
> The spec attracted some misplaced concern about negative impact to
> small browsers, which I've rebutted in [1]. I'm not quite so
> enthusiastic about this spec as I was initially, especially after I was
> convinced that the GREASE is never going to be enough to remove our
> quirks list, but it's certainly not going to *hurt* small browsers.
>
> This spec has received some pretty harsh criticism from the user
> tracking industry (some call it the "ad industry"). Not historically a
> friend of WebKit, so sounds good to me. ;)
>
> One concern I haven't mentioned elsewhere is that frozen UA header
> might encourage deeper levels of fingerprinting than are currently
> used, e.g. for ad fraud prevention. caddy has started blocking
> WebKitGTK users based on TLS handshake fingerprint (yes, really!) [2].
> If techniques like that take off as a result of this, that could
> potentially backfire on us quite badly. But websites could choose to do
> such things today anyway, client hints or no, and if so, the solution
> will be for us to just try even harder to look more like Chrome.
>
> Seems like a net positive overall. I don't work for Apple and can't say
> whether it might be implemented by WebKit.
>
> Michael
>
> [1]
> https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002
> [2] https://mitm.watch/

This particular thing is bullshit, it's not even using the TLS handshake.
Copying the curl options is enough and what made me notice it that
glib-networking with OpenSSL (non-default) has the message.

Screenshot showing a simple curl vs. a curl with webkit-gtk's options:
https://queer.hacktivis.me/media/5d9122fd-64c4-43de-ba02-776b162c106e/screen.png

Most aggressive fingerprinting done currently is done with JavaScript
or CSS, having yet another few lines to get the Client Hints isn't
going to change much things for them.
Sure, it makes it a bit harder for some small advertisers that wouldn't
do much fingerprinting but do not forget that Google is probably the
biggest one and with a very large toolset.
_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: Position on User-Agent Client Hints

Maciej Stachowiak
In reply to this post by Michael Catanzaro-2

I would consider myself mildly positive as to the direction, but that’s my personal view for the moment, absent consultation with my colleagues. I will solicit more viewpoints.

I particularly appreciate the responsiveness to feedback and that Yoav in particular has been willing to iterate.

I think there’s a number of things in the spec that should be cleaned up before an implementation ships enabled by default, specifically around interop, privacy, and protection against UA lockouts. I know there are PRs in flight for some of these issues. I think it would be good to get more of the open issues to resolution before actually shipping this.

Regards,
Maciej

> On May 7, 2020, at 4:22 PM, Michael Catanzaro <[hidden email]> wrote:
>
> My personal $0.02: I'm mildly supportive of this spec. It's certainly an improvement on existing HTTP user agent headers. I appreciate that you worked to incorporate feedback into the spec and considered the concerns of small browsers.
>
> Is it going to solve all the problems caused by user agent headers? No. If WebKit implements the spec, we're surely going to eventually need a quirks list for user agent client hints to decide which websites to lie to, just like we already have quirks for the user agent header. And as long as Chrome sends a user agent header that includes the string "Chrome", it's unlikely we'll be able to get rid of the existing quirks list. But I think client hints will probably reduce the amount of websites that *accidentally* break WebKit, by replacing wild west UA header parsing with well-defined APIs, and adding some GREASE for good measure. The promise of freezing Chrome's UA header sounds nice, as it makes quirks easier to maintain. And being able to ration entropy by revealing details about the platform on an active rather than passive basis is quite appealing.
>
> The spec attracted some misplaced concern about negative impact to small browsers, which I've rebutted in [1]. I'm not quite so enthusiastic about this spec as I was initially, especially after I was convinced that the GREASE is never going to be enough to remove our quirks list, but it's certainly not going to *hurt* small browsers.
>
> This spec has received some pretty harsh criticism from the user tracking industry (some call it the "ad industry"). Not historically a friend of WebKit, so sounds good to me. ;)
>
> One concern I haven't mentioned elsewhere is that frozen UA header might encourage deeper levels of fingerprinting than are currently used, e.g. for ad fraud prevention. caddy has started blocking WebKitGTK users based on TLS handshake fingerprint (yes, really!) [1]. If techniques like that take off as a result of this, that could potentially backfire on us quite badly. But websites could choose to do such things today anyway, client hints or no, and if so, the solution will be for us to just try even harder to look more like Chrome.
>
> Seems like a net positive overall. I don't work for Apple and can't say whether it might be implemented by WebKit.
>
> Michael
>
> [1] https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002
> [2] https://mitm.watch/
>
>
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: Position on User-Agent Client Hints

Maciej Stachowiak
Accidentally removed Yoav from Cc and I’m not sure if he is on this list.

> On May 8, 2020, at 12:04 AM, Maciej Stachowiak <[hidden email]> wrote:
>
>
> I would consider myself mildly positive as to the direction, but that’s my personal view for the moment, absent consultation with my colleagues. I will solicit more viewpoints.
>
> I particularly appreciate the responsiveness to feedback and that Yoav in particular has been willing to iterate.
>
> I think there’s a number of things in the spec that should be cleaned up before an implementation ships enabled by default, specifically around interop, privacy, and protection against UA lockouts. I know there are PRs in flight for some of these issues. I think it would be good to get more of the open issues to resolution before actually shipping this.
>
> Regards,
> Maciej
>
>> On May 7, 2020, at 4:22 PM, Michael Catanzaro <[hidden email]> wrote:
>>
>> My personal $0.02: I'm mildly supportive of this spec. It's certainly an improvement on existing HTTP user agent headers. I appreciate that you worked to incorporate feedback into the spec and considered the concerns of small browsers.
>>
>> Is it going to solve all the problems caused by user agent headers? No. If WebKit implements the spec, we're surely going to eventually need a quirks list for user agent client hints to decide which websites to lie to, just like we already have quirks for the user agent header. And as long as Chrome sends a user agent header that includes the string "Chrome", it's unlikely we'll be able to get rid of the existing quirks list. But I think client hints will probably reduce the amount of websites that *accidentally* break WebKit, by replacing wild west UA header parsing with well-defined APIs, and adding some GREASE for good measure. The promise of freezing Chrome's UA header sounds nice, as it makes quirks easier to maintain. And being able to ration entropy by revealing details about the platform on an active rather than passive basis is quite appealing.
>>
>> The spec attracted some misplaced concern about negative impact to small browsers, which I've rebutted in [1]. I'm not quite so enthusiastic about this spec as I was initially, especially after I was convinced that the GREASE is never going to be enough to remove our quirks list, but it's certainly not going to *hurt* small browsers.
>>
>> This spec has received some pretty harsh criticism from the user tracking industry (some call it the "ad industry"). Not historically a friend of WebKit, so sounds good to me. ;)
>>
>> One concern I haven't mentioned elsewhere is that frozen UA header might encourage deeper levels of fingerprinting than are currently used, e.g. for ad fraud prevention. caddy has started blocking WebKitGTK users based on TLS handshake fingerprint (yes, really!) [1]. If techniques like that take off as a result of this, that could potentially backfire on us quite badly. But websites could choose to do such things today anyway, client hints or no, and if so, the solution will be for us to just try even harder to look more like Chrome.
>>
>> Seems like a net positive overall. I don't work for Apple and can't say whether it might be implemented by WebKit.
>>
>> Michael
>>
>> [1] https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002
>> [2] https://mitm.watch/
>>
>>
>> _______________________________________________
>> webkit-dev mailing list
>> [hidden email]
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: Position on User-Agent Client Hints

Alex Christensen-2
Last I recall talking about this, we did not oppose to client hits header fields in general, just some specific ones that expose information we do not wish to expose to reduce fingerprinting information.  For example, I think we do oppose adding Device-Memory because that currently cannot be queried through WebKit any other way, but I don’t think we oppose adding Viewport-Width which is trivial to query with 100% accuracy once you have JavaScript on the client.  I think Downlink and RTT were in a grey area because they can indeed be measured other ways, but we don’t want to possibly increase the fingerprinting information by providing values that can be used for more effective client fingerprinting, such as if we were to send the exact same value to multiple servers.

I don’t think this is an official position, just what I recall from TPAC discussions in Lyon.

> On May 8, 2020, at 12:14 AM, Maciej Stachowiak <[hidden email]> wrote:
>
> Accidentally removed Yoav from Cc and I’m not sure if he is on this list.
>
>> On May 8, 2020, at 12:04 AM, Maciej Stachowiak <[hidden email]> wrote:
>>
>>
>> I would consider myself mildly positive as to the direction, but that’s my personal view for the moment, absent consultation with my colleagues. I will solicit more viewpoints.
>>
>> I particularly appreciate the responsiveness to feedback and that Yoav in particular has been willing to iterate.
>>
>> I think there’s a number of things in the spec that should be cleaned up before an implementation ships enabled by default, specifically around interop, privacy, and protection against UA lockouts. I know there are PRs in flight for some of these issues. I think it would be good to get more of the open issues to resolution before actually shipping this.
>>
>> Regards,
>> Maciej
>>
>>> On May 7, 2020, at 4:22 PM, Michael Catanzaro <[hidden email]> wrote:
>>>
>>> My personal $0.02: I'm mildly supportive of this spec. It's certainly an improvement on existing HTTP user agent headers. I appreciate that you worked to incorporate feedback into the spec and considered the concerns of small browsers.
>>>
>>> Is it going to solve all the problems caused by user agent headers? No. If WebKit implements the spec, we're surely going to eventually need a quirks list for user agent client hints to decide which websites to lie to, just like we already have quirks for the user agent header. And as long as Chrome sends a user agent header that includes the string "Chrome", it's unlikely we'll be able to get rid of the existing quirks list. But I think client hints will probably reduce the amount of websites that *accidentally* break WebKit, by replacing wild west UA header parsing with well-defined APIs, and adding some GREASE for good measure. The promise of freezing Chrome's UA header sounds nice, as it makes quirks easier to maintain. And being able to ration entropy by revealing details about the platform on an active rather than passive basis is quite appealing.
>>>
>>> The spec attracted some misplaced concern about negative impact to small browsers, which I've rebutted in [1]. I'm not quite so enthusiastic about this spec as I was initially, especially after I was convinced that the GREASE is never going to be enough to remove our quirks list, but it's certainly not going to *hurt* small browsers.
>>>
>>> This spec has received some pretty harsh criticism from the user tracking industry (some call it the "ad industry"). Not historically a friend of WebKit, so sounds good to me. ;)
>>>
>>> One concern I haven't mentioned elsewhere is that frozen UA header might encourage deeper levels of fingerprinting than are currently used, e.g. for ad fraud prevention. caddy has started blocking WebKitGTK users based on TLS handshake fingerprint (yes, really!) [1]. If techniques like that take off as a result of this, that could potentially backfire on us quite badly. But websites could choose to do such things today anyway, client hints or no, and if so, the solution will be for us to just try even harder to look more like Chrome.
>>>
>>> Seems like a net positive overall. I don't work for Apple and can't say whether it might be implemented by WebKit.
>>>
>>> Michael
>>>
>>> [1] https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002
>>> [2] https://mitm.watch/
>>>
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> [hidden email]
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>> _______________________________________________
>> webkit-dev mailing list
>> [hidden email]
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev
Reply | Threaded
Open this post in threaded view
|

Re: Position on User-Agent Client Hints

Yoav Weiss


On Fri, May 8, 2020 at 6:01 PM Alex Christensen <[hidden email]> wrote:
Last I recall talking about this, we did not oppose to client hits header fields in general, just some specific ones that expose information we do not wish to expose to reduce fingerprinting information.  For example, I think we do oppose adding Device-Memory because that currently cannot be queried through WebKit any other way, but I don’t think we oppose adding Viewport-Width which is trivial to query with 100% accuracy once you have JavaScript on the client.  I think Downlink and RTT were in a grey area because they can indeed be measured other ways, but we don’t want to possibly increase the fingerprinting information by providing values that can be used for more effective client fingerprinting, such as if we were to send the exact same value to multiple servers.

I don’t think this is an official position, just what I recall from TPAC discussions in Lyon.

Thanks! Just noting that this request is about User-Agent Client Hints in particular.
 

> On May 8, 2020, at 12:14 AM, Maciej Stachowiak <[hidden email]> wrote:
>
> Accidentally removed Yoav from Cc and I’m not sure if he is on this list.

I'm still subscribed :D
 
>
>> On May 8, 2020, at 12:04 AM, Maciej Stachowiak <[hidden email]> wrote:
>>
>>
>> I would consider myself mildly positive as to the direction, but that’s my personal view for the moment, absent consultation with my colleagues. I will solicit more viewpoints.
>>
>> I particularly appreciate the responsiveness to feedback and that Yoav in particular has been willing to iterate.

Thank you! :)
 
>>
>> I think there’s a number of things in the spec that should be cleaned up before an implementation ships enabled by default, specifically around interop, privacy, and protection against UA lockouts. I know there are PRs in flight for some of these issues. I think it would be good to get more of the open issues to resolution before actually shipping this.

Regarding the discussion around `architecture`, my thinking is that we could either reach a conclusion there before shipping, or ship with that value currently empty and "fill it" once we reach agreement on what it should be.

Regarding the GREASE discussion, I don't think it's blocking, as Chromium's initial implementation will include GREASE: The UA will be a list of values, will include a non-value that would encourage standard Structured Header parsing, and will have the list order randomized (but remain stable for the lifetime of the major version, the avoid caching churn).
With that said, your arguments about making this a MUST make sense, and I'll send a PR to that effect.

The other issues seem to be either around future enhancement (which we could add later), or general discussions that don't seem blocking.

>>
>> Regards,
>> Maciej
>>
>>> On May 7, 2020, at 4:22 PM, Michael Catanzaro <[hidden email]> wrote:
>>>
>>> My personal $0.02: I'm mildly supportive of this spec. It's certainly an improvement on existing HTTP user agent headers. I appreciate that you worked to incorporate feedback into the spec and considered the concerns of small browsers.
>>>
>>> Is it going to solve all the problems caused by user agent headers? No. If WebKit implements the spec, we're surely going to eventually need a quirks list for user agent client hints to decide which websites to lie to, just like we already have quirks for the user agent header. And as long as Chrome sends a user agent header that includes the string "Chrome", it's unlikely we'll be able to get rid of the existing quirks list. But I think client hints will probably reduce the amount of websites that *accidentally* break WebKit, by replacing wild west UA header parsing with well-defined APIs, and adding some GREASE for good measure. The promise of freezing Chrome's UA header sounds nice, as it makes quirks easier to maintain. And being able to ration entropy by revealing details about the platform on an active rather than passive basis is quite appealing.
>>>
>>> The spec attracted some misplaced concern about negative impact to small browsers, which I've rebutted in [1]. I'm not quite so enthusiastic about this spec as I was initially, especially after I was convinced that the GREASE is never going to be enough to remove our quirks list, but it's certainly not going to *hurt* small browsers.
>>>
>>> This spec has received some pretty harsh criticism from the user tracking industry (some call it the "ad industry"). Not historically a friend of WebKit, so sounds good to me. ;)
>>>
>>> One concern I haven't mentioned elsewhere is that frozen UA header might encourage deeper levels of fingerprinting than are currently used, e.g. for ad fraud prevention. caddy has started blocking WebKitGTK users based on TLS handshake fingerprint (yes, really!) [1]. If techniques like that take off as a result of this, that could potentially backfire on us quite badly. But websites could choose to do such things today anyway, client hints or no, and if so, the solution will be for us to just try even harder to look more like Chrome.
>>>
>>> Seems like a net positive overall. I don't work for Apple and can't say whether it might be implemented by WebKit.
>>>
>>> Michael
>>>
>>> [1] https://github.com/w3ctag/design-reviews/issues/467#issuecomment-583104002
>>> [2] https://mitm.watch/
>>>
>>>
>>> _______________________________________________
>>> webkit-dev mailing list
>>> [hidden email]
>>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>> _______________________________________________
>> webkit-dev mailing list
>> [hidden email]
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> [hidden email]
> https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
[hidden email]
https://lists.webkit.org/mailman/listinfo/webkit-dev