What Is a Cookie?
A cookie (formally an HTTP cookie) is a small piece of text data that a website stores in a user's browser. When you visit a website, the server can instruct your browser to save a cookie. On your next visit, the browser sends that cookie back to the server — allowing the site to remember information about you between visits.
Cookies were invented in 1994 by Lou Montulli at Netscape to solve a fundamental problem: HTTP is a stateless protocol, meaning each request is completely independent. Without cookies, websites couldn't keep you logged in, remember your shopping cart, or personalize any experience.
How Cookies Work Technically
Here is what happens when a website sets a cookie:
1 # Step 1: Server sends a Set-Cookie header with the response 2 HTTP/1.1 200 OK 3 Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Lax; Max-Age=3600 4 5 # The cookie has several attributes: 6 # Name=Value : session_id=abc123 (the actual data) 7 # Path : Which URL paths can access this cookie 8 # HttpOnly : JavaScript cannot access this cookie (security) 9 # Secure : Only sent over HTTPS 10 # SameSite : Lax/Strict/None — controls cross-site sending 11 # Max-Age : Expires after 3600 seconds (1 hour) 12 13 # Step 2: Browser stores the cookie 14 # Step 3: On every subsequent request to the same domain: 15 GET /dashboard HTTP/1.1 16 Cookie: session_id=abc123 17 # The browser automatically sends the cookie back
Cookie Classification: Two Key Dimensions
Session Cookies
Temporary — exist only while the browser is open. Deleted when you close the browser. Used for logins, shopping carts, and form data.
Persistent Cookies
Survive after the browser is closed. Have an expiry date set by the website. Used for remembering preferences, analytics, and advertising.
First-Party Cookies
Set by the domain you are visiting. Generally considered privacy-respecting. Used for logins, preferences, and your own analytics.
Third-Party Cookies
Set by a domain other than the one you're visiting. Used by advertisers to track users across different websites. Being phased out by major browsers.
The Death of Third-Party Cookies
Third-party cookies have been the backbone of online advertising for 25 years. But they are being phased out:
- Safari (2017): Intelligent Tracking Prevention (ITP) blocks third-party cookies by default
- Firefox (2019): Enhanced Tracking Protection blocks known third-party trackers
- Chrome: Attempted to phase out third-party cookies but reversed course in 2024. Chrome now prompts users to choose their privacy settings rather than removing cookies entirely.
For advertisers and analytics teams, this means increasing reliance on first-party data, server-side tracking (like sGTM), and privacy-preserving APIs like Google's Privacy Sandbox.
What Are Your Legal Obligations?
If your website sets any cookies beyond the strictly necessary ones, you have legal obligations in most countries:
- Obtain consent before setting non-essential cookies (GDPR, PECR, and most other privacy laws)
- Maintain a cookie policy listing all cookies, their purpose, and retention period
- Provide a mechanism to withdraw consent at any time
- Keep records of when and how consent was obtained
Consent Must Come BEFORE Cookies Are Set
This is the most common compliance mistake. Cookies must not be set until after the user has given informed consent. Setting Google Analytics cookies on page load (before the user sees or interacts with the banner) is a GDPR violation, regardless of whether a banner appears afterwards.
CookieBeam Blocks Cookies Automatically
CookieBeam prevents all non-essential cookies from being set until after the user consents. It works by intercepting cookie-setting calls from analytics and advertising scripts, holding them in a queue until the appropriate consent signal is received — then releasing them instantly.
Cookie Security: HttpOnly, Secure, and SameSite Attributes
Not all cookies are equal from a security perspective. The way a cookie is configured — specifically its security attributes — determines how vulnerable it is to theft, forgery, and misuse. As a website owner, understanding these attributes helps you assess whether third-party services you rely on are implementing cookies responsibly, and whether your own server-set cookies expose users to unnecessary risk.
Data protection authorities increasingly consider poor cookie security hygiene as part of broader GDPR compliance assessments. A cookie that inadvertently exposes a session token because it lacked the HttpOnly flag is not just a security problem — it is a personal data breach reportable under GDPR Article 33.
| Attribute | Purpose | Privacy / Security Benefit | When to Use |
|---|---|---|---|
| HttpOnly | Blocks JavaScript access to the cookie via document.cookie | Prevents XSS attacks from stealing authentication tokens or session identifiers stored in cookies | All session and authentication cookies. Should be standard practice. |
| Secure | Cookie is only transmitted over HTTPS | Prevents interception of cookie values on unencrypted networks (public Wi-Fi, HTTP connections) | Every cookie on a site running HTTPS (i.e. all production sites) |
| SameSite=Strict | Cookie never sent on cross-site requests | Strongest protection against Cross-Site Request Forgery (CSRF). May break OAuth login flows. | Highly sensitive cookies where cross-origin access is never needed |
| SameSite=Lax | Cookie sent on same-site requests and top-level navigations | Good CSRF protection with minimal usability tradeoffs. The modern browser default. | Most cookies — a safe default for first-party cookies |
| SameSite=None; Secure | Cookie sent on all cross-site requests (requires Secure) | No CSRF protection — use only when cross-origin access is genuinely needed. Always pair with Secure. | Third-party cookies, embedded widgets, ad pixels requiring cross-site access |
How to View Cookies in Your Browser
Every major browser includes developer tools that let you inspect the cookies currently stored on your device for any website. Knowing how to do this is useful for verifying what your own site sets, checking whether a cookie consent banner is working correctly, and understanding what data websites you visit are storing about you.
Viewing Cookies in Chrome DevTools
Open Developer Tools
Press F12 on Windows/Linux, or Cmd + Option + I on macOS. Alternatively, right-click anywhere on the page and select Inspect from the context menu.
Navigate to the Application tab
In the DevTools panel, click the Application tab. If you do not see it, click the double-arrow (») at the right of the tab bar to reveal additional tabs. This tab shows all client-side storage, including cookies, local storage, and session storage.
Expand the Cookies section
In the left sidebar under Storage, expand the Cookies section. You will see your current domain (e.g. https://www.example.com) listed. Click it to see all cookies set for that domain in the main panel.
Inspect individual cookies
Click any cookie row to see its full details: Name, Value, Domain, Path, Expires/Max-Age, Size, HttpOnly flag, Secure flag, SameSite setting, and Priority. Hover over the Expires field to see the exact date and time the cookie will be deleted.
Check cookies from third-party domains
Third-party cookies appear under their own domain in the Cookies section sidebar. For example, a Google Analytics cookie will appear under https://www.google.com or the cookie domain set by GA4. Expand each domain to see cookies from embedded scripts and iframes.
Filter cookies by name
Use the search/filter box at the top of the cookie table to quickly find a specific cookie by name. This is useful when verifying whether a particular third-party service (e.g. the Meta Pixel's _fbp cookie) is present after accepting consent, or absent before consent is granted.
First-Party Data Strategy: The Post-Cookie Future
Third-party cookies — the backbone of cross-site tracking and retargeting for over two decades — are disappearing. Safari and Firefox already block them by default. Google Chrome, which holds the majority of browser market share, has been progressively restricting third-party cookie access and is rolling out user controls that effectively end their usefulness for advertising at scale.
This is not the end of data-driven marketing. It is the beginning of a more sustainable, consent-driven model. The winners in the post-cookie era will be businesses that invest now in first-party data strategy — collecting, organising, and activating data that users have explicitly chosen to share with you.
What First-Party Data Strategy Looks Like in Practice
Server-Side Tracking: Instead of relying on browser-set third-party cookies, server-side tracking sends event data directly from your server to analytics and ad platforms. This approach is not affected by browser cookie restrictions, ITP, or ad blockers. Tools like server-side Google Tag Manager (sGTM) combined with CookieBeam's consent signals make this possible while remaining GDPR-compliant.
Consent-Based Data Collection: Build value exchanges that motivate users to opt in. Gated content, personalised recommendations, loyalty programmes, and email newsletters are all mechanisms for collecting first-party data with genuine user consent. With proper GDPR consent in place — managed through CookieBeam — this data is legally your most valuable asset.
Customer Data Platforms (CDPs): A CDP unifies first-party data from your website, CRM, email platform, and point-of-sale into a single customer profile. With consent status passed from CookieBeam, a CDP can suppress data activation for users who have not consented, ensuring that your downstream marketing tools only use data they are legally permitted to process.
Contextual Advertising: Contextual targeting — serving ads based on the content of the page rather than the user's profile — has seen a significant renaissance as cookie-based targeting declines. Contextual advertising does not require cookies or user consent, and modern contextual platforms using NLP and AI match ad relevance that was previously only achievable with behavioural targeting.
Cookies vs Local Storage vs Session Storage: What's the Difference?
Cookies are not the only way browsers store data locally. Modern browsers support three main client-side storage mechanisms: cookies, local storage, and session storage. Each has different capabilities, lifetimes, and privacy implications — and all three can potentially be used for tracking, which means all three can fall under GDPR consent requirements depending on how they are used.
Cookies vs Local Storage vs Session Storage
| Feature | Cookies | Local Storage | Session Storage |
|---|---|---|---|
| Default lifetime | Set by Expires/Max-Age attribute — from session to years | Permanent until explicitly cleared by JavaScript or user | Deleted when the browser tab or window is closed |
| Storage limit | ~4 KB per cookie | ~5–10 MB per origin | ~5–10 MB per origin |
| Sent to server automatically | Yes — sent with every HTTP request to the matching domain | No — only accessible via JavaScript | No — only accessible via JavaScript |
| Accessible from JavaScript | Yes (unless HttpOnly flag is set) | Yes — always | Yes — always |
| Cross-tab sharing | Yes — shared across all tabs for the domain | Yes — shared across all tabs for the origin | No — isolated per tab |
| Can be used for tracking | Yes — the traditional tracking mechanism | Yes — increasingly used as a cookie alternative | Limited — short-lived, but fingerprinting scripts can use it |
| Requires GDPR consent | Yes, for non-essential use cases | Yes, if used for tracking or analytics purposes | Yes, if used for tracking — though session-only use for UX may be exempt |
The Cookie Consent Requirement: What You Must Do
The requirement to obtain consent before setting non-essential cookies stems from Article 5(3) of the ePrivacy Directive (the 'Cookie Law'), as interpreted in conjunction with the GDPR's requirements for valid consent. Every website that serves users in the EU, UK, or other jurisdictions with similar laws must comply — regardless of where the website is hosted or where the company behind it is based.
Cookie Consent Compliance Checklist
Conduct a full cookie audit and document every cookie by name, provider, purpose, and retention period.
Implement a consent management platform (CMP) like CookieBeam that displays a compliant consent banner before any non-essential cookies are set.
Ensure that declining consent is as easy as accepting — a single 'Reject All' button must be present at the same level as 'Accept All', not buried in a sub-menu.
Block all non-essential scripts (analytics, marketing, functional) until the user grants consent. Do not pre-tick any categories.
Obtain explicit, affirmative consent — silence, pre-scrolling, or continued use of the site does not constitute valid consent under GDPR.
Store a verifiable consent record for each user — including timestamp, banner version, and the specific choices made. CookieBeam does this automatically.
Publish a cookie policy that lists all cookies, explains their purpose, and tells users how to withdraw consent.
Provide a persistent way for users to change or withdraw consent at any time — typically a 'Manage Cookie Preferences' link in the site footer.
Implement Google Consent Mode v2 if you use Google Ads or GA4, to ensure consent signals are passed correctly to Google's measurement infrastructure.
Re-audit your cookies quarterly, or whenever you add a new third-party service. Update your policy and CookieBeam configuration to reflect changes.
Frequently Asked Questions About Cookies
Do all cookies require consent?
No. Cookies that are strictly necessary for a website to function — session cookies that maintain a shopping cart, authentication cookies that keep you logged in, load-balancing cookies — do not require consent under the ePrivacy Directive's Article 5(3) exemption. However, the category of 'strictly necessary' is narrow and often misapplied. Analytics cookies, preference cookies, and marketing cookies always require consent, even if the vendor markets them as 'functional'.
How long can cookies last?
There is no universal legal maximum, but the GDPR's data minimisation principle (Article 5(1)(e)) requires that cookie retention periods are limited to what is necessary for the stated purpose. The French data protection authority (CNIL) has explicitly recommended a maximum of 13 months for analytics cookies. Some DPAs have gone further and suggested 6 months. Browser-level restrictions (Apple's ITP, for example) cap first-party cookies set via JavaScript at 7 days, regardless of the Expires value you set.
What is a supercookie?
A supercookie is a tracking mechanism that survives beyond normal cookie deletion. Unlike regular cookies, supercookies may be stored in browser caches, ETags, local storage, or even embedded in ISP network headers — making them extremely difficult for users to delete. They are generally considered a more invasive form of tracking than regular cookies and are viewed by regulators as technically circumventing users' consent choices. The use of supercookies without consent is illegal under the ePrivacy Directive and GDPR.
What is cookie syncing?
Cookie syncing (also called cookie matching) is a technique used by ad networks to match their user IDs with those of other ad networks. When a user visits a page with ads from multiple networks, the networks exchange ID information so they can build a shared profile of that user across platforms. Cookie syncing requires consent under the GDPR and is regulated under the IAB Transparency and Consent Framework (TCF). CookieBeam passes TCF consent signals to integrated ad networks to prevent cookie syncing for users who have declined.
Can cookies be used to store personal data?
Cookies can store any string of text, including personal data such as email addresses, user IDs, or demographic information. Under GDPR, any cookie that stores or enables the processing of personal data must have a valid legal basis — typically consent for non-essential cookies. Even pseudonymised IDs (like a hashed user ID) are considered personal data under GDPR if they can be re-linked to an individual. Developers should avoid storing raw personal data in cookie values; use server-side session management instead.
What happens if I do not implement cookie consent?
Operating without a compliant cookie consent mechanism exposes your organisation to regulatory action from EU data protection authorities. GDPR fines can reach €20 million or 4% of global annual turnover — whichever is higher. In practice, most enforcement actions start with a complaint to a DPA (e.g. from a user who notices non-compliant cookies), followed by an investigation and a compliance order. Repeated non-compliance after a formal order leads to financial penalties. Beyond fines, non-compliance damages user trust and can affect your ad platform accounts if Google or Meta determine you are violating their terms on data consent.
Cookie Security: HttpOnly, Secure, and SameSite Attributes
Not all cookies are equal from a security perspective. The way a cookie is configured — specifically its security attributes — determines how vulnerable it is to theft, forgery, and misuse. As a website owner, understanding these attributes helps you assess whether third-party services you rely on are implementing cookies responsibly, and whether your own server-set cookies expose users to unnecessary risk.
Data protection authorities increasingly consider poor cookie security hygiene as part of broader GDPR compliance assessments. A cookie that inadvertently exposes a session token because it lacked the HttpOnly flag is not just a security problem — it is a personal data breach reportable under GDPR Article 33.
| Attribute | Purpose | Privacy / Security Benefit | When to Use |
|---|---|---|---|
| HttpOnly | Blocks JavaScript access to the cookie via document.cookie | Prevents XSS attacks from stealing authentication tokens or session identifiers stored in cookies | All session and authentication cookies. Should be standard practice. |
| Secure | Cookie is only transmitted over HTTPS | Prevents interception of cookie values on unencrypted networks (public Wi-Fi, HTTP connections) | Every cookie on a site running HTTPS (i.e. all production sites) |
| SameSite=Strict | Cookie never sent on cross-site requests | Strongest protection against Cross-Site Request Forgery (CSRF). May break OAuth login flows. | Highly sensitive cookies where cross-origin access is never needed |
| SameSite=Lax | Cookie sent on same-site requests and top-level navigations | Good CSRF protection with minimal usability tradeoffs. The modern browser default. | Most cookies — a safe default for first-party cookies |
| SameSite=None; Secure | Cookie sent on all cross-site requests (requires Secure) | No CSRF protection — use only when cross-origin access is genuinely needed. Always pair with Secure. | Third-party cookies, embedded widgets, ad pixels requiring cross-site access |
How to View Cookies in Your Browser
Every major browser includes developer tools that let you inspect the cookies currently stored on your device for any website. Knowing how to do this is useful for verifying what your own site sets, checking whether a cookie consent banner is working correctly, and understanding what data websites you visit are storing about you.
Viewing Cookies in Chrome DevTools
Open Developer Tools
Press F12 on Windows/Linux, or Cmd + Option + I on macOS. Alternatively, right-click anywhere on the page and select Inspect from the context menu.
Navigate to the Application tab
In the DevTools panel, click the Application tab. If you do not see it, click the double-arrow (») at the right of the tab bar to reveal additional tabs. This tab shows all client-side storage, including cookies, local storage, and session storage.
Expand the Cookies section
In the left sidebar under Storage, expand the Cookies section. You will see your current domain (e.g. https://www.example.com) listed. Click it to see all cookies set for that domain in the main panel.
Inspect individual cookies
Click any cookie row to see its full details: Name, Value, Domain, Path, Expires/Max-Age, Size, HttpOnly flag, Secure flag, SameSite setting, and Priority. Hover over the Expires field to see the exact date and time the cookie will be deleted.
Check cookies from third-party domains
Third-party cookies appear under their own domain in the Cookies section sidebar. For example, a Google Analytics cookie will appear under https://www.google.com or the cookie domain set by GA4. Expand each domain to see cookies from embedded scripts and iframes.
Filter cookies by name
Use the search/filter box at the top of the cookie table to quickly find a specific cookie by name. This is useful when verifying whether a particular third-party service (e.g. the Meta Pixel's _fbp cookie) is present after accepting consent, or absent before consent is granted.
First-Party Data Strategy: The Post-Cookie Future
Third-party cookies — the backbone of cross-site tracking and retargeting for over two decades — are disappearing. Safari and Firefox already block them by default. Google Chrome, which holds the majority of browser market share, has been progressively restricting third-party cookie access and is rolling out user controls that effectively end their usefulness for advertising at scale.
This is not the end of data-driven marketing. It is the beginning of a more sustainable, consent-driven model. The winners in the post-cookie era will be businesses that invest now in first-party data strategy — collecting, organising, and activating data that users have explicitly chosen to share with you.
What First-Party Data Strategy Looks Like in Practice
Server-Side Tracking: Instead of relying on browser-set third-party cookies, server-side tracking sends event data directly from your server to analytics and ad platforms. This approach is not affected by browser cookie restrictions, ITP, or ad blockers. Tools like server-side Google Tag Manager (sGTM) combined with CookieBeam's consent signals make this possible while remaining GDPR-compliant.
Consent-Based Data Collection: Build value exchanges that motivate users to opt in. Gated content, personalised recommendations, loyalty programmes, and email newsletters are all mechanisms for collecting first-party data with genuine user consent. With proper GDPR consent in place — managed through CookieBeam — this data is legally your most valuable asset.
Customer Data Platforms (CDPs): A CDP unifies first-party data from your website, CRM, email platform, and point-of-sale into a single customer profile. With consent status passed from CookieBeam, a CDP can suppress data activation for users who have not consented, ensuring that your downstream marketing tools only use data they are legally permitted to process.
Contextual Advertising: Contextual targeting — serving ads based on the content of the page rather than the user's profile — has seen a significant renaissance as cookie-based targeting declines. Contextual advertising does not require cookies or user consent, and modern contextual platforms using NLP and AI match ad relevance that was previously only achievable with behavioural targeting.
Cookies vs Local Storage vs Session Storage: What's the Difference?
Cookies are not the only way browsers store data locally. Modern browsers support three main client-side storage mechanisms: cookies, local storage, and session storage. Each has different capabilities, lifetimes, and privacy implications — and all three can potentially be used for tracking, which means all three can fall under GDPR consent requirements depending on how they are used.
Cookies vs Local Storage vs Session Storage
| Feature | Cookies | Local Storage | Session Storage |
|---|---|---|---|
| Default lifetime | Set by Expires/Max-Age attribute — from session to years | Permanent until explicitly cleared by JavaScript or user | Deleted when the browser tab or window is closed |
| Storage limit | ~4 KB per cookie | ~5–10 MB per origin | ~5–10 MB per origin |
| Sent to server automatically | Yes — sent with every HTTP request to the matching domain | No — only accessible via JavaScript | No — only accessible via JavaScript |
| Accessible from JavaScript | Yes (unless HttpOnly flag is set) | Yes — always | Yes — always |
| Cross-tab sharing | Yes — shared across all tabs for the domain | Yes — shared across all tabs for the origin | No — isolated per tab |
| Can be used for tracking | Yes — the traditional tracking mechanism | Yes — increasingly used as a cookie alternative | Limited — short-lived, but fingerprinting scripts can use it |
| Requires GDPR consent | Yes, for non-essential use cases | Yes, if used for tracking or analytics purposes | Yes, if used for tracking — though session-only use for UX may be exempt |
The Cookie Consent Requirement: What You Must Do
The requirement to obtain consent before setting non-essential cookies stems from Article 5(3) of the ePrivacy Directive (the 'Cookie Law'), as interpreted in conjunction with the GDPR's requirements for valid consent. Every website that serves users in the EU, UK, or other jurisdictions with similar laws must comply — regardless of where the website is hosted or where the company behind it is based.
Cookie Consent Compliance Checklist
Conduct a full cookie audit and document every cookie by name, provider, purpose, and retention period.
Implement a consent management platform (CMP) like CookieBeam that displays a compliant consent banner before any non-essential cookies are set.
Ensure that declining consent is as easy as accepting — a single 'Reject All' button must be present at the same level as 'Accept All', not buried in a sub-menu.
Block all non-essential scripts (analytics, marketing, functional) until the user grants consent. Do not pre-tick any categories.
Obtain explicit, affirmative consent — silence, pre-scrolling, or continued use of the site does not constitute valid consent under GDPR.
Store a verifiable consent record for each user — including timestamp, banner version, and the specific choices made. CookieBeam does this automatically.
Publish a cookie policy that lists all cookies, explains their purpose, and tells users how to withdraw consent.
Provide a persistent way for users to change or withdraw consent at any time — typically a 'Manage Cookie Preferences' link in the site footer.
Implement Google Consent Mode v2 if you use Google Ads or GA4, to ensure consent signals are passed correctly to Google's measurement infrastructure.
Re-audit your cookies quarterly, or whenever you add a new third-party service. Update your policy and CookieBeam configuration to reflect changes.
Frequently Asked Questions About Cookies
Do all cookies require consent?
No. Cookies that are strictly necessary for a website to function — session cookies that maintain a shopping cart, authentication cookies that keep you logged in, load-balancing cookies — do not require consent under the ePrivacy Directive's Article 5(3) exemption. However, the category of 'strictly necessary' is narrow and often misapplied. Analytics cookies, preference cookies, and marketing cookies always require consent, even if the vendor markets them as 'functional'.
How long can cookies last?
There is no universal legal maximum, but the GDPR's data minimisation principle (Article 5(1)(e)) requires that cookie retention periods are limited to what is necessary for the stated purpose. The French data protection authority (CNIL) has explicitly recommended a maximum of 13 months for analytics cookies. Some DPAs have gone further and suggested 6 months. Browser-level restrictions (Apple's ITP, for example) cap first-party cookies set via JavaScript at 7 days, regardless of the Expires value you set.
What is a supercookie?
A supercookie is a tracking mechanism that survives beyond normal cookie deletion. Unlike regular cookies, supercookies may be stored in browser caches, ETags, local storage, or even embedded in ISP network headers — making them extremely difficult for users to delete. They are generally considered a more invasive form of tracking than regular cookies and are viewed by regulators as technically circumventing users' consent choices. The use of supercookies without consent is illegal under the ePrivacy Directive and GDPR.
What is cookie syncing?
Cookie syncing (also called cookie matching) is a technique used by ad networks to match their user IDs with those of other ad networks. When a user visits a page with ads from multiple networks, the networks exchange ID information so they can build a shared profile of that user across platforms. Cookie syncing requires consent under the GDPR and is regulated under the IAB Transparency and Consent Framework (TCF). CookieBeam passes TCF consent signals to integrated ad networks to prevent cookie syncing for users who have declined.
Can cookies be used to store personal data?
Cookies can store any string of text, including personal data such as email addresses, user IDs, or demographic information. Under GDPR, any cookie that stores or enables the processing of personal data must have a valid legal basis — typically consent for non-essential cookies. Even pseudonymised IDs (like a hashed user ID) are considered personal data under GDPR if they can be re-linked to an individual. Developers should avoid storing raw personal data in cookie values; use server-side session management instead.
What happens if I do not implement cookie consent?
Operating without a compliant cookie consent mechanism exposes your organisation to regulatory action from EU data protection authorities. GDPR fines can reach €20 million or 4% of global annual turnover — whichever is higher. In practice, most enforcement actions start with a complaint to a DPA (e.g. from a user who notices non-compliant cookies), followed by an investigation and a compliance order. Repeated non-compliance after a formal order leads to financial penalties. Beyond fines, non-compliance damages user trust and can affect your ad platform accounts if Google or Meta determine you are violating their terms on data consent.