API Proposal of App Launcher Search Private API.

[yaw...@chromium.org]

Hi,

We would like to propose a new API that allows Files.app to provide file search results to App Launcher Search.

App Launcher Search Private API Proposal

https://docs.google.com/document/d/17fEXlEWI71xpXn00XF_Al7pxEUkKyy7bW34EUwjpkCg/edit?usp=sharing

Please take a look.

Thanks,

Yuki

[Benjamin Kalman]

Does anybody else see the "Drive app is currently unreachable" when trying to open this file? I had it yesterday with another proposal.

Could you add me to the doc with +kalman on some comment? That's how it got fixed last time.

[Benjamin Kalman]

It works if I open in incognito. Weird.

[λ Ken Rockot]

I've hit that problem a few times over the past several weeks. No idea.

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

[Mike Tsao]

Possibly related? https://code.google.com/p/chromium/issues/detail?id=435783

[λ Ken Rockot]

Huh. I think it could be related to that bug. It's happening to me now on multiple devices. If I use a non-corp profile without the Drive hosted app installed, I have no problem opening the doc.

[Yuki]

Thank you for adding/replying the comments to/of the doc.

Almost all discussions seems to have been done.

PTAL before I go to the next step.

App Launcher Search Private API Proposal

https://docs.google.com/document/d/17fEXlEWI71xpXn00XF_Al7pxEUkKyy7bW34EUwjpkCg/edit?usp=sharing

Thanks,

Yuki

[Benjamin Kalman]

Could you resolve the resolved comments and update the doc where necessary? It's a little out of date.

[Yuki]

I resolved comments, and updated the document. As we discussed in the comments, I changed it to go this API with opt-in and silent permission style (when we make this API public). PTAL. Thank you!

[Benjamin Kalman]

I added a new comment about not making this API private. Other than that, lgtm.

[Yuki]

Thank you for the comment, it seems good to me for having a public API restricted to dev channel, and whitelisted to tester extensions on stable channel.

@bengold: What do you think about this? I think there is a benefit of making this API with this style since other developers also can test this API on dev channel. If we are going to go with this way, I need to update the document, and also we need to provide opt-in/disabling an app/extension feature from the beginning.

[Yuki Awano]

SGTM. Yes, if we go with making this API public from the beginning,
even it's only for dev build, we need to provide some configuration UI
to mitigate the privacy concerns and abuse of this API. I though that
the benefit of making this API public from the beginning is that other
developers also can test this API, but if there isn't much demand for
this API yet, it seems to be better to go with private API. I agree
with keeping this API private for M42, and making this API public in
M43 with extra work.

@kalman: How about going with this plan?

On Thu, Dec 18, 2014 at 2:08 AM, Benjamin Goldsmith <ben...@google.com> wrote:
> We actually have a pretty good reason for starting with a private
> implementation of the API:
> - In order to make this API public, it requires significant extra work due
> to a privacy issue. Apps using this API get every single keystroke typed
> into the search box; to fix this privacy concern, we would need a settings
> UI where users can enable/disable individual apps from being in the search
> results. If it's a private API restricted to FIles.app, we don't need to
> build this UI yet.
> - We haven't heard that much demand from other Apps to use this API yet.
> We'd rather launch the Files.app integration first, and then do the extra
> work to make the API public-safe later.
>
> I would like to stay on track for keeping this API public for M42, and then
> talk about doing the extra work to make the API public in M43. Does that
> sound okay?

[Benjamin Kalman]

You could go with the extra-conservative approach of limiting this to canary channel. Basically,

• if a API doesn't end in "private", it's expected to be public
• if an API is expected to be public at some point, it shouldn't end in "private"

[Yuki]

What we want to do is to ship this API earlier for Files.app since there is a need to implement a feature which uses this API.

If we go with this API public from the beginning, it requires a significant amount of work to address issues such as privacy concerns, abuse of this API.

We want to avoid it at now.

