Privacy by Design

No operable specimen yet; the illustration is editorial. When applied to a product, still verify that each default really is the most protective reasonable option, that collection points state their purpose, and that the withdrawal path has no more steps than the opt-in path; regulatory compliance must be assessed separately by legal professionals.

{
  "values": [
    "Protected by default",
    "Data minimization",
    "Purpose transparency"
  ],
  "tension": "Protective defaults versus data-driven features and growth",
  "questions": [
    "If the user does nothing, what data is collected, and for what?",
    "Is turning this data collection off as easy as turning it on?"
  ]
}

{
  "id": "privacy-by-design",
  "type": "philosophy",
  "name": {
    "zh": "隐私保护设计",
    "en": "Privacy by Design"
  },
  "aliases": [
    "PbD",
    "隐私设计",
    "Data Protection by Design and by Default"
  ],
  "granularity": "experience",
  "intents": [
    "protect-privacy",
    "configure"
  ],
  "tags": [
    "privacy",
    "default settings",
    "data minimization",
    "purpose specification",
    "user control"
  ],
  "definition": "Make privacy protection the default mode of operation for systems and business processes, embedded at design time rather than bolted on afterwards: if a person does nothing, their personal data stays protected; by default only the data necessary for the stated purpose is processed; and the purpose is explained at the point of collection and not extended beyond it.",
  "boundary": "It is a philosophy that runs through the design process, not a checklist of consent banners or privacy switches; more toggles do not mean protected by default. It is also not the same as security: security is about keeping data from unauthorized access, while privacy by design also asks whether data should be collected at all, how much, and for what. Cavoukian explicitly treats \"privacy versus security\" as a false dichotomy to avoid; both should hold. It is related to but not identical with GDPR Article 25 \"data protection by design and by default\": that is a legal obligation on controllers, whereas this entry describes a design orientation.",
  "signature": [
    "The default state is the most protective reasonable option, with no action required from the user",
    "The purpose is stated where data is collected, and only the data needed for that purpose is collected",
    "Entry points to inspect, withdraw, and adjust data processing are as easy to reach as the features themselves"
  ],
  "when": [
    "The product needs personal data such as location, contacts, or activity records to provide its features",
    "Defining the default settings and first-run flow of a new feature",
    "The product serves markets governed by regulations such as the GDPR and must show that data protection was considered at design time"
  ],
  "when_not": [
    "Treating a consent dialog added before launch as having implemented privacy by design",
    "Using \"privacy\" as a reason to push every data-processing judgment and its labor onto the user, item by item",
    "Substituting a passed security audit for scrutiny of whether collection is necessary and what it is for"
  ],
  "tradeoff": "Protective defaults and data minimization can reduce the data available for personalization, analytics, and growth, and some features will need to be switched on by the user; Cavoukian argues for positive-sum rather than zero-sum, but each specific feature still has to justify whether its data needs are genuinely necessary.",
  "comparison": {
    "focus": "Under what default state, and for what purpose, personal data is processed",
    "mechanism": "Design-time defaults, minimization, and purpose specification",
    "cost": "May reduce available data and add steps to enable features"
  },
  "sources": [
    {
      "id": "cavoukian-7-principles",
      "title": "Cavoukian / IPC Ontario · Privacy by Design: The 7 Foundational Principles (SFU mirror)",
      "url": "https://www.sfu.ca/~palys/Cavoukian-2011-PrivacyByDesign-7FoundationalPrinciples.pdf",
      "claim": "Lists the seven foundational principles: \"privacy as the default setting\" requires that privacy remains intact when the person does nothing, \"privacy embedded into design\" rejects bolting it on afterwards, and \"positive-sum, not zero-sum\" treats privacy versus security as a false dichotomy. The original is an IPC Ontario document published in 2009 and revised in 2011; this check used the copy hosted by SFU.",
      "checkedAt": "2026-09-15",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260915*/https://www.sfu.ca/~palys/Cavoukian-2011-PrivacyByDesign-7FoundationalPrinciples.pdf",
        "status": "unconfirmed",
        "checkedAt": "2026-09-15T18:36:49.962Z",
        "error": "status-request-failed",
        "jobId": "spn2-f39f40426bd50a4f1ad985dba7fb7aa132d13bd1"
      }
    },
    {
      "id": "gdpr-art-25",
      "title": "gdpr-info.eu · Art. 25 GDPR: Data protection by design and by default",
      "url": "https://gdpr-info.eu/art-25-gdpr/",
      "claim": "Article 25(2) requires controllers to ensure that, by default, only personal data necessary for each specific purpose are processed, covering the amount collected, the extent of processing, the storage period, and accessibility; supports this entry's default-setting rule and data-minimization recommendation.",
      "checkedAt": "2026-09-15",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260915*/https://gdpr-info.eu/art-25-gdpr/",
        "status": "available",
        "checkedAt": "2026-09-15T18:31:50.477Z",
        "jobId": "spn2-3e18503e3df2eab2c48e1c77131a99a8c5b1fef9",
        "url": "https://web.archive.org/web/20260915183342/https://gdpr-info.eu/art-25-gdpr/",
        "timestamp": "20260915183342"
      }
    },
    {
      "id": "w3c-privacy-principles",
      "title": "W3C · Privacy Principles (W3C Statement, 2025-05-15)",
      "url": "https://www.w3.org/TR/privacy-principles/",
      "claim": "Principle 2.2.1 restricts transferred data to what is necessary for the user's goals; 2.10.1 and 2.10.2 require stating the purpose when accessing data and not using it for other purposes; 2.12.3 says checking, withdrawing consent, or opting out should be as easy as giving consent; 1.1.1 argues for privacy-protective defaults to reduce \"privacy labour\".",
      "checkedAt": "2026-09-15",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260915*/https://www.w3.org/TR/privacy-principles/",
        "status": "pending",
        "checkedAt": "2026-09-15T18:32:09.187Z",
        "error": "status-request-failed",
        "jobId": "spn2-a83915a4b8cc8b273ce580742c18e1842a45fc9f"
      }
    }
  ],
  "relations": [
    {
      "target": "obstruction",
      "kind": "conflicts_when",
      "condition": "The path to withdraw consent or turn off data collection is longer than the path to turn it on",
      "reason": "Making exit harder than entry directly contradicts the principle that withdrawing should be as easy as giving, turning privacy by design into the obstruction anti-pattern.",
      "basis": "editorial"
    },
    {
      "target": "hidden-costs",
      "kind": "related",
      "condition": "Data purposes are disclosed or expanded only after collection",
      "reason": "Purposes not stated at the point of collection and fees that appear late are both \"late disclosures\" that undermine informed decisions.",
      "basis": "editorial"
    },
    {
      "target": "calm-technology",
      "kind": "composes_with",
      "condition": "Deciding when privacy notices and permission requests appear",
      "reason": "Protective defaults reduce how often users must be interrupted by permission requests; the remaining requests should appear when genuinely needed and explain why.",
      "basis": "editorial"
    }
  ],
  "rules": [
    {
      "when": "Setting the defaults for a feature that involves personal data",
      "instruction": "The default must be the most protective of the reasonable options; modes that need more data are switched on by the user.",
      "strength": "must",
      "basis": "editorial"
    },
    {
      "when": "Designing a data collection point",
      "instruction": "Collect only the data the stated purpose needs, and explain the purpose in one sentence at the point of collection.",
      "strength": "recommend",
      "basis": "editorial"
    },
    {
      "when": "Placing the entry points for privacy controls",
      "instruction": "Entry points to inspect, withdraw, and adjust data processing should be as easy to reach as the features that collect data.",
      "strength": "recommend",
      "basis": "editorial"
    }
  ],
  "philosophy": {
    "values": [
      "Protected by default",
      "Data minimization",
      "Purpose transparency"
    ],
    "tension": "Protective defaults versus data-driven features and growth",
    "questions": [
      "If the user does nothing, what data is collected, and for what?",
      "Is turning this data collection off as easy as turning it on?"
    ]
  },
  "demo": null,
  "version": "0.1.0",
  "editorialStatus": "drafted",
  "requirements": [],
  "demoCapabilities": [],
  "implementationNote": "No operable specimen yet; the illustration is editorial. When applied to a product, still verify that each default really is the most protective reasonable option, that collection points state their purpose, and that the withdrawal path has no more steps than the opt-in path; regulatory compliance must be assessed separately by legal professionals.",
  "image": {
    "src": "/images/privacy-by-design.webp",
    "alt": "A fictional FIELDNOTES privacy settings screen with five toggles all off by default, a small shield icon at the top, and a short data-purpose note card below."
  },
  "searchTerms": [
    "隐私",
    "默认设置",
    "数据最小化",
    "目的说明",
    "用户控制"
  ]
}