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

Issue 636985 link

Starred by 5 users

Issue metadata

Status: Archived
Owner:
OOO until 4th Feb
Closed: Nov 23
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug
Team-Security-UX



Sign in to add a comment

FTP permission exceptions do not persist

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 ftp://ftp.hp.com/
(2) In the OIB dropdown, choose "JavaScript: always block on this site" and "Images: always block on this site"
(3) Refresh the page

Observe: OIB setting reverts to allow JavaScript and images

(4) Visit chrome://settings/siteSettings/javascript

Observe: Exception not listed
 
Cc: lshang@chromium.org
Owner: raymes@chromium.org
Status: Assigned (was: Untriaged)
Hmmm ... I don't think FTP permissions should persist, probably we shouldn't show any permissions in the OIB for FTP pages.

What do others think?
Is there some reason we /wouldn't/ want FTP permissions to persist?

While I'm not super-excited about per-site permissions, I would like to add a BLOCK for JavaScript on ftp://*

Related: https://bugs.chromium.org/p/chromium/issues/detail?id=636981

Comment 3 by raymes@chromium.org, Aug 15 2016

I'm curious why you would want to block JS on these pages? The JS that is running is bundled with Chrome right?
I'd like to block any JavaScript delivered non-securely, including JavaScript served in FTP-delivered HTML or from FTP-servers, since FTP is a non-secure protocol.

The JavaScript of interest isn't bundled with Chrome, it is supplied by the FTP server itself.

Comment 5 by raymes@chromium.org, Aug 16 2016

Ah I see, if you go to ftp://ftp.hp.com/pub/alphaserver/archive/news/index.html for example, you can't disable JS for it. 

I'd argue that it would be easier to disable JS by default and enable it on https. I know that doesn't fix the hole here but it should be a good enough workaround. We should fix this though, I think we can address it at the same time we address file: permissions.

Comment 6 by raymes@chromium.org, Aug 16 2016

Components: Security>UX
Labels: -OS-Windows -Pri-2 OS-All Pri-3
Oh, wow, I see now.

This feels like it should treated in a similar way to we treat file:// urls.
(which I should add we are reassessing as well)

Comment 9 by raymes@chromium.org, Aug 31 2016

Labels: PageInfo
Components: UI>Browser>Omnibox>PageInfo
Components: -UI>Browser>Omnibox>PageInfo UI>Browser>Bubbles>PageInfo
Labels: -PageInfo
Components: -Security>UX Internals>Permissions>Model
Components: -Internals>Permissions
Components: -UI>Browser>Permissions
Cc: -lshang@chromium.org
 Issue 588722  has been merged into this issue.
Labels: Hotlist-EnamelAndFriendsFixIt
Labels: -Hotlist-EnamelAndFriendsFixIt
Labels: Hotlist-DesktopUIChecked
Status: Archived (was: Assigned)
***Mass UI Triage***

The UI has changed completely on the latest version as compared to the older version hence archiving. If you have more data to
reproduce this bug or have alternate repro steps, please reopen or file a new issue.
Thanks!

Sign in to add a comment