From aa4c3d11c342fc262308ca06ba2ee06a499d61de Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 5 Aug 2026 08:28:29 +0000 Subject: [PATCH 1/3] Privacy policy: credential custody, transfers wording, sharing clause Wording updates to the served privacy policy and its source text, from the review rounds of 2026-08-03/04: - Credential custody: the long-term credentials are never sent to the Service; passkey private keys remain with the authenticator, recovery material with the user, and linked-account credentials with their providers. The follow-on custody paragraph is aligned. - International transfers: the network paragraph describes the processing factually. The Service submits requests deliberately at the user's direction; node locations are set by the network's governance and can include countries without an adequacy finding; the text names what travels. The AWS residual-access sentence names the concrete mechanism (the AWS Data Processing Addendum incorporating the EU Standard Contractual Clauses, with the Swiss extension). - Sharing: no sale, no disclosure for advertising, disclosure only to the recipients section 2 describes, and section 2 now includes the public-authorities recipient category so the comply-with-law clause has a covered recipient. - The source doc's header notes are updated to neutral maintenance notes recording the rounds; engineering follow-ups are tracked in issues #120, #121, and #122. Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01TGhwpdTbUqQbR5AiiN8Ljw --- docs/icp-mcp-privacy-policy-draft.md | 95 ++++++++++++++++++++-------- src/assets/privacy-policy.html | 46 +++++++++----- 2 files changed, 100 insertions(+), 41 deletions(-) diff --git a/docs/icp-mcp-privacy-policy-draft.md b/docs/icp-mcp-privacy-policy-draft.md index 087a73f..bfda5db 100644 --- a/docs/icp-mcp-privacy-policy-draft.md +++ b/docs/icp-mcp-privacy-policy-draft.md @@ -34,17 +34,45 @@ > 3. **Metrics retention: resolved.** Verified in code: gauges are computed > on demand from in-memory session maps and the status dashboard persists > nothing, so the policy states they are not stored. -> 4. **EU representative: open with DFINITY legal, off the page.** The -> published text asserts nothing either way (the FDPIC/EU-authority -> complaint sentence is accurate regardless), so publication does not -> pre-empt the decision. The underlying question stands: if GDPR -> Art. 3(2) applies (a directory listing distributed to EU users weighs -> toward it), Art. 27's exemption will not fit — the processing is core -> and continuous, not occasional — so legal should either name a -> representative in section 7 (reusing any existing appointment) or -> record a reasoned position that Art. 3(2) does not apply. -> `dfinity.org/privacy` is JS-rendered and could not be text-checked for -> an existing appointment. +> 4. **EU representative: handled outside this repository.** The published +> text asserts nothing either way (the FDPIC/EU-authority complaint +> sentence is accurate regardless). Update section 7 if a representative +> is named. +> +> **Revised against the legal review round of 2026-08-03.** Three wording +> corrections adopted verbatim or near-verbatim from that review: +> +> 5. **Credential custody restated.** "Never leave Internet Identity" wrongly +> implied II stores the credentials. The policy now says they are never +> sent to the Service and names where each actually lives (passkey private +> keys with the authenticator, recovery material with the user, +> linked-account credentials with their providers). +> 6. **International transfers.** Section 3's network paragraph describes the +> international processing factually: the Service submits requests +> deliberately at the user's direction, node locations are set by the +> network's governance, and it names what travels. The wording of this +> paragraph is maintained together with DFINITY legal; coordinate any +> change to it (and keep the served page and this text in sync). The AWS +> hosting sentence (Data Processing Addendum incorporating the EU +> Standard Contractual Clauses, with the Swiss extension) is confirmed +> and stands. +> 7. **Sharing sentence de-contradicted.** "We do not share it with third +> parties for their own purposes" conflicted with section 2, which +> discloses that assistants, applications, and their operators process +> data under their own policies. Replaced with: no sale, no disclosure +> for advertising, disclosure only to the section-2 recipients as +> necessary to perform requests, secure the Service, or comply with law. +> 8. **OAuth registration lifetime: engineering, tracked.** The review asks +> for a fixed inactivity lifetime (and ideally a deletion mechanism) for +> OAuth client registrations instead of retention until LRU displacement. +> That is a code change; the policy keeps stating the current behaviour +> honestly until it ships, and the retention row must be updated when it +> does. Tracked with the other two engineering follow-ups from this +> round: purging session credentials immediately when revocation is +> observed, and a deployment-level logging audit (AWS services, load +> balancer, reverse proxy, crash diagnostics, DNS/CDN, journald, support +> access) to substantiate the policy's logging claims beyond application +> code. --- @@ -80,15 +108,16 @@ using a consensus protocol. The Service lets an AI assistant read public information from it without any sign-in. For an assistant to act on your behalf, you sign in once with Internet -Identity. **Your long-term authentication credentials never leave Internet -Identity**: your passkeys, recovery phrase, and any linked accounts stay -there, are never entered into the chat, and are never shared with the -Service. +Identity. **Your long-term credentials are never sent to the Service.** +Passkey private keys remain with your authenticator, recovery material +remains with you, and linked-account credentials remain with their +respective providers; none of them are entered into the chat or shared with +the Service. What the Service does hold, once you approve a connection, is a **delegated session signing key that the Service generates itself**, inside the server. No secret key crosses a network in either direction: your credentials stay -with Internet Identity, and the Service's key never leaves the Service. What +where they already live, and the Service's key never leaves the Service. What travels is only the key's public half, which Internet Identity signs, issuing a time-limited, scope-limited authorization for that key to act as you. The Service uses the session key with Internet Identity to obtain, for @@ -239,8 +268,13 @@ data-processing terms. We use no other infrastructure processors today; if an observability or error-reporting provider is ever introduced, it will be named here first. -We do not sell your data, and we do not share it with third parties for their -own purposes. +**Public authorities, where the law requires it.** If we are legally obliged +to disclose personal data, for example by a court order or a binding request +from a competent authority, we disclose the minimum required. + +We do not sell personal data or disclose it for advertising. We disclose it +only to the recipients described above, as necessary to perform your +requests, secure the Service, or comply with law. ### 3. International Transfers @@ -250,14 +284,23 @@ the European Economic Area, whose countries are recognised by the Swiss Federal Council as providing adequate data protection, so no additional transfer safeguard is required for this hosting. Amazon Web Services may have limited remote access from other countries for support and operations; -that access is governed by its data-processing terms, which incorporate the -recognised safeguards for such transfers. - -Separately, and by design, the Internet Computer is a global public network: -its nodes are operated by independent providers in many countries, so -requests you submit and anything you write to an application are processed -internationally and outside our control. That is inherent to using a public -network rather than a transfer we arrange. +that access is governed by the AWS Data Processing Addendum, which +incorporates the EU Standard Contractual Clauses, as extended to Swiss +transfers in line with the FDPIC's guidance, for any processing from a +country without an adequate level of data protection. + +Separately, the Internet Computer is a global public network: its nodes are +operated by independent providers in many countries, whose locations are set +by the network's governance, not by us, and can include countries that +Switzerland and the EEA do not recognise as providing adequate data +protection. When you direct the Service to read from or act on an +application, the Service submits that request to the network deliberately, +on your instruction, and the network processes it internationally to execute +what you asked. What travels is the content of your request and its results +(section 1) under the pseudonymous per-application identifiers described in +section 6. This processing is inherent to the network's design and applies +to every request, so take it into account when deciding which applications +to direct the Service at. ### 4. Data Retention diff --git a/src/assets/privacy-policy.html b/src/assets/privacy-policy.html index 0b126ff..00386e4 100644 --- a/src/assets/privacy-policy.html +++ b/src/assets/privacy-policy.html @@ -171,15 +171,16 @@

