Incognito only clears data when you close the *last* Incognito tab. If any are left open, the session is not ended. 

https://chromium.googlesource.com/chromium/src/+/master/docs/security/faq.md#Are-privacy-issues-considered-security-bugs

The issue is related to how cache is being handled, not if the cache is cleared.

I thought I was going insane when I kept seeing old versions of my web app showing up.

You can see how, even under Developer Tools, "Disable Cache" isn't being respected. In this screenshot, the website uses a webmanifest file.

Deleted: Screen Shot 2018-05-15 at 1.16.53 PM.png 95.3 KB

	Screen Shot 2018-05-15 at 1.16.53 PM.png 95.3 KB View Download

To clarify, are you closing all incognito windows as part of step 3?

Yes. This continues to happen even if I completely close Chrome or even reboot the machine.

Hello,

I can also confirm that session data was in fact retained after closing even the last incognito tab. Thank you.

We have an in-memory cache implementation for Incognito, so there should be no way for the cleanup to fail.

Could you please try posting a screencap of what happened?

+Cache folks, do you have any ideas?

Unable to reproduce this issue on reported version 66.0.3359.170 using Mac 10.13.3 with steps given in comment#0. Closed incognito and opened again, on navigating to tumblr.com it is asking for credentials again. Attaching screencast for reference.

@Reporter:Please check the screencast and let us know if we miss anything. Any further info on reproducing the issue would help in better triaging. Also please respond to comment#8.

Thanks!

Deleted: 843042_M66.mp4 4.7 MB

	843042_M66.mp4 4.7 MB View Download

The issue isn't cache removal. It's cache retrieval. Maybe I should I file a new bug since I can't know what issues the original poster has.

Basically, accessing a website without incognito that uses appmanifest will store its cache (normal).

When opening incognito, the appmanifest from the non-incognito session will leak into the incognito session. Incognito mode will always load the appmanifest (and thus page cache) no matter what (even after reboots). The only solution is remove the web application cache.

It's a rather major security flaw since, basically, I could theoretically track users if they switch to incognito by writing some sort of hash token inside the app manifest file and then loading it over JavaScript to read said hash.

I can supply a proof of concept if needed.

I see. The Incognito profile sometimes does use the configuration of the underlying regular profile, but that generally should be the case for web-facing things. There are sometimes exceptions for various reasons, for example we used to inherit HSTS to Incognito, but removed that too.

+dominickn@, +yfriedman@, do you know some history behind this? This does sound like a bug to me.

But yes actually, this sounds like a specific issue different than what was originally reported.

This sounds like an implementation issue between incognito and the disk cache.

Is an accurate description of this issue that the disk cache is shared between incognito and non-incognito sessions, such that if you go to a website in incognito, its disk cache artefacts might end up being used in a non-incognito session?

AppCache is separate from normal disk cache (though I don't know where the *manifest* fetch goes through), but both normal cache and appcache should be using an *in-memory store* for incognito. Not seeing anything wrong in a quick scan of the code, but a testcase would likely reveal what I am missing.

Code path:

 GetStoragePartitionFromConfig() in browser_context.cc

  if (browser_context->IsOffTheRecord())
    in_memory = true;

  return partition_map->Get(partition_domain, partition_name, in_memory,
                            can_create);

StoragePartitionImplMap::Get(const std::string& partition_domain,  const std::string& partition_name, bool in_memory, bool can_create)
StoragePartitionImplMap::PostCreateInitialization(StoragePartitionImpl* partition, bool in_memory)

    BrowserThread::PostTask(
        BrowserThread::IO, FROM_HERE,
        base::BindOnce(
            &ChromeAppCacheService::InitializeOnIOThread,
            partition->GetAppCacheService(),
            in_memory ? base::FilePath()
                      : partition->GetPath().Append(kAppCacheDirname),
            browser_context_->GetResourceContext(),
            base::RetainedRef(partition->GetURLRequestContext()),
            base::RetainedRef(browser_context_->GetSpecialStoragePolicy())));

(So path should be empty below...)

void ChromeAppCacheService::InitializeOnIOThread(
    const base::FilePath& cache_path,
    ResourceContext* resource_context,
    net::URLRequestContextGetter* request_context_getter,
    scoped_refptr<storage::SpecialStoragePolicy> special_storage_policy) {

  cache_path_ = cache_path;
  Initialize(cache_path_);

void AppCacheServiceImpl::Initialize(const base::FilePath& cache_directory) {
  cache_directory_ = cache_directory;
  AppCacheStorageImpl* storage = new AppCacheStorageImpl(this);
  storage->Initialize(cache_directory, db_task_runner_);


void AppCacheStorageImpl::Initialize(
    const base::FilePath& cache_directory,
    const scoped_refptr<base::SequencedTaskRunner>& db_task_runner) {
  cache_directory_ = cache_directory;
  is_incognito_ = cache_directory_.empty();


then in:
AppCacheDiskCache* AppCacheStorageImpl::disk_cache() {
  DCHECK(IsInitTaskComplete());
  DCHECK(!is_disabled_);

  if (!disk_cache_) {
    int rv = net::OK;
    disk_cache_.reset(new AppCacheDiskCache);
    if (is_incognito_) {
      rv = disk_cache_->InitWithMemBackend(
          kMaxAppCacheMemDiskCacheSize,
          base::Bind(&AppCacheStorageImpl::OnDiskCacheInitialized,
                     base::Unretained(this)));

#14: are you referring to the AppCache web platform feature? I think this bug isn't to do with websites caching things in the AppCache, it's to do with the actual disk cache that Chrome itself uses.

I consider comment #10 sufficient feedback, thus removing Needs-Feedback label.

Unable to reproduce the issue on mac 10.13.3 using chrome latest stable #67.0.3396.62 and latest canary #69.0.3448.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Opened incognito tab on macOS
2. Signed into web account i.e Tumblr.com
3. Closed incognito window
4. Opened new incognito window.
5. Browsed back to logged in site, observed that the session was not open and requested to log back in.

Note: But as per comment #1, Incognito only clears data when we close the *last* Incognito tab. If any are left open, the session is not ended.

As we are unable to reproduce the issue from TE-end. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!

Attaching screen cast

Deleted: 843042.mp4 4.9 MB

	843042.mp4 4.9 MB View Download

Network folks, is there anything else to be done on this bug?

The original bug report sounds severe, and OP confirmed it in #7, but we couldn't reproduce it (#9, #18).

#10 looks like a different bug to me.

Hello,

This was from several months ago. The bug did in fact exist (at least on my
computer) but I found it on an employers Macbook Pro which I don't have
access to anymore. So unfortunately I cannot provide exact version numbers
of the OS or Chromium. I did check on my personal computer with the latest
Mac OS update and Chrome and the issue is not happening anymore.

I would say it's safe to close this bug report. I apologize for not
recording the exact version numbers of the browser and OS when I discovered
the issue.

It seems to be fixed now.

Thank you.

Thanks a lot for checking again and getting back to us! I'll close the bug then, please feel free to reopen in case you spot the issue again.