API proposal review: the public version of the Launcher Search Provider API

[Yuki Awano]

Hi,

We want to go through the API proposal review of the "public version" of the Launcher Search Provider API before we enable it on Dev channel (http://crrev.com/1205893002).

As the API itself, it's almost same with the white listed version of this API.

I updated the API proposal to the public version of this API.

API Proposal: Launcher Search Provider API

https://docs.google.com/document/d/17fEXlEWI71xpXn00XF_Al7pxEUkKyy7bW34EUwjpkCg/edit

The followings are the keys points of the public version of this API.

• We will go with install time permission with warning message.
  
• We use the relevance score which are provided by apps/extensions. User can disable spamming/annoying app/extensions by uninstalling them.

PTAL. Thank you!

Reference:

https://groups.google.com/a/chromium.org/d/msg/apps-dev/Wzy-VUCYWGM/hf0bwnbucRgJ

[Benjamin Kalman]

On Thu, Jun 25, 2015 at 3:09 AM, Yuki Awano <yaw...@chromium.org> wrote:

• We will go with install time permission with warning message.
  

Is there some background for this decision? We try very hard to avoid installation warnings, and I can imagine other (more effective) ways to grant this capability - which ties into Adrienne's point. For example, you say "user can disable spamming/annoying app/extensions by uninstalling them". An alternative would be to allow "blocking" apps/extensions from the launcher search, and have apps/extensions start off in this blocked state (with appropriate, contextual prompting to allow them).

[Yuki Awano]

We've considered both install time permission and runtime permission.

We have two reasons that we think install time permission is better for this API.

The first reason is that this API does not have specific context.

The most benefit of opt-in permission is that the application can provide its context to a user.

For example, it's reasonable that camera application requests photo-capture-permission when user press capture photo button.

But for this API, when would be the best time to prompt to a user?

The second reason is to keep consistent with platform.

Most extension APIs use install time permission except the API has a specific context.

[Adrienne Porter Felt]

I accidentally sent from the wrong address before:

Have you talked to the Proteus team about this API at all? I suspect it could have search spam implications and the Proteus teams might have thoughts on how to message or harden it.

[Benjamin Kalman]

We've considered both install time permission and runtime permission.

We have two reasons that we think install time permission is better for this API.

The first reason is that this API does not have specific context.

The most benefit of opt-in permission is that the application can provide its context to a user.

For example, it's reasonable that camera application requests photo-capture-permission when user press capture photo button.

But for this API, when would be the best time to prompt to a user?

I agree that contextual permission prompts are far superior to install prompts, which is why you should always aim for them when possible.

In this case, a strawman could be the first time you try using the launcher when an extension/app has been enabled for it, show a card inline (where you'd usually surface search results):

"My Extension wants to show search results here. It can read what you type. [Allow]."

This is absolutely contextual.

 

The second reason is to keep consistent with platform.

Most extension APIs use install time permission except the API has a specific context.

Like I said we are trying very hard to migrate existing APIs to use a contextual model.

[Matt Giuca]

On Tue, 30 Jun 2015 at 02:34 Benjamin Kalman <kal...@chromium.org> wrote:

We've considered both install time permission and runtime permission.

We have two reasons that we think install time permission is better for this API.

The first reason is that this API does not have specific context.

The most benefit of opt-in permission is that the application can provide its context to a user.

For example, it's reasonable that camera application requests photo-capture-permission when user press capture photo button.

But for this API, when would be the best time to prompt to a user?

I agree that contextual permission prompts are far superior to install prompts, which is why you should always aim for them when possible.

In this case, a strawman could be the first time you try using the launcher when an extension/app has been enabled for it, show a card inline (where you'd usually surface search results):

"My Extension wants to show search results here. It can read what you type. [Allow]."

This is absolutely contextual.

And I'm not a fan of adding a prompt to the App Launcher UI. Aside from being annoying (and extra work for us), I don't think of this as contextual, because it isn't in response to a user gesture in the application.

A contextual prompt is like when I click "Take Photo" in the app and then a prompt appears asking for Camera permission. That makes a lot of sense to the user.

Whereas in this case, you're talking about installing an app, and then at some unspecified time later, the user tries to use the App Launcher to search, and gets prompted about some app that they aren't even necessarily using. I think that prompting the user at install time is more contextual because at least they're thinking about that app (whereas the App Launcher is a totally unrelated piece of UI).

The problem I have with the current proposal is not contextualization, but the inability to opt out. It has the classic permission problem of having to choose between accepting the permission, or ditching the extension. So ideally we would have a way to set optional permissions at install time. But I think that is a general problem to solve, and shouldn't have a specific solution made for this particular API. (And we shouldn't block the launch of this API on that feature.)

[Ben Wells]

On Thu, Jul 2, 2015 at 6:30 PM Matt Giuca <mgi...@chromium.org> wrote:

On Tue, 30 Jun 2015 at 02:34 Benjamin Kalman <kal...@chromium.org> wrote:

We've considered both install time permission and runtime permission.

We have two reasons that we think install time permission is better for this API.

The first reason is that this API does not have specific context.

The most benefit of opt-in permission is that the application can provide its context to a user.

For example, it's reasonable that camera application requests photo-capture-permission when user press capture photo button.

But for this API, when would be the best time to prompt to a user?

I agree that contextual permission prompts are far superior to install prompts, which is why you should always aim for them when possible.

In this case, a strawman could be the first time you try using the launcher when an extension/app has been enabled for it, show a card inline (where you'd usually surface search results):

"My Extension wants to show search results here. It can read what you type. [Allow]."

This is absolutely contextual.

And I'm not a fan of adding a prompt to the App Launcher UI. Aside from being annoying (and extra work for us), I don't think of this as contextual, because it isn't in response to a user gesture in the application.

A contextual prompt is like when I click "Take Photo" in the app and then a prompt appears asking for Camera permission. That makes a lot of sense to the user.

Whereas in this case, you're talking about installing an app, and then at some unspecified time later, the user tries to use the App Launcher to search, and gets prompted about some app that they aren't even 

necessarily using.

Its worse than this - you might be prompted about multiple apps you aren't using.

[Benjamin Kalman]

I'm not talking about a modal prompt or anything so invasive.

Google Now (on Android) has a feature where apps can show cards. The UI it renders is a card, which says "<app> wants to show you results in here [allow]". It's a different API of course - apps can't read what you type in the search box, they can only push results in there - but it was the sort of UI I had in mind.

It's contextual because the user has the launcher open, so they're able to see the context in which the permission is being granted. An install warning "<app> can read what you type in the app launcher" means very little to me, despite it being a fairly significant permission.

Are there screenshots of this in action, or a way I can test it?

The unwanted-results issue is not something that needs to be solved in the install warning, and I agree with Matt that there should be a way to control this.

[Matt Giuca]

(Sending again from the right address.)

I'm not sure where we'd show that card, though. This isn't related to Google Now so it doesn't make sense to show it there. The most logical place would be to have it as a row in search results, but that doesn't have any relevance.

Say that I installed an app called "Grocery Shopper" that lets me search for vegetables, a week ago. Now I open the App Launcher (for the first time) and type "StarCraft"... do we display a card in the search results that says "Grocery Shopper wants to read your search queries and display search results."? What does that have to do with my search? It's totally out of context; I can't even remember this random app I installed a week ago, and it's not helpful to me right now.

I think it's *more* relevant when I install the app in the first place to say, "by the way, this app can insert search results", because at least that's related to the app itself.

You can test it by turning on the Chrome flag #enable-launcher-search-provider-api or #enable-drive-search-in-app-launcher (it has been renamed as of 45.0.2446.0).

[Benjamin Kalman]

"Context" is so that the user understands what capability they're giving to an extension. Installation time only gives you the extension, not the context of the capability.

Whether or not you open the launcher to type "starcraft", and at that time you care about "grocery shopper", the reality is that "grocery shopper" can read what you're typing. This is exactly the argument in favour of contextual permission granting. The user is not going to remember that at the time of installation they granted that capability, nor necessarily what a description of it actually means in practice.

I've enabled the flag, but what is a good extension to test this with?

[Yuki Awano]

I've enabled the flag, but what is a good extension to test this with?

Since the API is whitelisted to File Manager for now, you can test it with Drive Search (File Manager). e.g. Try to search files on Drive with App Launcher. 

[Reilly Grant]

Perhaps some sort of promo when you install a new search provider. To avoid frustrating popups it would have a couple of steps:

1. First search after installation a popup, pointing at the search box, would say, "You have just installed $APP_NAME. Would you like to allow it to see what you're searching for and provide suggestions?"

2. If that prompt is ignored later searches would display a butter bar at the bottom of the search results, "Enable new search providers." If this is clicked then a list of unapproved search providers will be displayed.

3. If the 'x' on this bar is clicked then there is no more notification of search providers. There should be a settings page to enable and disable them.

[Benjamin Kalman]

Reilly, that is the sort of thing I had in mind, but omitting step 1.

Unrelated:

A UI comment, after trying this API out, is that it would look better if the name of the extension looked different from the search result itself. For example, the results that the webstore gives have "Chrome Web Store" in grey text, and the result in black.

[Ben Wells]

I don't think there is a clear answer here - I can see both side of the argument. At install time it is hard for the user to understand what the permission means. But if we prompt at search time we could have the system asking about a bunch of apps / extensions that the user may have forgotten about.

Weighed up, I think prompting at search time is probably better if we can build a UI for it that doesn't suck. We'll also need UI to remove the permission in context so users can remove spammy apps etc.

On a different topic, I assume this is just for ChromeOS. Yuki - is that correct?