How signing in works, and what the Service holds

information from it without any sign-in.

For an assistant to act on your behalf, you sign in once with Internet -Identity. Your long-term authentication credentials never leave -Internet Identity: your passkeys, recovery phrase, and any linked -accounts stay there, are never entered into the chat, and are never shared -with the Service.

+Identity. Your long-term credentials are never sent to the +Service. Passkey private keys remain with your authenticator, +recovery material remains with you, and linked-account credentials remain +with their respective providers; none of them are entered into the chat or +shared with the Service.

What the Service does hold, once you approve a connection, is a delegated session signing key that the Service generates itself, inside the server. No secret key crosses a network in either -direction: your credentials stay with Internet Identity, and the Service's +direction: your credentials stay where they already live, and the Service's key never leaves the Service. What travels is only the key's public half, which Internet Identity signs, issuing a time-limited, scope-limited authorization for that key to act as you. The Service uses the session key @@ -338,8 +339,14 @@

2. Who Receives Data

today; if an observability or error-reporting provider is ever introduced, it will be named here first.

-

We do not sell your data, and we do not share it with third parties for -their own purposes.

+

Public authorities, where the law requires it. If we are +legally obliged to disclose personal data, for example by a court order or a +binding request from a competent authority, we disclose the minimum +required.

+ +

We do not sell personal data or disclose it for advertising. We disclose +it only to the recipients described above, as necessary to perform your +requests, secure the Service, or comply with law.

