Default host permission grants during installation

[Simeon Vincent]

Chrome folks, would it be possible to get an update on how the Chrome team's current plans with respect to default host permission grants during the installation flow?

Back at CDS 2020, the extensions team gave a talk where they said "In a future release, Chrome will no longer grant declared host permissions at installation time by default" and later included the following napkin sketch of the updated installation prompt. Note that the default option in this sketch is "on excretion activation."

During I/O 2023 the extensions team gave a talk that revisited this topic and said that "we're also exploring how to give end users easier ways of toggling host permissions at install." There were several UI mocks that accompanied this image (I've only included one here), but notably all of them appeared to default to "On all sites."

I realize that this change has not been finalized and there is probably still a good bit of testing to be done, but I'm curious, how the Chrome team is currently thinking about default host permission grants during installation? Any information you can share would be greatly appreciated as it will help inform the strategies developers use and development schedules.

Simeon - @dotproto

[Simeon Vincent]

Apologies, my original framing was a bit too vague. I have two specific questions for the Extensions team:

1. Does the Extensions team currently plan to default to "on all sites" as the default value?

I expect that the default setting will have a massive impact on grant rates and, by extension, the scale of the changes extension developers will have to make to their UX. All of the example UIs show in the recent Google I/O talk seemed to use "on all sites" as the default value, but clarification here would be extremely useful.

2. Will Chrome share statistics about how many Canary users change this setting and what they change it from/to?

Amalgamated data would help extension developers better predict how the change will impact their individual extensions. This in turn will help developers better understand how this change will impact their user retention rates, support request volume, etc.

Simeon - @dotproto

[Uladzimir Yankovich]

If it's not too late, I would like to express my opinion from the developer's point of view.

Developers should be able to limit the possible responses for their extension.

For example, we don't want to support and process various cases if the user refuses to provide us with all_host. In fact, without this permission, our extension is broken and cannot correctly execute its one proposal. Therefore, this is my requirement as a developer. If the user disagrees with this, let him not install the extension.

I worked as a product manager for a huge browser. I understand that Chrome, as a platform, should take care of its end users. But this price should not be paid by extension developers. If you give a choice to users, give it to developers.

[Simeon Vincent]

Yankovich, are you asking for a way to prevent users from using an extension if they don't grant broad host permissions? If so, I think the platform already provides the necessary tools for an extension to check its permission grants and to limit its own functionality, to disable itself, or even to uninstall itself. To my knowledge there are no policies or procedures that would prevent extension developers from implementing that kind of behavior.

Simeon - @dotproto

[Uladzimir Yankovich]

Not really. I believe that the extension should have the ability to mark host resolution as mandatory so that the user does not have the ability to change the choice and set it with a different option.

I don't understand why the user should install a broken extension without realizing it himself, and I should keep track of it and then teach him how to fix it.

It reminds me a lot of the situation with the fact that users of any browser can install extensions from the Chrome Store and write reviews. And I don't want to support other browsers. Why should I get 1 star in the Chrome Store from Edge users?

Of course, the platform has to take care of itself and its users. Just always remember that developers are platform users too.

 

--

Uladzimir Yankovich,

Founder @ Manganum (manganum.app).

[Jackie Han]

Below is a joking example to solve the problem :)

chrome.permissions.onRemoved.addListener(async function(e) {
  // here needs debounce for a short time
  const hasMinimumPermission = await chrome.permissions.contains({ origins: [...] });
  if(!hasMinimumPermission) {
    chrome.management.uninstallSelf();
  }
});

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/CAFc1iR4ni%2BQrnQMhXMYGpEMyLVzOFO4SH8CPU233vt%3DS%3D%3D0w-A%40mail.gmail.com.

[Uladzimir Yankovich]

It's funny and sad :)

[Oliver Dunk]

Hi Simeon & Uladzimir,

Thanks for the questions (and sorry for the delay, there’s a lot of active discussion here so I wanted to make sure that what I said properly represented our thinking).

To answer each of your questions individually…

Does the Extensions team currently plan to default to "on all sites" as the default value?

I’m afraid we don’t have a specific answer here right now - we’re still working through a lot of the details and we’ll definitely share some thoughts when we get closer to making any changes. What I can say is that our goal at I/O was to share a vision for generally giving users more control over permissions (I hope you like the designs!) and that we’re very aware of the potential churn for developers here.

Will Chrome share statistics about how many Canary users change this setting and what they change it from/to?

