Part of our GDPR Requirement is to disable the GA tracking, we already achieved this by setting the window property to "window['ga-disable-UA-XXXXX-Y'] = true;". But aside from this, we also wanted to delete the set cookies (i.e. " _ga", "_gid"). Will expiring the said cookie suffice for the deletion of those cookies, or is there a better way to approach this?
Or if this cookies won't be deleted, what are they for if the tracking is disabled.
These are first-party cookie set via Javascript, so expiring them will work just fine.
what are they for if the tracking is disabled.
I would venture that Google did not put a lot of thought into this - after all their cookie solution precedes the GDPR and any widespread notion of data protection. They just remain there because that is the default behaviour for cookies. The obvious downside is that if the opt-out is revoked (either on purpose or by accident) the client id from the cookie might be reused and the tracking data would be connected to existing data. So deleting the cookie is a really good idea. If you want to be particularly thorough, you could pick up the client id of a user who opts out and sent a request to the User Deletion API. This will not remove aggregated data, but will remove PII (namely client id and user id) to anonymize the data.
Related
One of my clients has a cross domain analytics set up.
Everything works well, but there are different behaviors when user gives full cookie consent and when he allows only strictly necessary cookies.
Behavior in case of full cookie consent:
GA stores data into cookies i.e. _ga cookie _ga_ID can be found in console cookie tab.
Behavior in case of only strictly necessary cookie consent:
GA stores some data in URL, for example:
https://www.example-page.com/?_gl=1*XXXXXXX*_up*MQ..*_ga*ZZZZZZZ.*_ga_YYYYYYY*YYYYYYY..
According to google documentation the second case is default behavior. And cross domain measurement is working when _gl param is added to url.
What I do not understand is why are URL params not added everytime and only when some cookies are not accepted, so I would like to get better understanding of this.
There is also a possible issue which I do not understand and that is:
GA params are added to url also when user is just switching between subsites in the same domain i.e. from www.example-page.com/home-page to www.example-page.com/about-page. If I understand correctly this should not happen as I am staying within domain.
The questions I am most interested in are:
How is GA determining if it should store its data as cookies or push it to url?
Where are these parameters stored before user redirect first time? Is it part of datalayer / google_tag_manager global variables?
Is there way to store the params somewhere else than in url when full cookie consent is not granted?
Is adding of GA params to url even when staying withing same domain a correct behavior?
Project details:
Site is running on Wordpress and use OneTrust for cookie management.
EDIT: Issue with URL resolved.
In my case this issue was caused by update of consent mode template (gtm-templates-simo-ahava). Reverting to previous version fixed the problem. Possible cause of the problem can be maybe connected to this pull request in template repository
How is GA determining if it should store its data as cookies or push it to url?
Pushing the data to url is the mechanism of cross-domain tracking. You set a list of domains that cross-domain tracking should work for. This is likely your problem here. You're not supposed to set subdomains, only TLDs in vast majority of cases.
Where are these parameters stored before user redirect first time? Is it part of datalayer / google_tag_manager global variables?
This data is stored in cookies before the user goes to a different domain. If cookies are deleted, then it's stored in the JS scope of the GA library. This implies that they would be erased and regenerated on JS context loss. Loss on a page unload, regeneration on a page load.
Is there way to store the params somewhere else than in url when full cookie consent is not granted?
Well. Yes. But very tricky and expensive. And the immediate question is why would you do that. This would defeat the purpose of blocking the cookie. Natively, GA doesn't support other methods of passing the value, but if you're into tinkering, you can either store the value on your backend and then retrieve it, using some "primary functionality" cookie. Another option is using third party server's cookies, but that would defeat the purpose even more.
Is adding of GA params to url even when staying withing same domain a correct behavior?
No, it's most likely a mistake.
Now, you really asked all the right questions, so I don't have much to add, except that disabling your primary anonymized behavioral tracking is usually a lazy "safe" choice. And lazy here implies wrong.
Normally, larger corps don't block primary tracking. They only block third party marketing-related tracking. Basically, pixels. They consider their main analytics part of the primary functionality, which is a strong case given that main analytics data is often used in debugging, performance measurement and even for app security audits.
Finally, using onetrust or a similar solution to completely manage your tracking is sub optimal. They basically just destroy all "offending" cookies all the time. This will mess up your behavioral data very significantly.
The proper way to use consent management systems is declaring user consent choice in your tag management system and then in it, block rules/tags from firing in case the consent is not given. You normally just carefully block marketing tags there based on consent. Remember, consent management systems are only deleting cookies. Because that's trivial. They don't block network requests. Absence of cookies may not prevent the data from being sent, often even uniquely identifying the client, using the primary cookie's user id, allowing to match the activity to the backend database.
When a user logs out from a session-based site should their corresponding anti csrf token (stored in the session) be refreshed?
If the token should be refreshed then why specifically? Which possible vulnerabilities could bring not refreshing of the anti CSRF token?
The official OWASP advice is that yes, the corresponding Anti-CSRF token should be refreshed, though there is actually little security benefit in doing so:
Note that this value should be unique for every individual session. This guarantees that every form/request is tied to the authenticated user and, therefore, protected from CSRF. [...] The standard frequency of token generation is per-session, so make sure your sessions have a reasonable/configurable time-out. It is possible to issue new tokens on a per-request basis. However, the added protection may be insignificant, if this approach even fits your application.
However, the linked StackExchange question's accepted answer does have a security benefit if applied to anywhere with a principal change in the session stage (this is usually only on the login / log out) screen itself. This prevents a session fixation attack, where the attacker hijack's the victim's active session:
This is done via cookie theft, client-side scripting, abusing the <meta> tag or through the HTTP headers. Resetting the anti-CSRF token during the login flow prevents this. However, note that a secondary token should only be applied at such points, as that there is a usability cost in terms of problems in using the back button and browsing in multiple tabs.
This is not SEO related but somewhat merely client related.
There is a website in particular that uses Google Analytics tracking to uniquely identify each one of their users.
This website has a blocking system that is preventing me from viewing some of their content, which I'd like to view.
I figured out that the website uses the Google Analytics cookie to somehow identify me.
Is there a way I can somehow spoof the client-ID from Google Analytics to basically make a new identity for myself? Thanks community.
GA has two ids that could identify a user, clientId and userId. The client id is set by the javascript tracking code. To delete that you would simply have to delete the _ga cookie. You will get a new ID randomly generated that does not identify you other than in the sense that multiple pageviews with that clientId will be treated as coming from the same user.
The userId is set by the server when a user logs in (to connect all sessions of that user, however it must not personally identify the user in question), so at that point the website already has to know you to set a userid.
It seems more than unlikely (and technologically not even feasible) to use Google Analytics to limit access to a website. For starters, Google provides an opt-out plugin for Analytics that would make such a system rather ineffectual, and I'm not quite sure how such a system would work.
To yet answer your question, you can change the clientId by manipulating the _ga cookie and replace the value therein, and you could spoof the userID e.g. by using a browser plugin that allows you to manipulate http requests. However I don't think this will let you bypass any access protection.
I have a client that has a site in Germany. Due to Germany privacy laws and the client's request, I need to use session cookies or "convenience cookies" instead of tracking cookies. The requirement simply is that the cookie must be deleted when the users closes the browser.
I can't tell what type of cookies google is using and if there a way to configure this in Google Analytics.
Google Analytics uses a permanent cookie (i.e. one with a long lifetime that is renewed every time the visitor returns) and you cannot configure cookie lifetime in Google Analytics. The cookie stores a client id and is required to recognize recurring users; your client will not be able to recongize recurring users or to create user based segments. I doubt that GA makes that much sense under the circumstances.
What you can do is to configure Google not to set cookies at all by setting the "storage:none" option when you create the tracker. Then you could set a client id for the session in a session cookie, and pass the value as client id to the tracker.
ga('create', 'UA-XXXX-Y', {
'storage':'none',
'clientId': 'value from the cookie'
});
Btw. German law does not require you to use session cookies only (you need to provide a comprehensive privacy policy, an opportunity for an opt-out from tracking and your client needs an agreement with Google pertaining to the processing of data on behalf of your client, a "Vereinbarung zur Auftragsdatenvereinbarung". Google provides a document that you just need to sign. And you must not save personally identifiable data). So this is probably just your client being a bit overcautious.
Just came across this question since I had to do something similar for compliance. The solution to set the GA cookies to session is as follows:
ga('create', 'UA-XXXX-Y', {
'cookieExpires': 0,
'cookieFlags': 'expires=0;secure;samesite=none;httponly'
});
Hopefully it solves the issue for anyone looking for it
I have a little web browser in my application that hits a webpage using Google analytics. That little web browser has cookies and local disk storage disabled.
Are my user analytics going to be skewed because of this? Is every user reported as a new user when in actuality they are an existing one?
Yes, your Analytics data is going to be impacted. For example, you will not be able to differentiate hits between Sessions and Returning Visitors. As you say, each Visitor will be reported as a new one.
Analytics uses the Client ID parameter to uniquely identify a Visitor. As the official Field Reference states:
Client ID
Required for all hit types.
Anonymously identifies a browser instance. By default, this value is
stored as part of the first-party analytics tracking cookie with a
two-year expiration.
If your application can generate a unique key for each user and persist it elsewhere that in cookies or localStorate, you could still create your own Client ID:
Disabling Cookies
By default, analytics.js uses a single cookie to persist a unique
client identifier across pages. In some cases you might want to use
your own storage mechanism and send data directly to Google Analytics
without the use of cookies.
You can disable analytics.js from setting cookies using the following:
ga('create', 'UA-XXXX-Y', {
'storage': 'none',
'clientId': '35009a79-1a05-49d7-b876-2b884d0f825b'
});
When you disable cookie storage, you will have to supply your own
clientId parameter except for the special case where you are using
cross-domain linking parameters.
Yes. Google Analytics uses the client ID to determine if a user is new or returning.
Note, if your users are logged in (probably not though without cookies), then you can use the user ID feature to determine new from returning users.