Web Privacy Terms Glossary
This comprehensive glossary explains key terms, technologies, and concepts related to web privacy, tracking, data protection, and compliance. Understanding these terms is essential for implementing effective privacy protection strategies and ensuring regulatory compliance.
Table of Contents
- Tracking Technologies
- Cookies and Storage
- Data Brokers and Data Sharing
- Privacy Tools and Platforms
- Privacy Regulations
- Technical Concepts
- Security and Certificates
- Additional Privacy Terms
Tracking Technologies
Fingerprinting
Fingerprinting is a tracking technique that creates a unique identifier for a user's device by collecting and analyzing various browser and device characteristics. Unlike cookies, fingerprinting doesn't require storing data on the user's device.
How Fingerprinting Works
Fingerprinting collects information such as:
- Browser characteristics: User agent, screen resolution, installed fonts, plugins
- Hardware information: CPU cores, GPU details, memory information
- System settings: Timezone, language preferences, screen orientation
- Behavioral patterns: Typing patterns, mouse movements, scrolling behavior
Why Fingerprinting is Problematic
| Issue | Description |
|---|---|
| No User Control | Users cannot easily delete or block fingerprints like they can with cookies |
| Persistent Tracking | Works even when cookies are blocked or cleared |
| Privacy Invasion | Collects detailed information without explicit consent |
| Cross-Site Tracking | Enables tracking across different websites and sessions |
| Regulatory Risk | May violate GDPR, CCPA, and other privacy regulations |
Common Fingerprinting Techniques
- Canvas Fingerprinting: Uses HTML5 Canvas API to render text/images and analyze pixel patterns
- WebGL Fingerprinting: Analyzes WebGL rendering characteristics
- Audio Fingerprinting: Uses Web Audio API to detect audio processing differences
- Font Fingerprinting: Detects installed fonts by measuring text rendering
- Battery API Fingerprinting: Uses Battery Status API to identify devices
Session Replay Tools
Session replay tools are analytics platforms that record user interactions on a website, creating a video-like playback of user sessions. These tools capture mouse movements, clicks, scrolling, form inputs, and other interactions.
How Session Replay Works
What Gets Recorded
- Mouse movements and clicks: Every cursor movement and click
- Keyboard input: Text entered in forms (including sensitive data)
- Scrolling behavior: How users navigate through pages
- Page interactions: Button clicks, dropdown selections, hover events
- Form submissions: Data entered before submission
- Page navigation: URLs visited and time spent
Privacy Concerns
| Risk | Impact |
|---|---|
| Sensitive Data Capture | Passwords, credit cards, personal information recorded |
| Compliance Violations | GDPR, CCPA, HIPAA violations if not properly configured |
| User Trust | Privacy violations damage customer relationships |
| Legal Liability | Fines and legal action for non-compliance |
Best Practices
- Field Masking: Mask sensitive input fields (passwords, credit cards, SSN)
- Data Exclusion: Exclude entire pages or sections containg sensitive data
- Consent Management: Obtain explicit user consent before recording
- Data Retention: Limit how long session recordings are stored
- Access Controls: Restrict who can access session recordings
Tracking Pixels and Trackers
Tracking pixels (also called web beacons or pixel tags) are tiny, invisible images (typically 1x1 pixels) embedded in web pages or emails that track user behavior. When loaded, they send information back to the tracking server.
How Tracking Pixels Work
Information Collected by Tracking Pixels
- Email open rates: Whether an email was opened
- Page views: Which pages were visited
- Time spent: How long users stayed on pages
- Device information: Browser type, operating system, screen resolution
- IP address: User's location (approximate)
- Referrer information: Where the user came from
Types of Trackers
| Type | Description | Example |
|---|---|---|
| Analytics Trackers | Measure website performance and user behavior | Google Analytics, Adobe Analytics |
| Advertising Trackers | Track users for targeted advertising | Facebook Pixel, Google Ads |
| Social Media Trackers | Enable social sharing and track engagement | Facebook, Twitter, LinkedIn pixels |
| Retargeting Trackers | Track users to show ads on other sites | AdRoll, Criteo |
| Affiliate Trackers | Track referrals and commissions | Amazon Associates, affiliate networks |
Privacy Implications
- Cross-site tracking: Enables tracking across multiple websites
- Behavioral profiling: Creates detailed profiles of user behavior
- Data sharing: Information shared with third parties
- Consent requirements: May require explicit consent under GDPR/CCPA
Cookies and Storage
First-Party Cookies
First-party cookies are cookies set by the domain that the user is directly visiting. For example, if a user visits example.com, cookies set by example.com are first-party cookies.
Characteristics
- Domain: Set by the same domain the user is visiting
- Access: Can be read and written by the website's own scripts
- Purpose: Typically used for essential website functionality
- Privacy: Generally considered less invasive than third-party cookies
Common Uses
| Use Case | Description |
|---|---|
| Authentication | Rembering login sessions |
| Preferences | Storing user settings and preferences |
| Shopping Carts | Maintaing cart contents |
| Analytics | First-party analytics (more privacy-friendly) |
| Security | CSRF tokens, session management |
Who Can Access First-Party Cookies?
- ✅ The website itself: Can read and write first-party cookies
- ✅ Subdomains: If configured, subdomains can access parent domain cookies
- ❌ Other domains: Cannot access first-party cookies (same-origin policy)
Third-Party Cookies
Third-party cookies are cookies set by a domain different from the one the user is visiting. For example, if a user visits example.com but a cookie is set by adnetwork.com, that's a third-party cookie.
How Third-Party Cookies Work
Characteristics
- Domain: Set by a different domain than the one being visited
- Cross-site tracking: Enables tracking across multiple websites
- Privacy concerns: Major privacy and regulatory concerns
- Browser blocking: Being phased out by major browsers
Common Uses
| Use Case | Description |
|---|---|
| Advertising | Targeted ads across websites |
| Retargeting | Showing ads for previously viewed products |
| Analytics | Cross-site analytics and attribution |
| Social Media | Social sharing buttons and tracking |
| Content Delivery | CDN and content optimization |
Who Can Access Third-Party Cookies?
- ✅ The third-party domain: Can read and write its own third-party cookies
- ✅ Any website: That loads scripts from the third-party domain
- ❌ The first-party website: Cannot directly access third-party cookies
- ⚠️ Note: Third parties can also write first-party cookies through embedded scripts
Browser Restrictions
| Browser | Third-Party Cookie Status |
|---|---|
| Safari | Blocked by default since 2017 |
| Firefox | Blocked by default since 2019 |
| Chrome | Phasing out by 2024 |
| Edge | Following Chrome's timeline |
Cookie Access and Permissions
Who Can Read and Write Cookies?
The following table explains cookie access patterns:
| Cookie Type | Set By | Readable By | Writable By |
|---|---|---|---|
| First-Party Cookie | example.com | example.com, subdomains* | example.com, subdomains* |
| Third-Party Cookie | adnetwork.com | adnetwork.com | adnetwork.com |
| First-Party Cookie (via Third-Party Script) | example.com (via adnetwork.com script) | example.com, adnetwork.com script | example.com, adnetwork.com script |
*If domain attribute is set to parent domain (e.g., .example.com)
Important Security Note
⚠️ Third parties can read and write first-party cookies when:
- A third-party script is embedded on the page
- The script runs in the same origin context
- The script has access to
document.cookieAPI
This is why it's critical to:
- Only load scripts from trusted sources
- Use Content Security Policy (CSP)
- Implement proper consent management
- Regularly audit third-party scripts
Data Brokers and Data Sharing
Data Brokers
Data brokers are companies that collect, aggregate, and sell personal information about individuals. They gather data from various sources and create detailed profiles that are sold to marketers, advertisers, and other businesses.
How Data Brokers Operate
Types of Data Collected
| Category | Examples |
|---|---|
| Demographics | Age, gender, income, education, marital status |
| Location | Home address, work address, travel patterns |
| Behavioral | Shopping habits, online activity, interests |
| Financial | Credit scores, purchase history, financial products |
| Health | Medical conditions, prescriptions, health interests |
| Professional | Job title, company, industry, salary range |
Privacy Concerns
- No direct relationship: Data brokers collect data without direct user interaction
- Lack of transparency: Users often don't know their data is being collected
- Inaccurate data: Profiles may contain incorrect or outdated information
- Opt-out difficulties: Difficult for users to remove their data
- Regulatory compliance: May violate GDPR, CCPA, and other regulations
Major Data Brokers
- Acxiom: One of the largest data brokers globally
- Experian: Credit reporting and marketing services
- Equifax: Credit reporting and identity verification
- Oracle Data Cloud: Marketing and advertising data
- Epsilon: Email and marketing services
Location Data Brokers
Location data brokers specialize in collecting, aggregating, and selling precise location information about individuals. They gather data from mobile apps, websites, and other sources to track where people go.
How Location Data is Collected
| Source | Method | Precision |
|---|---|---|
| Mobile Apps | GPS, Wi-Fi, Bluetooth beacons | Very high (meters) |
| Web Browsing | IP geolocation, HTML5 Geolocation API | Medium (city/region) |
| Cell Towers | Triangulation from cell towers | Medium (hundreds of meters) |
| Wi-Fi Networks | Wi-Fi access point mapping | High (tens of meters) |
| Bluetooth Beacons | Proximity to beacons in stores/venues | Very high (meters) |
Location Data Uses
Privacy and Security Risks
- Stalking and harassment: Precise location can enable stalking
- Home address exposure: Can reveal where people live
- Pattern analysis: Reveals daily routines and habits
- Sensitive locations: Can identify visits to medical facilities, places of worship, etc.
- Data breaches: Location data breaches can have serious safety implications
Regulatory Considerations
- GDPR: Requires explicit consent for location tracking
- CCPA: Location data is considered personal information
- State laws: Various states have specific location privacy laws
- FTC enforcement: FTC has taken action against location data brokers
Privacy Tools and Platforms
Consent Management Tools (CMPs)
Consent Management Platforms (CMPs) are tools that help websites obtain, manage, and document user consent for data collection and processing activities. They are essential for GDPR, CCPA, and other privacy regulation compliance.
How Consent Management Works
Key Features
| Feature | Description |
|---|---|
| Consent Banners | Display privacy notices and consent options |
| Granular Controls | Allow users to choose specific categories |
| Consent Logging | Record consent decisions for compliance |
| Script Blocking | Prevent third-party scripts until consent |
| Preference Centers | Allow users to change consent later |
| Multi-Region Support | Handle different regulations (GDPR, CCPA, etc.) |
Popular CMPs
- OneTrust: Enterprise-focused, comprehensive platform
- Cookiebot: User-friendly, automated scanning
- Osano: Developer-friendly API
- TrustArc: Enterprise compliance platform
- Quantcast Choice: Free, open-source option
Global Privacy Control (GPC)
Global Privacy Control (GPC) is a browser-based privacy signal that allows users to communicate their privacy preferences to websites. When enabled, GPC signals that users want to opt out of the sale or sharing of their personal information.
How GPC Works
GPC Signal Detection
Browser Implementation:
- GPC signal is sent via HTTP header:
Sec-GPC: 1 - Or via JavaScript:
navigator.globalPrivacyControl === true - Signal persists across browser sessions
Website Detection:
// Check for GPC signal
const gpcEnabled = navigator.globalPrivacyControl === true;
if (gpcEnabled) {
// Automatically deny all non-necessary consent
// Block tracking scripts
}
Legal Requirements
CCPA/CPRA Compliance:
- California law requires websites to honor GPC signals
- GPC is equivalent to "Do Not Sell" requests
- Websites must respect GPC without requiring additional action
Other Jurisdictions:
- Colorado (CPA) requires honoring GPC
- Connecticut (CTDPA) requires honoring GPC
- Other states may require GPC compliance
Privacy Benefits
- Universal Opt-Out: Single signal works across all websites
- Automatic Enforcement: No need to opt out on each site
- Persistent: Signal persists across browser sessions
- User Control: Users can easily enable/disable
Implementation Requirements
Websites Must:
- Detect GPC signal on page load
- Automatically deny non-necessary consent when GPC is detected
- Block tracking scripts when GPC is active
- Not show consent banners when GPC is detected (in some jurisdictions)
- Honor GPC signal as equivalent to opt-out request
Best Practices:
- Check GPC signal before showing consent banner
- Automatically set consent to "denied" when GPC is detected
- Log GPC signal detection for compliance
- Test GPC implementation regularly
Tag Managers
Tag Managers are platforms that allow website owners to manage and deploy tracking scripts, analytics tools, and marketing pixels without modifying website code directly. They use a container system to load scripts dynamically.
How Tag Managers Work
Why Tag Managers Matter for Privacy
| Issue | Impact |
|---|---|
| Uncontrolled Script Loading | Tag managers can load scripts without proper consent checks |
| Privacy Risk | Scripts may collect data before consent is obtained |
| Compliance Violations | Loading tracking scripts without consent violates GDPR/CCPA |
| Lack of Visibility | Difficult to know which scripts are loading |
Best Practices
- Consent Integration: Integrate tag manager with consent management platform
- Conditional Loading: Only load tags after consent is obtained
- Regular Audits: Review which tags are configured and why
- Documentation: Document all tags and their purposes
- Testing: Test consent flows to ensure tags don't load prematurely
Tag Manager and Consent Management Integration
Critical Integration Points:
- Tag manager must check consent status before loading any tags
- Consent preferences must be accessible to tag manager
- Tags should be categorized (necessary, analytics, marketing, etc.)
- Users must be able to change consent and have tags reload accordingly
Privacy Regulations
GDPR (General Data Protection Regulation)
GDPR is a comprehensive data protection regulation that came into effect in the European Union in May 2018. It applies to any organization that processes personal data of EU residents, regardless of where the organization is located.
Key Principles
| Principle | Description |
|---|---|
| Lawfulness | Processing must have a legal basis |
| Purpose Limitation | Data collected for specific purposes only |
| Data Minimization | Collect only necessary data |
| Accuracy | Keep data accurate and up-to-date |
| Storage Limitation | Don't keep data longer than necessary |
| Integrity and Confidentiality | Secure data appropriately |
| Accountability | Demonstrate compliance |
Legal Bases for Processing
- Consent: Explicit, informed, freely given consent
- Contract: Necessary for contract performance
- Legal Obligation: Required by law
- Vital Interests: Protect life or physical safety
- Public Task: Public authority functions
- Legitimate Interests: Legitimate business interests (with balancing test)
Key Rights
- Right to Access: Users can request their data
- Right to Rectification: Users can correct inaccurate data
- Right to Erasure: "Right to be forgotten"
- Right to Restrict Processing: Limit how data is used
- Right to Data Portability: Receive data in portable format
- Right to Object: Object to processing
- Rights Related to Automated Decision-Making: Including profiling
Penalties
- Up to €20 million or 4% of annual global turnover, whichever is higher
- Fines have been issued to major companies for violations
CCPA (California Consumer Privacy Act)
CCPA is a California state law that gives California residents rights over their personal information. It went into effect in January 2020 and was expanded by CPRA (California Privacy Rights Act) in 2023.
Who Must Comply
- Businesses that:
- Have annual gross revenue over $25 million, OR
- Buy, sell, or share personal information of 100,000+ consumers, OR
- Derive 50%+ of revenue from selling personal information
Consumer Rights
| Right | Description |
|---|---|
| Right to Know | What personal information is collected, used, shared, or sold |
| Right to Delete | Request deletion of personal information |
| Right to Opt-Out | Opt-out of sale of personal information |
| Right to Non-Discrimination | Cannot be discriminated against for exercising rights |
| Right to Correct | Correct inaccurate personal information |
| Right to Limit | Limit use of sensitive personal information |
Key Differences from GDPR
| Aspect | GDPR | CCPA |
|---|---|---|
| Scope | EU residents | California residents |
| Consent | Explicit consent required | Opt-out for sales |
| Penalties | Up to €20M or 4% revenue | Up to $7,500 per violation |
| Enforcement | Data protection authorities | California Attorney General |
VPPA (Video Privacy Protection Act)
VPPA is a U.S. federal law enacted in 1988 that protects the privacy of video rental and sale records. It was expanded to cover online video services and streaming platforms.
What VPPA Protects
- Video rental records: What videos were rented or purchased
- Viewing history: What content was watched
- Personal information: Name, address, and other identifying information
- Preferences: Video preferences and recommendations
Key Requirements
| Requirement | Description |
|---|---|
| Consent Required | Written consent need to disclose viewing information |
| Opt-In Only | Cannot use opt-out mechanisms |
| Time-Limited Consent | Consent expires after 2 years or when revoked |
| No Implied Consent | Consent must be explicit and informed |
Who Must Comply
- Video rental stores
- Streaming services (Netflix, Hulu, etc.)
- Video-on-demand services
- Any service that rents or sells video content
Penalties
- Actual damages (minimum $2,500 per violation)
- Punitive damages
- Attorney's fees
- Litigation costs
Modern Applications
VPPA applies to:
- Streaming platforms tracking viewing history
- Video analytics tools
- Recommendation engines
- Social sharing of viewing activity
Technical Concepts
Payload
Payload refers to the actual data being transmitted in an HTTP request or response. It's the "body" of the message that carries the substantive information, as opposed to headers or metadata.
Components of HTTP Communication
What Payload Includes
| Component | Description | Example |
|---|---|---|
| POST Body | Data sent in POST requests | Form submissions, API calls |
| JSON Data | Structured data in JSON format | {"name": "John", "email": "john@example.com"} |
| Form Data | URL-encoded form data | name=John&email=john@example.com |
| XML | XML-formatted data | <user><name>John</name></user> |
| Binary Data | Files, images, etc. | Image uploads, file transfers |
What Payload Does NOT Include
❌ Headers: Metadata like Content-Type, Authorization, User-Agent
❌ Query Parameters: Data in URL after ? (e.g., ?id=123)
❌ URL Path: The path portion of the URL (e.g., /api/users)
❌ Cookies: Stored separately and sent in headers
Privacy Implications
- Sensitive Data: Payloads often contain personal information
- Interception Risk: Payloads can be intercepted if not encrypted (HTTPS)
- Logging: Servers may log payload data
- Third-Party Access: Payloads sent to third parties expose data
Example: Tracking Pixel Payload
When a tracking pixel loads, the payload might include:
{
"event": "page_view",
"timestamp": "2024-01-15T10:30:00Z",
"user_id": "abc123",
"page_url": "https://example.com/products",
"referrer": "https://google.com",
"user_agent": "Mozilla/5.0...",
"screen_resolution": "1920x1080",
"viewport_size": "1440x900"
}
Initiator Chain / Request Hierarchy
Initiator chain (also called request hierarchy or dependency chain) refers to the sequence of requests that occur when a webpage loads, showing which resources trigger other resources. This creates a "daisy chain" of dependencies.
How Initiator Chains Work
Understanding the Chain
| Level | Resource | Initiator | Purpose |
|---|---|---|---|
| 1 | HTML Document | User/Browser | Initial page load |
| 2 | Stylesheet | HTML Document | Page styling |
| 3 | Main JavaScript | HTML Document | Core functionality |
| 4 | Tag Manager | Main JavaScript | Script management |
| 5 | Analytics Script | Tag Manager | Analytics tracking |
| 6 | Ad Script | Analytics Script | Advertising |
| 7 | Tracking Pixel | Ad Script | User tracking |
Privacy Implications
| Issue | Description |
|---|---|
| Hidden Dependencies | Users don't know what scripts will load |
| Cascading Tracking | One script triggers multiple trackers |
| Consent Bypass | Scripts may load before consent is checked |
| Data Leakage | Each script in chain may collect data |
| Performance Impact | Long chains slow page load |
Example: Real-World Initiator Chain
1. User visits example.com
↓
2. HTML loads → Requests main.js
↓
3. main.js executes → Loads Google Tag Manager
↓
4. GTM loads → Triggers Google Analytics
↓
5. Google Analytics → Loads DoubleClick
↓
6. DoubleClick → Loads multiple ad trackers
↓
7. Ad trackers → Load additional pixels
Result: One page visit triggers 20+ third-party requests, many without user knowledge or consent.
Best Practices
- Audit Initiator Chains: Use browser DevTools to see all requests
- Minimize Dependencies: Reduce unnecessary script dependencies
- Consent Gates: Block scripts until consent is obtained
- Document Chains: Document which scripts trigger others
- Regular Reviews: Periodically review and remove unused scripts
Security and Certificates
SSL/TLS Certificates
SSL/TLS certificates are digital certificates that authenticate a website's identity and enable encrypted communication between a browser and a web server. They're essential for secure data transmission.
How SSL/TLS Works
Certificate Types
| Type | Description | Validation Level |
|---|---|---|
| Domain Validated (DV) | Basic validation, verifies domain ownership | Low |
| Organization Validated (OV) | Verifies organization identity | Medium |
| Extended Validation (EV) | Extensive verification, shows company name in browser | High |
| Wildcard | Covers domain and all subdomains | Varies |
| Multi-Domain (SAN) | Covers multiple domains | Varies |
Why Certificate Issues Matter for Privacy
| Issue | Privacy Risk |
|---|---|
| Expired Certificates | Browser warnings, potential security vulnerabilities |
| Self-Signed Certificates | No third-party validation, browser warnings |
| Invalid Certificates | Potential man-in-the-middle attacks |
| Mixed Content | HTTP resources on HTTPS pages expose data |
| Third-Party Certificate Issues | Third-party scripts with bad certificates can compromise security |
Self-Signed Certificates
Self-signed certificates are certificates that are signed by the entity that created them, rather than by a trusted Certificate Authority (CA).
Why Self-Signed Certificates Are Problematic
| Problem | Impact |
|---|---|
| No Trust Validation | No third party verifies identity |
| Browser Warnings | Browsers show security warnings |
| Man-in-the-Middle Risk | Easier for attackers to create fake certificates |
| User Confusion | Users may ignore warnings and proceed |
| Compliance Issues | May violate security requirements |
When Self-Signed Might Be Acceptable
- Internal networks (intranets)
- Development/testing environments
- Local development (localhost)
- Never acceptable for: Production websites, third-party scripts, public-facing sites
Third-Party Certificate Issues
When third-party scripts load with certificate problems:
| Scenario | Risk |
|---|---|
| Expired Certificate | Browser blocks or warns, script fails |
| Self-Signed Certificate | Browser warning, user may block |
| Invalid Certificate | Security risk, potential data interception |
| Mixed Content | HTTP script on HTTPS page creates vulnerability |
Best Practices
- Use Valid Certificates: Always use certificates from trusted CAs
- Monitor Expiration: Set up alerts for certificate expiration
- Automated Renewal: Use Let's Encrypt or similar for auto-renewal
- Third-Party Audits: Verify third-party scripts use valid certificates
- Content Security Policy: Use CSP to control which scripts can load
Additional Privacy Terms
Subresource Integrity (SRI)
Subresource Integrity (SRI) is a security feature that allows browsers to verify that external resources (JavaScript, CSS) haven't been tampered with. It uses cryptographic hashes to ensure the integrity of resources loaded from third-party domains.
How SRI Works
Why SRI Matters
Domain Hijacking Risk:
- External domains can expire or be acquired by malicious actors
- Attackers can serve malicious versions of legitimate scripts
- All sites loading from compromised domains are affected
SRI Protection:
- Browser verifies resource matches expected hash
- Blocks resources that don't match
- Prevents malicious code injection
Implementation
<!-- Without SRI: Vulnerable to domain hijacking -->
<script src="https://cdn.example.com/polyfill.js"></script>
<!-- With SRI: Protected against tampering -->
<script src="https://cdn.example.com/polyfill.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
crossorigin="anonymous"></script>
Privacy and Security Benefits
- Prevents malicious code injection from compromised CDNs
- Protects user data from being stolen by malicious scripts
- Ensures resource integrity matches expected content
- Critical for privacy compliance when loading third-party resources
Referrer Policy
Referrer Policy is a web standard that controls how much referrer information (the URL of the page that linked to the current page) is sent with requests. It helps protect user privacy by preventing third parties from learning where users came from.
Referrer Policy Values
| Policy | Behavior | Privacy Level |
|---|---|---|
no-referrer | No referrer sent | Maximum privacy |
strict-origin-when-cross-origin | Full URL same-origin, origin only cross-origin | Recommended default |
origin | Only domain sent | Balanced |
same-origin | Referrer only for same-origin requests | Internal sites |
unsafe-url | Always send full URL | Not recommended |
Privacy Implications
Without Referrer Policy:
- Third parties learn which pages users visited
- Sensitive URLs exposed (healthcare pages, financial pages)
- Cross-site tracking enabled through referrer data
- Compliance violations (HIPAA, GLBA, privacy regulations)
With Referrer Policy:
- Control what referrer information is shared
- Protect sensitive page URLs
- Prevent cross-site tracking through referrers
- Improve privacy compliance
Implementation
<!-- Site-wide referrer policy -->
<meta name="referrer" content="strict-origin-when-cross-origin">
<!-- Per-link referrer policy -->
<a href="https://external-site.com" rel="noreferrer">Link</a>
rel="noopener" and rel="noreferrer"
rel="noopener" and rel="noreferrer" are HTML link attributes that provide privacy and security protection for external links.
rel="noopener"
Purpose: Prevents the new page from accessing the window.opener property, which can be used for security attacks.
Security Benefit:
- Prevents new page from accessing parent window
- Blocks potential security vulnerabilities
- Should always be used with
target="_blank"
rel="noreferrer"
Purpose: Prevents the referrer header from being sent with the request.
Privacy Benefit:
- Third parties don't learn where users came from
- Protects sensitive page URLs from being exposed
- Prevents cross-site tracking through referrer data
Combined Usage
<!-- Maximum privacy and security -->
<a href="https://external-site.com"
target="_blank"
rel="noopener noreferrer">
External Link
</a>
Best Practice: Always use rel="noopener noreferrer" together for external links that open in new tabs.
Server-Side Tracking
Server-side tracking refers to tracking implementations where data collection and forwarding occurs on the server rather than in the user's browser. This includes edge functions, reverse proxies, and event forwarding pipelines.
How Server-Side Tracking Works
Common Implementations
First-Party Relays:
- Your server receives data from client
- Your server forwards data to third parties
- Data appears to come from your domain
Edge Functions:
- Cloudflare Workers, AWS Lambda@Edge, Vercel Edge Functions
- Process requests at the edge
- Can modify or forward data to third parties
Reverse Proxies:
- Cloudflare, Fastly, Akamai, AWS CloudFront
- Intercept requests between client and server
- Can inject tracking or forward events
Event Forwarding Pipelines:
- Google Tag Manager Server-Side, Segment, Tealium
- Server-side event collection and routing
- Forward to multiple third parties simultaneously
Privacy Implications
Important: Server-side tracking does not remove consent obligations:
- GDPR still requires consent for data processing
- CCPA/CPRA still requires disclosure of data sharing
- Privacy policies must disclose server-side forwarding
- Consent must be obtained before server-side data forwarding
Why It Matters
- Accountability shifts to server-side infrastructure
- Privacy teams need visibility into edge functions and reverse proxies
- Traditional client-side scanning cannot detect server-side forwarding
- Compliance requires server-side monitoring and logging
Edge Functions
Edge functions are serverless functions that run at the edge of a network (close to users) rather than on origin servers. They can process requests, modify data, and forward information to third parties before requests reach the origin server.
Common Edge Function Platforms
- Cloudflare Workers: Run JavaScript at Cloudflare's edge
- AWS Lambda@Edge: Run code at AWS edge locations
- Vercel Edge Functions: Run at Vercel's edge network
- Fastly Compute@Edge: Run WebAssembly at Fastly's edge
Privacy Concerns
Why Edge Functions Matter for Privacy:
- Can forward data to third parties without client-side scripts
- Often invisible to traditional client-side scanning tools
- May process personal data without user knowledge
- Require consent and disclosure like client-side tracking
Privacy Teams Must:
- Audit edge function configurations
- Review data forwarding logic
- Document edge function data processing
- Monitor edge function execution
Reverse Proxy
Reverse proxy is a server that sits between clients and origin servers, intercepting requests and responses. Reverse proxies can modify requests, inject tracking, and forward data to third parties.
Common Reverse Proxy Services
- Cloudflare: CDN and reverse proxy service
- Fastly: Edge cloud platform
- Akamai: Content delivery network
- AWS CloudFront: Content delivery service
Privacy Implications
How Reverse Proxies Affect Privacy:
- Can inject tracking pixels or scripts server-side
- Can forward request data to third parties
- Operate transparently to the client
- May process personal data without user knowledge
Privacy Considerations:
- Reverse proxy configurations must be audited
- Data forwarding must be disclosed in privacy policies
- Consent required for data processing through reverse proxies
- Logging required for compliance
Event Forwarding Pipeline
Event forwarding pipeline is a server-side system that collects events from websites and forwards them to multiple third-party destinations. Examples include Google Tag Manager Server-Side, Segment, and Tealium.
How Event Forwarding Works
Privacy Implications
Why Event Forwarding Matters:
- Server-side event collection and forwarding
- Can forward to multiple third parties simultaneously
- May bypass client-side consent checks
- Requires server-side consent enforcement
Compliance Requirements:
- Must obtain consent before forwarding events
- Must disclose all third-party destinations
- Must log event forwarding for audit purposes
- Must honor opt-out requests
First-Party Relay
First-party relay is a server-side implementation where your server receives data from the client and forwards it to third parties, making the data appear to come from your domain rather than third-party domains.
How First-Party Relays Work
- Client sends data to your server
- Your server receives the data
- Your server forwards data to third parties (Google Analytics, Facebook, etc.)
- Third parties see data as coming from your domain
Privacy Implications
Common Misconception: "If data goes through our server first, it's first-party data and doesn't require consent."
Reality:
- Data destination matters: If data is shared with third parties, consent/disclosure is still required
- Purpose matters: Processing for third-party purposes still requires consent
- Legal basis matters: Server-side forwarding doesn't change legal basis for processing
Compliance Requirements:
- Consent required before forwarding to third parties
- Disclosure required in privacy policies
- Data processing agreements required for third parties
- Logging required for compliance audits
Data Residency / Geographic Compliance
Data residency (also called geographic compliance) refers to legal requirements that restrict where personal data can be stored and processed geographically. Different jurisdictions have different requirements for data processing locations.
Why Geographic Compliance Matters
Legal Requirements:
- US Regulations: State privacy laws require disclosure of data processing locations; sector-specific laws (HIPAA, GLBA) may restrict data geography
- EU Regulations: GDPR requires adequate safeguards for data transfers outside EU/EEA; Schrems II decision requires case-by-case assessment
- Other Regions: Canada (PIPEDA), Australia (Privacy Act), Brazil (LGPD) have data residency requirements
Risks of Undesirable Geographies:
- Legal Compliance Violations: Violation of GDPR data transfer requirements, breach of contractual obligations
- Security and Surveillance Risks: Government access to data without proper legal process, mandatory data localization laws
- Reputational and Business Risks: Loss of customer trust, inability to serve certain markets
Common High-Risk Scenarios
- Analytics and tracking services processing data globally
- CDN routing caching data in multiple countries
- Cloud processing in various geographic regions
- Data backups stored in different geographic locations
Cookie Cleanup
Cookie cleanup refers to the process of deleting first-party cookies set by third parties when users opt out of tracking. This is critical because many consent management platforms only block third-party scripts but don't remove first-party cookies that remain in the browser.
Why Cookie Cleanup Matters
The Problem:
- When users opt out, third-party scripts are blocked
- But first-party cookies set by third parties remain
- When users later accept consent, third parties can read existing cookies
- Historical data becomes immediately accessible
- Privacy violation occurs despite previous opt-out
Common First-Party Cookies Set by Third Parties:
_ga,_gid,_gat(Google Analytics)_fbp,_fbc(Facebook Pixel)_hjSession,_hjSessionUser(Hotjar)amplitude_*(Amplitude)mixpanel(Mixpanel)segment_*(Segment)
The Solution
Consent management platforms must actively delete first-party cookies when users opt out:
// Delete cookies on opt-out
function cleanupThirdPartyCookies() {
const cookies = ['_ga', '_gid', '_fbp', '_fbc', '_hjSession'];
cookies.forEach(cookie => {
document.cookie = `${cookie}=; expires=Thu, 01 Jan 1970 00:00:00 UTC; path=/;`;
});
}
Best Practice: Always implement cookie cleanup when users opt out to prevent data leakage.
Cross-Site Tracking
Cross-site tracking refers to the practice of tracking users across multiple websites to build comprehensive profiles of their behavior, interests, and activities.
How It Works
- Third-party cookies set on one site are accessible on other sites
- Tracking pixels and scripts collect data across sites
- Data brokers aggregate information from multiple sources
- Fingerprinting creates persistent identifiers
Privacy Concerns
- Users have limited control
- Creates detailed behavioral profiles
- Enables targeted advertising and manipulation
- May violate privacy regulations
Behavioral Profiling
Behavioral profiling is the process of creating detailed profiles of individuals based on their online behavior, including websites visited, content viewed, purchases made, and interactions.
Profile Components
- Demographics (age, gender, location)
- Interests and hobbies
- Purchase history and preferences
- Browsing patterns
- Device and technology usage
Privacy Implications
- Profiling can be invasive and inaccurate
- Used for targeted advertising and manipulation
- May lead to discrimination
- Users often unaware of profiles
Summary
This glossary covers essential web privacy terms that are critical for understanding:
- Tracking technologies and how they work
- Cookie mechanisms and access patterns
- Data collection and sharing practices
- Privacy regulations and compliance requirements
- Technical concepts underlying web privacy
- Security considerations for privacy protection
Understanding these terms is essential for:
- Implementing effective privacy protection
- Ensuring regulatory compliance
- Building user trust
- Making informed decisions about third-party tools
- Developing privacy-first strategies
For more detailed information on specific topics, refer to the other documentation pages in the Privacy & Compliance section.