New issue
Advanced search Search tips

Issue 868712 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: Sep 10
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

Incognito mode secretly logs into (non-incognito) home page

Reported by topherwh...@gmail.com, Jul 29

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0

Steps to reproduce the problem:
1. Set homepage to a service that you log into and that also provides you with popup notifications. (and log in)

2. Close Chromium and reopen it in "Incognito" mode (only).

3. Witness your personal popups, from the site, appear.

What is the expected behavior?
Chromium should NOT access the normal homepage (secretly, in the background).  Incognito mode should be checked-for before attempting to load anything else.

What went wrong?
It showed my personal popup messages even though I opened the browser in Incognito mode!

Did this work before? Yes 

Chrome version: 68.0.3440.75 (Official Build) (64-bit)   Channel: stable
OS Version: 6.3
Flash Version:
 
Components: Privacy>Incognito
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Flipping some labels around so that the right developers can take a look. We don't generally treat issues related to incognito as security vulnerabilities, but rather as privacy bugs.
Labels: Needs-Bisect Needs-Triage-M68
Cc: susan.boorgula@chromium.org
Labels: Triaged-ET Needs-Feedback
topherwheeler@ Thanks for the issue.

Tested this issue on Windows 10 on the reported version 68.0.3440.75 and the latest Canary 70.0.3507.0 by following the below steps.

1. Launched Chrome, navigated to chrome://settings and set www.facebook.com under 'Open a specific page or set of pages' option.
2. Logged into facebook.com and closed the browser window.
3. Launched Google Chrome in Ingonito mode and can observe a new tab is opened.
4. On navigating to www.facebook.com, cannot see any data of the normal window.
Attached is the screen cast for reference.

Request you to check and confirm if anything is missed from our end in triaging the issue.

Thanks..
868712.mp4
1.6 MB View Download
Cc: rhalavati@chromium.org
You need to click "Allow" popup notifications and make sure you are signed into Facebook (all in non-Incognito mode).  Then shut the browser and reopen in Incognito mode.  You shouldn't need to navigate to any particular page in Incognito mode.  The popups (if any) will fire as soon as browser is opened in incognito mode.
Project Member

Comment 6 by sheriffbot@chromium.org, Aug 1

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: Needs-Feedback
topherwheeler@ thanks for the update.

Re-tested this issue on Windows 10 on the reported version 68.0.3440.75 and the latest Canary 70.0.3508.0 as per comment #5.

Couldn't observe any popups of the Non-Incognito window in the Incognito Window.
Attached is the screen cast for reference.

Request you to provide the URL where this issue is observed which will help in further triaging.

Thanks..
868712-1.mp4
2.7 MB View Download
That looks good, so far.  But you actually have to get a notification from the site (even though you're not "there", of course, when in incognito mode).

I'm not super social so I don't get many notifications.  If I ever do get another one then I'll be sure to record the behavior.

It happens for me when I'm logged into Youtube, but visiting the otherwise completely unrelated https://techdevguide.withgoogle.com/paths/advanced/ (my chromium homepage), and someone replies to a comment I've made on Youtube.

If I ignore the notifications and close & reopen in incognito mode.  Then I receive the notifications (again, without having to navigate anywhere).

If you create a page that automatically (without user interaction) sends a notification, and pre-"Allow" it, set it as your homepage, and click your heels ten times then you might and go incognito... then I think my work here is done. =]
Project Member

Comment 9 by sheriffbot@chromium.org, Aug 1

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Needs-Bisect
Unable to reproduce the issue on Win-7 using chrome latest stable #68.0.3440.84 and latest canary #70.0.3509.0.
Observed that incognito mode did not secretly log into (non-incognito) home page.

As the issue is not reproducible from TE-end. Hence, removing Needs-Bisect label and requesting someone from Privacy>Incognito team to please have a look into the issue.

Thanks...!! 
Well I created a page to test it but apparently Chromium doesn't allow local notifications from non-httpS sites (gimme a freakin break, please -- no chrome://flags option -- c'mon! =P ) but Firefox does.

So I was able to create a page which should demonstrate the behavior.  It will need to be accessed from a HTTPS site.  I am extremely busy, if I find time I will upload it to a publicly available server later.  (or the HTML file is attached, so feel free to attempt it)

Shoot.  Forgot to request permission for notification, in last file.  Firefox doesn't even ask for permission from local notifications (where's the happy medium ?!) so I forgot to implement it.  This file should fix that.
notification.html
770 bytes View Download
Labels: TE-NeedsTriageHelp
Unable reproduce the issue as per comment#12 on reported chrome version #68.0.3440.75 and latest chrome version #70.0.3543.0 using windows 10 by following steps in comment#0.As the issue is not reproducible from TE-end, hence adding TE-NeedsTriageHelp label and requesting anyone from Privacy>Incognito team to look into it.

@reporter: Could you please check if the issue is seen on recent chrome version #69.0.3947.81, as recently the stable has been rolled out to M-69.You can download the latest chrome builds from the link "https://www.chromium.org/getting-involved/dev-channel".

Attached screencast for reference.
Thanks.!
868712.mp4
3.9 MB View Download
Cc: peter@chromium.org
Components: Blink>PushAPI
Owner: peter@chromium.org
Status: Assigned (was: Unconfirmed)
I think these are just push notifications?