I think it’s too early to commit to sharing any specific statistics. More generally, though, these are the sorts of changes where I want to make sure we do as much communication as possible.

> Developers should be able to limit the possible responses for their extension.

I’d be interested to hear about the use cases you have in mind - in most cases I’ve seen (especially outside of enterprises where there are other options through policy) extensions usually degrade fairly gracefully when they don’t have permissions for a specific site.

As Simeon mentioned, there’s also the chrome.permissions API which allows you to check your permissions, and could be used to request additional permissions if needed: https://developer.chrome.com/docs/extensions/reference/permissions/. I think that’s an API we should continue to expand where needed to make sure there’s enough control for developers.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--

You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/bcd85a9e-ea6a-44da-9bfd-7519c05cb24dn%40chromium.org.

[Uladzimir Yankovich]

Oliver, on the one hand. I agree with you - in web development, and especially in extension development - everything is possible, you can always find some kind of workaround.

On the other hand, it is an additional job I am forced to do. And the saddest thing is that it is not even a genuine concern for the user. You invite him to make a choice when he cannot make it consciously. He is not yet familiar with the product, its features, and its UX, and you ask him this question? On what basis should he answer it? Based on phobias? Past experience with other products?

I believe that a developer should have the option to declare minimal hosts in the manifest without being able to change them. Fill out an additional field before submitting for moderation to explain the reason for this.

[Simeon Vincent]

I have a simple question on this - Is this functionality (giving users the ability to control host permissions for each extension at the time of installation and/or during runtime) limited to MV3 extensions only?

In the extension team's Chrome Dev Summit 2020 talk I shared that "site access restrictions will apply to all extensions, regardless of manifest version." I no longer work for Google, but to the best of my knowledge this is still the plan. 

I don't understand why the user should install a broken extension without realizing it himself, and I should keep track of it and then teach him how to fix it.

The short answer is "security." The slightly longer answer is "the developer is responsible because they are the party trying to do something dangerous." Let's take a look at another ecosystem with a similar issue.

Users tend to be cautious about camera access on their phones. Actually, users have been so concerned that mobile phone OSs won't give out camera access by default. Instead, apps often only request camera access as part of an onboarding flow or when the user taps on a camera button in the UI. The app wants access, so it has to convince the user to grant that access. 

Why do camera app developers have to educate users about the permission, make sure it's granted, and guide users if it's not? Because camera access is simply too dangerous to hand out without explicit, informed user consent.

It's not a perfect system. It's possible for developers to abuse permission requests, for users to accidentally grant access, or for users to misunderstand what they're being asked to do. But by and large I think the consensus in the world of consumer devices is that in-context permission requests are more informative and understandable than their install-time counterparts.

You invite him to make a choice when he cannot make it consciously. He is not yet familiar with the product, its features, and its UX, and you ask him this question? On what basis should he answer it? Based on phobias? Past experience with other products?

I think you're saying that users shouldn't be able to change host permission grants during the installation flow because they don't have enough context to make an informed decision. Assuming I have that right, I don't follow that argument. To be honest, what you wrote seems more like a list of reasons browsers shouldn't grant any host permissions at install time.

A first time user has never seen this product. They don't know what it does or how it does it, they don't know when it will use the capabilities it's requesting or why, what kind of UX the extension will provide, or what tradeoffs the developer had in mind when designing the extension. Given the myriad ways host permissions can be abused and how bad that abuse can be, your line of questioning suggests that the user shouldn't even be asked or they might accidentally give out persistent access to all of their online activity.

You posed the question "On what basis should he answer it?" I would say that they should not trust it. Instead, they should test it on a couple of unimportant websites, evaluate how it's performing, pay attention to what capabilities it's requesting and why, and slowly build up trust in the tool. Only after they have a good amount of experience with and trust in the extension should they begin to consider granting it access to everything. And even then they should only do so with caution.

I'd suggest thinking of the control in the install dialogue as a power user feature. If you've already used this extension before and trust it, you can give it access to all of your web traffic. If you haven't, err on the side of caution and let the extension sell you on its value.

Simeon - @dotproto

[Oliver Dunk]

I wouldn't see this as a workaround - we intentionally provide permission APIs to allow developers to request permissions if needed. Your extension should never be broken, but should instead have handling for the different permission states it can be in and guide users to address those. A developer can already change your "all sites" extension to run on specific hosts so this is a problem that you should really handle today.

