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

Issue 362794 link

Starred by 5 users

Issue metadata

Status: Fixed
Closed: Dec 2015
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Cleanup extension permission strings

Project Member Reported by, Apr 11 2014

Issue description

A couple of ideas to improve the permission warnings:

- Make the wording consistent. Some warnings say "Access your data" while others say "Read a list of <...>".
- Combine similar warnings into a single warning that covers all.
- Remove warnings that are too subtle and don't have privacy or security impact.

The exhaustive list of permission warnings and comments from security team's audit is here:

Comment 1 by, Apr 11 2014

Status: Assigned

Comment 2 by, Apr 13 2014

Do not forget to update the extension documentation (permission warnings): issue 163515
Labels: Cr-Privacy

Comment 4 by, Apr 16 2014

A couple of ideas from palmer@:

- Consider not showing a warning for clipboard access for extensions, since extensions can already instantiate Flash and access the clipboard.
- Consider changing the wording of "sockets" to a more understandable text. E.g. "Allow the app to communicate in any way, not just with web servers"

Comment 5 by, Apr 17 2014

topSites permission warning: "Read and modify your browsing history"
The API only gives a list of most visited sites, doesn't allow modifying history.
I guess this one's status should be "fixed" now, right?
meacer@ is this still in progress?
I was thinking of this as an umbrella bug for all cleanup work. It would be good to make this blocked on the individual bugs you are working on, so that we can keep track of the cleanup. What do you think?
Blockedon: chromium:384490
Project Member

Comment 13 by, Jul 22 2014

The following revision refers to this bug:

commit 571a6711562cd1a8cbe1ba00f435aa227a012c3e
Author: <>
Date: Tue Jul 22 00:26:35 2014

Fixing consistency of permissions warning strings.

Fixing some of the strings that are used for permissions warnings to ensure their consistency.

BUG= 362794 

Review URL:

git-svn-id: svn:// 0039d316-1c4b-4281-b951-d872f2087c98

Project Member

Comment 14 by, Jul 22 2014

r284555 | | 2014-07-22T00:26:35.156253Z

Changed paths:

Fixing consistency of permissions warning strings.

Fixing some of the strings that are used for permissions warnings to ensure their consistency.

BUG= 362794 

Review URL:

Comment 15 by, Aug 15 2014

Our users encountered this problem. Namely, as says, the topSites permission causes users to see the same user-facing description as the "history" permission, even though it has far, far less access.

Both permissions say it's possible to "Read and modify your browsing history." While that's accurate for the history permission, for topSites, it should say something like "Read the 20 most frequently visited URLs" or "Read most frequently visited URLs."

(If one wanted to be really user-friendly, I could see checking for "newtab" in "chrome_url_overrides" and adjusting the message for that, like "Read most frequently visited URLs (such as for new tab pages)" or linking to a page which says same.)

Anyway, end result is that right now, end users can't tell the difference between two permissions which should involve very different amounts of trust.
@15: We recently changed topSites to show only "Read your browsing history" warning. I agree "Most 20 frequently visited urls" also makes sense, but adding that message will lead to complexity such as suppressing that message if the extension already has history permission and so on. I'm happy to reconsider this though.

Comment 17 by, Aug 16 2014

Thanks for the fast reply and thoughtful comments, Mustafa. I totally agree that none of these is universally perfect. I do think there's 3 challenges with the current (new) topSites description:

1. When interpreted by almost any user, it's inaccurate. No user thinks of "browsing history" as "the most frequently accessed sites," let alone "the sites on my new tab page." It uses a phrase ("browsing history") which, while obviously not intentionally wrong, doesn't mean what it's intended to.

Here's an example I encountered today: Nobody thinks "browsing history" means "URLs of top 20 sites." This manifests in lower user satisfaction because users decline to use extensions they'd actually be comfortable with.

2. Users can't differentiate between 2 very different permission levels. By conflating two very different amounts of access (topSites and history) into the same single message, a user isn't told the difference. Many, maybe a majority of, users who would be uncomfortable granting history would be completely comfortable granting topSites.

In as much as the goal of the permissions system is to let users make informed decisions, two very different amounts of access should be described differently. (The corollary of this argument: if they aren't different enough to justify different descriptions, we might as well obsolete topSites and exclusively use history. I don't think that at all, though!).

3. It deters extensions from using topSites, or would if extension authors knew about this problem ahead of time. I just released an update to a new tab page which started using topSites ( If I'd known 24 hours ago what I know now about the permission wording, I would not have added topSites support to our extension. Because it's so generic, the user message is scarier than the feature justifies.
Thanks for the detailed response, I'm sold on the idea of having a more granular warning for topSites, but kalman@ has the last say. I filed  bug 404334 . Also, we welcome patches ;)
Blockedon: chromium:404334
Labels: Hotlist-Recharge Hotlist-Recharge-Stale
This issue likely requires triage.  The current issue owner maybe inactive (i.e. hasn't fixed an issue in the last 30 days).  It has also not been modified in a year (prior to this update).  Thanks for helping out!

Status: Fixed
Components: -Security>UX
Labels: Team-Security-UX
Security>UX component is deprecated in favor of the Team-Security-UX label

Sign in to add a comment