Privacy by Design and Default Questions

Direct answer

Collect only what the first session needs, ask for anything else at the moment a feature needs it, and make every optional or sharing setting start in its protective position. Data minimization means collecting no more personal data than a stated purpose requires.

Field-by-field redesign

Required fields at sign-up fall from 6 inputs to 2 typed inputs (email and password), plus the single "I am 16 or older" tick that replaces the birthdate. Defaults: profile private, analytics limited to what runs the service, marketing off.

Timing: progressive profiling

Ask for the extra fields the first time a feature needs them (progressive profiling: the profile fills in gradually as the user uses features), with one sentence on why. Users who never use that feature are never asked.

Showing each change lowers risk, without hurting conversion

• Data inventory diff: stored items per new account go from 6 to 3 (email, the password stored as a hash, and the yes/no age flag), listed per system (profile database, logs, analytics, email tool).
• Log check: sample sign-up logs before and after and confirm phone and birthdate no longer appear.
• Conversion: A/B test the old and new flows with a non-inferiority guardrail on sign-up completion agreed up front. Non-inferiority means the new flow only has to be no worse than the old one by more than a margin chosen in advance, because the goal is less data, not higher conversion. Illustrative: the old flow completes 62% and the margin is 1 point, so the new flow passes if the data show it is not below 61%. Showing non-inferiority within that margin, assuming the two flows truly complete at the same 62%, with 80% power and a one-sided 2.5% test, takes about 36,984 users per arm (computed in python: (1.96 + 0.8416)^2 * 2 * 0.62 * 0.38 / 0.01^2), so a small product may need to choose a wider margin or a longer run. Also track completion of the later prompts, because moving a question does not remove its cost.
• Deletion test: delete a test account and confirm fewer places need clearing.

Pitfall

Dropping a field everywhere is wrong if a real purpose needs it (a regulated product may need verified age). The test for each field is: what purpose, and could it be asked later or derived?

Direct answer. Build the export as an asynchronous job run by a dedicated export service. It re-authenticates the user, collects only data tied to that user through per-dataset exporters (one small piece of code per dataset that names the exact fields it writes, so a new table is never exported by accident, unlike a generic "select everything" query), writes JSON plus CSV files into a ZIP with a manifest (an index file listing what the ZIP contains), and delivers it through a short-lived, single-use download link. Data about other people is stripped or replaced with placeholders before anything is written.

What the law asks for. GDPR (General Data Protection Regulation) Article 20 gives people the right to receive personal data they provided, "in a structured, commonly used and machine-readable format", when processing is based on consent or contract and is automated. Article 20(4) says the right must not adversely affect the rights and freedoms of others, which is the source of the third-party PII (personally identifiable information) problem. Article 12(3) sets a response deadline of one month, extendable by two further months for complex or numerous requests. Which of your datasets count as "provided by" the user, and when repeated requests become excessive, is a call for counsel. The product can export more than the legal minimum.

Format choices

• JSON for nested data (profile, settings, posts), one file per entity type, with a schema_version field and a manifest.json listing files, row counts and field descriptions. An illustrative manifest: {"schema_version":"1.0","generated_at":"2026-03-13T09:30:00Z","files":[{"name":"profile.json","rows":1},{"name":"posts.json","rows":212},{"name":"orders.csv","rows":37}]}.
• CSV for flat, tabular data (orders, activity history) so non-engineers can open it in a spreadsheet.
• Media in its original format. No PDF-only exports, because PDF is readable but not machine-readable.
• Stable field names and ISO 8601 timestamps (the international date format, like 2026-03-14T09:30:00Z) so another service can import it.

Authentication and authorization

1. Step-up authentication (asking the user to prove who they are again, even though they are logged in, before a sensitive action): require a fresh login or second factor within the last 10 minutes (illustrative window), because an export is the highest-value payload in the account.
2. The request creates a job keyed to the authenticated subject_id. The subject comes from the session, never from a request parameter.
3. Each exporter has an allowlist of fields (the only fields it may write; everything else is excluded by default). A new column is excluded until someone classifies it.
4. Email the account owner when a request is made and when the file is ready. Deliver via a signed link bound to the account, valid 24 hours (illustrative), single use, over HTTPS. A signed link carries an expiry time, the account ID and a signature computed with a secret only the server holds, for example /dl/9c1e?acct=1042&exp=1773480600&sig=4cfcdc722238f1b2; changing the account or the expiry makes the signature fail, and the server also marks the link used after the first download. Encrypt the stored archive and delete it after expiry.

Throttling. Allow one active export job per user and queue the rest. Rate-limit the request endpoint per account and per IP, run workers off-peak with a size cap per part (split large exports into several ZIP parts), and limit download attempts per link. Throttling protects the system and stops an attacker with a stolen session from draining data repeatedly. It must not become a way to make the legitimate request hard, since the deadline in Article 12(3) still runs.

Keeping other users' PII out

Enforce it with a field classification (subject, other, shared) in the exporter schema, and a test: seed two users who mention and reply to each other, run user A's export, and assert user B's ID, email and display name appear nowhere in any file.

Trade-offs. Stripping mentions makes threads less readable, so the placeholders should be consistent inside one export. Generous formats cost engineering time, so start with JSON plus CSV for the core entities.

Direct answer

Follow each field from the form to every system that touches it, noting for each whether it is created, stored, transformed, cached or logged. PII (personally identifiable information) here means all five fields. The riskiest places are usually the unintended copies, not the main database.

