Privacy

Privacy

Web application architects and developers must treat privacy not as a compliance afterthought, but as a foundational architectural design requirement. Modern web platforms are shifting away from implicit tracking toward explicit, user-consented, browser-mediated identity and permission exchanges.

1. Privacy by Design and Data Minimization

Reducing the digital footprint to limit breach exposure and foster user trust.

DOs:

• DO collect only adequate, relevant, and strictly necessary data for a stated purpose.
• DO use lower granularity ("fuzzing") where precise data is not required (e.g., age brackets vs. exact birthdates).
• DO offer guest checkouts to avoid forced account creation.
• DO explain why data is collected inline, using aria-describedby to link inputs to their explanations.
• DO use the Clear-Site-Data HTTP header upon logout to wipe client-side cookie caches and local storage.

DON'Ts:

• DON'T collect data speculatively "just in case" it becomes useful.
• DON'T rely on dark patterns or pre-checked opt-ins to force consent.

Code Examples:

Clear-Site-Data (HTTP)

Send this header on the page after logout confirmation.

Clear-Site-Data: "cache", "cookies", "storage"

Inline Transparency (HTML)

<div>
  <label for="email">Email address*</label>
  <input id="email" type="email" name="email" required aria-describedby="whyemail">
  <a href="#whyemail">Why do we need this?</a>
  
  <aside id="whyemail">
    We need this email to send password resets. We will not use it for marketing unless you opt-in.
  </aside>
</div>

2. Third-Party Audits and Mitigations

Limiting leakage introduced by external scripts, embeds, and tracking pixels.

DOs:

• DO audit third parties technically using DevTools (Network panel) and HAR logs.
• DO use the Façade Pattern (Lazy Loading) to load static thumbnails first, only loading heavy widget iframes upon user click.
• DO replace third-party social buttons with static HTML sharing links (e.g., zero tracking SDKs).
• DO set strict HTTP Referrer policies (strict-origin-when-cross-origin or no-referrer) to prevent leaking sensitive URL query parameters.
• DO use rigid Permissions-Policy to lock down powerful APIs (geolocation, camera) globally or for subframes.
• DO use Content-Security-Policy-Report-Only for continuous automated audits of where third-party scripts are attempting to send data.

DON'Ts:

• DON'T use default tracking SDKs if a static hyperlink suffices.

Code Examples:

Referrer-Policy and Permissions-Policy (HTTP)

Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: accelerometer=(), camera=(), fullscreen=*

3. Cookie Deprecation and Partitioned Storage

Architecting for a web without unpartitioned third-party cookies.

DOs:

• DO use CHIPS (Cookies Having Independent Partitioned State) by appending the Partitioned attribute for 1:1 embeds that do not share state across top-level sites.
• DO use the Storage Access API (SAA) when cross-site state sharing is functionally critical (such as SSO portals).
• DO trigger SAA permission requests (requestStorageAccess()) via direct user interaction (click/keypress).

DON'Ts:

• DON'T rely on unpartitioned SameSite=None cookies as they are being systematically blocked by modern browser engines.

Code Examples:

CHIPS Set-Cookie (HTTP)

Set-Cookie: session_id=abc123; SameSite=None; Secure; Path=/; Partitioned; HttpOnly

Storage Access API (JavaScript)

document.getElementById('login-btn').addEventListener('click', async () => {
  try {
    const hasAccess = await document.hasStorageAccess();
    if (!hasAccess) {
      await document.requestStorageAccess();
    }
    // Access granted: unpartitioned cookies are now attached to fetch()
  } catch (err) {
    console.error('Storage access denied', err);
  }
});

Third-Party State Matrix

Heuristic Rule: Use CHIPS for isolated widgets (un-shared state), and SAA for shared identity state requiring explicit user consent.