New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 744481 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Buried. Ping if important.
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug
Team-Security-UX



Sign in to add a comment

Consider marking `ftp://` as non-secure.

Project Member Reported by mkwst@chromium.org, Jul 17 2017

Issue description

FTP accounts for something approaching ~0.0028% of navigations in the last month (across ~0.07% of users in the last ~week). Since the protocol is even less secure than HTTP (as it has no headers, and therefore no way of expressing any security stance whatsoever), it seems reasonable to treat it in the same way as we'd eventually like to treat HTTP. Given its low usage, it seems like we could be more aggressive about this mode of transport with regard to timelines.
 
Labels: Hotlist-HttpBad

Comment 2 by mkwst@chromium.org, Jul 17 2017

I sent out https://chromium-review.googlesource.com/c/574024/ as a strawman to discuss. :)

Comment 3 by mmenke@chromium.org, Jul 17 2017

How does HTTP-bad treat downloads?  i.e., if I have a link on an HTTP page to download an FTP resources, do we display any warning?  (May have asked this before, can't remember).
This has no impact on downloads today; Googlers can view go/httpbadfordownloads for more discussion. I suspect that most FTP usage today results in a Download, so this change isn't likely to impact the majority of FTP scenarios.

Issue 333943 tracks the proposal to remove FTP support entirely.
Project Member

Comment 5 by bugdroid1@chromium.org, Sep 15 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3c82f58d3cb10286362992a01b2254e6066edb36

commit 3c82f58d3cb10286362992a01b2254e6066edb36
Author: Mike West <mkwst@chromium.org>
Date: Fri Sep 15 07:35:17 2017

Mark `ftp:` URLs as affirmatively "not secure".

FTP accounts for something approaching ~0.0026% of navigations in the
last month (across ~0.063% of users in the last ~week). Since the
protocol is even less secure than HTTP (as it has no headers, and
therefore no way of expressing any security stance whatsoever), it seems
reasonable to treat it in the same way as we'd eventually like to treat
HTTP. Given its low usage, it seems like we could be more aggressive
about this mode of transport with regard to timelines.

PSA: https://groups.google.com/a/chromium.org/d/msg/security-dev/HknIAQwMoWo/xYyezYV5AAAJ

Bug:  744481 
Change-Id: Icef02d00e9a0a5dba8bf3db8b6dc42d04b596d15
Reviewed-on: https://chromium-review.googlesource.com/574024
Reviewed-by: Emily Stark <estark@chromium.org>
Commit-Queue: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#502184}
[modify] https://crrev.com/3c82f58d3cb10286362992a01b2254e6066edb36/chrome/browser/ssl/security_state_tab_helper_browser_tests.cc
[modify] https://crrev.com/3c82f58d3cb10286362992a01b2254e6066edb36/components/security_state/core/security_state.cc
[modify] https://crrev.com/3c82f58d3cb10286362992a01b2254e6066edb36/components/security_state/core/security_state_unittest.cc

Comment 6 by mkwst@chromium.org, Sep 15 2017

Labels: M-63
Owner: mkwst@chromium.org
Status: Fixed (was: Available)

Comment 7 by mkwst@chromium.org, Sep 15 2017

Closing this out; future work on downloads in general seems like it's going to be a distinct project.

Sign in to add a comment