Data-flow description

Browser form, over TLS, to the backend API. The API sends credentials to the auth service (email plus a password hash), writes name, phone and birthdate to the user-profile database, and sends the picture to object storage that a CDN (content delivery network, edge servers that cache files near users) serves. The API then emits an event that feeds the search index and the analytics pipeline.

Per-field map

Three high-risk storage points to fix first

1. Logs and traces. Request bodies and validation errors capture email, phone and birthdate in plain text, with wide access and long retention. Mitigation: log with an allow-list of fields, redact at the logging library, and set short retention.
2. Search index and analytics copies. Name and email get denormalised into stores that are hard to delete from and widely readable. Mitigation: send a pseudonymous ID instead of raw values, keep only age band, and wire deletion into the erasure flow.
3. Profile pictures in object storage and CDN. Embedded location metadata, guessable URLs, and cached copies that outlive deletion. Mitigation: strip image metadata at upload, use unguessable or signed URLs, and purge the CDN on delete.

The profile database holds the most data but is the intended store, so its mitigations are access control and encryption.

Direct answer. Drive the banner from a region policy table instead of hard-coded logic: the server decides the consent mode per visitor (opt-in means nothing non-essential runs until the person agrees; opt-out means it runs until the person objects; notice-only means the person is informed), the page loads no non-essential tags until the stored consent state allows them (a tag is a small piece of third-party code, such as an analytics or advertising script, that the page loads and that sets cookies or sends data to a vendor), and automated tests plus a production scanner prove it. Counsel sets what each region requires; engineering makes the behaviour enforceable and testable.

Policy table (configuration, owned jointly by privacy and engineering)

As configuration it can be as small as a map from region to mode, for example { "EU": "opt-in", "UK": "opt-in", "US-CA": "opt-out", "default": "notice" }, plus a fallback of opt-in when the region is unknown. The page reads the mode and never contains region logic of its own.

The California points are the ones I would check with counsel; the California Consumer Privacy Act (CCPA) states the opt-out link, and its regulations (11 CCR 7025) require a business that sells or shares personal information to treat a qualifying opt-out preference signal such as GPC as a valid opt-out request.

Per-purpose choices. Offer separate toggles: strictly necessary (always on, no consent), analytics, marketing, personalization. A tag declares its purpose, and the tag manager (the tool that decides which tags load on a page and when) fires it only if that purpose is allowed. Vendor scripts are the third-party tags themselves.

Region detection and its failure modes. Use an edge geo-lookup (the CDN or edge server, which sits close to the visitor, maps the IP address to a country or state before the page is served). It fails with VPNs, mobile carriers, travellers and lookup errors. The rule: if the region is unknown, apply the strictest mode. Cache the banner per region (include the region in the cache key, so each region gets its own cached copy), or an EU visitor can be served a California page. Let users change region-specific choices later through a persistent preference link.

Keeping tags off until consent. Default consent state is denied. Load the tag manager with consent conditions; do not load vendor scripts at all, or set cookies, before the allowed state exists. Beware hard-coded tags, tags added by a vendor script, and server-side events that bypass the banner.

Verification

• CI: a headless browser test (an automated browser with no visible window) per region with consent denied asserts zero requests to the list of tag domains and no non-essential cookies; a second test accepts and asserts the tags fire. A sketch of the denied-consent assertion: visit(page, region="EU", consent="denied"); assert requests_to(TAG_DOMAINS) == []; assert non_essential_cookies() == [].
• Production: a scheduled crawler repeats this from each region's vantage point and alerts on new domains or cookies.

Consent record storage. Store: pseudonymous visitor or user ID, timestamp, per-purpose choice, region mode applied, banner and policy version, and source (banner, preference page, GPC signal). Withdrawal is a new record, and a policy change re-prompts. Link the record to the account when the person signs in.

Direct answer

The default is whatever happens when the user does nothing, so I choose defaults that collect and share the least that still lets the sign-up work. Then I prove they protect people by testing the actual default state of a fresh account, not by reading the design. A default "looks protective" if the screen says private but optional extras are pre-checked, the real data flow is wider than the label, or opting out takes five steps.

Defaults I would choose

How to convince yourself the defaults really protect

1. Fresh-account test: create a new account, touch nothing, and record the resulting settings. An automated end-to-end test asserts each default (profile private, marketing off, no optional fields stored) so a later change cannot silently flip it.
2. Network and storage check: capture network traffic during sign-up and confirm which third parties receive data, and that fields the user left blank are not sent as empty-but-tracked values. Query the database after sign-up to confirm only the intended columns are populated.
3. Dark-pattern review: pre-checked boxes, a bright "accept all" beside a grey "manage", or confusing wording means the default is cosmetic. Both choices should be equally easy and equally clear.
4. Escape-hatch test: time how many steps it takes to change a setting or delete the account.
5. Real-user check: put the screen in front of a few users and ask what they think will happen with their data. If their answer is wrong, the default is not honest.

Convincing product

Product worries about conversion and personalization. Offer evidence: run the minimal form against the longer one; fewer fields usually help completion, and optional data can be asked in context later. Show that opt-in rates are an honest measure of interest, and that a data breach or regulator question about a longer form is the larger business risk.

Pitfalls

A "private by default" label with an inherited global setting that undoes it; defaults that differ by platform (web protective, mobile not); and testing only the happy path where the user clicks through all prompts.