cookie set on redirect not being cleared

[practik]

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]

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]

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]

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

• Start http://www.surfaceimpression.com
• End https://surfaceimpression.digital

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

So, these two are not even registered:

• http://beta.surfaceimpression.digital
• http://surfaceimpression.digital

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]

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

Out of curiosity, I went through the steps from #114 (comment) 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]

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]

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:

• from www.globest.com
• to store.law.com
• to store.globest.com
• and finally back to www.globest.com. The final URL is the same as the original one, except it has a tracking parameter appended to it.

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:

• first to login.wyborcza.pl
• then back to the original URL with an SSO session ID appended as a parameter
• and finally to the original URL with the parameter disableRedirects=true appended.

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]

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]

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:

0. First to leadgen-cbslnk.cnet.com (the original link URL domain),
1. then inmotion-hosting.evyy.net,
2. then www.ojrq.net,
3. then back to inmotion-hosting.evyy.net again, the same URL from (1) but with some tracking parameters appended,
4. 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]

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

[practik]

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!