Single referrer for all savable resources from a given frame.

Single referrer for all savable resources from a given frame.

When gathering savable resources from the whole page, each resource
could have come from a different frame and therefore could have had a
different referrer associated with it - back then it made sense to send
a vector of referrers (potentially a different one for each savable
resource).  Now (after crrev.com/1308113008) we gather savable resources
per frame and therefore can simplify the IPCs and send only a single
referrer for the whole frame.

Note that for the main frame, the browser already knows the referrer ...

  render_frame_host_impl->frame_tree_node()
                        ->navigator()
                        ->GetController()
                        ->GetLastCommittedEntry()
                        ->GetReferrer()

... but this CL keeps communicating the referrer over IPC, because 1) it
covers all the frames and 2) the renderer seems like a simpler, single,
race-free, more authoratitative source of the referrer information.

This CL is to some extent a reply to a CR feedback at
crrev.com/1413103003/#msg6 that pointed out general undesirability of
sending over IPC a struct-of-vectors (as opposed to a
vector-of-structs).

This CL improves upon crrev.com/10387090 which introduced sending of
referrer information during save-page-as operation, but initially kept
sending only default, rather than actual referrers.

BUG=526786
Committed: https://crrev.com/f05b1f759c5c29e8a2cf22690477d1572a1d5fc1
Cr-Commit-Position: refs/heads/master@{#356990}

[Łukasz Anforowicz, 2015-10-28 22:16:14]

lukasza@chromium.org changed reviewers:
+ jochen@chromium.org

[Łukasz Anforowicz, 2015-10-28 22:16:15]

jochen@, could you please take a look?

[dcheng, 2015-10-29 00:04:21]

dcheng@chromium.org changed reviewers:
+ dcheng@chromium.org

[dcheng, 2015-10-29 00:04:21]

Hmm...

If someone is using referrer policy
(https://w3c.github.io/webappsec-referrer-policy/), would it be possible to have
different referrers for different resources on a page?

[Łukasz Anforowicz, 2015-10-29 02:33:15]

On 2015/10/29 00:04:21, dcheng wrote:
> Hmm...
> 
> If someone is using referrer policy
> (https://w3c.github.io/webappsec-referrer-policy/), would it be possible to
have
> different referrers for different resources on a page?

I read section 3 of the spec as saying that there is a single referrer policy
per frame / html document:

http://www.w3.org/TR/referrer-policy/#referrer-policy-states:

"Every global environment has a referrer policy which governs the referrer
information sent along with requests made for subresources, and for
navigations."


Additionally, the spec says that the referrer policy can only be delivered via
per-page / per-document mechanisms:

http://www.w3.org/TR/referrer-policy/#referrer-policy-delivery:

"[...] referrer policy is delivered in one of four ways:

1) Via the referrer Content Security Policy directive, delivered via the
Content-Security-Policy HTTP header. [CSP]
2) Via the referrer Content Security Policy directive, delivered via a <meta>
element [CSP]
3) Via a meta element with a name of referrer.
4) Implicitly, via inheritance."

[dcheng, 2015-10-29 03:15:42]

On 2015/10/29 at 02:33:15, lukasza wrote:
> On 2015/10/29 00:04:21, dcheng wrote:
> > Hmm...
> > 
> > If someone is using referrer policy
> > (https://w3c.github.io/webappsec-referrer-policy/), would it be possible to
have
> > different referrers for different resources on a page?
> 
> I read section 3 of the spec as saying that there is a single referrer policy
per frame / html document:
> 
> http://www.w3.org/TR/referrer-policy/#referrer-policy-states:
> 
> "Every global environment has a referrer policy which governs the referrer
information sent along with requests made for subresources, and for
navigations."
> 
> 
> Additionally, the spec says that the referrer policy can only be delivered via
per-page / per-document mechanisms:
> 
> http://www.w3.org/TR/referrer-policy/#referrer-policy-delivery:
> 
> "[...] referrer policy is delivered in one of four ways:
> 
> 1) Via the referrer Content Security Policy directive, delivered via the
Content-Security-Policy HTTP header. [CSP]
> 2) Via the referrer Content Security Policy directive, delivered via a <meta>
element [CSP]
> 3) Via a meta element with a name of referrer.
> 4) Implicitly, via inheritance."

The document has a single referer policy, but it seems like something like
https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-state-origin...
would cause the actual referer to differ between same-origin and cross-origin
subresource requests.

[Łukasz Anforowicz, 2015-10-29 03:25:38]

On 2015/10/29 03:15:42, dcheng wrote:
> On 2015/10/29 at 02:33:15, lukasza wrote:
> > On 2015/10/29 00:04:21, dcheng wrote:
> > > Hmm...
> > > 
> > > If someone is using referrer policy
> > > (https://w3c.github.io/webappsec-referrer-policy/), would it be possible
to
> have
> > > different referrers for different resources on a page?
> > 
> > I read section 3 of the spec as saying that there is a single referrer
policy
> per frame / html document:
> > 
> > http://www.w3.org/TR/referrer-policy/#referrer-policy-states:
> > 
> > "Every global environment has a referrer policy which governs the referrer
> information sent along with requests made for subresources, and for
> navigations."
> > 
> > 
> > Additionally, the spec says that the referrer policy can only be delivered
via
> per-page / per-document mechanisms:
> > 
> > http://www.w3.org/TR/referrer-policy/#referrer-policy-delivery:
> > 
> > "[...] referrer policy is delivered in one of four ways:
> > 
> > 1) Via the referrer Content Security Policy directive, delivered via the
> Content-Security-Policy HTTP header. [CSP]
> > 2) Via the referrer Content Security Policy directive, delivered via a
<meta>
> element [CSP]
> > 3) Via a meta element with a name of referrer.
> > 4) Implicitly, via inheritance."
> 
> The document has a single referer policy, but it seems like something like
>
https://w3c.github.io/webappsec-referrer-policy/#referrer-policy-state-origin...
> would cause the actual referer to differ between same-origin and cross-origin
> subresource requests.

Right - there is a single (referrer policy, referrer uri) pair per
document/frame, but as you point out this single pair can result in different
http referrer headers being sent in http requests (i.e. different for
same-origin and cross-origin resources).  Sending a single (referrer policy,
referrer url) pair per IPC from a given frame seems ok - when making the network
requests the browser will use this single pair to potentially generate different
referrers for individual network/http requests.

[jochen (gone - plz use gerrit), 2015-10-29 14:20:32]

lgtm

[Łukasz Anforowicz, 2015-10-29 14:45:02]

Daniel, could you please take a look for content/common/frame_messages.h?

[dcheng, 2015-10-29 21:02:26]

lgtm

[Łukasz Anforowicz, 2015-10-29 21:29:16]

The CQ bit was checked by lukasza@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2015-10-29 21:29:43]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1425013004/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1425013004/20001

[commit-bot: I haz the power, 2015-10-29 22:53:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2015-10-29 22:53:13]

Dry run: This issue passed the CQ dry run.

[Łukasz Anforowicz, 2015-10-29 23:53:27]

The CQ bit was checked by lukasza@chromium.org

[Łukasz Anforowicz, 2015-10-29 23:53:27]

The patchset sent to the CQ was uploaded after l-g-t-m from jochen@chromium.org
Link to the patchset: https://codereview.chromium.org/1425013004/#ps20001
(title: "Rebasing...")

[commit-bot: I haz the power, 2015-10-29 23:53:50]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1425013004/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1425013004/20001

[commit-bot: I haz the power, 2015-10-30 00:00:14]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2015-10-30 00:01:03]

Patchset 2 (id:??) landed as
https://crrev.com/f05b1f759c5c29e8a2cf22690477d1572a1d5fc1
Cr-Commit-Position: refs/heads/master@{#356990}