Switch remaining functions from SchemeIsSecure() to SchemeIsCryptographic().

Switch remaining functions from SchemeIsSecure to SchemeIsCryptographic.

BUG=362214

[lgarron, 2015-04-24 19:08:02]

lgarron@chromium.org changed reviewers:
+ jww@chromium.org, palmer@chromium.org

[lgarron, 2015-04-24 19:08:03]

This CL is a complement to https://codereview.chromium.org/1099453005, which was
about IsOriginSecure for Fizzy code.

This CL is a manual `sed s/SchemeIsSecure/SchemeIsCryptographic/g` on the
remaining files. I looked carefully at each affected line, and I couldn't find
any that should obviously be using IsOriginSecure() instead, and
SchemeIsCryptographic() is safe because it preserves semantics.

However, there are a few use places I want to ask owners about, which I might
want to split into another CL that converts to IsOriginSecure() instead:

--------------------------------

Referrer: In several places (referrer_util.cc, referrer.cc, url_request_job.cc),
the code takes into account whether the navigation was from a secure scheme to
an insecure scheme, presumably to strip out some referrer information. I think
IsOriginSecure makes sense here instead, but I want to hear from an owner before
making that call.

--------------------------------

Password manager + sign-in: the feature behaves differently for HTTPS. Is there
value in extending this behaviour to localhost or chrome extensions? The former
might be useful for testing.

--------------------------------

signin_header_helper.cc::IsDriveOrigin seems to have an optimization to check if
the scheme is secure before checking if an origin equals
https://drive.google.com or https://docs.google.com . The check seems a bit
redundant if we don't expect the function to change.

--------------------------------

net_error_helper_core.cc has the following comment: // Don't use the correction
service for HTTPS (for privacy reasons).
Perhaps this should cover all privileged contexts?
(I think I also saw something similar related to the omnibox.)

--------------------------------

If anyone knows the appropriate owners, I'd appreciate if you CCed them. Else
I'll go find them myself later today. :-)

[lgarron, 2015-04-24 19:12:15]

Mike, do you know if referrer stripping should happen just from cryptographic
schemes to non-cryptographic ones, or from privileged contexts to non-privileged
ones?

[jww, 2015-04-24 19:23:21]

On 2015/04/24 19:12:15, lgarron wrote:
> Mike, do you know if referrer stripping should happen just from cryptographic
> schemes to non-cryptographic ones, or from privileged contexts to
non-privileged
> ones?

Mike should respond with a more definitive answer, but I'm pretty sure
IsSecureOrigin is the better bet for referrer.

[palmer, 2015-04-24 19:29:39]

Regarding Referer header checks, see sections 14.36, 15.1.2, and 15.1.3 in
http://tools.ietf.org/html/rfc2616.

"""The Referer field MUST NOT be sent if the Request-URI was obtained from a
source that does not have its own URI, such as input from the user keyboard."""

"""Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP
request if the referring page was transferred with a secure protocol."""

I am inclined to agree that we should also NOT send it when navigating from
private zones to public ones (e.g. localhost, file:, localdomain, et c.). That
*might* line up exactly with IsOriginSecure, now or in the future, but I
wouldn't bet on it staying that way. Probably Referer checking should have its
own logic (definitely making use of GURL::SchemeIsCryptographic, but also using
other stuff).

[palmer, 2015-04-24 19:55:10]

palmer@chromium.org changed reviewers:
+ markusheintz@chromium.org

[palmer, 2015-04-24 19:55:11]

markusheintz: Question for you on secure cookie semantics.

https://codereview.chromium.org/1101173004/diff/1/net/cookies/canonical_cooki...
File net/cookies/canonical_cookie.cc (right):

https://codereview.chromium.org/1101173004/diff/1/net/cookies/canonical_cooki...
net/cookies/canonical_cookie.cc:398: if (IsSecure() &&
!url.SchemeIsCryptographic())
This is a semantic change. It might be a change from the right semantics to the
wrong semantics (in which case we don't want to do it), or from the wrong
semantics to the right semantics (in which case this change fixes a bug
— possibly already filed, possibly not). "git blame" shows the owner of this
code is markusheintz; let's ask him.

[lgarron, 2015-04-24 20:22:41]

On 2015/04/24 at 19:55:11, palmer wrote:
> markusheintz: Question for you on secure cookie semantics.
> 
>
https://codereview.chromium.org/1101173004/diff/1/net/cookies/canonical_cooki...
> File net/cookies/canonical_cookie.cc (right):
> 
>
https://codereview.chromium.org/1101173004/diff/1/net/cookies/canonical_cooki...
> net/cookies/canonical_cookie.cc:398: if (IsSecure() &&
!url.SchemeIsCryptographic())
> This is a semantic change. It might be a change from the right semantics to
the wrong semantics (in which case we don't want to do it), or from the wrong
semantics to the right semantics (in which case this change fixes a bug
— possibly already filed, possibly not). "git blame" shows the owner of this
code is markusheintz; let's ask him.

Two CLs have been split out from this:

https://codereview.chromium.org/1098983003 Switch SchemeIsSecure to
SchemeIsCryptographic for referrer-related code
https://codereview.chromium.org/1108673002 Switch SchemeIsSecure to
SchemeIsCryptographic for password-manager-related code.

Note that net/base/sdch_manager.cc contained a single referrer-related line, and
three other lines. Only the one line has been split into 1098983003.

[lgarron, 2015-05-08 02:53:16]

This CL is now defunkt. See https://codereview.chromium.org/1136643004/