While we discussed in the comments about the problems which happens when this API becomes public (because I think it's better to also consider problems at now which will happen when we make this API public later), this API proposal is for private API.

When we make this API public, we'll file another API proposal for it with addressing these issues.

For going this API restricted to dev/canary and whitelist on stable, it causes the situation that we use an API which doesn't have a final review lgtm on stable channel.

IMHO, it's better to avoid such situation.

WDYT?

[Matt Giuca]

Is this about the name of the API (whether it has "private" in the name or not) or whether it is actually private? 

We've had APIs we recently put in (for launcherPage) which doesn't have "private" in the name but it's currently whitelisted for some Google-only apps. I think this is OK (if we intend to make it public later). The difficult part is renaming the API, so we are essentially future-proofing ourselves from having to do that rename.

But I think we should be able to take features to stable without waiting for the APIs to be un-whitelisted.

[Ben Wells]

In these particular cases, the APIs are for things which could be considered currently to be part of ChromeOS. E.g. Drive. We want to open these up, so having these things done via an extension API (e.g. versus a C++ api) is a good way to do it, even if we make it private via a whitelist first if there are gnarly issues in making it public.

[Tomasz Mikolajewski]

Let me chime in. We have two options now:

1. Go with chrome.searchLauncherPrivate in this proposal. It doesn't include UI for disabling particular results, so it must not be used by external apps. That was one of biggest concerns by privacy folks. We don't want to pass all search queries to random apps without good attribution as well as a way to disable it. In the future we'd file a separate proposal for chrome.searchLauncher which is focused on external apps and privacy.

2. Go with chrome.searchLauncher but enable it to all on dev only, while whitelist it to Files app to use on stable. We'd ask for final review of the API without promoting it externally to stable. We can still file a new proposal for an upgrade of the API with the UI and better attribution. 

I like (1) as we can separate things. We can do the private version first, then get the final review. In the future we can file a new proposal for the public version, and focus on privacy in that proposal. No trickiness with whitelisting Files app.

If we go with (2), we'd avoid renaming the API, but it's IMHO little bit more of organizational mess with releasing and reviews.

Note, that we don't want to promote this API to stable to external apps before implementing UI and better attribution. However, we want to start using this API in Files app on stable before implementing those. Simply, we'd like to go incrementally and start from Files app.

Saying than, I'm fine with both (1) and (2). Let's make some decision. @benwells, @kalman, @mgiuca: Are you fine with either of (1) or (2)?

[Matt Giuca]

Why can't we have chrome.searchLauncher but have it whitelisted on all channels? (I don't see why the name and the whitelisting need to be tied together).

Also, I didn't realise it was called "searchLauncher" now. (I know kalman wanted to have "launcher" in the name to distinguish it from a potential future search outside of the launcher.) This name makes me think that it's an API that launches search. Can we rename it to "launcherSearch" (to suggest that it provides search results in the launcher)?

[Yuki]

For making the discussion clear, the name of this API in the current proposal is chrome.launcherSearchProviderPrivate (or chrome.launcherSearchProvider if we go it with public).

[Tomasz Mikolajewski]

As for whitelisting, of course we can do that on all channels, but it doesn't change much. This workflow just sounds confusing to me. Would chrome.launcherSearchProvider be a public or private API? It's not public, as it's whitelisted. If it's private, then it should IMHO have a private suffix. But if that's the common workflow, then I'm fine with it.

[Benjamin Kalman]

The way we always do APIs is to assume they'll be public (so name things accordingly), get feedback early (restrict to dev channel), and often use it now for our immediate use case (whitelist it to whatever on stable channel).

The only unusual thing about this API is that it's unfinished until the full attribution/revocation flow is implemented, so you could argue the scope should be narrower than dev channel, say canary. Either way, make it available to third party developers as early as possible.

Other than that, it's the same as any other API.

[Tomasz Mikolajewski]

I didn't know that it's commonly accepted to start using the API in stable before it's completed. This changes things. If that's the case, then we can go with chrome.launcherSearchProvider. 

One more unusual thing about this API is that we don't know how the final version will look like, yet. The attribution and revocation flow is not yet decided. We sldo plan to add opt-in in the public version, but for now since it's for whitelisted apps, we don't know how it will be implemented. It's quite a lot of things.

After we finish the basic implementation, we will file a new proposal including the things above. The API may change. Are we fine with it?

[Benjamin Kalman]

On Thu, Dec 18, 2014 at 5:12 PM, Tomasz Mikolajewski <mto...@chromium.org> wrote:

One more unusual thing about this API is that we don't know how the final version will look like, yet

That's not too unusual :-) that's one of the reasons we start it in dev actually.

[Tomasz Mikolajewski]

Great! Let's go with chrome.launcherSearchProvider then. @yawano: Could you update the doc?

[Yuki]

