Info about Vanilla Cookies
Digital Spy is prepping for a release of a cookies modal. They are asking for a bit more info around our cookies. Specifically these:
vf_digitalspy_T21DJ-vA (domain: forums.digitalspy.com)
· __cfduid (domain: vanillicon.com)
· __cfduid (domain: v-cdn.net)
I let them know that Vanilla creates 2 persistent cookies on a user’s computer, the first one is used to keep a user logged in (ability to ‘remember me’ when logging in), the other is used for analytics. Vanilla does not store any PII (personally identifiable information) in cookies and does not track users activities across different Vanilla forums. Vanilla uses cookies to help Vanilla identify and track visitors, their usage of Vanilla website, and their website access preferences. Vanilla visitors who do not wish to have cookies placed on their computers should set their browsers to refuse cookies before using Vanilla’s websites, with the drawback that certain features of Vanilla’s websites may not function properly without the aid of cookies.
vf_digitalspy_T21DJ-vA (domain: forums.digitalspy.com) - I assume this is the cookie needed for login
vf_digitalspy_T21DJ-vA (domain: forums.digitalspy.com) - I assume this is the cookie for the Vanillicon Add-on
__cfduid (domain: v-cdn.net) - I assume this is for our CDN
Do we have any more info on how these are used and why their necessary?
Comments
-
The
__cfduidis used by Cloudflare to for security purposes. There is more information in this article.The I'm not sure about
vf_digitalspy_T21DJ-vAcookie is for tracking analytics. This could technically be considered PII I think.We should have a
vf_digitalspy_T21DJ-Vvcookie. This cookie is to help track visits and is anonymous.We also have a
vf_digitalspy_T21DJ-tkcookie which is used for CSRF protection and is anonymous. You can just say it's used for security.0 -
Just to follow up on the
-vAcookie. I meant to write this:The vf_digitalspy_T21DJ-vA cookie is for tracking analytics. This could technically be considered PII I think.
So I am sure. Whoops.
After doing some reading I see that we are sending pseudo anonymous data with this cookie. We need to do a bit of work for GDPR here which we'll start this sprint. So if digital spy are concerned they need to turn off analytics for now.
Immediately we'll be adding the following:
- A config setting to anonymize analytics data from EU users. This will still allow analytics to be collected but will reduce the accuracy of unique user reports.
- The config will be configurable for EU guests or all EU users. Sites that have updated their TOS to include an opt in to tracking information can use the EU guests setting.
- Longer term we'll add a setting for our own opt-in modal that will use the tracking cookie for individual users that opt-in. This would be used as a general setting for other tracking data.
We need to do 1-2 this upcoming sprint while #3 will be done later.
1 -
@Todd More questions from Digital Spy:
We have come across another issue during testing around embeds and cookies being dropped by these embeds. If a user opts out of non-essential cookies we have code in place to block the embeds from loading, however there is still some related JS code that is being executed and dropping cookies on the user. We are unable to control these files as they sit on your side of things, can you advise us on where this code is being executed and how we can stop them for users who opt out. We believe it will be from the ‘smart embed’ feature. Please see the attached screengrabs (simulating an opt out) .
0 -
A lot of our embeds use iframes that may include scripts that set cookies. For these I need to do a bit of research, but we may be able to block them.
Some of our embeds must use scripts such as vine and twitter. For those we'd have to disable the embeds entirely which would require additional coding. Do you think Hurst would pay for that?
0 -
Okay it looks like we can't sandbox iframes from external embeds so they will have to block them on their end.
WRT vine. It looks like we can remove its script and leave the iframe which should make it behave like the other embeds and be blocked.
0 -
The vine change has been merged and will be deployed next release.
0 -
Hey @Todd Thanks for the additional info!
I've still got a handful of questions from the client:
- vf_digitalspy_T21DJ-Vv – we said this was to track Visits, but DS would like a clearer explanation for how we define a "Visit"
- Dev work to make the cookies dropped on the user anonymous – is this in progress and/or completed?
@Todd said:
After doing some reading I see that we are sending pseudo anonymous data with this cookie. We need to do a bit of work for GDPR here which we'll start this sprint. So if digital spy are concerned they need to turn off analytics for now.Immediately we'll be adding the following:
- A config setting to anonymize analytics data from EU users. This will still allow analytics to be collected but will reduce the accuracy of unique user reports.
- The config will be configurable for EU guests or all EU users. Sites that have updated their TOS to include an opt in to tracking information can use the EU guests setting.
- Longer term we'll add a setting for our own opt-in modal that will use the tracking cookie for individual users that opt-in. This would be used as a general setting for other tracking data.
We need to do 1-2 this upcoming sprint while #3 will be done later.
0 -
Found the info on visits :
Visit: Multiple page views and actions between periods of inactivity.
The question remains though - how do we define a new visit? For those who may still be struggling to understand the definition of a Visit I find Adobe's Doc explain the idea pretty clearly, but know that what defines a new visit in Vanilla (i.e. # of minute inactive, or # of time of consistent activity) is likely different - all Analytics tools are. This just helped me wrap my head around the concept -
https://marketing.adobe.com/resources/help/en_US/reference/metrics_visit.html0 -
We define a new visit after at least 20 minutes of inactivity. We track this with the
-Vvcookie which just deletes itself every 20 minutes. That's all it really does.The dev work on anonymizing cookies is mostly complete, but not deployed. Here is a summary of the changes and what needs to be done.
- Complete. Page view calls are being stripped of user information for EU users. This means that EU users will show up as anonymous in most active user leaderboards, but are still included in aggregate graphs.
- Working. Currently we are completing the work by stripping the last octet of IP addresses off of analytics calls. We are switching to anonymous IP addresses for all users.
- Future. We will be providing opt-in tools on our communities so that EU users can opt-in to having user information tracked.
- Additionally, we still track user information for everyone based on actions that they, themselves take such as posting and reacting. Since their user information is associated with the data they post we think that the analytics aren't tracking anything additional to the data in the community.
If you want to know more about these changes or have more questions Ryan is demoing this afternoon. I'm also happy to answer here.
0 -
Amazing. Thank you so much, Todd!
0 -
Is there any way to disable smart-embed by user? i.e. if I opt out I don't see embedded content, I only see the links to that content? Digital Spy is considering disabling the feature altogether, but it's so heavily used by their end-users that the Community Manager and I are foreseeing an uproar from users if it's disable globally.
0 -
Kind of like a follow up this.
Bose's legal team has decided that based on the current Vanilla cookie set up they're ok with no creating a banner warnings users of cookies within the dev community. Their concern is that if/once changes are made to our cookies, how do we notify our clients?
Email from Bose below.
Hi Farhan,
I’ve been working with my legal team to understand in detail our requirements around presenting a cookie consent banner, which is something I asked you about previously (you mentioned Pockets might be a potential solution). Based on a review of the Vanilla offering and policies, they are generally ok with actually not needing a cookie banner on the vanilla portions of our developer offering, with one request: they’d like to understand what mechanisms are in place to notify us if, in a future software update, Vanilla changes how cookies are used, as that could result in a new behavior that would drive us to needing a cookie banner.
Is there any mechanism like detailed release notes or regular outreach from you about software updates that could satisfy this request from my legal team?
Let me know if you have clarifying questions for me!
Thanks,
Zach
0 -
We do publish release notes with each software update that would include major changes to how we use cookies.
One of our software's fundamental principles is not collecting or storing personal information that isn't central to the platform's functionality, and that extends to our use of cookies. We do not foresee this changing.
We have two items related to cookie behavior on our roadmap (no estimate on delivery):
- Adding a cookie for super-admin users to be able to continue to view debug information while "logged out" from a site. This would not effect their users, only Vanilla staff.
- Moving to proper session management, which would allow the invalidation of a particular users' session(s).
Both will be noted whenever they are released. Neither fundamentally changes how we use cookies.
0 -
@Linc This is the infamous Staff post regarding Cookie info. These questions here were specific to Digital Spy.
I'm working with King at the moment and they are going through an assessment of our cookies, how they're used, who uses them and why. I'd also like to put together some docs about this either for CSMs or for clients, or both.
Here's the info I've been able to gather from this discussion which we can perhaps, with your help, include in documentaton.
__cfduid
Cloudflare uses 2 cookies, both named __cfduid. These live on:
- .v-cdn.net
- yourforums.vanillacommunities.com
These are used to identify individual clients behind a shared IP address and apply security settings on a per-client basis.
For example, if a visitor is in a coffee shop where there may be several infected machines, but the specific visitor's machine is trusted (for example, because they completed a challenge within your Challenge Passage period), the cookie allows Cloudflare to identify that client and not challenge them again. It does not correspond to any user ID in your web application, and does not store any personally identifiable information.
Full description here:
@Tim or @D̸̨͝ą̸͂a̵͍̔z̴̙͋K̶̤̀u̷̢̇ perhaps you can weigh in here on what we should say or not say about these cookies, and how we use them.
%-tk
This token is anonymous and is used for CSRF protection.
%-Vv
This token is anonymous and is used to track visits.
%-vA
This token is used for Analytics tracking and is anonymous for EU users.
Questions:
- Are these all the standard cookies we can expect to see on client sites?
- I'm seeing additional cookies on certain customer sites - like King, for example, that I'm not certain about:
__vnf&vf_node_ENDTX - We're told that Troll Management works with a browser cookie, which cookie would that be?
@Todd perhaps you also want to weigh in here.
0 -
__vnfis the Troll Management cookie. It is not anonymous and does persist after logout. It's not used by anything except Troll Management. It is only initially assigned when users log in, not users who remain as guests.vf_node_ENDTXis the generic user authentication cookie for logging into any node site. I don't know why it's hard-coded to that name everywhere instead of having a random name like non-node sites, but that's all it is.In general, whenever you see those patterns above, the % (wildcard) part you're noting above is also the name of the generic user authentication cookie ("I'm signed in and this is my user account"). It is deleted when you log out.
We do not use the Cloudflare cookies within Vanilla, FYI. I highly doubt Ops does anything with them on our side, either.
2 -
Thanks for this Linc!
0 -
I have Fox pushing hard to get some answers on this one.
They are looking for
- Cookie Type
- Cookie Name
- Third or First party cookie?
- Description
- How to opt-out
For the following cookies:
%-tk
This token is anonymous and is used for CSRF protection.
%-Vv
This token is anonymous and is used to track visits.
%-vA
This token is used for Analytics tracking and is anonymous for EU users.
__vnf
is the Troll Management cookie. It is not anonymous and does persist after logout. It's not used by anything except Troll Management. It is only initially assigned when users log in, not users who remain as guests. You can turn off the ‘troll’ add-on if you do not want this.
I am not too sure what to tell them for any of these.. I am wondering if cookie type refers to session, persistent, secure etc as I see on wiki, or not. I believe you can't opt out of any of these. Any notes that anyone has for me would be amazing :)
0 -
They are all first-party and cannot be opted out of if their respective systems (Troll Mgmt, Analytics) are enabled. We have a built-in opt-out of the Analytics cookie for EU IP addresses.
By "type" they perhaps mean "purpose"? E.g. Tracking vs Session vs Preferences. We only use Tracking and Session cookies. I think they should be self-explanatory from the descriptions.
0 -
For cookies that do make use of personal data - i.e. Troll Management and Analytics - what personal data do they contain/use?
0 -
- Troll Management (__vnf cookie) - This is a randomly-generated ID we use to "fingerprint" users to determine if one user is utilizing multiple accounts on a community. It is not derived from any PII.
- Analytics (%-vA) - We store several pieces of information packed into a single cookie.
- Privacy Mode - A numeric flag, used to determine how much we anonymize a user's data when tracking analytics. This value is automatic, based on the detected country of origin.
- Session ID - A randomly-generated ID used to track signed-in-user activity. This value is reset between visits to the site.
- Secondary Session ID - A randomly-generated ID used to track events that could include guest data (e.g. page views).
- UUID - A randomly-generated ID used to uniquely identify the user. This ID can persist between site visits, but only lives in the user's analytics cookie.
1 -
Ryan, I thank you. :) King's cookie assessment is now complete. Thank you all!
1 -
Fox still has one question:
>would you categorize these cookies as functional, targeting or essential?
0 -
New Cookie:
__cfruid - another Cloudflare cookie related to rate limiting
Do we know if this cookie stores personal information? I believe rate limiting is done by IP, no?
0 -
Also just found a vf-%-sid Cookie
0 -
The __cfduid cookie is used to identify individual clients behind a shared IP address and apply security settings on a per-client basis.
__cfduid does not correspond to any user ID in your web application, and does not store any personally identifiable information.
0 -
So it seems that we made a mistake.
__cfduid is already explained and has nothing to do with rate limiting.
if you go on a rate limited URL like `/api/v2` you'll get that __cfruid cookie which is indeed used for rate limiting https://community.cloudflare.com/t/what-does-cfruid-cookie-do/65510 (that's the best I could find)
Basically, it makes sure that different users on the same network (sharing the same IP) doing requests to rate limited URLs won't be counted as one user.
(P.S. I did not get that cookie before from the office because we're bypassing rate limiting)
0
