Lusito / forget-me-not

Make the browser forget website data, except for the data you want to keep.
zlib License
226 stars 25 forks source link

cookie set on redirect not being cleared #114

Closed practik closed 5 years ago

practik commented 5 years ago

Steps to reproduce:

  1. Set FMN to clean cookies on all instances of leaving a domain, with a short delay – say, 6 seconds.
  2. Open http://www.surfaceimpression.com/ in a new tab. The tab will immediately redirect to https://surfaceimpression.digital/.
  3. Check cookies. There will be three: one from www.surfaceimpression.com, one from surfaceimpression.digital, and one from beta.surfaceimpression.digital.
  4. Wait 6 seconds and check cookies again. All three will still be there, meaning that the redirect from surfaceimpression.com to surfaceimpression.digital was not handled by FMN as a domain leave.
  5. Close the surfaceimpression.digital tab.
  6. Wait 6 seconds and check cookies again. The two from surfaceimpression.digital will be gone but the one from surfaceimpression.com will still be there.

Tested in a fresh profile with FMN 1.0.5 on FF 62.0.3 on macOS 10.12.

PS: I just saw your new post in #67 and look forward to reading through the details when I get a moment.

Lusito commented 5 years ago

Nice catch and well done issue description. Thanks!

I imagine that the redirect never hits the domain logging mechanism in this case. I might need to work around this issue. I will investigate.

Lusito commented 5 years ago

There are actually 3 redirects happening here:

Start: http://www.surfaceimpression.com

  1. http://beta.surfaceimpression.digital
  2. http://surfaceimpression.digital
  3. https://surfaceimpression.digital

And they all create their own cookies.

Lusito commented 5 years ago

After doing a few tests, I get the following events:

(from the documentation, I assumed it should be start and end for all 4 urls)

So, these two are not even registered:

Not sure if this is a bug or intended behavior.

I will have to find a way to get them all, possibly with different APIs. Will have to try another time, the day is almost gone.

practik commented 5 years ago

Interesting! I'm glad I could give you a mystery to solve :-)

Out of curiosity, I went through the steps from https://github.com/Lusito/forget-me-not/issues/114#issue-372681788 with Cookie AutoDelete. I used the latest version and set it to clear cookies on tab close and domain change. It did not treat the redirect as a domain change (step 4), but it did clear all three cookies when I closed the tab (step 6). So there may be something for you to look at there, although I get the impression that the way CAD works is rather different from the way FMN works.

practik commented 5 years ago

Found another one that appears to be similar:

  1. Open https://vk.com/doc510634745_478264003?hash=018f47b0b1f30c6c91&dl=GQ4TONRUGAZTG:1539611328:ff2003e0f35a61cd69&api=1&no_preview=1 in a new tab.
  2. The page will automatically redirect to https://psv4.userapi.com/c848424/u510634745/docs/d12/a4bd51658d3c/New_York_Magazine_-_October_15_2018.pdf?extra=bVWabPwKk7IFkJh1hbl63LhzKtZSmFbyZX-1FjRHEPSNZnqitAHh9XG9wpqSkJGg-0dDOr1DLB7pqkdJxaikM3jXMqc14A9RNrvfKzCxYUQike18-wcSoMFJoe-Tu8mQzAzHJqMYvA
  3. Check cookies: There will be one from vk.com that will not be deleted by FMN after the tab is closed.
practik commented 5 years ago

And here are a couple more:

1 Opening https://www.globest.com/2018/12/04/dumbo-empire-stores-developers-obtain-161m-loan-secured-by-one-broadway/ triggers a series of redirects:

After you close the tab, several cookies from law.com and store.law.com are not cleared by FMN.

2 Opening http://www.wysokieobcasy.pl/wysokie-obcasy/7,152731,24241053,anna-maria-jopek-w-liceum-poszlam-w-gleboko-duchowosc-tatus.html does much the same thing:

When you close the tab, that SSO session ID is left behind as a cookie from wyborcza.pl which is not cleared by FMN.

** Is it helpful for me to continue sharing these examples with you, or am I not really adding useful information because the mechanism is the same in all these cases?

Lusito commented 5 years ago

Thanks for the examples. I'm already working on improving the situation. Not sure if I can catch all of these cases, but it will get better :)

practik commented 5 years ago

Another one for you, just in time for Christmas :-) If you go to https://www.cnet.com/web-hosting/ and click on the link for InMotion Hosting, you'll trigger a cascade of redirects through the following domains:

  1. First to leadgen-cbslnk.cnet.com (the original link URL domain),
  2. then inmotion-hosting.evyy.net,
  3. then www.ojrq.net,
  4. then back to inmotion-hosting.evyy.net again, the same URL from (1) but with some tracking parameters appended,
  5. and finally to www.inmotionhosting.com with a clickid parameter appended to the URL.

After you close the tab and FMN clears the cookies, there are still four cookies left behind, two from evyy.net and two from ojrq.net. One cookie from each domain has the name brwsr, and each of these has the same 32-character alphanumeric string as its value.

That's just one example – the other links on that CNET page work similarly but go through different middlemen, depending on which service is being used to track affiliate clicks, I guess. The link for Web Hosting Pad is interesting in that it sets cookies from two "extra" domains – shareasale.com and shareasale-analytics.com – and FMN is able to clear the ones from the second but not the first, I guess because of the redirect mechanism being used in that case.

Lusito commented 5 years ago

Just tested all scenarios with the new code and all cookies get removed correctly.

practik commented 5 years ago

I can confirm that FMN 2.0.0 has fixed all of these, and also #117. Now that I don't need to block all those domains individually, the cookies permission list in my Firefox preferences is much saner – thank you!