Add a section about CSS and referrers (#5) #68

jeisinger · 2016-09-22T12:11:20Z

jeisinger · 2016-09-22T15:26:40Z

index.src.html

+  Implementations should keep track of a referrer policy for each stylesheet
+  that should be used to create requests for resources from the respective
+  stylesheet. The referrer policy should be inherited from the entity that
+  triggered the load of the stylesheet, i.e., a document, or another


@annevk pointed out that gecko uses the stylesheet's URL as referrer. I'd argue that the main point should be that the policy comes from the same place as the referrer. So if the stylesheet is the referrer, then the only way to get the referrer policy was via the referrer policy header.

In that argument, if there was no Referrer-Policy header served with the stylesheet, is the referrer policy the default? Or does it fall back to the document's policy?

Oh, now I see @domenic's comment outlining the different possibilities. Hmm.

domenic

This is all very interesting. We should have similar discussions for <script> possibly. Although right now <script> does not have a referrerpolicy="" attribute.

There are several scenarios here, restricting ourselves to aligning referrer and referrer policy sources.

Document has referrer policy documentRP and URL documentURL; <style> contents do some fetches (e.g. @import or background-image())
- Probably those fetches should use documentURL referrer and documentRP referrer policy
<link rel="stylesheet" href="linkHref" referrerpolicy="linkRP"> and the fetched stylesheet has no Referrer-Policy header
- (A): inside fetches use documentURL referrer and documentRP referrer policy
- (B): inside fetches use linkHref referrer and linkRP referrer policy
<link rel="stylesheet" href="linkHref" referrerpolicy="linkRP"> and the fetched stylesheet has a Referrer-Policy header with valid value headerRP
- (A): inside fetches use documentURL referrer and documentRP referrer policy
- (B): inside fetches use linkHref referrer and linkRP referrer policy
- (C): inside fetches use linkHref referrer and headerRP referrer policy

This is basically about the extent to which we want to say that stylesheet resources have their own referrer/referrer policy information, independently configurable (C), or whether it should only be affected by the root request's referrerpolicy="" (B), or whether all fetches should just use the referrer and referrer policy based on the original document (A).

domenic · 2016-09-22T18:11:08Z

index.src.html

+<section class="informative">
+  <h2 id="integration-with-css">Integration with CSS</h2>
+
+  <em>This section is not normative.</em>


I think the intention is more like, "This section is normative but we want it to go away when CSS gets its act together and specifies all this more precisely."

domenic · 2016-09-22T18:11:24Z

index.src.html

+
+  The CSS Standard does not specify how it fetches resources referenced from
+  stylesheets. However, implementations use the URL a given stylesheet was
+  loaded from as referrer for the requests for resources form that stylesheet.


s/form/from

estark37 · 2016-09-23T04:51:38Z

index.src.html

+  `<code>Referrer-Policy</code>` header, the header's policy should take
+  precedence.
+
+  Both, the value of the referrer and the value of the referrer policy should be


unnecessary comma after "Both"

(I don't think I'm using this new github code review thing right)

estark37 · 2016-09-23T05:36:20Z

Ugh, <script> is a can of worms, I think. Suppose we say that, for example, requests initiated by a stylesheet use the stylesheet URL as the referrer and the stylesheet's Referrer-Policy header for the policy. I'm guessing we don't want <script>s to behave the same way, right? i.e. we wouldn't want to use the script URL as the referrer for requests that the script initiates, we'd use the document URL, which means we'd want to use the document referrer policy and not the Referrer-Policy header served with the script. It sucks that stylesheets and requests they initiate behave differently than scripts and requests they initiate.

FWIW I really like the simplicity of "always use the document/worker URL as the referrer and the document/worker's referrer policy, unless overridden for an individual request by a referrerpolicy attribute". But I guess it just doesn't make sense to use the document's referrer policy for stylesheets if the referrer is the stylesheet URL.

jeisinger · 2016-09-23T10:20:31Z

ok, next attempt.

jeisinger · 2016-09-23T10:25:33Z

btw, I think even if we add a referrerpolicy attribute to at some point in the future, that referrer policy shouldn't influence the referrer policy for loading resources from that stylesheet.

domenic · 2016-09-23T13:31:55Z

index.src.html

+  referrer policy.
+
+  Both the value of the referrer and the value of the referrer policy should be
+  captured at the time a given request is created.


Is this really the intention? Or is it at the time the stylesheet is created?

I think this only matters for inline style sheets where the containing document's referrer policy can change over time as meta elements are added/removed.

This is also when we capture the base URI which is used to resolve relative URLs, and yes, it should only matter for inline stylesheets.

domenic · 2016-09-23T13:32:17Z

index.src.html

+
+  For external stylesheets, the referrer policy should be
+  <a>"<code>no-referrer-when-downgrade</code>"</a> unless overwritten by an
+  `<code>Referrer-Policy</code>` header.


Maybe explicitly state that the referrerpolicy attribute on link should not impact fetches from inside the stylesheet.

annevk

The other thing I was wondering about is what happens for style="" attributes. I guess those just pick up whatever is current for the document or do they also snapshot?

annevk · 2016-09-26T07:23:36Z

index.src.html

+  stylesheets. However, implementations use the URL a given stylesheet was
+  loaded from as referrer for the requests for resources from that stylesheet.
+
+  Implementations should keep track of a referrer policy for each stylesheet


RFC2119 terms like "should" are reserved for normative requirements. We should keep them out of notes.

I removed the "style=informative" from the entire section, since it's normative until CSS got its stuff figured out.

annevk · 2016-09-26T07:23:46Z

index.src.html

+  loaded from as referrer for the requests for resources from that stylesheet.
+
+  Implementations should keep track of a referrer policy for each stylesheet
+  that should be used to create requests for resources from the respective


annevk · 2016-09-26T07:23:52Z

index.src.html

+  that should be used to create requests for resources from the respective
+  stylesheet. 
+
+  For external stylesheets, the referrer policy should be


annevk · 2016-09-26T07:24:23Z

index.src.html

+  requests for resources referenced from the stylesheet.
+
+  For inline stylesheets, the referrer policy is the containing {{Document}}'s
+  referrer policy.


Maybe it's best to say here when it's captured? Or merge the next paragraph into this one.

merged the paragraphs

jeisinger · 2016-09-28T16:03:12Z

style="" should be handled like inline stylesheets (i.e. captured at parse time). Should I explicitly add that?

annevk · 2016-09-28T16:35:31Z

Yeah, I think mentioning style="" would be good, since it doesn't end up in document.styleSheets so folks might expect it to work differently.

jeisinger · 2016-09-29T06:57:07Z

done, ptal

annevk · 2016-09-29T06:58:40Z

Looks reasonable to me now. Also paging @tabatkins since he said he might work on this at some point in CSS at which point we could remove this again.

bzbarsky · 2016-11-02T14:45:18Z

index.src.html

+  <h2 id="integration-with-css">Integration with CSS</h2>
+
+  The CSS Standard does not specify how it fetches resources referenced from
+  stylesheets. However, implementations use the URL a given stylesheet was


Is this section informative or normative? Because if this is meant to be normative, then "the URL a given stylesheet was loaded from" needs to be defined much more clearly than it is now. If this is meant to be informative, the text is still confusing, of course...

It's meant to be normative.

For e.g. Document's, we use "the document's URL" as referrer, without specifying this further. Would saying something like "the stylesheet's URL" address your concerns?

we use "the document's URL" as referrer, without specifying this further.

No. You use "the document's URL" with the "URL" bit being a link to the explicit definition of that term in the spec that defines it, and which can then be used to figure out what that URL actually is in any given circumstance.

Would saying something like "the stylesheet's URL" address your concerns?

Not without a clear definition, either inline or via link to the relevant spec that does define it.

fwiw, the definition "document's URL" points to says "each document is associated with [...] an URL".

Yes, and the spec that definition is in, plus other specs that might manipulate document URLs, defines what that URL is for each Document object. For example, the very next paragraph says:

Unless stated otherwise ... URL is "about:blank"

So in practice, an implementor has a field called "URL" on document objects. When a document is created, set the field to "about:blank". When some spec says to change the document's URL, change it accordingly. For example, https://html.spec.whatwg.org/multipage/browsers.html#set-the-document%27s-address does this during navigation. https://html.spec.whatwg.org/multipage/browsers.html#dom-history-pushstate step 10 does this when pushState or replaceState is called. That sort of thing.

Then when some spec says to use the document's URL, use the value of that field. Everything is clearly defined, no ambiguity.

yeah, i'm just whining a bit about the absence of all of this from CSS.

Oh, I agree the CSS situation is rather sucky. Can we just get @zcorpan or @tabatkins to just fix it already? :(

If not, we could probably define it as https://drafts.csswg.org/cssom/#concept-css-style-sheet-location unless that's null or our load is not coming from a stylesheet, in which case it's the owner node's node document's URL (those would all be links to the relevant definitions) or the element's node document's URL, for inline stylesheets and style attributes respectively. And then we hope the CSS situation gets resolved sanely before there's a way to create stylesheets that have neither a location or an owner node...

(And I'm not even going to think about what happens if we ever get nontrivial ways to animate url values in CSS, for example taking part of the URL from one stylesheet and part from another. Let's just assume people won't do that without thinking about the consequences.)

bzbarsky · 2016-11-02T14:47:50Z

index.src.html

+  For inline stylesheets, and styles applied via an <code>style</code>
+  attribute on an element, the referrer policy is the containing {{Document}}'s
+  referrer policy.  Both the value of the referrer and the value of the
+  referrer policy should be captured at the time a given request is created.


So not at stylesheet parse time, right?

What is expected to happen for directly-constructed stylesheets that are then filled with rules, once CSSOM supports that?

What is expected to happen if a single stylesheet (inline, or directly constructed) is attached to multiple documents?

There's only one request for a sub-resource, even if it's used from multiple documents, so I'd say that whatever needs the resource first triggers the creation of the request, and therefore provides the referrer & referrer policy

There's only one request for a sub-resource, even if it's used from multiple documents

That may or may not be true.

For example, when a node is adopted into a different document, resources it links to via its "style" attribute may be refetched. Or they may not. It's not like the CSS specs say. Of course in the multiple-requests situation things are easy: just use the relevant document for each request.

It's the single-request case that's hard. Say you have a stylesheet created via new CSSStyleSheet() that is being shared across two documents (can't do that yet, but people want to add it). You insert an @import rule into this stylesheet; this starts the load of the child sheet. What referrer should be used in this situation? What referrer policy?

That's really a question for the people speccing cross-document sheet sharing, in some sense, but it would be good to have specific issues about this filed on the relevant specs so it doesn't just fall through the cracks and we end up having to pick up the incompatible pieces later.

bzbarsky · 2016-11-02T14:48:59Z

index.src.html

+  declared <{link/referrerpolicy}>, this referrer policy will not affect the
+  requests for resources referenced from the stylesheet.
+
+  For inline stylesheets, and styles applied via an <code>style</code>


Oh, and s/an/a/ before "style".

bzbarsky · 2016-11-02T14:50:48Z

And of course the future-looking CSSOM bits would best be dealt with by the CSS/CSSOM specs...

Add a section about CSS and referrers (w3c#5)

63ba9cb

jeisinger commented Sep 22, 2016

View reviewed changes

domenic reviewed Sep 22, 2016

View reviewed changes

estark37 reviewed Sep 23, 2016

View reviewed changes

annevk mentioned this pull request Sep 23, 2016

Define how CSS interacts with spec for the sake of defining how referrers should be handled #5

Closed

updates

6b29036

domenic approved these changes Sep 23, 2016

View reviewed changes

add text about link/referrerpolicy

0807137

annevk reviewed Sep 26, 2016

View reviewed changes

Address Anne's comments

234e2c8

also mention style attributes

c0fe8c6

estark37 merged commit f33451d into w3c:master Oct 3, 2016

bzbarsky reviewed Nov 2, 2016

View reviewed changes

Add a section about CSS and referrers (#5) #68

Add a section about CSS and referrers (#5) #68

Conversation

jeisinger commented Sep 22, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

estark37 commented Sep 23, 2016

jeisinger commented Sep 23, 2016

jeisinger commented Sep 23, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

annevk Sep 26, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jeisinger commented Sep 28, 2016

annevk commented Sep 28, 2016

jeisinger commented Sep 29, 2016

annevk commented Sep 29, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bzbarsky commented Nov 2, 2016

annevk Sep 26, 2016 •

edited

Loading