Allow silent update for default-installed apps.

Allow silent update for default-installed apps.

This suppresses the automatic-disabling and requirement for
explicit user consent when upgrading the permissions of
a default-installed app.

BUG=450300
R=asargent@chromium.org

Committed: https://crrev.com/92c7f7b3d0974547a628b5d21838c20b0f37839a
Cr-Commit-Position: refs/heads/master@{#316608}

[asargent_no_longer_on_chrome, 2015-01-20 21:31:00]

I'm a little nervous about us doing this for 2 reasons:

-It's conceivable that some advanced users actually checked out the permissions
of a default installed app and decided to leave it installed because the
permissions were acceptable to them, but a subsequent increase would make them
change their mind. 

-I vaguely recall that there might be some situations where the default
installed item list could come from a 3rd party (default brownser bundling
deals?) and those items might not be as closely vetted for things like privacy
policy adherence, etc. as ones selected just by Google for all Chrome users.

[Ken Rockot(use gerrit already), 2015-01-20 21:58:00]

Jake or Xiaowen, can you comment on the concerns listed by Antony?

I believe even third-party default apps must go through extra manual review
before new versions are published to the CWS.

[chromium-reviews, 2015-01-20 22:17:32]

Yes, apps requested for default-install by OEMs go through extra manual
review.  +ambishop leads the manual review team.

On Tue, Jan 20, 2015 at 1:58 PM, <rockot@chromium.org> wrote:

> Jake or Xiaowen, can you comment on the concerns listed by Antony?
>
> I believe even third-party default apps must go through extra manual review
> before new versions are published to the CWS.
>
> https://codereview.chromium.org/863743002/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[jleichtling, 2015-01-20 23:26:47]

On 2015/01/20 21:31:00, Antony Sargent wrote:
> I'm a little nervous about us doing this for 2 reasons:
> 
> -It's conceivable that some advanced users actually checked out the
permissions
> of a default installed app and decided to leave it installed because the
> permissions were acceptable to them, but a subsequent increase would make them
> change their mind. 

This is a valid concern given that users probably expect that app permissions
won't silently change. Perhaps the app info dialog for default installed apps
should somehow imply that the app can be silently updated with elevated
permissions, after Google has reviewed them?

Although this is a conversation worth having, I don't think it should block this
change, especially since we already allow third-party default installed apps to
silently elevate permissions once Google has reviewed them.

> 
> -I vaguely recall that there might be some situations where the default
> installed item list could come from a 3rd party (default brownser bundling
> deals?) and those items might not be as closely vetted for things like privacy
> policy adherence, etc. as ones selected just by Google for all Chrome users.

[Ken Rockot(use gerrit already), 2015-01-22 23:54:40]

ping

[asargent_no_longer_on_chrome, 2015-01-23 00:51:26]

I've been thinking about this some more and I am still sort of philosophically
opposed. Let me explain my thinking. 

I've always been leery of the whole default apps feature because it can be a
turn off to many users in the same was as "crapware" pushed by traditional
windows PC OEM's. But putting that aside, why should default apps get a free
pass on permissions upgrades? (I don't think Android does this, for instance).
When other 3rd party developers complain about our policy of "disable on
significant permissions increase", our standard answer is tell them to use
optional permissions. I think either that should be a sufficient answer for the
developers of default apps too, or if it isn't then we should fix the platform
for all developers. 

I'm not trying to be a road block to progress here, so if someone else who
thinks differently about this wants to ok the patch I don't want to stand in the
way. I just am not personally convinced we should land it so I don't want to be
the one to ok it.

[xiaowenx, 2015-01-23 04:39:55]

We silently upgrade permissions for first-party apps today, right?  The idea is
that users can't tell the difference between first-party and other default apps,
and they're probably not in a good position to make the decision on whether to
grant the permissions or not since they wouldn't know the app as well as we do. 
So we should make the experience super seamless: either deny the default install
altogether because the app wants too many permission or silently upgrade.  This
was the result of a discussion with erikkay more than a year ago.

[jleichtling, 2015-02-02 04:37:51]

On 2015/01/23 04:39:55, xiaowenx wrote:
> We silently upgrade permissions for first-party apps today, right?  The idea
is
> that users can't tell the difference between first-party and other default
apps,
> and they're probably not in a good position to make the decision on whether to
> grant the permissions or not since they wouldn't know the app as well as we
do. 
> So we should make the experience super seamless: either deny the default
install
> altogether because the app wants too many permission or silently upgrade. 
This
> was the result of a discussion with erikkay more than a year ago.

To summarize the conversation so far, it seems like we all agree that first
party default installed apps should be allowed to elevate permissions silently.
However, there is some potential disagreement about whether third party default
installed apps should have the same ability, even though they currently do in
today's Chrome.

Ken, if first party default installed apps cannot silently elevate permissions
without this patch, then the patch is certainly necessary (and I'm hoping we can
get it into M42).

Antony, I think our review of default installed apps sets a high enough bar such
that users will not feel inundated with "crapware". Since we have a relatively
high quality threshold, as well as security and privacy reviews, I'm in favor of
allowing third party apps to elevate permissions silently. We can certainly
continue this discussion, but it should not block this CL since the code does
not affect the current ability of third party default installed apps to silently
elevate permissions.

[asargent_no_longer_on_chrome, 2015-02-02 18:26:33]

On 2015/02/02 04:37:51, jleichtling wrote:
> On 2015/01/23 04:39:55, xiaowenx wrote:
> > We silently upgrade permissions for first-party apps today, right?  The idea
> is
> > that users can't tell the difference between first-party and other default
> apps,
> > and they're probably not in a good position to make the decision on whether
to
> > grant the permissions or not since they wouldn't know the app as well as we
> do. 
> > So we should make the experience super seamless: either deny the default
> install
> > altogether because the app wants too many permission or silently upgrade. 
> This
> > was the result of a discussion with erikkay more than a year ago.
> 
> To summarize the conversation so far, it seems like we all agree that first
> party default installed apps should be allowed to elevate permissions
silently.
> However, there is some potential disagreement about whether third party
default
> installed apps should have the same ability, even though they currently do in
> today's Chrome.
> 
> Ken, if first party default installed apps cannot silently elevate permissions
> without this patch, then the patch is certainly necessary (and I'm hoping we
can
> get it into M42).
> 
> Antony, I think our review of default installed apps sets a high enough bar
such
> that users will not feel inundated with "crapware". Since we have a relatively
> high quality threshold, as well as security and privacy reviews, I'm in favor
of
> allowing third party apps to elevate permissions silently. We can certainly
> continue this discussion, but it should not block this CL since the code does
> not affect the current ability of third party default installed apps to
silently
> elevate permissions.

Again, I'm not attempting to block the CL; I just happen to still disagree with
the
reasoning that it should move forward. If someone else in relevant OWNERS wants
to ok it that's fine by me. 

Ken and I discussed this a little in person last week and it sounds like at
least
part of the motivation for this change was so that some first party default
installed
hosted apps could morph themselves into extensions without running into
permissions
problems, and we both agreed that it would make sense that a hosted app for
domain
foo.com should probably be allowed to change into an extension with host
permissions
on foo.com without hitting the disabling speed bump. However I don't know if
that fully
addresses the concerns behind the CL, and also we should certainly get security
team
sign off as well.

[jleichtling, 2015-02-06 17:49:18]

On 2015/02/02 18:26:33, Antony Sargent wrote:
> On 2015/02/02 04:37:51, jleichtling wrote:
> > On 2015/01/23 04:39:55, xiaowenx wrote:
> > > We silently upgrade permissions for first-party apps today, right?  The
idea
> > is
> > > that users can't tell the difference between first-party and other default
> > apps,
> > > and they're probably not in a good position to make the decision on
whether
> to
> > > grant the permissions or not since they wouldn't know the app as well as
we
> > do. 
> > > So we should make the experience super seamless: either deny the default
> > install
> > > altogether because the app wants too many permission or silently upgrade. 
> > This
> > > was the result of a discussion with erikkay more than a year ago.
> > 
> > To summarize the conversation so far, it seems like we all agree that first
> > party default installed apps should be allowed to elevate permissions
> silently.
> > However, there is some potential disagreement about whether third party
> default
> > installed apps should have the same ability, even though they currently do
in
> > today's Chrome.
> > 
> > Ken, if first party default installed apps cannot silently elevate
permissions
> > without this patch, then the patch is certainly necessary (and I'm hoping we
> can
> > get it into M42).
> > 
> > Antony, I think our review of default installed apps sets a high enough bar
> such
> > that users will not feel inundated with "crapware". Since we have a
relatively
> > high quality threshold, as well as security and privacy reviews, I'm in
favor
> of
> > allowing third party apps to elevate permissions silently. We can certainly
> > continue this discussion, but it should not block this CL since the code
does
> > not affect the current ability of third party default installed apps to
> silently
> > elevate permissions.
> 
> Again, I'm not attempting to block the CL; I just happen to still disagree
with
> the
> reasoning that it should move forward. If someone else in relevant OWNERS
wants
> to ok it that's fine by me. 
> 
> Ken and I discussed this a little in person last week and it sounds like at
> least
> part of the motivation for this change was so that some first party default
> installed
> hosted apps could morph themselves into extensions without running into
> permissions
> problems, and we both agreed that it would make sense that a hosted app for
> domain
> http://foo.com should probably be allowed to change into an extension with
host
> permissions
> on http://foo.com without hitting the disabling speed bump. However I don't
know if
> that fully
> addresses the concerns behind the CL, and also we should certainly get
security
> team
> sign off as well.

It seems that although third party default installed apps are not currently
allowed to silently elevate permissions, the original intention was that they
should be able to. Please see Erik's comment here:
https://code.google.com/p/chromium/issues/detail?id=312889#c27.

This patch will both enact that plan, as well as enable that functionality for
first party default installed apps as well. The overarching idea is that we'd
like to enable the best UX whenever possible, and in both of these cases we have
the opportunity to skip the user prompt since we trust/have thoroughly reviewed
these apps' updates.

We'll be sure to get security sign-off as well. Mustafa has previously told me
in person that he is okay with this. I'll loop him in on the crbug as well.

[not at google - send to devlin, 2015-02-17 17:07:23]

kalman@chromium.org changed reviewers:
+ kalman@chromium.org

[not at google - send to devlin, 2015-02-17 17:07:24]

lgtm

https://codereview.chromium.org/863743002/diff/1/extensions/common/permission...
File extensions/common/permissions/permissions_data.cc (right):

https://codereview.chromium.org/863743002/diff/1/extensions/common/permission...
extensions/common/permissions/permissions_data.cc:55:
extension->creation_flags() & Extension::WAS_INSTALLED_BY_DEFAULT;
Hm, seems odd that EXTERNAL_PREF/REGISTRY isn't excluded here, I hope/thought
that we didn't allow silent sideloading of extensions. Ah well, something to
look into later.

[Ken Rockot(use gerrit already), 2015-02-17 17:08:30]

The CQ bit was checked by rockot@chromium.org

[commit-bot: I haz the power, 2015-02-17 17:09:33]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/863743002/1

[commit-bot: I haz the power, 2015-02-17 18:07:56]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-02-17 18:08:39]

Patchset 1 (id:??) landed as
https://crrev.com/92c7f7b3d0974547a628b5d21838c20b0f37839a
Cr-Commit-Position: refs/heads/master@{#316608}

[Ken Rockot(use gerrit already), 2015-02-17 18:29:54]

A revert of this CL (patchset #1 id:1) has been created in
https://codereview.chromium.org/935663002/ by rockot@chromium.org.

The reason for reverting is: After landing, we've decided there's a better way
to do this. The change history on the bug will be less confusing if we just
revert this change first..