Re: [webkit-dev] User Agent Client Hints

[Maciej Stachowiak]

> On Nov 2, 2020, at 8:56 AM, Yoav Weiss  wrote:
> 
> Thanks for re-reviewing, Maciej!
> 
> Adding Mike Taylor, who's likely to take a closer look at this.
> 
> On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak  > wrote:
> 
> I just did a fresh review of that spec and explainer. Thanks for addressing 
> many of the previous issues. This addresses many of the potential objections.
> 
> Here’s the new issues I filed:
> 
> https://github.com/WICG/ua-client-hints/issues/141 
> 
> https://github.com/WICG/ua-client-hints/issues/142 
> 
> https://github.com/WICG/ua-client-hints/issues/143 
> 
> https://github.com/WICG/ua-client-hints/issues/144 
> 
> https://github.com/WICG/ua-client-hints/issues/145 
> 
> https://github.com/WICG/ua-client-hints/issues/146 
> 
> https://github.com/WICG/ua-client-hints/issues/147 
> 
> https://github.com/WICG/ua-client-hints/issues/148 
> 
> https://github.com/WICG/ua-client-hints/issues/149 
> 
> https://github.com/WICG/ua-client-hints/issues/150 
> 
> https://github.com/WICG/ua-client-hints/issues/151 
> 
> 
> 
> Thanks for filing those! We'll take a look and respond shortly.
>  
> Most of these are minor/editorial, but I think 151 is potentially a 
> deal-breaker. I may be misreading the spec, but as written 
> getHighEntropyValues seems to give access to all of the high entropy client 
> hints to third-party scripts in the first party context, and scripts running 
> in third-party iframes, regardless of which ones the site has opted into via 
> the relevant HTTP header. 
> 
> That's indeed the case, as we didn't consider the Client Hints opt-in to be 
> something that impacts the availability of the JS API. (as it doesn't do that 
> for other hints)

We’re currently deeply skeptical of implementing any of the other client hints 
due to their expansion of fingerprinting surface, so I don’t feel particularly 
compelled by that precedent. That said, it’s likely the other client hints have 
this same problem, where they expose fingerprinting surface way more widely 
than they may be intending to.

> That would be a huge problem, as it would grant a lot of active 
> fingerprinting surface unnecessarily 
> 
> We did discuss 
>  
> adding a Feature Policy (now Permission Policy) to that effect. Would that 
> help with your concerns?

My understanding is that feature policy applies at the frame level, and 
therefore could not be used to control what happens when a third-party script 
in a first party context calls the API. Even for third-party iframes, it seems 
like Feature Policy could only default-deny this JS API entirely, and would not 
be able to filter the results down to the set delegated via HTTP headers (or 
otherwise). Maybe you intend a feature policy per individual high entropy hint, 
but first of all that seems like overkill, and second, the spec is clearly not 
written to support such filtering.

So no, it would not address the concerns.

I think the best approach is to limit the hints to those opted into (or, in 
case of a third-party frame, delegated). That or remove the script API 
entirely. The origin-based delegation model that works well at the HTTP level 
is not well aligned with the widespread practice of including third-party 
scripts in the top frame.

The spec does not eve allow denying the request entirely as written. A 
non-normative Note suggests that is allowed, but I can’t find any step in the 
algorithm that would ever reject the promise.

>  
> (perhaps even expanding beyond what is currently possible with the UA string).
> 
> Can you expand on that last point?

I mean that the client hints might include info that is not in the UA sting 
(possibly not at all, or possibly frozen in UA string but could be unfrozen in 
the client hints).

>  
> 
> Regards,
> Maciej
> 
> 
>> On Oct 27, 2020, at 12:35 AM, Yoav Weiss > > wrote:
>> 
>> Yet-another ping! :)
>> 
>> On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss > > wrote:
>> Friendly ping! :)
>> 
>> On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss > > wrote:
>> Hi WebKit folks,
>> 
>> Circling back on the previous discussion 
>>  about 
>> User-Agent ClientHint. The feature was implemented in Chromium and is being 
>> rolled out in 

Re: [webkit-dev] Embedding Identifiers in Commit Messages

[Ryosuke Niwa]