3. International Transfers

@@ -349,14 +356,23 @@

3. International Transfers

Swiss Federal Council as providing adequate data protection, so no additional transfer safeguard is required for this hosting. Amazon Web Services may have limited remote access from other countries for support and operations; that -access is governed by its data-processing terms, which incorporate the -recognised safeguards for such transfers.

- -

Separately, and by design, the Internet Computer is a global public -network: its nodes are operated by independent providers in many countries, so -requests you submit and anything you write to an application are processed -internationally and outside our control. That is inherent to using a public -network rather than a transfer we arrange.

+access is governed by the AWS Data Processing Addendum, which incorporates +the EU Standard Contractual Clauses, as extended to Swiss transfers in line +with the FDPIC's guidance, for any processing from a country without an +adequate level of data protection.

+ +

Separately, the Internet Computer is a global public network: its nodes +are operated by independent providers in many countries, whose locations are +set by the network's governance, not by us, and can include countries that +Switzerland and the EEA do not recognise as providing adequate data +protection. When you direct the Service to read from or act on an +application, the Service submits that request to the network deliberately, +on your instruction, and the network processes it internationally to execute +what you asked. What travels is the content of your request and its results +(section 1) under the pseudonymous per-application identifiers described in +section 6. This processing is inherent to the network's design and applies +to every request, so take it into account when deciding which applications +to direct the Service at.

4. Data Retention

From fcda58f5eab3072b60a849fd70065c43136af338 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 5 Aug 2026 16:01:55 +0000 Subject: [PATCH 2/3] Transfers: distinguish authenticated requests from anonymous public reads The transfer paragraph said every request travels under a pseudonymous per-application identifier, but public reads made without signing in run through the shared anonymous agent and carry no user identifier (canister_query permits omitting derivation_origin). The sentence now separates the two cases. Also record both halves of issue #121 in the source doc's follow-ups note. Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01TGhwpdTbUqQbR5AiiN8Ljw --- docs/icp-mcp-privacy-policy-draft.md | 22 ++++++++++++---------- src/assets/privacy-policy.html | 9 +++++---- 2 files changed, 17 insertions(+), 14 deletions(-) diff --git a/docs/icp-mcp-privacy-policy-draft.md b/docs/icp-mcp-privacy-policy-draft.md index bfda5db..6715587 100644 --- a/docs/icp-mcp-privacy-policy-draft.md +++ b/docs/icp-mcp-privacy-policy-draft.md @@ -67,12 +67,13 @@ > OAuth client registrations instead of retention until LRU displacement. > That is a code change; the policy keeps stating the current behaviour > honestly until it ships, and the retention row must be updated when it -> does. Tracked with the other two engineering follow-ups from this -> round: purging session credentials immediately when revocation is -> observed, and a deployment-level logging audit (AWS services, load -> balancer, reverse proxy, crash diagnostics, DNS/CDN, journald, support -> access) to substantiate the policy's logging claims beyond application -> code. +> does. Tracked with the other engineering follow-ups from this round: +> purging session credentials immediately when revocation is observed and +> shortening the lifetime of already-issued per-application authorizations +> (both in issue #121), and a deployment-level logging audit (AWS +> services, load balancer, reverse proxy, crash diagnostics, DNS/CDN, +> journald, support access) to substantiate the policy's logging claims +> beyond application code. --- @@ -297,10 +298,11 @@ protection. When you direct the Service to read from or act on an application, the Service submits that request to the network deliberately, on your instruction, and the network processes it internationally to execute what you asked. What travels is the content of your request and its results -(section 1) under the pseudonymous per-application identifiers described in -section 6. This processing is inherent to the network's design and applies -to every request, so take it into account when deciding which applications -to direct the Service at. +(section 1); a request made as you travels under the pseudonymous +per-application identifier described in section 6, while a public read made +without signing in carries no user identifier at all. This processing is +inherent to the network's design and applies to every request, so take it +into account when deciding which applications to direct the Service at. ### 4. Data Retention diff --git a/src/assets/privacy-policy.html b/src/assets/privacy-policy.html index 00386e4..4f5ab17 100644 --- a/src/assets/privacy-policy.html +++ b/src/assets/privacy-policy.html @@ -369,10 +369,11 @@

3. International Transfers

application, the Service submits that request to the network deliberately, on your instruction, and the network processes it internationally to execute what you asked. What travels is the content of your request and its results -(section 1) under the pseudonymous per-application identifiers described in -section 6. This processing is inherent to the network's design and applies -to every request, so take it into account when deciding which applications -to direct the Service at.

