Re: [webkit-dev] Feedback on Blink's text fragment directive proposal

[Maciej Stachowiak]

> On Oct 30, 2020, at 1:40 PM, David Bokan  wrote:
> 
> Hi Ryosuke,
> 
> Would just like to clarify one point.
> 
> On Fri, Sep 25, 2020 at 12:42 PM David Bokan  > wrote:
> [Sorry, meant to reply-all]
> 
> On Fri, Sep 25, 2020 at 1:25 AM Ryosuke Niwa  > wrote:
> 
> On Thu, Sep 24, 2020 at 8:19 AM David Bokan  > wrote:
> Can you clarify what question you’re looking to have answered? Are you asking 
> for a new standards position in light of the replies below?
> 
>  There are two specific points:
> 
>  - As I understand it, HTML requires multi-vendor interest to merge changes 
> to specs. Is Apple's position sufficient to start that process? I'd be happy 
> to start turning the spec into PRs but I interpreted the earlier position in 
> this thread more as "not-opposed" rather than support (is that a fair 
> reading?)
> 
> Given we're concerned about compatibility and this affects how URL, which is 
> a pretty fundamental part of the Web, is interpreted, it's fair to say we're 
> not ready to endorse such a motion.
> 
> The change we've proposed and implemented in Chrome doesn't touch anything in 
> the URL spec or handling; it's entirely an extension to fragment processing 
> in HTML documents only. If this were implemented in WebKit and Gecko I think 
> that'd address any compat issues? If you don't agree, could you clarify what 
> you see as the main compat risk?

It looks like the current spec does not affect URL per se, but does have this 
remark re the fragment directive: "It is reserved for UA instructions, such as 
text=, and is stripped from the URL during loading so that author scripts can’t 
directly interact with it.” 
>

The is not specified precisely enough for interop. What does it mean to strop 
the fragment directive from the UR? When during loading does this occur?

Section 3.3.1 is more specific 
>
 in that it monkeypatches the HTML create and initialize a Document object 
steps in a way that would affect what JavaScript sees.  However, it’s not clear 
what happens to other ways the UA exposes the URL, such as in the location 
field, or if the page is bookmarked or shared.

Regards,
Maciej

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

Re: [webkit-dev] User Agent Client Hints

[Maciej Stachowiak]

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 


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 would be a huge problem, as it would grant a lot of active fingerprinting 
surface unnecessarily (perhaps even expanding beyond what is currently possible 
with the UA string).

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