Re: [webkit-dev] Question: referrerpolicy in Safari

[Dominic Farolino]

On Wed, Sep 23, 2020 at 12:16 PM Maud Nalpas  wrote:

> Hi,
>
> I'm reaching out for a question about Referrer-Policy, more specifically
> about *element**-level* referrer policies (referrerpolicy=...)
> 
> .
>
> I would expect referrerpolicy on HTML elements to override a page's
> policy for the corresponding request.
>
> But this is not what I'm observing on Safari iOS (12) and Desktop (13,
> with "Prevent cross site tracking" on). And this diverges from Chrome's and
> Firefox's behaviour, which seem to honor referrerpolicy on elements.
>
> It's very possible that I'm mistaken and/or that my test site is wrong --
> your input would help!
>

I haven't dug too deep here, but just going to post this in case it answers
your question and saves you some time. As documented here
,
it appears that Safari is starting to not honor the `referrerpolicy`
attribute on HTML elements where it would override the referrer policy
redaction that their cross-site tracking work has performed, or at least in
cases where it would expose more information than what was intended by the
cross-site tracking protection. That may be an oversimplification, (I trust
someone from WebKit can clarify), but it may explain the behavior you are
seeing.

>
> Test
>
> Test site
> 
>
> A policy can be selected in the blue button bar. To test referrerpolicy,
> the useful section is "Let's test element-based referrerpolicy" at the
> bottom of the page.
>
> Examples of unexpected behaviour (can be reproduced on the test site)
>
> 1. On https://site-one.example/path/foo with a document-level policy of
> strict-origin-when-cross-origin:
>
>-
>
>An  element with referrerpolicy=no-referrer-when-downgrade links to
>https://site-two.example (href).
>-
>
>Upon clicking the link and navigating to site-two, site-two gets the
>origin as a Referer in the request (Referer=https://site-one.example).
>-
>
>I would expect Referer=https://site-one.example/path/foo instead (and
>this is the behaviour in Chrome and Firefox).
>
> 2. On https://site-one.example/path/foo with a document-level policy of
> no-referrer:
>
>-
>
>An  element with referrerpolicy=strict-origin-when-cross-origin
>loads an image from *https://site-two.example
>* (src).
>-
>
>site-two gets the full URL in this image request (Referer=
>https://site-one.example/path/foo).
>-
>
>I would expect Referer=https://site-one.example instead (and this is
>the behaviour in Chrome and Firefox).
>
> 3. On https://site-one.example/path/foo with an document-level policy of
> no-referrer-when-downgrade:
>
> A *referrerpolicy* on a 

[webkit-dev] Lazy loading

[Dominic Farolino]

*Maciej wrote:*

- I couldn’t find a spec for a lazy loading feature policy either, and the
Chrome Platform Status page for it gives the status as “removed”[2] so this
too might be a nonstandard thing. Or maybe there is a newer  (Doesn’t look
like the feature policy aspect is in your patch though.)

I hope I am not being too nitpicky. I do think this is a great feature. I
just want to make sure we’re cautious about the line between implementing
standards-track stuff vs copying things from Chromium that are nonstandard
or unspecified (so far).

It’s also really worrisome if Chrome implemented semantics for the
“loading” attribute beyond what is in the PR, as that will make interop a
challenge.

Regards, Maciej


Just to circle back to this, the current spec PR does not include the
"auto" attribute, so there is no need for any Feature/Document policies to
control the default image- or frame-loading. The `loading` attribute has
two values "lazy" and "eager", and the missing/invalid-value default is
"eager".

Long-term, Chrome is interested in exploring making the default
"lazy". However, we're thinking a good intermediate step is in the future,
add "auto" back to the spec and introduce a Document or Feature Policy that
allows developers to specify that "auto" == "lazy". Then over time, we may
consider simply making the default "lazy". There has been
discussion/proposals for image- and frame-policies [1] [2]. There has not
been many updates to the proposals, so I am not sure how reliable the
current text is. Furthermore, there is a tracking issue for Chrome [3]
which covers some implementation discussion for these policies, however it
too seems stalled.

FYI Chrome currently ships the "auto" attribute, but it is treated as
"eager" unless the user has opted into Lite mode, as Thomas mentioned.

[1]:
https://github.com/w3c/webappsec-feature-policy/blob/master/policies/loading-image-default-eager.md
[2]:
https://github.com/w3c/webappsec-feature-policy/blob/master/policies/loading-frame-default-eager.md
[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=949683
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev