I'm working on a hobby project. The project is basically an integrable live support service. To describe my questions easily, I will call my service service.com and call the website that uses my service website.com. I'm thinking on implementing session management to restore disconnected visitors chat. To do that I'm planning to use cookie based session management. If owner of the website.com wants to use my service I will provide them a JavaScript file which will inject some HTML on the body, style tags on head and implement interaction. All the website.com's have to do will be importing that JS file and calling a function defined by that JS file. To set 3rd party cookies on that website.com from my service.com I will use this request/response. When website.com requests my JS file from service.com, my service will respond the request with the JS file along with a cookie to manage visitor's sessions. This way service.com will set 3rd party on website.com's visitors.
1st Question: Could this stage of setting cookie on website.com's visitor done on the front-end with that requested JS file or locally (from the website.com's web server) requested JS file? Would that still be a 3rd party cookie since it would be set on the front-end of the website.com?
2nd Questios: My other question is about cookie consents. Can a website that sets 3rd party cookies (e.g service.com) on some other website (e.g website.com) ask to allow their cookies on that website.com? In other words, can I ask website.com's visitors to allow only 3rd party cookies that are set by service.com with the JS file I serve/give to website.com? Would that be legal?
3rd Question: How do cookie consent banners work behind the scenes? What happens when you accept/deny all of the 3rd party cookies used on a website? Or what happens when you filter and accepy only a few of them? How does the process of allowing/disallowing work? Is there some kind of JavaScript that is triggered when you click that "Accept" button or "Decline" button? You can provide me any resources on this topic.
Thanks!
All the website.com's have to do will be importing that JS file and calling a function defined by that JS file. To set 3rd party cookies on that website.com from my service.com I will use this request/response. When website.com requests my JS file from service.com, my service will respond the request with the JS file along with a cookie to manage visitor's sessions. This way service.com will set 3rd party on website.com's visitors.
If by by "request/response" you mean an http request to service.com which will reply with cookies to be stored under website.com (customer domain)...that doesn't work with http cookies because you are limited to reading/setting cookies within your domain namespace. i.e. a response to a request to api.foo.example.com can receive and set cookies at:
but NOT cookies at www.example.com.
So in that request from website.com to service.com... service.com can only set cookies under service.com. These are called "third party cookies" in this scenario as the "first party" is website.com and your service.com is a third party (site visitor is interacting with website.com). Many browsers (safari, firefox) block third party cookies by default.
To work around this problem and have a more reliable cookie (even if you are only using it for a session and not across multiple visits to website.com), you have two options:
customer whitelabel DNS. customer creates DNS record livechat.website.com and CNAMEs that to api.service.com. api.service.com then handles traffic via the livechat.website.com domain and can read/set cookies there (or even on website.com). However this requires a more technical connection on the customer's side as it involves adding a DNS record in addition to adding your script tag.
javascript cookies. instead of setting the cookie in the http response from service.com, the javascript returned from service.com is running in the website.com domain/frame and so can set javascript cookies as well as reading cookies under that domain (as long as they weren't set with the httponly option). Take a look at js-cookie library if you don't want to worry about cross-browser issues when coding against the native browser document.cookies API. Content Security Policy can prevent your script/cookies for working, so you will need to check/monitor that the customer doesn't break you there (at setup and over time).
If you don't do one of the above, your cookie set on a response to a request to service.com will be a third party cookie and may not work consistently.
...are cookies set via http response header set-cookie and are only able to be set for the domain namespace of the host that was requested. If this host (full domain name with sub domains) is different than the domain in the user's address bar, this is considered a third party cookie and subject to some limitations.
You can set first-party http cookies as a third-party if the customer will point a DNS record under their domain at your service.
are cookies set by javascript within the page. They can set cookies within the domain/namespace of the frame the javascript is running within. They can read cookies from that domain/namespace as well as long as they weren't set with httponly option (often done to prevent third party javascript from hijacking session cookies).
You can use javascript cookies as a third party by being loaded into a frame of appropriate domain.
You will also want to read up on Content Security Policy which can prevent your third party javascript from running as part of your customer deployment documentation if the customer is using CSP to lock down their site.
The difference between http cookie and javascript cookie is how they are set.
An http cookie is set by a server setting an http response header set-cookie: name=value.
A Javascript cookie is set by javascript running in the browser (ie "client side") calling a standard browser API cookies.set().
If the cookie is properly set (not expired, etc) and "sticks" (ie not blocked by CSP or whatever)... then that cookie will be available
cookies.get() (if the cookie was not specified as HttpOnly for security reasons)Cookie: name=value.Note that cookies will not always be sent. Cookies can be scoped to domains and paths (folders). A cookie can be specified as secure in which case it will only be sent on https but not http requests.
In incognito mode, third party cookies are often blocked by default so even if they are present they may not be sent to the server or be available to javascript (be aware of this incognito mode if testing and not seeing your cookies). I've also run into weird issues with third party cookies not be displayed in chrome devtools network request headers even though they are sent and received by the server.
Could this stage of setting cookie on website.com's visitor...
done on the front-end with that requested JS file
Yes, this is javascript cookie. See above.
or locally (from the website.com's web server) requested JS file
Not sure exactly what you mean. The website.com webserver could host/proxy your js file, but that is just static file serving so it doesn't really help you with the session cookie logic.
The customer could host a proxy to your api that included re-writing the cookie headers on your response to make them first party. Though technically possible, this is way over-complicated and I don't recommend it. Just showing that many things are possible.
You can contrive many solutions of course. For instance your customers could host a very simple webapp that handles reading/setting cookies on demand in response to a javascript request. ie the customer hosts a little app you built under their domain in order to read/set certain http cookies and provide this info in response to API calls from your javascript. However I would argue this requires more technical integration on the customer's end than the custom-DNS (above) option.
I suggest you stick with one of the following...
Can a website that sets 3rd party cookies (e.g service.com) on some other website (e.g website.com) ask to allow their cookies on that website.com?
There are two relevant pieces of regulation where all these cookie consents come from. eprivacy/GDPR in the EU and CCPA in California.
Most cookie popups you see are eprivacy/GDPR related and are following a standard called Transparency Consent Framework (TCF) managed by the Internet Advertising Bureau (IAB). The technical party that provides the cookie popup functionality is called a Consent Management Platform (CMP) within the TCF spec. They sit between the website (aka "publisher") and the various third party vendors that might want to do something with visitor data on that website (cookies or otherwise). Vendors/cookies are grouped into "purposes" which allow visitors to consent to one type of data use but not another. There are required cookies (required for website to work...like a login cookie) and analytics and marketing and other types of purposes. Feel free to read the spec if you want to know all the technical details of how these guys (Publishers - CMPs - Vendors) work.
But long story short, you don't request anything from the cookie popup, your company is registered to participate in the spec as a vendor and then the CMP can include you in the list of third party vendors on a website that a visitor can consent to. As a personal hobby-project, forming a company and joining the TCF framework is probably beyond what you want to do at this point. But the website can usually add you to their cookie disclosure manually if your cookies need to be disclosed.
this is only required in the EU (and california, canada), if you don't have customers/users in the above, you probably don't need to worry about this.
your livechat would fall under the required/functional cookies for the website in order to make the livechat function of the website work...so as long as you are careful about data collection/storage-location/processing...you probably can also operate in the EU no problem and don't require any special additional cookie consent as you can fall under the required/functional cookie umbrella for the website. Leave data processing and privacy responsibility in website.com's hands.
ideally use a session cookie with the DNS option (under website.com domain). Don't track user beyond session restoration or put any sensitive data in the cookie (or local storage) that will persist across sessions.
if you are going to store chat logs on your own servers, then there is a high risk you get personal data as the user provides it to a support agent (phone number, name, address, etc). This gets hairy fast in terms of legal requirements and disclosures. If you aren't a company, no legit company doing business in europe will use your live chat because of lack of data security/privacy accountability.
ideally use servers in the EU for EU visitors to avoid inadvertently transferring data abroad without consent (even if it is ephemeral).
Don't log any personally identifiable info, user ids, etc on your service.com servers. Just log a chat ID, start/end time, agent ID, topic and other stats you need for billing...but nothing about the visitor. If you want to record the IP address, truncate the last octet (or set it to 0) to semi-anonymize the IP.
Make a privacy explainer "one sheet" that explains technically how you avoid ever touching (or persisting) any potentially sensitive data ("private by design") and include this with your marketing materials as it will help short-circuit any inquiries from prospective customer legal teams.
To be extra safe you could also avoid generating a chat session token/cookie until they initiate the chat and consent (technically an ephemeral but unique user id that also requires storing information on user's device...the cookie). Basically you use basic country-level geoip in nginx (or whatever) to determine user's country and if they initiate chat and are in a country on your list...you give them a little popup before they start telling them that the chat function requires storing a temporary unique ID in a cookie on their computer to maintain their chat session and they must consent in order for the chat to function. Or skip geoip and just annoy everyone with the consent popup when they initiate the chat. After they consent, generate the session id, set the cookie and start the chat.
How do cookie consent banners work behind the scenes?
Most large companies are using legit cookie consent banners that implement the TCF framework (policy and technical specs) from IAB Europe. All the tech specs are public on that website (for CMPs for Vendors, etc). The same cookie consent vendors that implement support for TCF also generally added support for CCPA rules. Canada has now adopted TCF from the EU as well to keep things simpler. However you can also be added manually to most cookie popups (CMPs) without participating in TCF...since TCF is mostly focused on advertising industry.
You can't just integrate in TCF with a callback. Doesn't work that way. You need to be registered to participate in the framework as a vendor. Then you can call a specific API function provided by the CMP to check whether the visitor has provided consent yet and whether you (as a third party vendor) have received consent for any specific purposes and which ones.
The cookie consent providers often provide the ability for websites to manually (or automatically via crawler) add and declare additional vendors/cookies that are outside the scope of TCF framework (which is advertising focused). This would apply to you if needed.
Some cookie consent providers will copy/remove/parse the page in order to block the firing of third party scripts and then re-inject the page with modifications. I'm not a fan as that can lead to strange behaviours. Some providers also use MutationObserver to watch for third party things being loaded. The common/manual case was to manually modify third party iframe/javascript/image/etc html tags using data attributes in order to flag this to the cookie consent...and prevent loading (ie move src to a different attribute so the tag doesn't load). If consent is given then those elements can be updated by the cookie consent library to load.
However as I mentioned in the answer to question 2 you probably don't need to worry about this if you are careful.
Some websites have rolled their own cookie consent widgets because they are too small to deal with complicated licensing of a full CMP and because they often have very limited third party vendors they need to disclose (maybe just google analytics and a google ads and facebook remarketing pixel). These ones if they are well built should prevent any of those third party javascripts (or other http calls) from being loaded until consent has been given (or rejected).
One I built years ago uses google tag manager (post consent) to manage what gets loaded using GTM Triggers. We don't load GTM until we have received a signal from the user. Before we fire GTM we add consent signals to the data layer indicating which purposes (functional/analytics/marketing) a user has consented to (or not). If the user has visited the site before, the previous consent is loaded from a cookie so the widget doesn't pop up again. If the consent disclosure details (vendors, purposes) have changed, all users get the popup again. They also get the popup after a year has passed. Anyway in GTM we setup triggers so that only tags fire when the appropriate consent has been given. Functional/Required cookies are always loaded outside GTM. If we don't have any analytics or marketing consent, then we never load GTM at all speeding up the site for "no" visitors. GTM has added consent-specific features as well at some point.
TCF works the opposite way, most vendors will always load but they are supposed to "self govern" themselves and check the signal from the CMP whether they have consent or not... which means their code has to be modified extensively to support what to do with requests in the case where they don't have consent to set/read cookies (for instance). A vendor may get consent for one purpose but not for another...so their code has to respect that. Gets complicated fast if a vendor has many different cookies and purposes. Following the policy is part of what vendors agree to when joining the TCF framework. TCF also is facing some big challenges at the moment due the Belgian Data Protection Authority's ruling about the validity of the TCF for implementing the privacy legislation. But that's another can of worms. Point is: clicking "no" to cookies doesn't necessarily mean less network requests or javascript running in the TCF world.
And you probably don't need to worry about cookie popups as a functional cookie if you are careful about what data you store (don't) and keeping things you do store under the customer's domain.
If you decide to build a business model based on the chat data (e.g. disqus style) then you have a lot more you will need to do to be legally compliant as well as to reassure your larger customers' legal/privacy teams.
Some other cookie popups are pure optics. Old sites with lots of manually added script tags and no tag management. Nightmare for them technically to get compliant. So they add a widget that makes it look like they are compliant but nothing changes behind the scenes. These are usually small websites with little to no revenue and so they figure the European DPAs will never bother to come after them... however it is just a matter of time until the specialty lawfirms have bots and letter generation to automate the mass harassment of long-tail sites. Main problem at the moment is how those lawfirms get paid, but if they manage to negotiate a percentage of the DPA fines for providing enforcement as a service...then it will become a big thing.