Remove Referrer Policy from URLFetcher.

Remove Referrer Policy from URLFetcher.

There were no consumers of this.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=267757

[mmenke, 2014-05-01 21:37:25]

LGTM!

https://codereview.chromium.org/268703003/diff/20001/net/url_request/url_fetc...
File net/url_request/url_fetcher_core.cc (right):

https://codereview.chromium.org/268703003/diff/20001/net/url_request/url_fetc...
net/url_request/url_fetcher_core.cc:514:
URLRequest::CLEAR_REFERRER_ON_TRANSITION_FROM_SECURE_TO_INSECURE);
Is this needed?  This is already the default (see URLRequest::Init)

[cbentzel, 2014-05-01 22:15:57]

https://codereview.chromium.org/268703003/diff/20001/net/url_request/url_fetc...
File net/url_request/url_fetcher_core.cc (right):

https://codereview.chromium.org/268703003/diff/20001/net/url_request/url_fetc...
net/url_request/url_fetcher_core.cc:514:
URLRequest::CLEAR_REFERRER_ON_TRANSITION_FROM_SECURE_TO_INSECURE);
On 2014/05/01 21:37:26, mmenke wrote:
> Is this needed?  This is already the default (see URLRequest::Init)

Done.

[cbentzel, 2014-05-02 00:37:44]

The CQ bit was checked by cbentzel@chromium.org

[commit-bot: I haz the power, 2014-05-02 00:38:57]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/cbentzel@chromium.org/268703003/40001

[commit-bot: I haz the power, 2014-05-02 05:30:17]

Change committed as 267757

[jochen (gone - plz use gerrit), 2014-05-02 05:36:40]

On 2014/05/02 05:30:17, I haz the power (commit-bot) wrote:
> Change committed as 267757

Hum, iOS depends on this afaik

[mmenke, 2014-05-02 05:50:31]

On 2014/05/02 05:36:40, jochen (OOO Wed-Thu) wrote:
> On 2014/05/02 05:30:17, I haz the power (commit-bot) wrote:
> > Change committed as 267757
> 
> Hum, iOS depends on this afaik

Ah, you're right, thanks for catching that!  and I signed off on that CL just a
couple months ago...

Sorry about that.

[jochen (gone - plz use gerrit), 2014-05-02 06:20:34]

+noyau, can you confirm?

[noyau (Ping after 24h), 2014-05-05 06:56:32]

On 2014/05/02 06:20:34, jochen wrote:
> +noyau, can you confirm?

I confirm, yes, iOS depends on this.

[noyau (Ping after 24h), 2014-05-05 07:13:56]

On 2014/05/05 06:56:32, noyau wrote:
> On 2014/05/02 06:20:34, jochen wrote:
> > +noyau, can you confirm?
> 
> I confirm, yes, iOS depends on this.

Also there is a CL in flight for Android that will also depend on this:
https://codereview.chromium.org/263563003/

Would it be possible to revert ASAP? There will be an iOS merge today, without a
revert this will introduce a privacy issue in iOS code as we would have to
remove the code setting the referrer policy.

[jochen (gone - plz use gerrit), 2014-05-05 07:20:18]

A revert of this CL has been created in
https://codereview.chromium.org/265253002/ by jochen@chromium.org.

The reason for reverting is: We still need this feature on ios and android.

[cbentzel, 2014-05-07 19:55:12]

On 2014/05/05 07:20:18, jochen wrote:
> A revert of this CL has been created in
> https://codereview.chromium.org/265253002/ by mailto:jochen@chromium.org.
> 
> The reason for reverting is: We still need this feature on ios and android.

OK, thanks.

That Android CL seems to only be setting the policy to the default policy which
doesn't seem too useful... But I can understand if there are iOS cases which use
this.

[noyau (Ping after 24h), 2014-05-09 08:20:23]

On 2014/05/07 19:55:12, cbentzel wrote:
> On 2014/05/05 07:20:18, jochen wrote:
> > A revert of this CL has been created in
> > https://codereview.chromium.org/265253002/ by mailto:jochen@chromium.org.
> > 
> > The reason for reverting is: We still need this feature on ios and android.
> 
> OK, thanks.
> 
> That Android CL seems to only be setting the policy to the default policy
which
> doesn't seem too useful... But I can understand if there are iOS cases which
use
> this.

iOS is "special": there is no webkit/blink API, this means that there is no way
to  access page content.

As an example, let's say the user wants to save an image visible on the page.
The only way to perform such an operation on iOS is to go through the DOM via
javascript, find the image URL and then re-download it. Hopefully hitting the
network cache instead of really re-downloading. This need to look at the page
policy, and apply it to the redownload, hence the need for this API.

Android doesn't have the same issues, as blink provides all the API necessary to
retrieve the image from the DOM.