[webkit-dev] Request for position on First-Party Sets

[Lily Chen]

Hi WebKit-dev,

We are requesting WebKit's position on the First-Party Sets proposal as
described in the explainer [1]. Feedback [2] was provided on a previous
version of the proposal, which has since been revised. The TAG review
thread is here [3].

Thanks!

[1] Explainer: https://github.com/krgovind/first-party-sets
[2] Previous feedback: https://github.com/krgovind/first-party-sets/issues/6
[3] TAG review: https://github.com/w3ctag/design-reviews/issues/342
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Position on emerging standard: HTMLLinkElement "disabled" attribute behavior

[Mason Freed]

Hi WebKit,

I would like to request an official WebKit position on the changes to the
HTMLLinkElement "disabled" attribute behavior, as discussed here:
https://github.com/whatwg/html/issues/3840. The interop situation here is
not great, so it would be good to align on a single spec. I would like to
ship the behavior specified in https://github.com/whatwg/html/pull/4519 in
Chromium, and Gecko already ships this behavior.

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

Re: [webkit-dev] Request for position on First-Party Sets

[Maciej Stachowiak]

(1) I notice that this proposal still exists only in a random personal repo. 
Could it please be contributed to an appropriate standards or incubation group? 
Privacy CG would almost certainly welcome this, and I’m sure it would be easy 
to move to WICG as well. There doesn’t seem to be a reason to keep the proposal 
in this “pre-incubation” state.

(2) As discussed in the Privacy CG Face-to-Face, there are two key problems to 
solve with First Party Sets or any similar proposals:
(a) Bad faith claims. How to prevent domains that are not actually 
owned and controlled by the same party from making claims of being related? For 
example, an ad network could get its top publishers to enter an association to 
regain a certain level of tracking powers.
(b) The “500 domains” problem. If a first party owns domains that 
aren’t obviously related and that appear to different and distinct brands to 
the user, then the user won’t expect to be tracked across them. (Problem named 
such because of a party known to have hundreds of domains that mostly appear to 
be totally distinct brands). Users would expect both transparency and control 
over this.

The explainer does not really give solutions to these problems. Rather, it 
defers entirely to each individual browser to define a policy to solve these 
problems. Deferring to individual browsers on such key points is problematic in 
a few ways:
(i) It doesn’t seem right for a proposed web standard to solve only the 
easy problem of syntax, and leave the hardest technical problems of semantics 
to each browser separately.
(ii) Deferring in this way is bad for interop.
(iii) It’s not entirely clear if there exists any policy that suitably 
addresses these problems. By only speculating about policies, the explainer 
fails to provide an existence proof that it is implementable.
(iv) If sites come to depend on First Party Sets for correct behavior, 
there is a risk that every UA will have to adopt a policy that’s the most 
permissive of any, or that copies the most popular UA, for the sake of 
compatibility. Thus, leaving this open may not in fact provide a useful degree 
of freedom.

Given these issues, I don’t think we’d implement the proposal in its current 
state. That said, we’re very interested in this area, and indeed, John Wilander 
proposed a form of this idea before Mike West’s later re-proposal. If these 
issues were addressed in a satisfactory way, I think we’d be very interested. 
It does seem that binding strictly to eTLD+1 is not good enough for web privacy 
features. Driving these issues to resolution is part of why we’d like to see 
this proposal adopted into a suitable standards or incubation group.

Regards,
Maciej


> On May 27, 2020, at 9:33 AM, Lily Chen  wrote:
> 
> Hi WebKit-dev,
> 
> We are requesting WebKit's position on the First-Party Sets proposal as 
> described in the explainer [1]. Feedback [2] was provided on a previous 
> version of the proposal, which has since been revised. The TAG review thread 
> is here [3].
> 
> Thanks!
> 
> [1] Explainer: https://github.com/krgovind/first-party-sets 
> 
> [2] Previous feedback: https://github.com/krgovind/first-party-sets/issues/6 
> 
> [3] TAG review: https://github.com/w3ctag/design-reviews/issues/342 
> 
> ___
> 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

Re: [webkit-dev] Suggesting to enable paint timing by default

[Yoav Weiss]

+Ryosuke Niwa  +Alex Christensen  who
were involved in the spec discussions.

On Wed, May 27, 2020 at 10:29 AM Noam Rosenthal  wrote:

>
>
> Following up on this.
>
>> FOn Tue, May 12, 2020 at 10:28 AM Maciej Stachowiak 
>> wrote:
>>
>>>
>>>
>>> On May 11, 2020, at 9:53 PM, Noam Rosenthal  wrote:
>>>
>>>
>>>
>>> On Tue, May 12, 2020 at 1:36 AM Maciej Stachowiak  wrote:
>>>

 I noticed from comments in one of the Radars that the patch may result
 in an additional “fake paint”, so it should probably be performance tested.
 Have you done any testing?

>>> I've tested it locally, I haven't noticed any significant side effect,
>>> because in complex situations the fake paint only happens once per page and
>>> bails early once contentfulness is detected. but I can run any additional
>>> test needed.
>>>
>>>
 We’ll likely want to A/B some of Apple’s page load speed benchmarks.

>>> A/B testing load speed sounds sensible. How do we go about doing that?
>>>
>>>
>>> Unfortunately our page load speed benchmarks are not public because they
>>> incorporate captured page content, which we can’t freely redistribute.
>>>
>>> So, can someone else from Apple review that the code is mature enough
> for this? Simon had reviewed the original patch. Maybe Zalan/Darin?
>
> A helpful person from Apple may be able to set up an A/B test for this
>>> patch.
>>>
>> What's required to ask for help from a helpful person at Apple? :)
> ___
> 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

Re: [webkit-dev] Suggesting to enable paint timing by default

[Noam Rosenthal]

Following up on this.

> FOn Tue, May 12, 2020 at 10:28 AM Maciej Stachowiak  wrote:
>
>>
>>
>> On May 11, 2020, at 9:53 PM, Noam Rosenthal  wrote:
>>
>>
>>
>> On Tue, May 12, 2020 at 1:36 AM Maciej Stachowiak  wrote:
>>
>>>
>>> I noticed from comments in one of the Radars that the patch may result
>>> in an additional “fake paint”, so it should probably be performance tested.
>>> Have you done any testing?
>>>
>> I've tested it locally, I haven't noticed any significant side effect,
>> because in complex situations the fake paint only happens once per page and
>> bails early once contentfulness is detected. but I can run any additional
>> test needed.
>>
>>
>>> We’ll likely want to A/B some of Apple’s page load speed benchmarks.
>>>
>> A/B testing load speed sounds sensible. How do we go about doing that?
>>
>>
>> Unfortunately our page load speed benchmarks are not public because they
>> incorporate captured page content, which we can’t freely redistribute.
>>
>> So, can someone else from Apple review that the code is mature enough for
this? Simon had reviewed the original patch. Maybe Zalan/Darin?

A helpful person from Apple may be able to set up an A/B test for this
>> patch.
>>
> What's required to ask for help from a helpful person at Apple? :)
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev