I believe this is an expected side-effect of Incognito/Guest mode's design.

theorywrong311@,

Could you please be more specific, I cannot exactly get what you mean?

The idea here is that, when you have an InPrivate instance open, links opened from external applications open inside that InPrivate instance.

In general, this may be desirable (because, say, you're currently doing bank transactions and don't want to leave local traces. Clicking a link in your bank email in your Outlook Desktop email inbox will open in your Incognito instance, preserving your intent and making it more likely that your login cookies, if any, carry over).

However, this may NOT be desirable. Consider the scenario where you're doing some sensitive browsing on, say, Amazon, and you don't want Amazon to know that you're foo@example.com. However, at some point you put the Incognito instance in the background and click on a link which was emailed to you from your Outlook Desktop email client. If that link contains a peruser tracking token (e.g. https://amazon.com/logemaillinkclick.php?user=foo@example.com&gotopage=1234), you have now sent Amazon an identifier in your Incognito session that binds your session to an existing real-world identity. Now, Amazon can attach your id (foo@example.com) to all of your previous-browsing within that Incognito Session.

Short of asking the user if they want a clicked link to open in the existing Incognito session (probably hard for humans to understand), I don't think there's a very good solution to this.

Thank you for the detailed description, and sorry for delay.

I tried to reproduce it on Windows and Linux, and as I don't have outlook, I tried the following:

1- I closed all Chrome tabs and just opened an incognito one.
2- I clicked on a link in a text editor, and it was opened in a new, regular Chrome tab.

Could you please check if it still happens on the latest version of Chrome, and does it only happen with outlook, or you can also reproduce it with other applications?

I don't see this behavior on Windows, but I do see it with Chrome 68.3397 on Mac. It repros when clicking on a link in the built-in TextEdit application that ships with OS X.

As per c#3, this falls into the grey zone of sometimes being helpful, and sometimes being detrimental. I'm inclined to call it WAI, but the privacy team should take a look to.

Assigning to msramek, who is the new TL of Chrome privacy.

Assigning back to rhalavati@, who's taken eng ownership of Incognito.

Still work on Chrome 66.0.3359.117 [macOS Sierra 10.12.4 (16E195)]

dullweber@,

Could you please take a look at this?

I can also reproduce this on Mac (open incognito window, click help>view license in vscode). Linux, Windows and ChromeOS don't open links from external applications in an incognito mode window so this is probably a bug.

I think I know what is happening:

Linux is using ProcessSingletonNotificationCallback when launching with a url. 
It decides which profile to use based on ProfileManager::GetLastUsedProfileDir(). This is never an incognito profile.

Mac is using "AppController openUrlsReplacingNTP" when lauching. It uses chrome::GetLastActiveBrowser() to decide on a profile. I'm not sure if there might be any other usage of this function that might be affected if I change something here?

Linux stacktrace:
#1 0x7f353ba7bdec content::NavigationControllerImpl::LoadURLWithParams()
#2 0x562c1d7035b9 (anonymous namespace)::LoadURLInContents()
#3 0x562c1d702ec9 Navigate()
#4 0x562c1d72a7ac StartupBrowserCreatorImpl::OpenTabsInBrowser()
#5 0x562c1d72b2d7 StartupBrowserCreatorImpl::RestoreOrCreateBrowser()
#6 0x562c1d72a295 StartupBrowserCreatorImpl::DetermineURLsAndLaunch()
#7 0x562c1d729c7d StartupBrowserCreatorImpl::Launch()
#8 0x562c1d726b63 StartupBrowserCreator::LaunchBrowser()
#9 0x562c1d726771 StartupBrowserCreator::ProcessCmdLineImpl()
#10 0x562c1d728a80 StartupBrowserCreator::ProcessCommandLineAlreadyRunning()
#11 0x562c1c5f7dee (anonymous namespace)::ProcessSingletonNotificationCallback()

Mac stacktrace:
1   libcontent.dylib                    0x00000001109bbef9 content::NavigationControllerImpl::LoadURLWithParams(content::NavigationController::LoadURLParams const&) + 105
2   libchrome_dll.dylib                 0x000000010c359dc7 (anonymous namespace)::LoadURLInContents(content::WebContents*, GURL const&, NavigateParams*) + 599
3   libchrome_dll.dylib                 0x000000010c35977c Navigate(NavigateParams*) + 3452
4   libchrome_dll.dylib                 0x000000010c38cdf6 StartupBrowserCreatorImpl::OpenTabsInBrowser(Browser*, bool, std::__1::vector<StartupTab, std::__1::allocator<StartupTab> > const&) + 390
5   libchrome_dll.dylib                 0x000000010c38cb37 StartupBrowserCreatorImpl::OpenURLsInBrowser(Browser*, bool, std::__1::vector<GURL, std::__1::allocator<GURL> > const&) + 71
6   libchrome_dll.dylib                 0x000000010af3bc24 -[AppController openUrls:] + 244
7   libchrome_dll.dylib                 0x000000010af38fa4 -[AppController openUrlsReplacingNTP:] + 132
8   libchrome_dll.dylib                 0x000000010af3bd9e -[AppController getUrl:withReply:] + 174
9   Foundation                          0x00007fff497fc404 -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 287

I created a CL that should fix the issue: https://crrev.com/c/1025656

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/820ee5fae034922ac3faa5762078339efceef69a

commit 820ee5fae034922ac3faa5762078339efceef69a
Author: Christian Dullweber <dullweber@chromium.org>
Date: Thu Apr 26 13:24:31 2018

Fix external urls open in incognito mode on Mac

On all platforms except Mac, external urls are opened in a regular
window of the last used profile. Mac is using the last used browser
which could be an incognito window. This CL changes urls to be opened
in the last used browser of the last used regular profile to fix this
issue.

Bug:  757253 
Change-Id: I8ced011356c8008560e1802622ab62999ba5e708
Reviewed-on: https://chromium-review.googlesource.com/1025656
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: Christian Dullweber <dullweber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#554002}
[modify] https://crrev.com/820ee5fae034922ac3faa5762078339efceef69a/chrome/browser/app_controller_mac.mm
[modify] https://crrev.com/820ee5fae034922ac3faa5762078339efceef69a/chrome/browser/app_controller_mac_browsertest.mm

This breaks how I've been using Chrome since the start. I explicitly want links to open in incognito of it's the last used window, I don't care about leaking the incognito profile data. The user should be in control here. 

Who are the right people to appeal this decision?

The privacy team does not have any strong opinion towards the "correct" default behavior, but currently the default behavior on all platforms is opening external links in regular profile, and for consistency, we need Chrome to be on Mac similar to the other platforms.

I think if we have this consistent behavior, the users know that if they want opening in incognito, they should open an incognito tab and drag/drop or paste the link there. Is there any specific use case that doesn't match this?
Would you like to file a feature request for selection of the behavior at Chrome level (with ability to choose the default one)?

Dragging/pasting takes a lot more user effort, especially if you want to retain the current behavior of opening a new tab. Dragging requires very precise positioning to drag between tabs in the tab strip, as any other place in the window will clobber. There's a very small drop target, and also much of the window may be obscured.

All this effort replacing the simplicity of a click, without having to move other windows out of the way or engage fine motor skills. From that perspective, this could possibly be an accessibility regression for some users. 

I don't think a user-level flag here is warranted, but changing the behavior of the app for the last 8+ years solely to make it more consistent with other platforms that existing users don't have or use should be reconsidered. 

+msramek,

I agree that the drag/paste effort is not a replacement for the previous simple click, but I think that unless there would be a very concrete reason, Chrome should maintain a consistent behavior on all platforms.

What do you think about requesting to change the behavior on all platforms?

I'd be for adopting the previous mac behavior on all platforms, but it's the behavior I'm used to. I can't speak to what users of other platforms would expect. 

I discussed the issue with privacy team and although both cases are reasonable, the default regular mode has less chance of accidental data leakage and hence preferred by us.

If we keep the current behavior (opening external links in regular), if a user needs to open in incognito, user knows that an explicit action is required.

But if we change it to open in the last opened window, if user clicks on a link that exposes some personal information (like email address) and the link opens in an incognito session which already has other history related to that link, the site will be able to connect these two separate threads of data.

 Issue 868130  has been merged into this issue.

I think that there's a risk of exposing user information whether the window opens in Incognito or not.  Suppose you are shopping on Amazon in a normal window with account A and shopping on Amazon in an Incognito window with account B.

Scenario 1 (pre Chrome 68):  You get an Amazon E-mail for account A and it opens in the Incognito window
If the link included some tracking cookie for account A, Amazon can now associate account A with B since account B has an open session in the Incognito window.

Scenario 2 (Chrome 68):  You get an Amazon E-mail for account B and it opens in the normal window
If the link included some tracking cookie for account B, Amazon can now associate account A with B since account A has an open session in the normal window.

I don't think there's a good solution to this, but my opinion would be to have it open in the last open window (Incognito or not).  This leaves the choice up to the user.  I know that currently, the choice can be up to the user if they copy/paste or drag/drop the link, but that seems cumbersome.

I agree that both cases have a scenario that will expose user data and hence choosing which one is the correct behavior is not an easy decision.
Our general assessment was establishing that Chrome by default opens in regular mode, will decrease the chance of user surprises. This is the behavior on all other platforms.