When you allowed notifications to facebook.com, the website registered with a push notification server. Notifications are routed through that server to the service worker that had been installed in the browser when you visited the website in the regular mode. This is independent from the fact that you're visiting the website in another tab or in Incognito.

Adding peter@ to sanity check. I think this is WAI, but I see where the confusion comes from, and there may be some UI treatment to help address it.
@Peter I think that you are probably exactly right.  I generally use Incognito mode when I want to be completely disassociated with _all_ of my personalized site content (including, of course, push notifications) because I will sometimes allow somebody else to use my PC and I don't want them getting my personal notifications (for several reasons).

Being a "private" mode, it would make sense (at least to me) if things err towards the more privacy-respecting of the available choices.

Thanks for all of the hard work.

Status: WontFix (was: Assigned)
This indeed is WAI. Notifications can only be enabled in non-Incognito sessions to make sure that the two modes don't mix. Chrome aims to deliver received notifications as soon as they're received, and will load the associated profile in the background if it hasn't been opened yet.

Because we now use native notifications whenever we can, I don't know what sort of UI treatment we could apply here that wouldn't just add more confusion. Happy to consider if anyone has ideas :).
Seems like the two modes are indeed mixing.  Maybe the "associated profile" shouldn't be associated with Icognito's private browsing --it should use a generic profile that's not attached to any individual's web preferences (unless specifically enabled for/in Incognito mode, as a possible option).

Then, for example, when I open my browser (non-incognito) I will get _my_ messages as intended because the profile with my cookies (or whatever) is loaded.

If the regular user already has Chromium browser running (as a foreground application or a background process in non-incognito) then it should be fine to allow notifications through.  But if incognito is the first (and only) mode launched, then the push notifications shouldn't automatically appear.

[I would say the same too for things like URLs and Bookmarks, but I know that would be pushing it]
> it should use a generic profile that's not attached to any individual's web preferences

That's the Guest mode. Incognito, on the other hand, is able to read some preferences from the underlying regular mode profile (just can't write any changes back)

> if incognito is the first (and only) mode launched, then the push notifications shouldn't automatically appear

I think this might be technically difficult to do. Even if you only have an Incognito window open, the underlying regular profile is already initialized. Exactly for the reason described above - there are settings and other state that Incognito "inherits" from the regular mode.

I agree though that this might better match user expectations. rhalavati@, any opinions?
I think it's best if notifications are not received and shown when the respective profile is not already open, but that's a feature request from notification team. 

peter@:
What happens now if user registers a notification in one regular profile, and has another regular profile open when one is sent. Does s/he receive the notification? If not, can't we accept notifications only if a profile has an open window?
Something similar to Android's slide-down notification drawer (in any form: button, icon, ...) which let's the user, via indication, know about pending notifications enqueued.  It would then become the user's choice of whether to view the notification(s) and whether or not they persist.

As an accompanying possibility, opening a particular profile could activate it.  Whether or not the profile persists in the background could be based on the "Continue running background apps when Chromium is closed" setting (or something equally simple).
> What happens now if user registers a notification in one regular profile, and has another regular profile open when one is sent. Does s/he receive the notification? If not, can't we accept notifications only if a profile has an open window?

Notifications are often time sensitive, on Android we even launch Chrome (+ the profile) so that it can be displayed immediately. Other browsers (e.g. Edge and Safari) are doing this too on desktop - we don't right now due to technical complexity. I don't think that immediate delivery is something we'd want to break, especially with native notifications it makes for a confusing experience.

On desktop, initializing a Profile* will automatically establish the connection over which messages are received; messages are then processed immediately. Do we load all profiles eagerly at browser start-up, or lazily when there's a window or a need?
If I open the browser in Incognito mode and with the "guest" profile loaded, via command-line switches, that may solve my specific issue.

Maybe a convenient option would be to activate profiles on launch (like how one can launch specific tabs on startup [which, by the way, are ignored in Incognito]).

If someone has their desktop browser with, say, a "work" profile and a "home" profile, then they might prefer not to be bombarded by social notifications (while working) until they switch to their social profile ("home") and vice-versa. Since I'm still on Windows 8.1 my desktop notifications don't go into any sort of queue (that I'm aware of) so my desktop notifications feel highly ephemeral (like vapor) --a history of some sort would be nice.

Anyway, I'll simmer down.  I know ideas are a dime-a-dozen and easier said than implemented.
When you start in guest mode, the regular profile is not needed and hence not loaded. But when you start in incognito, the regular profile is loaded first and then incognito profile is created based on that.
I *think* profiles are loaded on demand, so if one has two work and personal profiles and starts chrome in one, the other one would not be loaded and therefore the notifications won't be received.
As the web continues to evolve into a true "platform", it might make sense to consider partitioning responsibilities (of the browser).  Think about the Netscape/SeaMonkey suite...  should the browser really head that direction again?

If web notifications are first-class and prompt delivery is key, then it may be more efficient to eagerly load (ie. at system startup) a Chromium Profile Notification Service, of some sort, to immediately begin serving any pending & newly arriving messages.

Ideally the user(s) would be able to select the profile(s) to be loaded.  Any remaining profiles could be lazy loaded (the latter seems to be the current default behavior).

Better to be distinctly different than confusingly similar.  Or, in this case, better for the behavior to be distinct than ambiguous.

Sign in to add a comment