*dreamy harp arpeggios*

Deleted: IMG_3491.jpg 319 KB

	IMG_3491.jpg 319 KB View Download

privacy relevant topic -> adding Privacy component

vabr@: Could you explain your reasoning in more detail? There are a lot of security surfaces that are tangentially related to privacy, but don't need to be tagged with Privacy directly.

lgarron: There is no precise rule. Privacy is much more vaguely defined than security. This particular issue needs to be on privacy's radar because site settings are one of the core areas of even privacy's feature work (as opposed to just reviewed features). In general, if unsure, adding the Privacy component is a good thing to do. We need to err on the safe side.

 Issue 670239  has been merged into this issue.

It's time.

I've implemented most of this, at least on Mac. Here's a demo.

Deleted: page-info-hide-default-permissions.mov 9.7 MB

page-info-hide-default-permissions.mov 9.7 MB Download

(Don't think I'm needed here, so removing myself silently. Feel free to re-add me if needed.)

Amazing, we are SO pumped for this. +maxwalker to check video.

Design doc link: https://docs.google.com/document/d/19ZfLlD8xyeALW0RZvGsEdYM82wxXYcGLjLr__fUfXRQ/edit

It looks like the animation frame is eating into the bubble arrow frame, which looks a little janky. Any way to fix that?

Deleted: Screen Shot 2017-02-24 at 12.02.58 PM.png 34.4 KB

	Screen Shot 2017-02-24 at 12.02.58 PM.png 34.4 KB View Download

Some Enamel folks had a meeting, where others had concerns about adding a button to expand permissions.

The following is not *too* hard to implement:

- An enum flag with values for which permissions to show by default, say:
  - None
  - Hide all that don't match the browser default
  - Hide all permissions with a browser default of "Ask" that are set to the default.
  - All
- A boolean flag for whether to show a button to expand permissions (if not all permissions are shown).

This allows:
- Us to control and change what we ship using Finch.
- Users to choose alternative settings if they really want all permissions.
  - Us to record how many users chose to do this.
- Us to run Finch experiments to measure user actions based on which display mode?

(Also, we could just combine the enum + boolean that into a single enum.)

Thanks Lucas! IMO following options would be useful in an enum:
1. Hide all that don't match the browser default. No expand button.
2. Hide all that don't match the browser default. Yes expand button.
3. Hide all permissions with a browser default of "Ask" that are set to the default.
4. Show all (same as today).

I don't know why the other options would be useful but I am not against adding them if you see value.

IMO the default should be #1. I can take on writing an external doc/post/update that explains why we chose this as the default.

If we had a flag, 1 or 3 should be the default. My reasoning is that we should not have an expand button by default

But I'm not sure this is really a valuable use of time, this isn't what flags are designed or meant for. Flags are a way for the development team to create and experiment with features, not for a way to provide features to power users.

Maybe there are valid experiments to be done though. Can you outline what kind of experiments we'd run, what kind of data we'd collect and how we'd use it to make decisions?

At the very least, I would insist on a single flag to revert to the existing behaviour – so whatever change we roll out by default would be an "experiment", and the flag would also be a way for users to opt out.

Other options are not hard to add, and allows us to try them out to get a feel – I certainly don't have a good sense of how verbose I would find the intermediate states we're considering.

I can't think of useful metrics to collect, since we don't have an action that corresponds to "was it useful to show all the permissions"? (Except if we record how much people change permissions that we would have hidden by default.)
Hence the question mark on that point.

Enamel is still discussing which permissions to show by default, but here's a Views screenvid for https://codereview.chromium.org/2717613003

Note that the "Reload" infobar is required for some permission changes to go into effect, but Page Info reflects the latest permissions even if you click it when the infobar is showing. (This is expected behaviour.)

Deleted: initial-implementation-views.mov 8.6 MB

initial-implementation-views.mov 8.6 MB Download

re: animation in #15: (Based on from https://codereview.chromium.org/2712863005)