This change really breaks my regular workflow. Enough to make me downgrade to old version without that change.

Is there any chance we can make it optional, at least using some flag in the settings?

 Issue 877020  has been merged into this issue.

Thus also makes a bit dent in my regular workflow, and I've also missed this behaviour when using Linux (and would if I used Windows).

I believe letting the user decide is the best thing here, so I would suggest changing all platforms to open links in the last active window.

Short of that, a flag in the settings would be the next best thing.

When you click a link in the regular mode, it opens in a regular mode; and when you click a link in Incognito, it opens in Incognito. The browsing activities in the two modes should be isolated from each other (modulo the explicit user action of choosing to "Open in new Incognito tab"). And by design, Incognito should be isolated from anything that happens outside in the OS, so as not to leave any traces (that's the main point).

Therefore, from privacy perspective, we clearly see opening an external link in a browser as an interaction with the regular mode. The existence of Incognito session should be opaque to apps outside of Chrome, and we should certainly not allow them to inject data in the way the reporter described.

I'm convinced that the new behavior is the right default. Both from privacy perspective and as a more predictable user experience. The user doesn't need to reason about what window happened to be the last one opened, or what platform they happen to be using (that is, I strongly disagree with #19 - we should behave consistently across platforms).

If we want to support opening external links directly in Incognito, from privacy perspective we would again require an explicit user action (such as confirming in a dialog). +mardini@, +maxwalker@ have been recently exploring similar UI flows in a different context.

Re comment #17 about escalating this topic, I believe +rpop@ might be a good person.

I too vote for some user control here. I have personal and work-related accounts for things like Ebay, Amazon, Twitter, etc. I try to keep them separate, the sites recommendation engines might end up recommending things that I don't want showing up at work. There was always the risk that I would open the link in the wrong window, but I've successfully worked this way for years. Since "open in x browser" is a system wide settings, I guess my only option now is to create a whole separate user on my computer to keep these roles separate. 

 Issue 877806  has been merged into this issue.

#30,
The current behavior is opening the link in the regular mode of the last interacted profile. So if your previous approach was to have an incognito window open as the sink for inbound links, you can now have a dummy profile on the browser and open a window of that profile for this purpose.

That's good to know, I can see that being a valid workaround. 

Well, now, when this change was released with new Chrome version I do get personal data leaks every single day.

A lot of this discussion operates under the assumption that the external link being opened is under control of the user. For instance I have several tools that help me login to sites, I click a button, it does some internal magic and api calls, and pops up the resulting link in chrome.

Now that this behavior change I have no way to direct a link from an external program to an incognito window.

Before this change I had the choice to have that link open an incognito or regular mode, now I have no choice but to open in regular mode.

I'll admit, as a developer my workflow is irregular and probably not representative of all users. But this was a really big loss to no longer have the ability to choose this behavior.

Is there any plan to add this as a flag or something I can control or should I open up a new bug "Inbound links don't open in incognito mode, unmasking users"?

IMHO, it's much more likely that opening a link in regular mode would "unmask" someone than opening it in incognito mode ...

I discussed the issue again with the team, and we reached the same decision.

Although it's not as flexible as before, another alternative solution would be changing the command that opens links to include '--incognito' switch. (I am not a mac user, but it's possible on Windows and Linux).

That's sad to hear.

On the plus side, I've re-discovered Firefox, particularly the Multi-Account Containers. Good alternative workflow.

In original scenario, when browsing the site you are giving the site your IP. Your history is already bound to your IP. To give the site extra info via the link does not matter wether it comes through incognito or not.

Guys you broke default behavior on Mac, that I was relying on for years. This is beyond frustrating. I keep incognito window for links coming from chat apps. That's the first attack vector for viruses. Now I'm forced to copy-paste. Do you have statistics on user errors, instead on selecting a link, actually clicking on it? I'm feeling less safe now. And when another app opens a link (during install, or whatever), I have no control at all.

This is BY NO MEANS a bug! I rely on the original behavior quite a lot. This change is really annoying.

I, too, would expect it to open in the last active window since the runtime of Mac apps aren't tied to windows, as they are in Windows and Linux. Thus, Mac users expect this kind of functionality.

(As an aside, Safari works the old way as well).

In the interest of maintaining consistency, can this functionality be introduced as a choice for all users through a flag? Default option of the flag can be the current implementation. Can even be implemented with IncognitoModeAvailability policy, where a value of 4 can indicate this functionality.

It seems that we have a good solution for this:

If you open a guest window as your last window (instead of incognito), the inbound link will open in that. I think it would be a quite easy work around.