Thank you for the discussions. Okay, then we are going to go with whitelisted for Files.app on stable and public on dev channel. I removed 'private' suffix from name, and added "Release Plan of this API" section in the document - https://docs.google.com/document/d/17fEXlEWI71xpXn00XF_Al7pxEUkKyy7bW34EUwjpkCg/edit?usp=sharing .

[Yuki]

@meacer, @jww : Could you take a look at this API proposal? We updated the proposal, and we want a lgtm for security implications. Thank you!

App Launcher Search API Proposal

https://docs.google.com/document/d/17fEXlEWI71xpXn00XF_Al7pxEUkKyy7bW34EUwjpkCg/edit?usp=sharing

[Yuki Awano]

@meacer, @jww : Hi, how about the API proposal is? We want/need a lgtm for security implications before going to the next step. If there is a question or problem, please let me know. Thank you!

[Joel Weinberger]

From a security perspective, I really appreciate the card "opt-in" that is described. This is a great idea and looks really cool and mitigates most concerns I'd have. Additionally, the attribution with the icon in the search results is great.

However, why do Drive and Downloads get a free pass past this? Why are they special? I can imagine that many users might want only to search their local machine and not report their searches to drive, so I'm a little disturbed that we implemented and deployed this API whitelisted with this enabled.

All of this is to say, the proposal lgtm with opt-in, including for Downloads and Drive. Like I said before, I really don't see why they get to bypass this opt-in, and I can imagine users being upset about it (and reasonably so), a la the old Ubuntu searches Amazon fiasco.

--Joel

[Joel Weinberger]

Regarding Downloads, good point. That's really just searching the local file system, so yeah, fine by me.

The Gmail case is different in that you're aIready at a Google property, online. In this case, you're searching locally, so it would seem surprising (to me at least) that all of a sudden, my searches were going through Drive. Is there any way to do the search for already-downloaded Drive files? That is, for V1 can you make it search the local Drive folder rather than pinging the app? Then, in V2, with the proper opt-in system, you can it ping Drive so it can sync and get up to date and what-not?

On Wed Jan 07 2015 at 3:01:25 PM Benjamin Goldsmith <ben...@google.com> wrote:

Hmm, if we show the opt-in card for Drive/Downloads, we then have to build the UI for users to opt out for V1. We wanted to limit search over Drive and Downloads so as not to build the opt out UI for V1. 

Searching over Downloads seems non-controversial, since it's fully local. We also have precedent for searching over Drive from other search boxes -- Gmail search shows suggestions from Drive, for example. Is moving Drive to opt-in a blocker for you, Joel/

[Ben Wells]

I don't understand the problem with Drive. This is just for ChromeOS where Drive is a bundled part of the platform.

[Yuki Awano]

I don't think searching only already-downloaded Drive files (available offline files) is a good idea.

It seems very confusing for a user since Files.app don't tell a user which file is offline or online clearly except they click the context menu of a file.

I think this is by design because it's better that a user can use Drive without thinking which file is online or offline.

In addition, i don't think this search box is limited for a local search at now because it already shows web app store search results in it.

[Ben Wells]

I just realised the proposal doesn't explicitly mention ChromeOS at all (although it does mention Files.app which is ChromeOS only). Can someone working on it verify that this is something we're only rolling out on ChromeOS at the moment?

[Yuki Awano]

Thank you. I added a description in the API proposal for explicitly saying this API is rolled out only for Chrome OS.

API proposal

https://docs.google.com/a/chromium.org/document/d/17fEXlEWI71xpXn00XF_Al7pxEUkKyy7bW34EUwjpkCg

[Mustafa Emre Acer]

Thanks Yuki, I'll defer the security LGTM to Joel.

[Joel Weinberger]

Just because Drive is bundled with ChromeOS doesn't mean every user wants to use it, just like "Keep" or "Spreadsheets." This is in direct contrast with the Web Store (which, as Yuki pointed out, is currently searched in the search box) since it is necessary in using ChromeOS (for installing, uninstalling, etc.).

That having been said, this really seems ultimately like a privacy issue, so I've cc'd battre@. Dominic, what are your thoughts on this?

--Joel

[Tomasz Mikolajewski]

I didn't follow all the discussion, but FYI Drive can be disabled in Chrome OS in settings, if a user doesn't want to use it.

[Yuki Awano]

