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

Issue 636981 link

Starred by 1 user

Issue metadata

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

Blocked on:
issue 744499



Sign in to add a comment

Cannot add FTP exception to SiteSettings

Project Member Reported by elawrence@chromium.org, Aug 11 2016

Issue description

Version: Version 54.0.2826.0 canary (64-bit)
OS: Windows 7

What steps will reproduce the problem?
(1) Visit chrome://settings/siteSettings/javascript
(2) Attempt to add a "Block" exception for ftp://ftp.hp.com or ftp://*
(3) Cannot save the exception; save button never enabled
 

Comment 1 by finnur@chromium.org, Sep 28 2016

FTP patterns are apparently not even supported by the ContentSettingsPattern class:
https://cs.chromium.org/chromium/src/components/content_settings/core/common/content_settings_pattern.cc?q=contentsettingspattern&sq=package:chromium&l=297

I'd therefore argue UI>Settings is the wrong component for this bug -- or, at least you'd need changes elsewhere before this can be taken further.
Components: -UI>Settings Internals>Permissions>Model
Labels: -Type-Bug Type-Feature
Labels: OS-Android OS-Chrome OS-Fuchsia OS-iOS OS-Linux OS-Mac
Owner: msramek@chromium.org
Status: Assigned (was: Untriaged)
Adding msramek as an OWNER for ContentSettingsPattern. msramek: Can you help further triage/reassign? Thanks. (Also added all platforms, since this is not Windows specific).
Labels: -Pri-2 Pri-1
Owner: engedy@chromium.org
ftp:// is not listed in kSchemeNames[] in ContentSettingsPattern.

As a result, it seems that content settings don't apply to it. Not just exceptions, but also the default setting. I just tested disabling JavaScript completely, and was still able to execute console commands on ftp://ftp.hp.com.

Ideally, we would keep kSchemeNames[] in sync with the "webby" schemes defined in url/. Alternatively, we could decide that HTML served on ftp:// can't have some functionality, including running JavaScript, at all, but that would be a more far-reaching decision.

Passing to engedy@ and increasing priority, as I think this is a big oversight.
Cc: mkwst@chromium.org
+mkwst@

Since we're now deprecating rendering FTP resources, and the only documents we'd render on ftp:// now are directory listings, and we know that those won't contain JavaScript, it should now be safe to just blanket-disable JS on ftp://, right?
msramek@: Yes, if we get approval to fix  issue 744499  in https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/eopgOoY1QLs, then we could simply block all features on `ftp://` pages without issue.
Blockedon: 744499

Sign in to add a comment