On Mon, Nov 2, 2020 at 2:04 PM Jonathan Bedard  wrote:
>
> We appreciate everyone’s feedback on transitioning away from Subversion to 
> Git, I’ll be releasing an expected timeline of up-coming changes in the next 
> week before the contributors meeting.
>
> In the mean time, we’re preparing on adding identifiers to new commit 
> messages, that work is tracked in 
> https://bugs.webkit.org/show_bug.cgi?id=218407. At the moment, we’re likely 
> going to be appending the identifiers to commit messages (as the current 
> change proposes), but I wanted to provide a chance for folks to object to 
> this change before it becomes canonical.

I'm a bit confused here. It looks like the patch only affects commits
made via webkit-patch. Given there are a lot of people who don't use
webkit-patch land, I'm not certain this strategy is sound even in the
short term. Furthermore, the proposed patch seems to have a race
condition when multiple commits are made concurrency? Why don't we do
this in post commit hook instead?

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Embedding Identifiers in Commit Messages

[Jonathan Bedard]

Hello WebKit contributors,

We appreciate everyone’s feedback on transitioning away from Subversion to Git, 
I’ll be releasing an expected timeline of up-coming changes in the next week 
before the contributors meeting.

In the mean time, we’re preparing on adding identifiers 
 to new commit messages, that 
work is tracked in https://bugs.webkit.org/show_bug.cgi?id=218407 
. At the moment, we’re likely 
going to be appending the identifiers to commit messages (as the current change 
proposes), but I wanted to provide a chance for folks to object to this change 
before it becomes canonical.

Our intention is also to edit history in the Git clone to embed these 
identifiers to historical commits, but there is some disagreement on that 
intention, and that task will be tracked separately.

Thanks,
Jonathan___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] User Agent Client Hints

[Yoav Weiss]

Thanks for re-reviewing, Maciej!

Adding Mike Taylor, who's likely to take a closer look at this.

On Mon, Nov 2, 2020 at 2:17 AM Maciej Stachowiak  wrote:

>
> I just did a fresh review of that spec and explainer. Thanks for
> addressing many of the previous issues. This addresses many of the
> potential objections.
>
> Here’s the new issues I filed:
>
> https://github.com/WICG/ua-client-hints/issues/141
> https://github.com/WICG/ua-client-hints/issues/142
> https://github.com/WICG/ua-client-hints/issues/143
> https://github.com/WICG/ua-client-hints/issues/144
> https://github.com/WICG/ua-client-hints/issues/145
> https://github.com/WICG/ua-client-hints/issues/146
> https://github.com/WICG/ua-client-hints/issues/147
> https://github.com/WICG/ua-client-hints/issues/148
> https://github.com/WICG/ua-client-hints/issues/149
> https://github.com/WICG/ua-client-hints/issues/150
> https://github.com/WICG/ua-client-hints/issues/151
>
>
Thanks for filing those! We'll take a look and respond shortly.


> Most of these are minor/editorial, but I think 151 is potentially a
> deal-breaker. I may be misreading the spec, but as written
> getHighEntropyValues seems to give access to all of the high entropy client
> hints to third-party scripts in the first party context, and scripts
> running in third-party iframes, regardless of which ones the site has opted
> into via the relevant HTTP header.
>

That's indeed the case, as we didn't consider the Client Hints opt-in to be
something that impacts the availability of the JS API. (as it doesn't do
that for other hints)

That would be a huge problem, as it would grant a lot of active
> fingerprinting surface unnecessarily
>

We did discuss

adding
a Feature Policy (now Permission Policy) to that effect. Would that help
with your concerns?


> (perhaps even expanding beyond what is currently possible with the UA
> string).
>

Can you expand on that last point?


>
> Regards,
> Maciej
>
>
> On Oct 27, 2020, at 12:35 AM, Yoav Weiss  wrote:
>
> Yet-another ping! :)
>
> On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss  wrote:
>
>> Friendly ping! :)
>>
>> On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss  wrote:
>>
>>> Hi WebKit folks,
>>>
>>> Circling back on the previous discussion
>>> 
>>> about User-Agent ClientHint. The feature was implemented in Chromium and is
>>> being rolled out in Chrome.
>>>
>>> There were some concerns mentioned in the previous thread, that we
>>> believe were since addressed. Would the feature be something that WebKit
>>> would consider shipping?
>>>
>>> Cheers :)
>>> Yoav
>>>
>> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev