Allowing component extensions to request permissions NOT only from user's gestures

Allowing component extensions to request permissions NOT only from user's gestures.

Google Now extension will request background permission dynamically, and this won't necessarily happen from user's gestures.

BUG=164227
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=204735

[vadimt, 2013-06-04 00:53:43]

mpcomplete@, please provide OWNER's approval.

[Matt Perry, 2013-06-04 20:28:41]

Why would it request a permission from a non-gesture? The point of this
requirement is to avoid a random permission dialog appearing when the user is
not interacting with the app/extension.

[vadimt, 2013-06-04 21:22:56]

On 2013/06/04 20:28:41, Matt Perry wrote:
> Why would it request a permission from a non-gesture? The point of this
> requirement is to avoid a random permission dialog appearing when the user is
> not interacting with the app/extension.

1. There will be a Chrome option that enables polling for Google Now cards in
background mode. We want to check the value of this option on startup (not from
user gesture) and request background permission at this point.
2. I didn't see the permission dialog. Somehow, the permission was already
granted (even on clean profiles), so the dialog was not shown. I don't know why
(may be, you do?). Anyways, even if we see this dialog, I believe, it makes
sense to change Chrome to not show it for component extensions.

[Matt Perry, 2013-06-04 21:30:57]

On 2013/06/04 21:22:56, vadimt wrote:
> On 2013/06/04 20:28:41, Matt Perry wrote:
> > Why would it request a permission from a non-gesture? The point of this
> > requirement is to avoid a random permission dialog appearing when the user
is
> > not interacting with the app/extension.
> 
> 1. There will be a Chrome option that enables polling for Google Now cards in
> background mode. We want to check the value of this option on startup (not
from
> user gesture) and request background permission at this point.

Can we grant the extension permission when this option is enabled?

> 2. I didn't see the permission dialog. Somehow, the permission was already
> granted (even on clean profiles), so the dialog was not shown. I don't know
why
> (may be, you do?).

No, I don't know why. Maybe the background permission doesn't actually require a
dialog.

> Anyways, even if we see this dialog, I believe, it makes
> sense to change Chrome to not show it for component extensions.

I don't agree that component extensions should be any different here. Showing
the user permission dialogs without any context is a bad UX.

Why not just give the extension the background permission on install?

[vadimt, 2013-06-04 21:38:54]

On 2013/06/04 21:30:57, Matt Perry wrote:
> On 2013/06/04 21:22:56, vadimt wrote:
> > On 2013/06/04 20:28:41, Matt Perry wrote:
> > > Why would it request a permission from a non-gesture? The point of this
> > > requirement is to avoid a random permission dialog appearing when the user
> is
> > > not interacting with the app/extension.
> > 
> > 1. There will be a Chrome option that enables polling for Google Now cards
in
> > background mode. We want to check the value of this option on startup (not
> from
> > user gesture) and request background permission at this point.
> 
> Can we grant the extension permission when this option is enabled?
Suppose, the option is enabled first, and then the extension gets enabled via a
flag. So, this won't work.

> 
> > 2. I didn't see the permission dialog. Somehow, the permission was already
> > granted (even on clean profiles), so the dialog was not shown. I don't know
> why
> > (may be, you do?).
> 
> No, I don't know why. Maybe the background permission doesn't actually require
a
> dialog.
> 
> > Anyways, even if we see this dialog, I believe, it makes
> > sense to change Chrome to not show it for component extensions.
> 
> I don't agree that component extensions should be any different here. Showing
> the user permission dialogs without any context is a bad UX.
Agree. I'm speaking about NOT showing any dialog for component extensions.

> 
> Why not just give the extension the background permission on install?
Because the option will be off at the install time. We don't want make Chrome a
background process before the user acknowledges that they want to use the
feature.

[Matt Perry, 2013-06-04 22:05:55]

On 2013/06/04 21:38:54, vadimt wrote:
> On 2013/06/04 21:30:57, Matt Perry wrote:
> > On 2013/06/04 21:22:56, vadimt wrote:
> > > On 2013/06/04 20:28:41, Matt Perry wrote:
> > > > Why would it request a permission from a non-gesture? The point of this
> > > > requirement is to avoid a random permission dialog appearing when the
user
> > is
> > > > not interacting with the app/extension.
> > > 
> > > 1. There will be a Chrome option that enables polling for Google Now cards
> in
> > > background mode. We want to check the value of this option on startup (not
> > from
> > > user gesture) and request background permission at this point.
> > 
> > Can we grant the extension permission when this option is enabled?
> Suppose, the option is enabled first, and then the extension gets enabled via
a
> flag. So, this won't work.
> 
> > 
> > > 2. I didn't see the permission dialog. Somehow, the permission was already
> > > granted (even on clean profiles), so the dialog was not shown. I don't
know
> > why
> > > (may be, you do?).
> > 
> > No, I don't know why. Maybe the background permission doesn't actually
require
> a
> > dialog.
> > 
> > > Anyways, even if we see this dialog, I believe, it makes
> > > sense to change Chrome to not show it for component extensions.
> > 
> > I don't agree that component extensions should be any different here.
Showing
> > the user permission dialogs without any context is a bad UX.
> Agree. I'm speaking about NOT showing any dialog for component extensions.

You're proposing that component extensions should not see a permission prompt? I
don't think that's right in general, either. For example, we should prompt the
user before granting location access, since it's a privacy issue.

Can you find out why we do not prompt for the background permission in this
case? That might influence the decision here.

[stromme1, 2013-06-04 22:29:43]

> > > > Anyways, even if we see this dialog, I believe, it makes
> > > > sense to change Chrome to not show it for component extensions.
> > > 
> > > I don't agree that component extensions should be any different here.
> Showing
> > > the user permission dialogs without any context is a bad UX.
> > Agree. I'm speaking about NOT showing any dialog for component extensions.
> 
> You're proposing that component extensions should not see a permission prompt?
I
> don't think that's right in general, either. For example, we should prompt the
> user before granting location access, since it's a privacy issue.
> 
> Can you find out why we do not prompt for the background permission in this
> case? That might influence the decision here.

Just to ensure that everyone is on the same page, here are some details:

1. Component extensions are shipped with chrome, not shown as extensions to
users, and are for all user-facing purposes, part of chrome
2. Google Now won't use location access until a (new) setting in chrome is
checked, either by clicking "yes" to a toast or going into settings
3. Additionally, we don't want to prevent chrome from closing (i.e. request the
background permission) until location access is on, which is why we can't use a
permanent permission

Therefore, I feel that component extensions should be different in that they can
request permissions without confirmation dialogs because it is understood that
they are part of chrome.

[Matt Perry, 2013-06-04 22:50:31]

+battre (see my question at the end)

On 2013/06/04 22:29:43, stromme1 wrote:
> > > > > Anyways, even if we see this dialog, I believe, it makes
> > > > > sense to change Chrome to not show it for component extensions.
> > > > 
> > > > I don't agree that component extensions should be any different here.
> > Showing
> > > > the user permission dialogs without any context is a bad UX.
> > > Agree. I'm speaking about NOT showing any dialog for component extensions.
> > 
> > You're proposing that component extensions should not see a permission
prompt?
> I
> > don't think that's right in general, either. For example, we should prompt
the
> > user before granting location access, since it's a privacy issue.
> > 
> > Can you find out why we do not prompt for the background permission in this
> > case? That might influence the decision here.
> 
> Just to ensure that everyone is on the same page, here are some details:
> 
> 1. Component extensions are shipped with chrome, not shown as extensions to
> users, and are for all user-facing purposes, part of chrome
> 2. Google Now won't use location access until a (new) setting in chrome is
> checked, either by clicking "yes" to a toast or going into settings
> 3. Additionally, we don't want to prevent chrome from closing (i.e. request
the
> background permission) until location access is on, which is why we can't use
a
> permanent permission
> 
> Therefore, I feel that component extensions should be different in that they
can
> request permissions without confirmation dialogs because it is understood that
> they are part of chrome.

OK, I may be misremembering our privacy policy here. Adding battre to confirm.

The assertion is that this is a component extension, and therefore doesn't need
a permission prompt when asking for extra permissions (in this case, the
background and location permissions). Instead, there are explicit UI toggles
within Chrome that control the extra permissions.

Dominic, does that sound OK?

[vadimt, 2013-06-04 23:42:11]

On 2013/06/04 22:50:31, Matt Perry wrote:
> +battre (see my question at the end)
> 
> On 2013/06/04 22:29:43, stromme1 wrote:
> > > > > > Anyways, even if we see this dialog, I believe, it makes
> > > > > > sense to change Chrome to not show it for component extensions.
> > > > > 
> > > > > I don't agree that component extensions should be any different here.
> > > Showing
> > > > > the user permission dialogs without any context is a bad UX.
> > > > Agree. I'm speaking about NOT showing any dialog for component
extensions.
> > > 
> > > You're proposing that component extensions should not see a permission
> prompt?
> > I
> > > don't think that's right in general, either. For example, we should prompt
> the
> > > user before granting location access, since it's a privacy issue.
> > > 
> > > Can you find out why we do not prompt for the background permission in
this
> > > case? That might influence the decision here.
> > 
> > Just to ensure that everyone is on the same page, here are some details:
> > 
> > 1. Component extensions are shipped with chrome, not shown as extensions to
> > users, and are for all user-facing purposes, part of chrome
> > 2. Google Now won't use location access until a (new) setting in chrome is
> > checked, either by clicking "yes" to a toast or going into settings
> > 3. Additionally, we don't want to prevent chrome from closing (i.e. request
> the
> > background permission) until location access is on, which is why we can't
use
> a
> > permanent permission
> > 
> > Therefore, I feel that component extensions should be different in that they
> can
> > request permissions without confirmation dialogs because it is understood
that
> > they are part of chrome.
> 
> OK, I may be misremembering our privacy policy here. Adding battre to confirm.
> 
> The assertion is that this is a component extension, and therefore doesn't
need
> a permission prompt when asking for extra permissions (in this case, the
> background and location permissions). Instead, there are explicit UI toggles
> within Chrome that control the extra permissions.
> 
> Dominic, does that sound OK?

Meanwhile, answering Matt's question on why there is no prompt. Yes, Chrome
never prompts for background permission:
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/common/exte...
The line for background permission doesn't have message id, so no questions
asked.

[Matt Perry, 2013-06-04 23:58:29]

On 2013/06/04 23:42:11, vadimt wrote:
> On 2013/06/04 22:50:31, Matt Perry wrote:
> > +battre (see my question at the end)
> > 
> > On 2013/06/04 22:29:43, stromme1 wrote:
> > > > > > > Anyways, even if we see this dialog, I believe, it makes
> > > > > > > sense to change Chrome to not show it for component extensions.
> > > > > > 
> > > > > > I don't agree that component extensions should be any different
here.
> > > > Showing
> > > > > > the user permission dialogs without any context is a bad UX.
> > > > > Agree. I'm speaking about NOT showing any dialog for component
> extensions.
> > > > 
> > > > You're proposing that component extensions should not see a permission
> > prompt?
> > > I
> > > > don't think that's right in general, either. For example, we should
prompt
> > the
> > > > user before granting location access, since it's a privacy issue.
> > > > 
> > > > Can you find out why we do not prompt for the background permission in
> this
> > > > case? That might influence the decision here.
> > > 
> > > Just to ensure that everyone is on the same page, here are some details:
> > > 
> > > 1. Component extensions are shipped with chrome, not shown as extensions
to
> > > users, and are for all user-facing purposes, part of chrome
> > > 2. Google Now won't use location access until a (new) setting in chrome is
> > > checked, either by clicking "yes" to a toast or going into settings
> > > 3. Additionally, we don't want to prevent chrome from closing (i.e.
request
> > the
> > > background permission) until location access is on, which is why we can't
> use
> > a
> > > permanent permission
> > > 
> > > Therefore, I feel that component extensions should be different in that
they
> > can
> > > request permissions without confirmation dialogs because it is understood
> that
> > > they are part of chrome.
> > 
> > OK, I may be misremembering our privacy policy here. Adding battre to
confirm.
> > 
> > The assertion is that this is a component extension, and therefore doesn't
> need
> > a permission prompt when asking for extra permissions (in this case, the
> > background and location permissions). Instead, there are explicit UI toggles
> > within Chrome that control the extra permissions.
> > 
> > Dominic, does that sound OK?
> 
> Meanwhile, answering Matt's question on why there is no prompt. Yes, Chrome
> never prompts for background permission:
>
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/common/exte...
> The line for background permission doesn't have message id, so no questions
> asked.

Thanks, Vadim. That probably means that if a component extension asked for an
optional permission which *does* usually prompt, it will prompt in that case. I
don't think we should show prompts without a user gesture. So if it's OK for
component extensions to ask for optional permissions without a gesture, we
should also not prompt for them.

[vadimt, 2013-06-05 00:24:28]

> So if it's OK for component extensions to ask for optional permissions without
a gesture, we
should also not prompt for them.

Done.

[Matt Perry, 2013-06-05 00:26:52]

https://codereview.chromium.org/16085006/diff/11001/chrome/browser/extensions...
File chrome/browser/extensions/api/permissions/permissions_api.cc (right):

https://codereview.chromium.org/16085006/diff/11001/chrome/browser/extensions...
chrome/browser/extensions/api/permissions/permissions_api.cc:214: bool
has_no_warnings = extension_->location() == Manifest::COMPONENT ||
nit: this really belongs on the if statement below.

[vadimt, 2013-06-05 00:33:07]

https://codereview.chromium.org/16085006/diff/11001/chrome/browser/extensions...
File chrome/browser/extensions/api/permissions/permissions_api.cc (right):

https://codereview.chromium.org/16085006/diff/11001/chrome/browser/extensions...
chrome/browser/extensions/api/permissions/permissions_api.cc:214: bool
has_no_warnings = extension_->location() == Manifest::COMPONENT ||
On 2013/06/05 00:26:52, Matt Perry wrote:
> nit: this really belongs on the if statement below.

Done.

[battre, 2013-06-05 07:56:25]

On 2013/06/04 23:58:29, Matt Perry wrote:
> On 2013/06/04 23:42:11, vadimt wrote:
> > On 2013/06/04 22:50:31, Matt Perry wrote:
> > > +battre (see my question at the end)
> > > 
> > > On 2013/06/04 22:29:43, stromme1 wrote:
> > > > > > > > Anyways, even if we see this dialog, I believe, it makes
> > > > > > > > sense to change Chrome to not show it for component extensions.
> > > > > > > 
> > > > > > > I don't agree that component extensions should be any different
> here.
> > > > > Showing
> > > > > > > the user permission dialogs without any context is a bad UX.
> > > > > > Agree. I'm speaking about NOT showing any dialog for component
> > extensions.
> > > > > 
> > > > > You're proposing that component extensions should not see a permission
> > > prompt?
> > > > I
> > > > > don't think that's right in general, either. For example, we should
> prompt
> > > the
> > > > > user before granting location access, since it's a privacy issue.
> > > > > 
> > > > > Can you find out why we do not prompt for the background permission in
> > this
> > > > > case? That might influence the decision here.
> > > > 
> > > > Just to ensure that everyone is on the same page, here are some details:
> > > > 
> > > > 1. Component extensions are shipped with chrome, not shown as extensions
> to
> > > > users, and are for all user-facing purposes, part of chrome
> > > > 2. Google Now won't use location access until a (new) setting in chrome
is
> > > > checked, either by clicking "yes" to a toast or going into settings
> > > > 3. Additionally, we don't want to prevent chrome from closing (i.e.
> request
> > > the
> > > > background permission) until location access is on, which is why we
can't
> > use
> > > a
> > > > permanent permission
> > > > 
> > > > Therefore, I feel that component extensions should be different in that
> they
> > > can
> > > > request permissions without confirmation dialogs because it is
understood
> > that
> > > > they are part of chrome.
> > > 
> > > OK, I may be misremembering our privacy policy here. Adding battre to
> confirm.
> > > 
> > > The assertion is that this is a component extension, and therefore doesn't
> > need
> > > a permission prompt when asking for extra permissions (in this case, the
> > > background and location permissions). Instead, there are explicit UI
toggles
> > > within Chrome that control the extra permissions.
> > > 
> > > Dominic, does that sound OK?
> > 
> > Meanwhile, answering Matt's question on why there is no prompt. Yes, Chrome
> > never prompts for background permission:
> >
>
https://code.google.com/p/chromium/codesearch#chromium/src/chrome/common/exte...
> > The line for background permission doesn't have message id, so no questions
> > asked.
> 
> Thanks, Vadim. That probably means that if a component extension asked for an
> optional permission which *does* usually prompt, it will prompt in that case.
I
> don't think we should show prompts without a user gesture. So if it's OK for
> component extensions to ask for optional permissions without a gesture, we
> should also not prompt for them.

I agree that UX wise it would be bad to have a permission dialog without a user
gesture. I wonder, though, whether enabling the component extension via some
user gesture (a toast or setting) would be sufficient.

If all major changes of component extensions go through launch bugs, I am ok to
remove permission prompts (component extensions should be treated as part of
Chrome) but we need to ensure that e.g. geolocation permission is still
explicitly granted by the user.

Best regards,
Dominic

[vadimt, 2013-06-05 17:47:50]

When the user checks the checkbox with the flag (on Settings page), the
extension may not to run (1) because its command-line flag wasn't specified or
(2) because the extension hasn't started yet. Based on this, we cannot rely on
being in a user's gesture. And even if we could, we would still want to avoid
showing a prompt because the user has already approved the permission in a
different way.
Yes, geolocation permission will be granted by the user. The user will have to
check "Enable geolocation" box on Settings page or do this via a toast we'll
show.

Google Now has (or will have) launch bug. I cannot guarantee, though, that
authors of other component extensions will always create launch bugs. Logically,
they should since they already use powerful private APIs etc.

[Matt Perry, 2013-06-06 20:45:13]

On 2013/06/05 17:47:50, vadimt wrote:
> When the user checks the checkbox with the flag (on Settings page), the
> extension may not to run (1) because its command-line flag wasn't specified or
> (2) because the extension hasn't started yet. Based on this, we cannot rely on
> being in a user's gesture. And even if we could, we would still want to avoid
> showing a prompt because the user has already approved the permission in a
> different way.
> Yes, geolocation permission will be granted by the user. The user will have to
> check "Enable geolocation" box on Settings page or do this via a toast we'll
> show.
> 
> Google Now has (or will have) launch bug. I cannot guarantee, though, that
> authors of other component extensions will always create launch bugs.
Logically,
> they should since they already use powerful private APIs etc.

OK, this requires user opt-in at the Chrome level, so LGTM.

[commit-bot: I haz the power, 2013-06-06 22:40:50]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/vadimt@chromium.org/16085006/17001

[commit-bot: I haz the power, 2013-06-07 07:51:31]

Change committed as 204735