I definitely appreciate how this can be hard as a developer though, and as mentioned we haven't made any decisions here yet. What we showed in our I/O talk was just UI mocks for now.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Uladzimir Yankovich]

Great discussion.

Simeon, thank you for your reasoning. I think you gave a great example. And I want to support and expand on your conclusion.

Indeed, in Android, most of the dangerous permissions have been relegated to optional permissions. Now you have to get them by user gesture in the context of the operation for which those permissions are needed. And this has worked great. The main reason is that this behavior for all apps, and for the most popular and small ones, quickly formed new patterns for most users.

Following this analogy. I must admit that completely moving host permissions to optional permissions would be a fair and convenient solution for everyone: platform, users, and devs.

[Cuyler Stuwe]

My take on this is to basically hard-leverage optional permissions and stop relying on CWS for presentation.

Essentially:

1. Make literally all permissions optional, so that the user is not prompted with anything at all during install time.

2. Request all runtime permissions after install by opening a new tab. Just as with the pattern we're seeing with OSX apps these days, explain to the user in an onboarding phase what each permission is meant to do.

3. Gate all access to the extension's functionality if the user hasn't accepted a minimum set of requirements that makes sense to do its job. Instead, if the user tries to use the extension while in a state of having accepted insufficient permissions, redirect them to the onboarding page where they can complete the checklist.

[Cuyler Stuwe]

All of this makes sense for a greenfield project, mind you, but it can be a major pain in the ass to implement in a legacy extension that has any meaningful amount of complexity and relies on these permissions to always be present.

[Uladzimir Yankovich]

I agree. It looks like a challenging but understandable and logical solution.

[Jackie Han]

It is not easy for users to accurately understand the meaning of permissions. Cameras, bookmarks, and notification permissions are easy to understand, but it is not easy to explain the meaning and dangers of Host permissions (and a few other permissions) to users, which are often misunderstood even if the users are developers. And many users often ignore its dangers.

The cost of educating users is high. For example, Google has made a lot of promotional videos and text introductions to how the search engine works and user privacy issues.

Browsers often warn about the dangers of permissions. But I rarely see browsers explaining to general users how extensions work and what each permission means, and how to judge the necessity and reasonableness of permissions. On the other hand, I also rarely see extensions explaining the meaning of permissions in detail, which of course adds extra work.

Browsers, developers, and users are all responsible for the issue of permissions. I think browsers should invest some resources in educating users, not just developers.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/3e45ef39-d73a-4d25-88e0-f0d22a0b7316n%40chromium.org.

[Cuyler Stuwe]

Definitely.

One of the things that makes it so difficult is that the warnings don't actually warn about "what the permissions do".

Instead, the warnings provide only one specific example (usually a worst-case scenario) of how they can be misused.

And some are misleading.

"tabs", for example, warns users that it can "read your browsing history".

This is a warning that I think is actively misleading for most users, as it seems to users that you're asking for effectively what's in chrome.history.

Most users don't think of their actively-open set of tabs as "history", but instead think of it as something like e.g., a "session". It's the present, not the past.

It feels like an engineer said "well, technically a user could have done the entirety of their web browsing by simply opening thousands of tabs, so we can't categorically eliminate this possibility in a mathematical sense."

[Chris Zalcman]

Hi Simeon! Do you have any statistics that the Chrome extensions platform is being used by many extensions for other i.e. bad purposes? If not, then why make such draconian changes? I do not see any benefit here for both users and developers, only troubles. But for the company this is very good, because people will use extensions less and less, and with troubles, and Google will be able to use more data in the end user personalization?

[Chris Zalcman]

With such new installation flow, it is already becoming easier to make an executable, sign it, then put it on the Microsoft store and thousands other resources. But in this case there will be no consensus. So for us it is unclear why Google want to open Pandora's box and completely lose currently powerful applications platform on Windows?

[Oliver Dunk]

Hi Chris,

Simeon no longer works at Google and wouldn't have any statistics to share here.

I'm not sure what changes you are describing as draconian - right now the only thing we have said is that we will be updating existing UI to make it better for users.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

--

You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/65c27c8b-33c2-4905-a9bd-b44e0178876fn%40chromium.org.

[Chris Zalcman]

Hi Oliver, 

Simeon...wasn't he present at the last IO? How quickly things change...

As for the UI, everything is Ok, it's good when an end user has a choice during installation.  By draconian ;) I meant not to disable all hosts by default, everything should be allowed according to the permissions in the manifest.