Personalization privacy and security baseline¶
Research date: 2026-09-20
Scope: persistent, cross-session, first-party Shopper personalization in the production
recommendation service and Commerce Simulation Harness.
Status: engineering baseline and legal-review input, not legal advice or a conclusion that any
particular law applies.
Executive answer¶
A property-scoped pseudonymous Shopper ID linked to browsing and purchase history must be treated as personal information. Pseudonymization reduces risk; it does not make a longitudinal profile anonymous. The service should therefore ship one conservative product baseline everywhere:
- personalization is off by default and starts only after the Commerce Property supplies a versioned, purpose-specific authorization;
- the identifier and all history, derived features, caches, logs, exports, and deletion state are strictly scoped to one Commerce Property;
- opt-out prevents collection and personalized serving immediately, while deletion removes raw and derived state through a measurable, bounded workflow;
- the Interaction API is authenticated, authorized, idempotent, ordered per Shopper, and returns a watermark that the next recommendation request must observe; and
- the service meets an OWASP ASVS 5.0 Level 2-oriented verification baseline, with stronger controls where the threat model requires them.
Explicit opt-in/default-off is a product baseline, not a claim that consent is the only lawful basis in every jurisdiction. For example, GDPR Article 6 provides several possible lawful bases, while Québec's regulator expressly interprets the province's profiling-technology rule as requiring the individual to activate the feature. The integrating merchant remains responsible for selecting and documenting the applicable legal basis and signals, with qualified counsel.
Required engineering baseline¶
| Area | Required behavior | Minimum verification evidence |
|---|---|---|
| Data inventory and purpose | Maintain a field-level inventory covering source, purpose, owner, recipients, location, retention, sensitivity, and deletion path. Do not collect a field until its necessity for a named personalization feature is documented. Do not infer or use sensitive traits in V1. | Versioned data map; purpose/field review; schema tests rejecting undeclared fields. |
| Authorization and transparency | Accept a purpose-specific personalization grant containing policy version, grant time, source, and effective state. Missing, expired, withdrawn, or indeterminate authorization produces the ordinary non-personalized fallback and no history write. Do not reveal which identity/privacy state caused fallback. | Default-off, withdrawal-race, stale-grant, and non-disclosure contract tests. |
| Identifier handling | Use a random, opaque, high-entropy Shopper ID scoped to one Commerce Property. It contains no direct identifier and is never accepted as proof of authority. Derive property scope from the authenticated caller. Keep any identity lookup outside the recommendation service. Do not link across properties. | Entropy/format test; cross-property negative tests; no raw ID in URL, metrics, traces, or logs. |
| Session association | Associate a Session with a Shopper only from an authenticated Commerce Property assertion. Make association idempotent and auditable. Never infer identity from device, network, behavior, or catalog overlap. | Forged-association and property-mismatch tests; repeat-call test; audit event. |
| Interaction integrity | Authenticate the property principal, authorize the (property, shopper) object on every operation, validate event schema and size, and rate-limit by principal/property. Untrusted browser input cannot directly select another Shopper. |
OWASP BOLA/BOPLA/function-authorization suite; malformed and limit tests. |
| Replay and ordering | Deduplicate on (property_id, interaction_id). The same ID and payload returns the original acknowledgement; the same ID with a different payload is rejected. Enforce an explicit per-Shopper sequence/version rule and reject invalid transitions. Bind credentials to a protected channel and use replay-resistant authentication where warranted. |
Duplicate, conflict, out-of-order, concurrent-write, stolen-token, and retry tests. |
| Read-your-actions | An acknowledged interaction returns the committed Shopper Profile version/watermark. A subsequent recommendation request carrying that acknowledgement observes at least that version or fails explicitly; it must not silently return a stale personalized result. | Deterministic view-A/view-B/next-response contract test in production code and simulation. |
| Isolation | Include authenticated property_id in storage keys, indexes, cache keys, queues, deduplication keys, profile versions, deletion jobs, and authorization decisions. Deny by default. Separate service and administrative roles using least privilege and separation of duties. |
Automated two-property isolation suite plus administrative-access review. |
| Retention | Apply TTLs by data class to raw interactions, live profiles, deduplication records, derived features, logs, replicas, and backups. The accepted 90-day Shopper History default is a product cap, not a universal statutory period; deployments may shorten it and may extend it only after a documented necessity and legal review. | Automated expiry tests; inventory-to-TTL reconciliation; backup/restore test proving expired or deleted profiles do not reappear. |
| Opt-out and deletion | Opt-out is an immediate serving/ingestion gate. Deletion is idempotent, property-scoped, and cascades through events, profiles, features, caches, queues, exports, and downstream processors. Preserve only a minimal, separated suppression/audit record where policy and law permit it, with its own TTL. Restoration must reapply deletion tombstones. | Deletion receipt with no raw identity; completeness reconciliation; deletion-during-write and restore tests. |
| Access, correction, export | Provide controller-facing operations to retrieve, correct, export, restrict, and delete Shopper History. Authenticate these operations strongly and never let the recommendation service independently establish the natural person's identity. | Positive/negative rights-request tests; structured export fixture; audit trail. |
| Cryptographic protection | Use current TLS for all external and service-to-service traffic, encrypt personal data and backups at rest, manage keys outside application data, rotate credentials/keys, and protect integrity of interaction and deletion workflows. | Configuration checks, rotation exercise, and recovery test. |
| Logging and monitoring | Record who/what/when/where/outcome for grants, associations, interaction commits, access, export, correction, deletion, privileged use, and authorization failures. Mask or keyed-hash identifiers for correlation; never log tokens, raw Shopper IDs, interaction payloads, or recommendation-revealed sensitive history. Protect logs from alteration and restrict access. | Log schema tests; secret/PI scanning; privileged-access alerts; incident drill. |
| Development and simulation | Use synthetic Shopper histories in routine simulation and tests. Production histories must not enter lower environments. The same authorization, isolation, ordering, expiry, and deletion state machine applies in production and simulation. | Environment data-policy check and parity tests. |
| Governance | Complete a privacy impact assessment before implementation, record controller/processor roles and subprocessors, perform jurisdiction-specific transfer and DPIA screening, and re-review when purposes, features, recipients, identity rules, or ranking consequences change. | Approved assessment and change-gate checklist; incident and breach-response runbook. |
These controls operationalize the NIST Privacy Framework's inventory, govern, control, communicate, and protect outcomes and NIST SP 800-53's PII processing/transparency, access control, audit, communications protection, and incident-response families (NIST Privacy Framework 1.0, NIST SP 800-53 Rev. 5, release 5.2.0). The Privacy Framework 1.1 material visible in 2026 is still an initial public draft, so this baseline uses final version 1.0.
For application verification, OWASP ASVS 5.0 specifically requires data-specific authorization, cross-tenant controls, documented protection requirements for encryption/retention/logging/access, safe treatment of sensitive log data, and logging of authorization failures (v5.0.0-8.2.2, 8.4.1, 14.1.2, 14.2.4, 16.2.5, and 16.3.2). OWASP API Security also identifies broken object-level, object-property, and function-level authorization as core API risks (ASVS 5.0, OWASP API Security Top 10: 2023). NIST's replay guidance explains freshness through nonces/challenges; at the business-event layer, the idempotency ledger and sequence/version rules above supply the equivalent protection against a captured interaction being applied twice (NIST SP 800-63B-4, Replay Resistance).
Legal trigger matrix¶
This matrix identifies questions for counsel and the controller; it does not determine geographic scope, lawful basis, or whether a particular recommendation is a legally significant decision.
Québec¶
Québec's private-sector statute covers information that directly or indirectly identifies a natural person. It requires purposes to be determined before collection, limits collection to what is necessary, requires a privacy impact assessment for a new or overhauled system involving personal information, imposes proportionate safeguards, restricts incompatible use, and requires destruction or compliant anonymization when the purpose has been achieved (sections 2, 3.3, 4-5, 10, 12, and 23). Its notice rules cover purposes, means, rights, withdrawal, recipients, transfers, retention, and profiling technology (sections 8 and 8.1) (official consolidated Act).
The Commission d'accès à l'information says a technology that identifies, locates, or profiles a person cannot have that function active by default; the person must activate it voluntarily. Its guidance even uses personalized content recommendations driven by browsing cookies as the example (CAI collection and profiling guidance, CAI consent guidelines). Section 9.1's separate highest-privacy-setting rule excludes browser-cookie privacy settings; that exception should not be mistaken for an exemption from section 8.1 or the Act's purpose, notice, consent, and withdrawal rules. Québec counsel should confirm how sections 8.1 and 9.1 apply to the merchant/service split.
Section 12.1 adds information and review rights for decisions based exclusively on automated processing. A ranked product list is not automatically such a “decision.” Personalized pricing, eligibility, exclusion, credit, or similarly consequential uses require a new legal and design gate.
Canada outside Québec / federal PIPEDA¶
PIPEDA Schedule 1 requires identified purposes, consent, limited collection, limited use/disclosure/ retention, safeguards, openness, access, and correction. Information no longer required for its purpose should be destroyed, erased, or made anonymous; retention policies should state minimum and maximum periods (official PIPEDA text, Schedule 1). The Office of the Privacy Commissioner says meaningful consent emphasizes what information is collected, who receives it, the purposes, and meaningful residual risk; non-integral processing should offer a clear choice and withdrawal (OPC meaningful-consent guidance). The exact consent form and whether federal or substantially similar provincial law applies require deployment-specific review.
EU/EEA¶
Online identifiers and longitudinal history can be personal data; preference inference is profiling. The controller must document an Article 6 lawful basis for each purpose and comply with purpose limitation, minimization, storage limitation, integrity/confidentiality, accountability, notices, data-subject rights, privacy by design/default, and risk-appropriate security. Pseudonymization is a safeguard, not anonymization. These duties appear in GDPR Articles 4-6, 13-22, 25, and 32 (official GDPR text).
If the chosen basis is legitimate interests, document necessity and balancing and implement the Article 21 objection path. If processing is direct marketing, an objection must stop related profiling. Consent must be as easy to withdraw as to give. A DPIA is mandatory for likely high-risk processing and expressly for the Article 35(3) cases; this project should perform one as an engineering gate even if counsel concludes ordinary retail ranking is outside those mandatory cases. Article 22 does not cover every automated recommendation: it concerns solely automated decisions with legal or similarly significant effects (EDPB profiling and automated-decision guidance, EDPB consent guidance 05/2020).
When cross-session identity relies on cookies or other storage/access on the user's device, ePrivacy Directive Article 5(3) requires prior informed consent unless the operation is strictly necessary for a service the user explicitly requested. Do not assume a personalization identifier is strictly necessary (official consolidated ePrivacy Directive).
California example¶
If the CCPA applies, map collection/use/retention notices and rights to know, correct, delete, and opt out of sale/sharing. A first-party personalization opt-out is not automatically the same as the statutory sale/sharing opt-out; Global Privacy Control must be honored where the latter applies, including for associated pseudonymous profiles. California's 2025 risk-assessment, cybersecurity- audit, and automated-decision regulations became effective in 2026, with phased compliance dates. Counsel must determine whether the business, processing, and any future consequential decision are in scope (CPPA law and regulations, CPPA 2025 regulations and effective dates).
Decisions this research supports¶
- Adopt explicit opt-in/default-off globally. This is the simplest safe product contract and directly satisfies the accepted requirement that consent authorization comes from the Commerce Property. The service consumes a decision; it does not invent a legal basis.
- Treat every Shopper identifier and profile as personal data. Property scoping and pseudonymization are safeguards, not grounds to bypass privacy controls.
- Make privacy state causally ordered with interactions. A withdrawal or deletion barrier must win against concurrent/retried events, and an acknowledgement must name the committed watermark.
- Separate opt-out from deletion. Both stop personalized use immediately; deletion additionally drives lifecycle-wide erasure and proof of completion.
- Keep V1 out of high-impact decisions and sensitive inference. Product ranking does not need health, biometric, precise-location, child-directed, credit, employment, housing, insurance, or similar attributes. Adding them redraws the legal and security boundary.
- Use the same state machine everywhere. Production and simulation implement identical authorization, isolation, ordering, expiry, and deletion semantics; simulation uses synthetic data by default.
Acceptance gate before implementation is called ready¶
- Privacy assessment records purposes, roles, jurisdictions, subprocessors, data locations, transfers, field inventory, retention, deletion, minors/sensitive-data exclusion, and the outcome of GDPR Article 22 / Québec section 12.1 screening.
- Contract tests prove default-off behavior, immediate withdrawal, consent-version changes, interaction idempotency/conflict handling, ordered watermarks, and read-your-actions.
- Adversarial tests prove no cross-property read/write/cache collision, no caller-selected authority, no deletion resurrection, and no identity-state leak through status, latency, or fallback shape.
- Lifecycle tests reconcile a Shopper across the event store, profile, derived features, cache, deduplication state, exports, replicas, and backup restoration.
- Security evidence covers ASVS 5.0 Level 2 controls applicable to the service, threat modeling, encryption/key rotation, privileged access, tamper-resistant audit, rate/size limits, dependency and endpoint inventory, incident response, and recurring control tests.
- Legal counsel approves the deployment-specific lawful-basis/signal mapping, notices, retention, rights deadlines, transfer mechanism, and controller/processor terms. The engineering team must not encode a jurisdictional conclusion from this research alone.
Source quality and freshness¶
Only official legal texts, regulator guidance, and first-party NIST/OWASP standards were used. Sources were checked on 2026-09-20. Privacy law and regulatory guidance change; repeat the legal applicability and citation review before launch in each jurisdiction and whenever personalization purpose, identity scope, or decision impact changes.