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

Issue 442446 link

Starred by 13 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Feature

Sign in to add a comment

Expose fine-grained permissions for images/media/Javascript on Android

Project Member Reported by, Dec 15 2014

Issue description

The simple popup interface for fine-grained permissions on desktop Chrome is fantastic (that exposed by clicking the page/lock icon). 

As we're rolling out a subset of this feature on Android, it would be nice to consider exposing additional controls for permissions besides only those that are selectively blocked for a given site (like location or microphone). In particular, I would love to selectively disable Javascript on a number of heavy-laden sites that run fine without Javascript. Currently, there is no way to achieve this short of disabling Javascript for all site. Alternatively, if Javascript (or images, or any other single permission) is blocked by default, we could consider selectively allowing certain sites the associated permission.

In a world lacking extensions (Chrome on Android), this kind of control is really all that the user has to fight some of the more invasive and unnecessary web-facing "features". I realize getting the UI right is tricky, but I feel it worth the investment. This is an area where the web can and should be *better* than native, and I think we should leverage that advantage.


Comment 1 by, Dec 15 2014

Glad you like the new UI!

Thanks to felt@ telling me it was important, Fizz is already planning to handle selective blocking with revamped Site Settings:

This is only for certain permissions though, such as JavaScript. We weren't planning on providing this for images.

If you have any other ideas/thoughts reach out to egm@, the PM for permissions and Fizz (go/fizz.)

Comment 2 by, Dec 15 2014

Labels: Cr-Security Cr-Security-UX

Comment 3 by, Dec 15 2014

Javascript was the primary permission I had in mind, so I'm perfectly happy if that's already on the radar.

Comment 4 by, Dec 16 2014

I'll be handling the UI part of this (for the Site Settings pages of Android). My take on it was that this functionality is already implemented in Chrome proper, so we just need to add a bit of UI and plumbing. If I add that for one category (JavaScript) we'd get others (such as Images) practically for free as well (I think the hard part is going from 0 to 1 -- and going from 1 to n is easy). Assuming that holds water, is there is a specific reason _not_ to do Images as well?

Comment 5 by, Dec 16 2014


I think the only question I have is whether the user will be able to access these per-site permissions from the tab directly, as they can on desktop (by tapping the page/lock icon in the URL bar, as opposed to diving into the Settings dialog). Or perhaps that is what you were referring to, finnur@? It appears that this is possibly for Chrome on Android currently only when a specific permission has been actively blocked on the current site.

Comment 6 by, Dec 16 2014

I'm describing the ability to manually add sites via the Site Settings menu in Chrome on Android. What you are describing is in Sasha's territory (Page Info, she's CC-ed). I don't exactly know what's planned for that in this regard (don't have the mocks handy ATM).

Comment 7 by, Dec 16 2014

I believe JavaScript and Images will only show up in PageInfo if they've been changed from their default value. So, if they are modified in site settings, they will appear in Page Info. Other than that there are no plans to explicitly add them to Page Info.

Comment 8 by, Dec 17 2014

Just to be clear... When you say "when they've been modified from their default value" are you talking about the global value for the whole category (e.g. Images) or the value for individual sites?

Comment 9 by, Apr 15 2015

 Issue 568092  has been merged into this issue.

Comment 11 by, Dec 12 2015

finnur, for some reason i thought you were going to implement this (hazy memory). was it cut from the plan, or am i mis-remembering?
Sorry for the late reply...

The mocks only showed this for JavaScript and, as I recall, nobody specifically asked for this to be implemented for other categories. Shouldn't be too hard, though.
See related bug for mocks showing exception options in both allow and block states:
Labels: -Restrict-View-Google -Type-Bug Hotlist-Jewelbox Type-Feature
Status: Assigned (was: Untriaged)
 Issue 593345  has been merged into this issue.
 Issue 506025  has been merged into this issue.

Comment 17 by, Oct 17 2016

 Issue 652553  has been merged into this issue.

Comment 18 by, Oct 17 2016

 Issue 652551  has been merged into this issue.

Comment 19 by, Oct 17 2016