As Tomasz pointed out, if the Drive can be disabled in Chrome OS settings, it means that Drive isn't necessary for using Chrome OS. In that sense, Drive is opt-out in Chrome OS, and it makes sense to make this feature opt-in also for Drive (at least, this feature can be opted-out for Drive).

While it will take more time, it may be better to implement the opt-in feature/UI from the begging of the implementation of this API.

Even if we decided Files.app(Drive/Download) to be whitelisted, we need to implement it later.

@bengold, WDYT?

[Matt Giuca]

On Fri Jan 09 2015 at 12:39:15 PM Yuki Awano <yaw...@chromium.org> wrote:

As Tomasz pointed out, if the Drive can be disabled in Chrome OS settings, it means that Drive isn't necessary for using Chrome OS. In that sense, Drive is opt-out in Chrome OS, and it makes sense to make this feature opt-in also for Drive (at least, this feature can be opted-out for Drive).

I don't see how that follows. Since it is possible to opt out of Drive on ChromeOS (which I didn't know about until now), wouldn't it make sense to tie this feature to that opt-out?

i.e., Drive search is on by default but if the user opts out of Google Drive, then the app launcher Drive search is also disabled. That sounds perfectly reasonable to me.

[Zelidrag Hornung]

+drewry

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

[Joel Weinberger]

On Mon Jan 12 2015 at 3:42:40 PM Benjamin Goldsmith <ben...@google.com> wrote:

Thanks Will! Some replies inline.

On Mon Jan 12 2015 at 2:33:06 PM Will Drewry™ <dre...@google.com> wrote:

On Mon, Jan 12, 2015 at 12:12 AM, Zelidrag Hornung <zeli...@google.com> wrote:

+drewry

On Thu, Jan 8, 2015 at 7:43 PM, Matt Giuca <mgi...@chromium.org> wrote:

On Fri Jan 09 2015 at 12:39:15 PM Yuki Awano <yaw...@chromium.org> wrote:

As Tomasz pointed out, if the Drive can be disabled in Chrome OS settings, it means that Drive isn't necessary for using Chrome OS. In that sense, Drive is opt-out in Chrome OS, and it makes sense to make this feature opt-in also for Drive (at least, this feature can be opted-out for Drive).

I don't see how that follows. Since it is possible to opt out of Drive on ChromeOS (which I didn't know about until now), wouldn't it make sense to tie this feature to that opt-out?

i.e., Drive search is on by default but if the user opts out of Google Drive, then the app launcher Drive search is also disabled. That sounds perfectly reasonable to me.

 

Today, we only send keystrokes from the launcher to the webstore if

is checked. Additionally, we only use Drive if 

​

is not checked.

[ It's kinda weird that we don't include Apps in the omnibox search since it is in the launcher, but whatever :) ]

From a user perspective, I think we are okay if we want add Drive to the launcher search since we already use a Google service for most users for what they type into the launcher (and it must be explicitly gated on the above checkboxes) and if prediction is on, you will often get a doc from your history anyway.  If we did not use a Google service, then I would say we _must_ get explicit user acceptance -- outside of Google, Google is Google. If we snarf the bytes into any service, then the privacy impact is already occurring.

Totally agree with this.

 

That said, I'd want to check with pcounsel (always :) about this change happening without users being informed in any way, and I'd like to make sure we're being careful about playing favorites too much.  Will Drive be in whatever unified control panel for the launcher search sources that third parties will be in some day?

Yep! That said, we aren't even sure if or when we'll open this up to third parties. There's been very little demand for it. We're going through this exercise in case one day we decide to open it up.

 

I think it'd be the wiser/more conservative approach to offer the card for Drive like we're saying for third parties on sign-in after an update to Mstone-whatever.  If we want to flip that card for Drive to make it be a "disable" instead of "enable", that might hit the right balance (given the above two controls).

It's more conservative; I don't think it's necessary though.

 

Dominic, am I way off?

Joel/enamel,  does this make sense to you guys? 

Tying it to the Drive setting makes sense to me, and making it clear from search that there's an easy way to opt-out also makes sense. I'm still deferring to Dominic, though. 

One more question, how are file types handled from the launcher?  For instance, in Files.app if I click on a jpg, I see it in the local Gallery app, NOT in a drive viewer.  Will this funnel to local apps, and how -- or will it funnel to drive only?

It would use the user's default app to open it with. Users can register a default app in Files.app (for jpg, it's by default the Gallery) and if the user has registered some other default handler in Files.app, it would funnel to that.

 

Thanks!

will