For the manifest, we can add a new activity for incognito which has android:enabled as false. Then we can enable the component when the proposed setting is turned on.

We can essentially use the same ChromeTabbedActivity for internal handling. Ted/Maria, thoughts?

I think that would work. We would essentially have IncognitoChromeLauncherActivity matching our existing bouncer that would set EXTRA_OPEN_NEW_INCOGNITO_TAB on the intent and then launch ChromeTabbedActivity the same way that ChromeLauncherActivity does today.

I guess the only concern off the top of my head is that there could be cases right now where we send intents back to ourselves by setting the package name, which we would probably need to change to setting package/class combo to avoid disambiguation dialogs between Chrome and Chrome incognito.

Assign to Kingston for priority.

Grace and I were also discussing allowing other applications to do a context menu "Open in Incognito". That could work the same way as the above -- by specifying a particular launcher in the intent.

That opens a number of questions about who could invoke incognito -- e.g. first parties only? Can CCT be incognito? If so, how do we message to the users that they are opening a different profile. 

From technical standpoint, if we implement the user setting, then what do we do for apps when the user setting is off?

Is it a privacy concern that as soon as we allow incognito intents to be sent to chrome, then any app on the system could do it without user gesture?

Granted, it will make Chrome visible, but we have no way of knowing if the app that sent the intent to us was visible or had a user gesture.

It scares me in terms of apps being able to stuff the incognito cookie jar shared across all your incognito tabs.  Something could log you into some random service and then start a redirect that leaks some previous data that you thought was isolated to incognito.

I think the "safer" yet drastically more annoying thing would be for Chrome to ask for every incoming intent so we can at least control the UI.

I agree with what Ted writes.

Just trying to understand, why is it more of a concern when the incognito cookie jar is stuffed than when a non-incognito cookie jar is stuffed (which I assume the apps are able to do now with an intent)?

Here's my non-privacy, personal, grain of salt thoughts:

Your normal non-incognito cookie jar contains things you are fine having be persisted, shared with external sources, synced to google, etc...

Your incognito cookie jar contains anything that you want to be very private and never shared.

I think cookie stuffing in either profile can be super annoying.  But if it gives a vector for discovering someone's incognito browsing habits then I think we're in a very, very bad way.

Alternative thought,

When we receive an incognito intent from an app, before we start loading a URL we put a dialog in front of the user that says something like:

"This URL is loading in incognito. Be careful. Bad things may happen." It would show up every time, unless the user selected "Never show this again option".

WDYT, Dominic?

Ted and I also talked about the possibility of asking the client to connect to a service so that we could verify the intent sender (the way CCT works today). It does seem a heavy solution from both integration standpoint and implementation, but would allow us to verify the intent sender is in the foreground and the user is aware who started the incognito intent.

The feature request was to give the user the power to decide whether an URL should be opened in incognito mode. I think that if every app needs to opt in to that, this would not be very successful? Or do you think that we can come up with a plan by which every app gets this automatically? If we manage to do that, I wonder whether we can do the extra step that the OS controls the long-press menu and can send the user into incognito mode if the user has decided to do that.

Simply as an interested bystander, I agree with battre@ that this should be a user choice rather than an app choice.  Just like if I was opening a link on the web, I can choose to right click and say "open in incognito".

I think that would be nice too -- but I think it's tricky to implement. Ted suggested that Chrome could host the contextual menu such that the application sends us a set of actions and we show those actions + open in incognito. But I think that would also require quite a bit of work from the application developer and I think it's a bit odd to have Chrome do something like this. I guess ideally such an option could be provided by Android system -- but I don't think that's possible on the existing versions of Android.

The original request is for a full user controlled behavior. But the proposal has discoverability challenge.

I would like to encourage us to explore whether we can provide "incognito" as part of standard api while having explicit user choices.

 

I get that we'd want users to have the ability to open in incognito from any app from the product perspective. I don't know that the benefit gained for the users who would want it is worth the added UI cost (e.g. a setting or showing a dialog or a persistent incognito picker after setting Chrome as default).

On link context menus, "open in incognito tab" is relatively low to the generic new tab option: https://docs.google.com/presentation/d/1zj2eJiE7Dd9OtgbE5wvW6P7Gz8hVw7hOoJCQ2NRnFXk/edit#slide=id.gbc32f2142_0_14

Being as that's within Chrome I presume it would be even lower in other apps. But I'd see context menu option to open in incognito being more useful in the long run vs a tap to open (as it would apply to Custom Tabs users too and only be adding one thing to a context menu.) It would be less discoverable but still handy for power privacy users.