New Clank UI is in the works for showing exceptions in order to better align with the MD desktop work:

Re-assigning this bug to myself until that's resolved.

raymes@ do you still plan to be the eng to implement all exceptions for all sections or should I re-assign to emilyschechter for triage when ready?
I don't see anything about Javascript in the mocks.

Is Javascript still planned to be handled in the same way?  (The current stable chrome for Android (M-53) already allows exceptions to be added to enable Javascript on particular sites if Javascript is globally disabled.  It does not allow exceptions to be added to disable Javascript on particular sites if Javascript is globally enabled.)

Summary: Expose fine-grained permissions for images/media/Javascript on Android (was: Expose fine-grained permissions for images/media/Javascript)
(Refining title because bugmail does not otherwise make clear this is only about Android.)

Comment 22 by, Oct 18 2016

(thanks for the title refining, lgarron - I might scope it wider than images/media/Javascript even and support whatever has exceptions on desktop perhaps)

mpearson: Imagine the mock link says "Javascript" instead of "Camera." (Or sub out any permission we want to have exceptions, really.) The idea is we'd add exceptions to all the permissions and have them accessible whether the permission toggle is on or off. So an improvement to Javascript, and then all the permissions to match it.

> raymes@ do you still plan to be the eng to implement all exceptions for all sections or should I re-assign to emilyschechter for triage when ready?

The latter - we should prioritize this with the other work that's going on :)
One additional thought: we may want to restrict people to adding origins rather than patterns with wildcards for permissions that don't already allow it (e.g. location). What I mean is, it's ok if we let them add specific origins - e.g. but not patterns, e.g. *:// 

The reason is that I think we need to rethink our UX around general patterns and if we let users add more of them it might be harder to do.

Comment 25 by, Oct 19 2016

Mocks OK'd by bettes@ for mobile:

Caveat being for the empty list we say:
"No sites added" instead of what's shown in the mocks

MD desktop settings deck here again for reference:

emilyschechter@ can triage. May be best to wait for MD release to ensure there's no future UI change.

Per comment 24 - your concern is specifically to Android or Chrome on desktop too? Wildcard exceptions are something emilyschechter wants to think more about. (related syncing bug for my reference: It would be great to make this bug about adding the current functionality to all the relevant permissions with the UI launching on desktop, and then spin out a different bug on how to tackle wildcard syncing and entry on Android. It wouldn't be gated on MD desktop stuff - you could move forward on it right away if you wish. Will leave it up to emilyschechter's discretion though.
> your concern is specifically to Android or Chrome on desktop too? 


> It would be great to make this bug about adding the current functionality to all the relevant permissions with the UI launching on desktop

Yep - I agree that this bug is specifically about adding a way to add custom exceptions to all relevant permissions. I'm just suggesting we may want to limit those custom exceptions to origins for the time being until we work out the UX story for patterns. It will mean we're not digging deeper into a hole that we might have to climb out of later. Note that this wouldn't affect the mocks at all. Does that make sense? Happy to chat briefly if needed :)

Comment 27 by, Oct 21 2016

Per No. 26 - just limit custom exceptions to origins on Desktop and Mobile for the time being:
OK sounds great! I'm not sure how to officially implement that... You may need to talk with the MD settings people (tbuckley@) for it to apply to desktop. Right now their focus is taking the current plugging and re-skinning it; they might need help with the limitation logic (unless you were to implement for current Chrome now.)
Sounds good, thanks. I'll find out who is implementing it :)
Components: -Security>UX Internals>Permissions>Model
Components: -Security>UX Internals>Permissions>Model

Comment 32 by, Mar 29 2017

Removing myself and adding +maxwalker as the primary design contact
Labels: -Pri-2 Pri-3
Labels: Hotlist-EnamelAndFriendsFixIt
Any thoughts on this feature request?  What's the next step that's needed here: a UX design for the page info dialog to change settings?  PM approval?  ...?
I think this should stay as a low-priority bug. It would be nice if this was fixed but it's not high priority and we shouldn't spend UX/PM cycles on it right now.
Labels: -Hotlist-EnamelAndFriendsFixIt

Sign in to add a comment