Closed callado4 closed 3 years ago
callado4
commented
3 years ago I suspect that this line of code sometimes doesn't work and the swallowed exception is masking the problem: https://github.com/amplitude/Amplitude-JavaScript/blob/3a9f25b7bc44931698c585576dc1ea1489b0988f/src/base-cookie.js#L56
jooohhn
commented
3 years ago Hey @callado4, sorry this is happening to you
Requests
callado4
commented
3 years ago The source is actually available here: intention-bundle-formatted-20201202.js.zip
I'll see if I can give better reproduction steps, but essentially it's just having at least the uBlock Origin extension + the GetIntention extension (that I linked above), add news.ycombinator.com as a site for the Intention extension to track as a "time wasting" site, navigate to news.ycombinator.com, the Intention extension will show a popup where you have to select like 5m of time (to read/not focus), then click on any of the comments links in new tabs and after a few you will see the cookies growing in the network tab for the requests to the site.
scottsb
commented
3 years ago Tagging @dkthehuman (creator of Intention) here in case he can provide any helpful input. I found this issue from the exact same problem (conflict between Intention and uBlock Origin) causing Google Accounts & Twitter to start breaking.
namukang
commented
3 years ago Thanks for tagging me @scottsb! This seems pretty nasty, and I didn't realize Amplitude was adding cookies for various domains. I definitely don't want Intention to be breaking sites, so I'm going to push a build now that disables Amplitude for all users until this issue is resolved.
@callado4 The reason why Amplitude requests are sent even though you have uBlock Origin enabled is not because Intention is doing anything nefarious but because extensions can't affect other extensions for security reasons. (I use uBlock Origin myself and would love to respect that preference, but I can't detect whether uBlock Origin is installed without requesting additional permissions to manage your extensions which I'd like to avoid.) The problem above should cease once Intention is updated, but in the meantime, you can go to Settings > Privacy > Uncheck "Send usage statistics" to disable Amplitude yourself.
orrc
commented
3 years ago Thank you for filing this (and fixing it in Intention)! I'd figured out that Amplitude was the cause of Twitter breaking daily due to huge numbers of redundant cookies, but not the root cause…
humaknlght
commented
3 years ago I am seeing the same issue happening when I enable the HTTPS Everywhere plugin in Chrome
Thomas131
commented
3 years ago I think this should fix it (untested):
diff --git a/src/base-cookie.js b/src/base-cookie.js
index a7531e9..39616fe 100644
--- a/src/base-cookie.js
+++ b/src/base-cookie.js
@@ -55,7 +55,9 @@ const areCookiesEnabled = (opts = {}) => {
const _areCookiesEnabled = get(cookieName + '=') === uid;
set(cookieName, null, opts);
return _areCookiesEnabled;
- } catch (e) {} /* eslint-disable-line no-empty */
+ } catch (e) {
+ set(cookieName, null, opts);
+ }
return false;
};Please fix this, thanks!
bolekkerous
commented
1 year ago This seems to be happening again. I have HTTPS Everywhere installed, but since roughly a week ago, both Twitter and Reddit, and also Google, started regularly throwing 400 Bad Request errors. When I looked into it, I found dozens of cookies named similarly to amp_cookie_test-nLiZkRAFqPtAXSvRjck9F and _tldtest_R8QlYl4XVyd4fCSp3BC9ju polluting the requests.
yuhao900914
commented
1 year ago Hi @bolekkerous, thanks for choosing amplitude. We are sorry about the inconvenience. We are investigating this issue right now.
bolekkerous
commented
1 year ago Thanks @yuhao900914, I managed to fix it for now by disabling HTTPS Everywhere, but a lot of people probably still use it. It started happening only recently and HTTPS Everywhere didn't have an update for months, so it's likely something on your end or some interaction with Chrome perhaps.
yuhao900914
commented
1 year ago @bolekkerous, we are still investigating this issue. However, we noticed that HTTPS Everywhere has been sunset, it's not available in the chrome extension, so we are not able to reproduce the issue immediately.
They provide instructions on how to enable HTTPS by default through the browser.
https://www.eff.org/https-everywhere/set-https-default-your-browser.
bfg1981
commented
1 year ago My first thought was to investigate if Twitter and Reddit are using old versions of Amplitude. I tested it for Twitter and I could not immediately see where Amplitude was used.
bfg1981
commented
1 year ago Also I originally investigated this with respect to Jitsi. HTTPS Everywhere was never the root cause, it just exacerbated the problem with Amplitude.
na-ji
commented
1 year ago The issue is happening on my website too. It's even weirder that I disabled the cookies when initiating Amplitude by using the disableCookies option. What's the point of the amp_cookie_test cookies? I didn't find any information about them in Amplitude documentation.
yuhao900914
commented
1 year ago Hi @na-ji, https://github.com/amplitude/Amplitude-JavaScript/blob/main/src/base-cookie.js#L97 amp_cookie_test cookie is just for testing. It has been wrapped in try-catch block. It will be removed in the finally block. navigator.cookiesEnabled yields false positives in IE, so we are using this way to test if the cookies have been enabled.
We have 2 cookies, the old cookies, and the new cookies. We will check if you have the old cookies (amp_cookie_test will be created and removed) and migrate the data to the new one if that's available. When you call to disable cookies, it disables the new cookies. That's why amp_cookie_test will be created even if you disable cookies.
But removing the test cookie will be called finally. It shouldn't be there. Is there an easy way I can reproduce it? Which browser you are using? Do you install any chrome extensions? Which webpage caused the issue?
na-ji
commented
1 year ago Hi @yuhao900914,
I think I misinterpreted the issue on my side. I thought I saw a few cookies amp_cookie_test, but in fact now I can only see one when navigating on my website. Also, I noticed that Chrome would still display the cookie, even though it has already been set as expired.
However, I do have another question: why testing if we can create cookies when the option disableCookies is enabled? Should we skip this check directly since we don't want to create any cookie anyway?
Thank you.
yuhao900914
commented
1 year ago Hi @na-ji, we just have a fix on that issue. With the latest version of Amplitude-JavasScript SDK. if you disable cookies, it will skip the check. Thanks.
swport
commented
10 months ago Something I'm failing to understand is why would amplitude set AMPMKT and other cookies for my site's domain? Every request made to my site contains these cookies that serves no purpose. After logging out and logging in with different users, these cookies gets build up overtime ultimately causing 413 - Request entity too large exception.
Expected Behavior
I can browse websites without issues and unwanted cookies
Current Behavior
The amplitude library keeps adding junk and seemingly duplicate cookies to my requests, eventually so many that web servers like nginx stop responding to requests
Possible Solution
Stop adding duplicate cookies, respect user's desire not to be tracked
Steps to Reproduce
I have tracked this down to partly being because of the Intention Chrome extension, partly this library not respecting user's who block tracking (via uBlock origin), but I feel like your library shouldn't be adding so many duplicate cookies.
I will definitely have to file a bug with the Intention Chrome extension and their use of buggy user tracking software.
I have uBlock origin which I use to block these types of trackers and I suspect that your library doesn't know how to properly behave when this happens. What I see happening in while I'm browsing https://news.ycombinator.com/news every time I navigate to a new link on that site a set of
amp_cookie_testand_tldtestwith a random id is appending to my cookies list, along with oneamplitude_testycombinator.comcookie. Eventually their nginx server responds with a 400 bad request error because one of the request headers is too big (because of all of the cookies). The only way to do a temporary fix it to close ALL of my tabs from that website, then use Chrome to delete the cookies for that site (but it starts to add up soon again and eventually it happens again).On every request to this site (ycombinator news), I see a blocked request to api.amplitude.com (blocked by uBlock) which is what makes me really suspect this is an issue with Amplitude.
Here is a sample curl request to demonstrate the problem
I have also attached the source code for the Intention extension where you can see the key prefixes for the cookies I mentioned above.Apparently I wasn't able to attach it, I can provide it if needed.Source code here: intention-bundle-formatted-20201202.js.zipEnvironment