+(section 1); a request made as you travels under the pseudonymous +per-application identifier described in section 6, while a public read made +without signing in carries no user identifier at all. This processing is +inherent to the network's design and applies to every request, so take it +into account when deciding which applications to direct the Service at.

4. Data Retention

From ab4ea49f233e9bea599733ce4a7fd6b916b30ce9 Mon Sep 17 00:00:00 2001 From: Claude Date: Wed, 5 Aug 2026 16:14:07 +0000 Subject: [PATCH 3/3] Transfers wording per review; keep only the policy in the source doc Adopt the reviewer's transfer sentence: authenticated requests carry the section-6 pseudonymous per-application identifier; unauthenticated public reads use the network's shared anonymous principal, which identifies no one. The source document now contains the synchronization notice and the policy text only. Operational and review notes are maintained outside this repository. Co-Authored-By: Claude Fable 5 Claude-Session: https://claude.ai/code/session_01TGhwpdTbUqQbR5AiiN8Ljw --- docs/icp-mcp-privacy-policy-draft.md | 117 +++------------------------ src/assets/privacy-policy.html | 11 +-- 2 files changed, 17 insertions(+), 111 deletions(-) diff --git a/docs/icp-mcp-privacy-policy-draft.md b/docs/icp-mcp-privacy-policy-draft.md index 6715587..922cc38 100644 --- a/docs/icp-mcp-privacy-policy-draft.md +++ b/docs/icp-mcp-privacy-policy-draft.md @@ -3,77 +3,11 @@ > This is the source text for the page served at > `https://mcp.internetcomputer.org/privacy-policy` > (`src/assets/privacy-policy.html`). Keep the two in sync: the served page is -> what users and the Anthropic directory review actually see. -> -> **Revised against the privacy review of 2026-07-31.** Technical claims are -> drawn from this repository's behaviour and were re-verified for that -> revision (see "Logging audit" at the foot of this file). Re-verify them -> against the deployed release whenever the policy is republished. -> -> **Open-items status (2026-07-31):** -> -> 1. **Hosting locations: resolved.** Both deployments run on AWS EC2 in -> `eu-central-1` (Frankfurt, Germany) — established by mapping the -> production and staging addresses (v4 and v6) against AWS's published -> `ip-ranges.json`. Logs live in journald on those same hosts; metrics are -> not persisted at all. Germany is an EEA state on Switzerland's adequacy -> list (FADP Art. 16(1)), so no additional transfer safeguard is needed -> for the hosting itself; the policy adds one sentence for residual -> processor access under the AWS data-processing terms. If the hosts ever -> move region, section 3 must be updated. -> 2. **Legal bases: adopted.** GDPR Art. 6(1)(b) (performance of the -> requested service) for the service categories — per EDPB Guidelines -> 2/2019 this covers processing objectively necessary to deliver what the -> user asked for, and does not require written terms — and Art. 6(1)(f) -> (legitimate interests: security per Recital 49, abuse prevention, -> service improvement) for the cookie, logs, and metrics. Under the Swiss -> FADP no per-purpose legal basis is required of private controllers; -> listing them satisfies GDPR Art. 13(1)(c) where the GDPR applies and is -> harmless otherwise. A short Terms of Use would make the 6(1)(b) footing -> more robust and is noted as a follow-up in the submission doc. -> 3. **Metrics retention: resolved.** Verified in code: gauges are computed -> on demand from in-memory session maps and the status dashboard persists -> nothing, so the policy states they are not stored. -> 4. **EU representative: handled outside this repository.** The published -> text asserts nothing either way (the FDPIC/EU-authority complaint -> sentence is accurate regardless). Update section 7 if a representative -> is named. -> -> **Revised against the legal review round of 2026-08-03.** Three wording -> corrections adopted verbatim or near-verbatim from that review: -> -> 5. **Credential custody restated.** "Never leave Internet Identity" wrongly -> implied II stores the credentials. The policy now says they are never -> sent to the Service and names where each actually lives (passkey private -> keys with the authenticator, recovery material with the user, -> linked-account credentials with their providers). -> 6. **International transfers.** Section 3's network paragraph describes the -> international processing factually: the Service submits requests -> deliberately at the user's direction, node locations are set by the -> network's governance, and it names what travels. The wording of this -> paragraph is maintained together with DFINITY legal; coordinate any -> change to it (and keep the served page and this text in sync). The AWS -> hosting sentence (Data Processing Addendum incorporating the EU -> Standard Contractual Clauses, with the Swiss extension) is confirmed -> and stands. -> 7. **Sharing sentence de-contradicted.** "We do not share it with third -> parties for their own purposes" conflicted with section 2, which -> discloses that assistants, applications, and their operators process -> data under their own policies. Replaced with: no sale, no disclosure -> for advertising, disclosure only to the section-2 recipients as -> necessary to perform requests, secure the Service, or comply with law. -> 8. **OAuth registration lifetime: engineering, tracked.** The review asks -> for a fixed inactivity lifetime (and ideally a deletion mechanism) for -> OAuth client registrations instead of retention until LRU displacement. -> That is a code change; the policy keeps stating the current behaviour -> honestly until it ships, and the retention row must be updated when it -> does. Tracked with the other engineering follow-ups from this round: -> purging session credentials immediately when revocation is observed and -> shortening the lifetime of already-issued per-application authorizations -> (both in issue #121), and a deployment-level logging audit (AWS -> services, load balancer, reverse proxy, crash diagnostics, DNS/CDN, -> journald, support access) to substantiate the policy's logging claims -> beyond application code. +> what users and directory reviews actually see. Technical claims are drawn +> from this repository's behaviour; re-verify them against the deployed +> release whenever the policy is republished (and update section 3 if the +> hosting region ever changes). Operational and review notes are maintained +> outside this repository. --- @@ -298,11 +232,12 @@ protection. When you direct the Service to read from or act on an application, the Service submits that request to the network deliberately, on your instruction, and the network processes it internationally to execute what you asked. What travels is the content of your request and its results -(section 1); a request made as you travels under the pseudonymous -per-application identifier described in section 6, while a public read made -without signing in carries no user identifier at all. This processing is -inherent to the network's design and applies to every request, so take it -into account when deciding which applications to direct the Service at. +(section 1). Authenticated requests also carry the pseudonymous +per-application identifier described in section 6; unauthenticated public +reads use the Internet Computer's shared anonymous principal, which +identifies no one. This processing is inherent to the network's design and +applies to every request, so take it into account when deciding which +applications to direct the Service at. ### 4. Data Retention @@ -409,33 +344,3 @@ to data already collected. For questions about this Privacy Policy or the Service, or to exercise any of the rights in section 7, email . - ---- - -## Logging audit (2026-07-31) - -Section 5 rests on this; redo it whenever the policy is republished. - -- Application logging lives in three files only: `src/main.rs`, - `src/auth.rs`, `src/identities.rs`. `calls.rs`, `discover.rs`, `tools.rs`, - `management.rs`, and `skills.rs` contain **zero** `tracing::` calls, which - is what makes the "no canister ids, arguments, or results in logs" claim - safe. A grep for `tracing::` lines mentioning `derivation`, `canister`, - `args`, or `origin` returns nothing. -- Request logging (`log_request`, `src/main.rs`) records method, path, status, - and latency, and deliberately omits the query string and the body. It covers - only the MCP application: Caddy proxies `/status/*` straight to the Node - dashboard, which has no routine request log (its one log line is a sanitised - error). Caddy's own failure diagnostics can include request URIs (with query - strings), so section 5 hedges accordingly. -- Session/auth events log `session_id` and the session-key principal - (`session_principal` = `self_authenticating` over the per-connection - session key, `src/identities.rs` — ephemeral, new per connection; NOT the - stable own-origin management identity, which is never logged), plus the - access level and expirations. -- `deploy/native/Caddyfile` configures no `log` directive, so the reverse - proxy writes no access log. -- The status dashboard emits a single sanitised error line - (`monitoring/mcp-status/server.js`). -- Everything lands in journald, bounded by the `MaxFileSec=1week` + - `MaxRetentionSec=12week` drop-in that `deploy/native/deploy.sh` installs. diff --git a/src/assets/privacy-policy.html b/src/assets/privacy-policy.html index 4f5ab17..8a263b8 100644 --- a/src/assets/privacy-policy.html +++ b/src/assets/privacy-policy.html @@ -369,11 +369,12 @@

3. International Transfers

application, the Service submits that request to the network deliberately, on your instruction, and the network processes it internationally to execute what you asked. What travels is the content of your request and its results -(section 1); a request made as you travels under the pseudonymous -per-application identifier described in section 6, while a public read made -without signing in carries no user identifier at all. This processing is -inherent to the network's design and applies to every request, so take it -into account when deciding which applications to direct the Service at.

+(section 1). Authenticated requests also carry the pseudonymous +per-application identifier described in section 6; unauthenticated public +reads use the Internet Computer's shared anonymous principal, which +identifies no one. This processing is inherent to the network's design and +applies to every request, so take it into account when deciding which +applications to direct the Service at.

4. Data Retention