The current method (long press to copy link, open Chrome, create new incognito tab, paste) is certainly cumbersome but perhaps sufficient still for now, until we can get around the cookie stuffing issue. Any way to know if users go that route? (Or at least how many create a new incognito tab on main intent compared to other actions?) I'd be interested in knowing how many determined users we currently have.

> Any way to know if users go that route?
As a boolean answer, yes :)  (I do).

> The current method (long press to copy link, open Chrome, create new incognito tab, paste) is certainly cumbersome but perhaps sufficient still for now
The issue with this is that some apps, like hangouts, don't allow copying just the url.  For instance, if someone messages me "yo, checkout example.com, it's awesome", my only option is to copy/paste the entire message, then go to chrome, open incognito, paste the full message, trim out the non-url text, etc.  As someone who wants to open 99% of links incognito, that's painful.

Could we do something like have an app that registers itself as being able to handle web intents and opens chrome incognito? Users without the app have it auto-open in normal chrome (since it's the default and only opener), and users with it get the choice unless they select "always this action".

> On link context menus, "open in incognito tab" is relatively low to the generic new tab option:
> Being as that's within Chrome I presume it would be even lower in other apps.

Well for myself, who does all browsing 100% incognito, I will just start Chrome, close the initial NTP, open an incognito tab and stay there forever, all links opened from the incognito tab will inherently be incognito tabs.
In this scenario I don't ever touch the "open in incognito tab" menu even once, so the UMA of the menu might not be an extremely precise measure of how often users go incognito. This is only me of course though.

If we think the common case for this can be solved by adding a setting in Chrome as proposed originally, we can start from there.

That might the real issue though. Adding a setting doesn't feel like the right solution to me (wishing we could Do The Right Thing rather than force a choice on the user.)

rdevlin.cronin@ - ick that sounds rough. Any idea why Hangouts wouldn't allow copying the URL?

I am afraid there are many apps don't offer to copy only url.
LINE, another messaging app hugely popular in east Asia; pixiv, a east Asia version of DeviantArt; and the world-class, Twitter. Just to name a few.

These apps are designed to be sharing-centric, their context menus mainly offer an option to share instead of a straight copying.
Twitter in particular brings up an intent picker loaded with TONS of targets to share to, then there is an intent somewhere in the mess to copy to clipboard.
And then copying a whole tweet copies an awful lot of non-url text to be trimmed. Open a link in Twitter app in incognito can literally cost one minute that I end up just use the mobile site of Twitter instead of the app.

Also there are links never give you a chance to copy anything, such as many in-app announcements, provided a "learn more" button. A long press on these buttons will do nothing (if not directly open it when you release), there is virtually no any way to browse them incognito.

So IMHO any sort of execution of the proposed feature will improve things on a degree. As long as it makes impossible possible it's helpful than forced no choice.

I found myself in a similar situation where I was looking for an intent that allows me to start Chrome in incognito mode. Since such an option is not available, I ended up installing Ghostery and use that as my primary browser on mobile now.

It seems like there are two use cases:

1) A user always wants to browse everything incognito. The setting proposal above seems like a good solution for this use-case because then the user could just hit "Always" on Incognito Chrome and enjoy all links going to the Incognito. This type of user would also be more likely to find a buried setting to do this. I think whether we should actually do this depends on how many users we'll get who use this setting, I wonder if we have a way to estimate this.

2) A user sometimes want to open links in incognito (e.g. an option to have some suspicious link go to incognito). Then the user-case above isn't particularly useful because even if they had turned on the preference (which they probably wouldn't have), they would always be spammed by intent picker or they wouldn't get the choice when they needed it. Providing apps with an ability to open in incognito is only a partial solution because only some of the apps would implement it. And even if we did want to, we don't have a good solution for cookie jar stuffing concerns. I also don't think we really want to prominently encourage people to open everything in incognito because that's not generally a great user experience (e.g. you don't get search autocomplete suggestions in omnibox in incognito and many other features).

I wonder if we could do something clever for this second category. If for example we knew that certain domains are more likely to be opened in incognito, then we could provide a one click option for the user to open the URL in their clipboard in an incognito tab. However, I guess we'll have trouble doing so since we can't collect data about what the users visit while in incognito mode...

+maxwalker as the privacy/security UX contact. Worth checking with sbirch@ on how CCT is doing in this area too.

With the Herb rollout, I think this will likely have to be some kind of CCT solution so passing on to Sam. Feel free to comment otherwise. Maybe with some kind of long-press action?

Oh, yes! We're planning to address (2) per #23.

Internally see: https://docs.google.com/presentation/d/1r0T1PJPNqAUfkdLOuSPslGErMM58Y-ajcOvYVTsl_Yk/edit#slide=id.g1ca6718d4c_0_227