New issue
Advanced search Search tips

Issue 845179 link

Starred by 10 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , iOS , Chrome , Mac , Fuchsia
Pri: 3
Type: Feature



Sign in to add a comment

Chrome browser has no option to disable or upgrade non-secure requests

Reported by narma...@playform.com, May 21 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36

Steps to reproduce the problem:
1. Open any http site
2. site is opened fine

What is the expected behavior?
I need option "Allow only HTTPS sites", may be temporary switched off by default

What went wrong?
i cant test sites for https only mode

Did this work before? N/A 

Chrome version: 66.0.3359.181  Channel: stable
OS Version: 10.0
Flash Version:
 

Comment 1 by tsepez@chromium.org, May 21 2018

Cc: tsepez@chromium.org palmer@google.com
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam -Via-Wizard-Security Type-Feature
Owner: est...@chromium.org
Status: Assigned (was: Unconfirmed)
Summary: Chrome browser has no option to disable non-https sites (was: Chrome brawser have no options for disable non-https sites)
This is a feature request, and not a security bug per-se. Removing restrictions.

Having said that, this is something we've considered in the past, but we may wish to re-evaluate.

Comment 2 by tsepez@chromium.org, May 21 2018

Components: Blink>SecurityFeature

Comment 3 by est...@chromium.org, May 21 2018

Labels: Needs-Feedback
OP, can you please clarify what you mean by "cant test sites for https only mode"?

Comment 4 by palmer@chromium.org, May 24 2018

Components: -Blink>SecurityFeature Security UI
Labels: -Pri-2 -Arch-x86_64 Team-Security-UX Security Hotlist-GoodFirstBug OS-Android OS-Chrome OS-Fuchsia OS-iOS OS-Linux OS-Mac Pri-3
Summary: Chrome browser has no option to disable or upgrade non-secure requests (was: Chrome browser has no option to disable non-https sites)
I've been meaning to file a feature request like this for quite a while. Basically I think we can and should add a boolean option in Settings to

  [x] Only Use Secure Transport

We could either implement it to mean "simply don't make any HTTP, WS, or FTP requests", or we could implement it to mean "treat HTTP and FTP as typos for HTTPS, and WS as a typo for WSS". Or (less awesome because more UX complexity) we could add a 2nd, dependent checkbox to toggle between those 2 meanings:

  [x] Only Use Secure Transport
    [x] Upgrade Non-Secure Requests

My preference would be for 1 checkbox, and to have it mean "upgrade". Obviously, this checkbox would have to be off by default, but it would be there for the paranoid.

I have a trivial extension that does this, but it doesn't apply to WS and FTP, and it's probably not as fast as it would be as a native feature in C++ at the right layer(s).

Could be a GoodFirstBug for an open source contributor, too? Or maybe a good second bug.

I don't think this is a Blink security feature; it's a bit of UX to change behavior in the net/ stack.
Labels: Hotlist-Privacy
Adding to Hotlist-Privacy. Strictly taken this is a security bug, but I can imagine that this could be a good first bug for someone on privacy team too.
If someone wanted to pick it up, I've got the beginnings of a CL: https://chromium-review.googlesource.com/c/chromium/src/+/1157245
Couple of questions/comment;s

1) Is this feature targeting most users, or just power users? Could it be just a runtime flag instead of a checkbox/toggle in settings?
2) If putting it in Settings is justified, I'd suggest avoiding the double checkbox approach. Either decide on a single setting, or turn it to a dropdown with the available options, if more than 2 exist, like [off, only use, upgrade].
#7: I understand it to be the case that very few people ever even look at the Settings page. So just about anything there is a 'power user' feature; certainly anything in Advanced.

I think that is perfectly OK.

I would argue against exposing the feature only as a command-line flag (if that is what you meant). Even fewer people know about those.

I would like for this to be a supported, visible, discoverable feature. Even if few people end up using it, as indeed I expect to be the case, I'd like for those who want it to be able to discover it and use it effectively.
I would +1 not using command line flags. Those are not available to even be set on ChromeOS and Android, only available on desktop and really hard to figure out how to do in some cases (MacOS).
This option may be recommended in a corporate environment
Or could be set by privacy extensions.

Sign in to add a comment