One simple option to avoid the animation issue is to simply set `animate:NO` at [1]. Given that nothing else will grow the window anymore (and I don't see a strong need for it here), that seems reasonable to me.

But I'm not a UX designer, and I don't know the right place to start addressing it otherwise.

My worry with a flag is that flags are difficult to take away once they're there. We shouldn't use user-visible flags to ship *alternate* pieces of UI. It's really for experimental or new behaviour that is intended to become the default in the future, whereas this flag would almost certainly enable UI that would be taken away at some point.

I really think if we hide permissions with an Ask (default) value, that should be sufficient to reduce the size of page info without requiring a show all permissions button. The only regression is if there are users who want to visit a site and immediately grant or block a default-asking permission via page info before it prompts. That's more clicks than just letting the site prompt and accepting, and I can't really imagine that being in someone's workflow.

In your initial-implementation-views.mov screenvid from comment #21 at 0:45, the dialog seems to shrink horizontally when you change "Automatic Downloads" from always-allow to global-default. That causes the top text to change layout and split "Learn more" onto two lines, adding a new line, and causing a big visual shift.

Can we avoid layout changes to the dialog while it's visible? That would require formatting the dialog to accommodate the widest contents of the visible permission rows.

Enamel folks: how much do you like this as a default?

I feel like it's still too much.
- Background Sync is not particularly relevant to most users on desktop.
- As far as I know, the main reason to disable images is to save bandwidth, which makes a per-site setting for it less useful.

But if everyone else strongly prefers this over a button to expand the list, I'd rather ship this in M58 than nothing.

Deleted: Screen Shot 2017-02-28 at 13.21.49.png 126 KB

	Screen Shot 2017-02-28 at 13.21.49.png 126 KB View Download

(Of course, if the button doesn't expand the list, it would say "Site settings" instead of "Show all permissions".)

 >Can we avoid layout changes to the dialog while it's visible? That would require formatting the dialog to accommodate the widest contents of the visible permission rows.

Is that easy to do without triggering a layout, recording the width, and then recreating the layout with fewer permissions?

Do we have metrics to tell us how often these are toggled or exceptions are added? Ideally we should use data to back up decisions like "people need JS toggle more than an images toggle".

Turns out we actually *do* count how often people change permission settings in Page Info: https://goto.google.com/uma-histograms?histograms=WebsiteSettings.OriginInfo.PermissionChanged

The numbers look weirdly similar for all permissions, with MIDI nearly as high as Images and Downloads.

Popups are way ahead of everything else, with Plugins (shown as "Flash") the only thing significantly higher than the others.

It puzzles me that all the permissions are so similar, though – as if users are likely to change *all* settings as soon as they change *one* other than Popups or Plugins.

24% Popups
12% Plugins
09% Location
08% MIDI sysex
08% Media
08% Media
08% JavaScript
07% Notifications
07% Images
07% Automatic downloads
05% "27"

"27" is a value of 27 on for ContentSettingsType, which appears to be CONTENT_SETTINGS_TYPE_SUBRESOURCE_FILTER [1] – but we don't show that on desktop. This means someone goofed – histogram.xml has significant discrepancies. I'm going to dig into it and double-check that the values I posted above are correct.

[1] https://cs.chromium.org/chromium/src/components/content_settings/core/common/content_settings_types.h?type=cs&sq=package:chromium&l=51

I like what you have roughly in #25. How did you choose those types? 

Would other types show up if they were changed from the default?

> I like what you have roughly in #25. How did you choose those types? 

(permission_info.setting != CONTENT_SETTING_DEFAULT || permission_info.default_setting != CONTENT_SETTING_ASK)

> Would other types show up if they were changed from the default?

Yes.

How come flash is shown? It seemed to be the default and be ask.

Also, what do the percentages int he stats mean? Does it mean 24% of the time people change any setting it is Popups?

Otherwise the design as described sgtm.

Hey Ben - take a look at https://bugs.chromium.org/p/chromium/issues/detail?id=697238 which Lucas filed about flash

OK thanks :)

Okay, here's a full proposal that I can update the CL to today:

1. We hide all permissions with a default value if the built-in default is Ask (see comment #25).
2. We update Flash to show something other than "Ask" ( Issue 697238 ) for default.
  - We can go back to "Detect". Alternatively, I think "Automatic" is also a decent choice.
3. We don't have a button to expand the list of permissions in-line, but we change the "Site settings" button to make it clear that not all permissions are shown before. I propose "Edit all permissions". Alternatively: "Edit more permissions", "Edit site settings"

I think 2. and 3. are important to minimize confusion among all users (regular users as well as power users).

In addition, we should update the appropriate Help Center article, and add some documentation (wiki page, or documentation checked into the repo; see  Issue 697248 ) explaining the state and direction of Page Info.

raymes@, benwells@, emilyschechter@: Assuming UI is okay with it, are you comfortable with this proposal?

That plan roughly sounds good to me :) I left some thoughts in  Issue 697238  about what we could do for Flash.

Lucas, is there any way you can add absolute #s to #c29? The only reason I can think of that i.e. MIDI is so high is that this represents some tiny population...

re: #35 Yep sounds good. Maybe site settings -> More settings? Since it just goes to a pretty top level part of settings.

Would be good to understand stats more to see if we can for e.g. remove images as well, as it is never Ask.

Okay, sounds like we're getting somewhere.

As much as I would like to ship in M58, I think the best here would be to land the change right after branch and tweak it from there. That also gives us longer to get used to it, and to get developer feedback.

> Lucas, is there any way you can add absolute #s to #c29?

I don't know if that's okay to post, but you can follow the link to the data. (consider setting the time range to 28 days).

If anyone wants to get this into M58, speak how or forever hold your peace.

(holding peace)

> As far as I know, the main reason to disable images is to save bandwidth, which makes a per-site setting for it less useful.

I should mentioned that I realized this is wrong. If the user changes the default for all sites to "disable", it makes sense to enable from Page Info on a per-site basis.
(However, the dropdown will show confusing UI:  Issue 614618 )

Here's how it all looks with https://codereview.chromium.org/2702923002 (+dependent CLs)

Deleted: Screen Shot 2017-03-03 at 19.28.46.png 117 KB

	Screen Shot 2017-03-03 at 19.28.46.png 117 KB View Download

Unfortunately, we don't have consensus on {what permissions to show by default, whether to have an "Expand" button} among Enamel + UI review, so this is blocked for the time being. :-(

:( Is there a UI review thread where this discussion is happening?

Current state of affairs:
* We are currently scoping work and timeline (who should implement, are there approved mocks, what's the difficulty, what's optimistic & pessimistic ETA) around MD Site Settings, since once that ships this issue is unquestionably unblocked. Right now things seem fairly optimistic for an MVP to ship with MD-settings but continued scoping is required.
* I made a deck (https://docs.google.com/presentation/d/1jkB3Ee7DwCFDeX9JWhuS7ChHhxhcbkNjCQY2rsbv0k0/edit#slide=id.p) outlining the options going forward. Once we have a more confident scoping around the former bullet, if it is likely post M60, we can present this to UI-review for a final decision.

We now have  Issue 709169  to track what features we need in place before we're comfortable hiding default permission without an expand button (and just linking to MD per-site settings).

Note the current plan is to show non-factory-default-sourced per Ben's doc: https://docs.google.com/document/d/1lN1-RtwaVeV-vj2n9_GuW7IpFs92zU4jQqwB8v7HHrA/edit

Also re-assigning to Patti per her work on Site Details and the new improved PageInfo

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

commit 0601e5375167f5894c2ffa22b81e7a6528637579
Author: Patti <patricialor@chromium.org>
Date: Wed Sep 20 08:39:30 2017

Permissions: Page Info now only shows non-factory-default content settings.

Now that Site Details (see  https://crbug.com/656758 ) shows all content settings,
the Page Info bubble can be updated to show only non-factory default ones, i.e.
content settings that have been changed away from the Chrome default.

Bug:  657267 
Change-Id: Ie400eaa61db58bb751b99279b59d69939de2f692
Reviewed-on: https://chromium-review.googlesource.com/662997
Commit-Queue: Patti <patricialor@chromium.org>
Reviewed-by: Raymes Khoury <raymes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#503089}
[modify] https://crrev.com/0601e5375167f5894c2ffa22b81e7a6528637579/chrome/browser/ui/page_info/page_info.cc
[modify] https://crrev.com/0601e5375167f5894c2ffa22b81e7a6528637579/chrome/browser/ui/page_info/page_info.h
[modify] https://crrev.com/0601e5375167f5894c2ffa22b81e7a6528637579/chrome/browser/ui/page_info/page_info_unittest.cc
[modify] https://crrev.com/0601e5375167f5894c2ffa22b81e7a6528637579/chrome/browser/ui/views/page_info/page_info_bubble_view_unittest.cc
[modify] https://crrev.com/0601e5375167f5894c2ffa22b81e7a6528637579/components/content_settings/core/browser/content_settings_info.cc
[modify] https://crrev.com/0601e5375167f5894c2ffa22b81e7a6528637579/components/content_settings/core/browser/content_settings_info.h
[modify] https://crrev.com/0601e5375167f5894c2ffa22b81e7a6528637579/components/content_settings/core/browser/content_settings_registry_unittest.cc

In M63, where this seems to be implemented, it's now impossible to change site settings only for the current incognito session, which is a feature I use very frequently (e.g. to avoid accidentally enabling Flash on a website forever). Is there a workaround or plans to bring this feature back?

Why hide them again (It was done before, strongly opposed by user community and finally reverted in #483899)? This change just makes it so much more difficult to make quick permission changes with no tangible benefits.

I find it hard to understand why breaking useful features is such a high priority for some people.

c#70: I think you mean r380227, or  https://crbug.com/483899 

There has always been a plan to have a better UI surface than Page Info for showing all permissions. Page Info has a limited size, and it had become unsustainably large (covering nearly the whole screen in many configurations). We couldn't add any new things to it whilst it was in this state.

Now that we have Site Details (which is the improved UI surface alluded to in  https://crbug.com/483899 ), there is a logical home for the full list of permissions. The reasoning is as follows:

 - if the website hasn't yet prompted you for a permission, manually toggling the permission doesn't make much sense as an easily accessible control (the website can't use the permission without asking you)
 - if the website tries to use the permission, you get prompted, and as soon as you make a YES or NO decision, that permission will appear in Page Info (i.e. "non-default" permission states always appear in Page Info).
 - if you really want to twiddle with Permissions, it's only one click away in Site Details from Page Info.

PageInfo worked well before M63, how would 10 permissions cover the whole screen? If the window is that small this might make sense as an optional feature. But how many users have lower than 720p resolution?

c#69 listed a very common use case for manually toggling permissions
New Site Details does not easily facilitate a whitelist-only approach (block notification/location unless whitelisted). 

If Site Details opens in a new tab, that is way more than one click away. It interrupts browsing of current page.

The permission prompt box is quite intrusive for browsing compared to the old horizontal bar (which can be ignored without severely impact browsing). 

Are there actually users demands for the new PageInfo? Why keep fixing things that aren't broken (#663971 reverted a "fix" like this)? 

dominickn@: What do you think about the issue mentioned in #69? 
Flash doesn't show a permission prompt anymore, so I don't think there is currently any way to change flash permissions in incognito mode if the state is "Ask". 
Currently you would have to change flash to be blocked in regular mode, which should work as a workaround but would leave a permanent trace of a website you might not want to be visible.

Maybe we could show the flash permission if there is flash content present? 
Or as a simpler fix, always show the flash permission in incognito?

I'm not sure if this is relevant to any permission other than flash?

Regarding #72:
If you go to chrome://settings/content/notifications and change the default setting on the top from "Ask" to "Blocked", you should be able to whitelist any page in pageinfo. 

c#72: as dullweber@ said, such a whitelist-only policy is fully supported. As the title of this issue states, only "non-factory-default" permissions are shown in the Page Info Bubble. If you block a permission by default for all sites, that is a non-factory-default, and the permission will always appear in Page Info.

Additionally, at last count Page Info had 12 permissions, with at least 2 more on the way. It was certainly not feasible to keep everything in there.

c#74: hmm, I was able to get a Flash permission prompt in 65.0.3306.0 Canary just then. Perhaps something to follow up on a fresh bug?

Hm, I'm not sure when the prompt is triggered and when this doesn't happen. I thought we added cases where the flash prompt will not be shown? 
I was recently confused by http://www.kia.com/de/konfigurator/ that their car configurator says "This page requires adobe flash player".
Enabling flash for http://kia.com in site settings fixes that. Maybe the page is
doing flash detection incorrectly? Still there would be no way to enable flash in this case?

Oh, I think I confused this with showing prompts instead of just enabling flash by default. (https://www.chromium.org/flash-roadmap#TOC-HTML5-By-Default-Target:-Chrome-55---Dec-2016-)
The site is probably doing it wrong in this case? They should just show the flash content and let the user click on it to enable flash?

c#77: yeah, that's the appropriate thing the site should be doing. :)

Hmm, I actually agree that we've probably regressed here slightly for the incognito case. I think it's a very rare situation where someone would want to change a default permission for incognito only but it's still a valid use case. 

Perhaps clicking "Site settings" from an incognito tab should bring up an incognito-specific site settings window. 

As a short-term solution, most settings allow you to add an incognito-specific setting. e.g. 
1) Open an incognito window
2) Navigate to chrome://settings/content/flash
3) Click "Add" under Allow or Block
4) Enter the URL and check "Current incognito session only"

For the issue described in #c69 and #c79, I filed this in a separate bug Issue 803724.