[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] User Agent Client Hints
From: Yoav Weiss <yoav () yoav ! ws>
Date: 2020-11-03 20:11:31
Message-ID: CACj=BEjM3NWxh_+g55cTueAEA1Zz-k-1DK86_COcihhnVwLVeA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Nov 3, 2020 at 8:03 PM Alex Christensen <achristensen@apple.com>
wrote:
> If I understand this correctly, the state of having received an Accept-CH
> header field in a response to a previous request is used to determine
> whether these new Sec-CH-* header fields will be sent. Not only does this
> add a new place to store bits on the client (as acknowledged by
> https://wicg.github.io/client-hints-infrastructure/#accept-ch-cache-definition )
> but it also seems to not provide a method for a server to receive client
> hint header fields on the first request from a client. Would both of these
> concerns be resolved if we used something like ALPN instead of needing to
> store state on the client?
>
+David Benjamin <davidben@chromium.org>'s Client Hints reliability proposal
and its ALPS part
<https://github.com/WICG/client-hints-infrastructure/blob/master/reliability.md#application-layer-protocol-settings>
are
planned to tackle something very similar to your ALPN proposal.
FWIW, the Accept-CH cache can only be set by HTTP response headers on the
top-level document, and are cleared whenever client state (e.g. cookies)
are cleared. So while it is another place to store state, it doesn't
outlive current same-origin client-side storage.
Am I understanding the Client Hints Infrastructure correctly?
>
> On Nov 2, 2020, at 3:32 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
>
>
> On Nov 2, 2020, at 8:56 AM, Yoav Weiss <yoav@yoav.ws> 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 <mjs@apple.com> 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
> <https://github.com/WICG/ua-client-hints/issues/37#issuecomment-576730548> 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 <yoav@yoav.ws> wrote:
> >
> > Yet-another ping! :)
> >
> > On Wed, Oct 7, 2020 at 8:23 AM Yoav Weiss <yoav@yoav.ws> wrote:
> >
> > > Friendly ping! :)
> > >
> > > On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss <yoav@yoav.ws> wrote:
> > >
> > > > Hi WebKit folks,
> > > >
> > > > Circling back on the previous discussion
> > > > <https://lists.webkit.org/pipermail/webkit-dev/2020-May/031195.html> 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
>
>
>
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Tue, Nov 3, 2020 at 8:03 PM Alex Christensen <<a \
href="mailto:achristensen@apple.com">achristensen@apple.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
style="overflow-wrap: break-word;">If I understand this correctly, the state of \
having received an Accept-CH header field in a response to a previous request is used \
to determine whether these new Sec-CH-* header fields will be sent. Not only does \
this add a new place to store bits on the client (as acknowledged by <a \
href="https://wicg.github.io/client-hints-infrastructure/#accept-ch-cache-definition" \
target="_blank">https://wicg.github.io/client-hints-infrastructure/#accept-ch-cache-definition</a> \
) but it also seems to not provide a method for a server to receive client hint \
header fields on the first request from a client. Would both of these concerns be \
resolved if we used something like ALPN instead of needing to store state on the \
client? </div></blockquote><div><br></div><div><a class="gmail_plusreply" \
id="plusReplyChip-0" href="mailto:davidben@chromium.org" tabindex="-1">+David \
Benjamin</a>'s <a \
href="https://github.com/WICG/client-hints-infrastructure/blob/master/reliability.md#application-layer-protocol-settings">Client \
Hints reliability proposal and its ALPS part</a> are planned to tackle something \
very similar to your ALPN proposal.</div><div><br></div><div>FWIW, the Accept-CH \
cache can only be set by HTTP response headers on the top-level document, and are \
cleared whenever client state (e.g. cookies) are cleared. So while it is another \
place to store state, it doesn't outlive current same-origin client-side \
storage.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
style="overflow-wrap: break-word;"> Am I understanding the Client Hints \
Infrastructure correctly?<br><div><br><blockquote type="cite"><div>On Nov 2, 2020, at \
3:32 PM, Maciej Stachowiak <<a href="mailto:mjs@apple.com" \
target="_blank">mjs@apple.com</a>> wrote:</div><br><div><div \
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal \
;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transf \
orm:none;white-space:normal;word-spacing:0px;text-decoration:none"><br><br><blockquote \
type="cite"><div>On Nov 2, 2020, at 8:56 AM, Yoav Weiss <<a \
href="mailto:yoav@yoav.ws" target="_blank">yoav@yoav.ws</a>> \
wrote:</div><br><div><div dir="ltr" \
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal \
;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div \
dir="ltr"><div>Thanks for re-reviewing, Maciej!<br></div><div><br></div><div>Adding \
Mike Taylor, who's likely to take a closer look at this.</div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 2, 2020 at 2:17 AM \
Maciej Stachowiak <<a href="mailto:mjs@apple.com" \
target="_blank">mjs@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><div><br></div>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.<div><br></div><div>Here's the new issues \
I filed:<br><div><br></div><div><a rel="nofollow" \
href="https://github.com/WICG/ua-client-hints/issues/141" \
style="box-sizing:border-box;color:rgb(3,102,214);text-decoration:none;font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px" \
target="_blank">https://github.com/WICG/ua-client-hints/issues/141</a><br \
style="box-sizing:border-box;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px"><a rel="nofollow" \
href="https://github.com/WICG/ua-client-hints/issues/142" \
style="box-sizing:border-box;color:rgb(3,102,214);text-decoration:none;font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px" \
target="_blank">https://github.com/WICG/ua-client-hints/issues/142</a><br \
style="box-sizing:border-box;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px"><a rel="nofollow" \
href="https://github.com/WICG/ua-client-hints/issues/143" \
style="box-sizing:border-box;color:rgb(3,102,214);text-decoration:none;font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px" \
target="_blank">https://github.com/WICG/ua-client-hints/issues/143</a><br \
style="box-sizing:border-box;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px"><a rel="nofollow" \
href="https://github.com/WICG/ua-client-hints/issues/144" \
style="box-sizing:border-box;color:rgb(3,102,214);text-decoration:none;font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px" \
target="_blank">https://github.com/WICG/ua-client-hints/issues/144</a><br \
style="box-sizing:border-box;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px"><a rel="nofollow" \
href="https://github.com/WICG/ua-client-hints/issues/145" \
style="box-sizing:border-box;color:rgb(3,102,214);text-decoration:none;font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px" \
target="_blank">https://github.com/WICG/ua-client-hints/issues/145</a><br \
style="box-sizing:border-box;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px"><a rel="nofollow" \
href="https://github.com/WICG/ua-client-hints/issues/146" \
style="box-sizing:border-box;color:rgb(3,102,214);text-decoration:none;font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px" \
target="_blank">https://github.com/WICG/ua-client-hints/issues/146</a><br \
style="box-sizing:border-box;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px"><a rel="nofollow" \
href="https://github.com/WICG/ua-client-hints/issues/147" \
style="box-sizing:border-box;color:rgb(3,102,214);text-decoration:none;font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px" \
target="_blank">https://github.com/WICG/ua-client-hints/issues/147</a><br \
style="box-sizing:border-box;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px"><a rel="nofollow" \
href="https://github.com/WICG/ua-client-hints/issues/148" \
style="box-sizing:border-box;color:rgb(3,102,214);text-decoration:none;font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px" \
target="_blank">https://github.com/WICG/ua-client-hints/issues/148</a><br \
style="box-sizing:border-box;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px"><a rel="nofollow" \
href="https://github.com/WICG/ua-client-hints/issues/149" \
style="box-sizing:border-box;color:rgb(3,102,214);text-decoration:none;font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px" \
target="_blank">https://github.com/WICG/ua-client-hints/issues/149</a><br \
style="box-sizing:border-box;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px"><a rel="nofollow" \
href="https://github.com/WICG/ua-client-hints/issues/150" \
style="box-sizing:border-box;color:rgb(3,102,214);text-decoration:none;font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px" \
target="_blank">https://github.com/WICG/ua-client-hints/issues/150</a><br \
style="box-sizing:border-box;color:rgb(36,41,46);font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px"><a rel="nofollow" \
href="https://github.com/WICG/ua-client-hints/issues/151" \
style="box-sizing:border-box;color:rgb(3,102,214);text-decoration:none;font-family:-apple-system,BlinkMacSystemFont,"Segoe \
UI",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI \
Emoji";font-size:14px" \
target="_blank">https://github.com/WICG/ua-client-hints/issues/151</a><br><div><br></div></div></div></div></blockquote><div><br></div><div>Thanks \
for filing those! We'll take a look and respond shortly.</div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"><div><div><div><div><div>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.<span> \
</span></div></div></div></div></div></blockquote><div><br></div><div>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)</div></div></div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div><div dir="ltr" \
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal \
;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div \
class="gmail_quote"><div></div><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><div><div><div><div>That would be a huge \
problem, as it would grant a lot of active fingerprinting surface unnecessarily<span> \
</span></div></div></div></div></div></blockquote><div><br></div><div>We did<span> \
</span><a href="https://github.com/WICG/ua-client-hints/issues/37#issuecomment-576730548" \
target="_blank">discuss</a> adding a Feature Policy (now Permission Policy) to that \
effect. Would that help with your \
concerns?</div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>So no, it would not address the \
concerns.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div><div dir="ltr" \
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal \
;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div \
class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><div><div><div><div>(perhaps even expanding \
beyond what is currently possible with the UA \
string).</div></div></div></div></div></blockquote><div><br></div><div>Can you expand \
on that last point?</div></div></div></div></blockquote><div><br></div><div>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).</div><br><blockquote type="cite"><div><div dir="ltr" \
style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal \
;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div \
class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><div><div><div><div><br></div><div>Regards,</div><div>Maciej</div><div><br></div><div><br><blockquote \
type="cite"><div>On Oct 27, 2020, at 12:35 AM, Yoav Weiss <<a \
href="mailto:yoav@yoav.ws" target="_blank">yoav@yoav.ws</a>> \
wrote:</div><br><div><div dir="ltr">Yet-another ping! :)</div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 7, 2020 at 8:23 AM \
Yoav Weiss <<a href="mailto:yoav@yoav.ws" target="_blank">yoav@yoav.ws</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
dir="ltr">Friendly ping! :)</div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Wed, Sep 30, 2020 at 9:29 AM Yoav Weiss <<a \
href="mailto:yoav@yoav.ws" target="_blank">yoav@yoav.ws</a>> \
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic