From 3ac23a9625420bf75f0495a65c6e2fa21f2962b4 Mon Sep 17 00:00:00 2001 From: Hector Date: Wed, 23 Sep 2026 15:25:26 +0200 Subject: [PATCH] ingest(other): netbits part 2 - data in use, cache persistence, mitigations --- ...its-ollama-cloud-privacy-prompt-caching.md | 141 +++++++++++++++++- .../inference-provider-data-retention.md | 126 +++++++++++++++- wiki/index.md | 7 +- wiki/log.md | 31 ++++ wiki/people/michael-hannecke.md | 38 +++++ 5 files changed, 336 insertions(+), 7 deletions(-) create mode 100644 wiki/people/michael-hannecke.md diff --git a/raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md b/raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md index fbed0f9..89d494b 100644 --- a/raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md +++ b/raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md @@ -106,6 +106,145 @@ Verifizierte Angaben aus dem PDF: Netbits bewertet die Lage für den eigenen Stack als „ungewöhnlich gut, aber mit einer echten Lücke" — ZDR-Zusagen stark, drittseitiges Routing über Partner der offene Punkt; die Prompt-Cache-Seitenkanäle als relevant, weil der Stack Prompt-Caching stark nutzt. Er schließt mit der offenen Frage, dass Ollamas Cache-Isolation unabhängig nicht getestet ist. +## Teil 2 (Fortsetzung des Posts, gleicher Tag) + +### Der Kernpunkt des Posts: Cache ≠ Trainingsleck, sondern Persistenz + +> Und der Punkt, um den es eigentlich geht: Ein Cache ist **kein** Trainingsdatenleck. Es ist ein *Persistenz*-Thema. Was im Cache liegt, sind **KV-Tensoren** auf fremder GPU-Hardware, für Minuten bis Stunden. Nicht der Rohtext — aber eine mathematische Repräsentation davon, örtlich gebunden an eine bestimmte Maschine in einem bestimmten Rechenzentrum. Die meisten Datenschutz-Rahmenwerke (DSGVO-Auftragsverarbeitung, CLOUD Act) haben dafür **keine Antwort**. Der Artikel, der das am besten aufarbeitet, ist [das hier](https://medium.com/@michael.hannecke/the-hidden-data-residency-problem-in-prompt-caching-f99e6207451e). + +### Was konkret rausgeht (Aussage des Posts) + +> Der komplette System-Prompt (inkl. **meiner Memory und deines User-Profils**) / der **ganze Konversationsverlauf** / jeder **Tool-Output** — also auch Dateiinhalte, Logausgaben, `state.db`-Auszüge / Fachinhalte: Erbschafts-Notizen, Cannabis-Anbau, eBay-Handel, Gesundheitsthemen / der Intim-/Rollenspiel-Teil. Das liegt alles als Klartext bei Ollama auf dem Weg. **Nicht geloggt laut ihrer Politik, aber übertragen.** + +### Optionen, die der Post nennt + +- **Ollama lokal** — `deepseek-v4.1-flash` hat offene Gewichte (MIT); bei 763B Parametern unrealistisch auf dem Ryzen, kleinere Modelle laufen. Dann geht nichts raus. +- **TEE-Inferenz** — Anbieter wie [Lyceum](https://lyceum.technology/magazine/zero-data-retention-in-llm-inference-how-to) betreiben Inferenz in vertraulichen Enklaven: „Prompts existieren nur in flüchtigem VRAM, keine Disk-Persistenz, per Architektur statt per Vertrag." +- **Auf lokale Route umschalten bei sensiblen Themen** — was [LLM-Redactor](https://arxiv.org/pdf/2604.12064.pdf) evaluiert habe. +- **Prompt-Caching für sensible Inhalte abschalten** — mehr Kosten, keine KV-Tensoren auf fremder Hardware. +- Eigene Einschränkung des Autors: Der Cache ist der Grund, warum „die 60-Call-Arbeit nur 8,7 Cent statt 4 Dollar kostet". **Echter Trade-off, kein Gratis-Vorteil.** + +### Was der Post ausdrücklich nicht behauptet + +> **Was ich nicht behaupten kann:** Dass Ollama sich an ihre Zusage hält. Ich kann ihre Politik zitieren und die Verbindung nachweisen — ich kann nicht in ihr Rechenzentrum schauen. „Transient" ist eine Behauptung, keine Audit-Tatsache. Wenn dir das wichtig ist, wäre der saubere Weg, **schriftlich** ZDR und Cache-Isolation zu verlangen — Ollama hat für Enterprise-Kunden Verträge, in denen das stehen kann. + +### Quellenangaben des Posts (Teil 2) + +Bereits oben verifizierte Links, plus neu: +- [Hannecke — The Hidden Data Residency Problem in Prompt Caching](https://medium.com/@michael.hannecke/the-hidden-data-residency-problem-in-prompt-caching-f99e6207451e) (Medium) +- [Lyceum — Zero Data Retention in LLM Inference: How to Verify It](https://lyceum.technology/magazine/zero-data-retention-in-llm-inference-how-to) +- [LLM-Redactor — An Empirical Evaluation of Eight Techniques for Privacy-Preserving LLM Requests](https://arxiv.org/pdf/2604.12064.pdf) +- [StealthCloud — LLM Provider Privacy Scoreboard](https://stealthcloud.ai/data/llm-provider-privacy-scoreboard) +- [TheRouter — LLM API Privacy & Data Retention Cross-Provider Reference](https://therouter.ai/blog/llm-api-privacy-data-retention-cross-provider-reference) +- [DeepSeek Privacy Policy](https://cdn.deepseek.com/policies/en-US/deepseek-privacy-policy.html) + +**Fehlerhafter Link im Post:** PROMPTPEEK (NDSS 2025) wird auf den **Medium-Artikel von Hannecke** verlinkt, nicht auf das Paper. Der korrekte Verweis ist die NDSS-Paper-Seite bzw. das PDF (siehe Teil 1 oben); Hannecke ist ein Sekundärartikel, der PROMPTPEEK referiert. + +## Verifikation Teil 2 (Abruf 2026-09-23) + +### Hannecke, „The Hidden Data Residency Problem in Prompt Caching" + +Abgerufen via web_fetch (Medium, 200, 18.815 Zeichen; Extract 5.812 Zeichen + Spill-Datei). Autor: **Michael Hannecke** (Medium-Serie zu Prompt-Caching), Datum **11.02.2026**, 12 min read. Titel und Substanz bestätigen die Empfehlung des Posts vollständig. + +Verifizierte Kernaussagen aus dem Artikel: + +- **Kernthese:** „Prompt caching stores your data as KV tensors on provider GPU infrastructure — most governance frameworks ignore this ‚data in use' gap." +- **Konkretisierung:** KV-Tensoren seien „a materialization of your prompt content on provider infrastructure. They are not the raw text. But they encode the semantic content of your input. They sit in VRAM on specific GPU nodes in specific datacenters." Bei **Google Gemini** (konfigurierbare TTLs) persistieren gecachte Tensoren auf **GPU-lokalen SSDs bis zu 24 Stunden**. +- **TTL-Fragen:** Default-Cache-Lebensdauern „5 minutes to 24 hours". Offen: ob Speicher bei TTL-Ablauf sofort genullt oder lazy überschrieben wird; ob Cache-Erzeugung/-Eviction geloggt wird. +- **GDPR Art. 17:** Kein großer Anbieter biete (Stand Anfang 2026) eine **Cache-Eviction-API für einzelne Einträge**. +- **GDPR Art. 6:** Offene Rechtsfrage, ob globales Cache-Sharing die Verarbeitung fremder Daten darstellt — „an open legal question that no provider has addressed publicly". +- **CLOUD Act:** „Whether a 5-minute ephemeral KV tensor on a GPU node in Frankfurt qualifies as data in a provider's ‚possession, custody, or control' … is untested in court. But the conservative interpretation … is that it does." Ein Anbieter, der technisch auf den Tensor zugreifen kann, kontrolliere ihn im Sinne des Gesetzes. +- **DPAs:** Basierend auf einer Durchsicht öffentlicher DPAs großer Anbieter „most do not mention KV-cache residency" — eingeordnet als **Aufsichtsversäumnis, nicht Bosheit**. +- **Anbieter-Zahlen:** Bestätigt die 7-von-8-Zahl aus Gu et al.; ergänzt, dass OpenAI **per-Organisation** isoliere (für GPT-4o mini validiert), aber „the same study detected global cache sharing patterns across other OpenAI API endpoints" — **modellabhängig, nicht pauschal sicher**. Anthropic isoliert zwischen Organisationen, DeepSeek per-user. +- **Tiered Approach:** öffentliche Daten → Provider-Caching; interne Daten → per-Org-Isolation; regulierte Daten → self-hosted Inference. +- **Entscheidungsfragen (vier):** PII/DSGVO/NIS2/EU-AI-Act-Betroffenheit; verifizierbare per-Tenant-Isolation; EU-Rechenzentrum mit vertraglicher Data Residency; KV-Cache im DPA abgedeckt. „If any answer is ‚no' for Tier 2 or Tier 3 data, escalate to the next tier." +- **Architektur-Empfehlungen:** AI-Gateway als **cache-aware policy enforcement point** (PII vor caching-fähigen Endpunkten strippen, sensitive Workloads automatisch self-hosted routen); Cache-Metriken (`cache_read_input_tokens`, `cache_creation_input_tokens`) als **Security-Signal**, nicht nur Billing-Signal — anomalie Cache-Hits seien untersuchungswürdig; Zero-Trust-Egress müsse zwischen cache-isolierten und cache-geteilten Endpunkten unterscheiden. +- **Self-Hosting relativiert:** „vLLM and SGLang both implement KV-cache sharing by default. This includes SGLang — the same framework exploited in the PROMPTPEEK study." Beide unterstützen per-User-/per-Session-Isolation **bei expliziter Konfiguration**; vLLM habe einen `cache_salt`-Parameter (**RFC #16016**). Fazit des Autors: „self-hosting does not eliminate KV-cache risk. It shifts control. … You still need to configure isolation, monitor cache behavior, and enforce eviction policies." +- **TEE als offene Frage:** NVIDIA H100/H200 unterstützen Confidential Computing; „In theory, this addresses the KV-cache residency problem directly." **Aber:** „In practice, this is still emerging. Few inference frameworks fully support TEE-based KV-cache isolation today. Performance overhead remains significant. And the question of whether KV tensors stay inside the enclave boundary during cache operations — or get offloaded to unprotected memory for performance — is an open implementation detail." Empfehlung: „verify the implementation before trusting the marketing." +- **Vendor-Fragen (fünf):** Sharing-Scope der Organisation; physischer Speicherort der KV-Tensoren während der TTL; Abdeckung durch Data-Residency-Vereinbarung; Opt-out pro Aufruf; wie Eviction verifiziert und auditierbar ist. +- **Erfahrungsbericht:** Bei einer Anbieter-Evaluierung mit einem großen EU-Region-Anbieter kam auf Frage 3 nur ein Verweis auf allgemeine Data-Residency-Bedingungen — „No mention of inference-time data. No mention of KV-cache. … That gap is the norm, not the exception." +- **Regulatorik-Zahlen (DLA Piper, Januar 2026):** DSGVO-Bußgelder 2025 ≈ **1,2 Mrd. EUR** (etwa Niveau 2024); Datenschutzverletzungs-Meldungen **+22 %** YoY auf durchschnittlich **443/Tag**; kumulierte Bußgelder seit 2018 ≈ **7,1 Mrd. EUR**. +- **Prognose:** „at least five providers have already changed course after external auditing exposed the risks" — deckt sich mit Gu et al. + +⚠️ **Korrektur zum Post:** Der Post beschreibt „TEE-Inferenz — Prompts existieren nur in flüchtigem VRAM, keine Disk-Persistenz, **per Architektur statt per Vertrag**" und belegt das mit dem **Lyceum**-Artikel. Hannecke — die vom Post selbst als beste Aufarbeitung bezeichnete Quelle — bewertet TEE ausdrücklich als **noch nicht belastbar** (wenige Frameworks, erheblicher Overhead, offene Frage, ob Tensoren die Enklave verlassen). Die Formulierung „per Architektur" ist damit optimistischer als die zitierte Quelle. Zudem vermischt der Post zwei Dinge: Lyceum beschreibt **flüchtiges VRAM + LRU-Eviction** (siehe unten) — das ist *kein* TEE. + +### Lyceum, „Zero Data Retention in LLM Inference: How to Verify It" + +Abgerufen via web_fetch (200, 12.616 Zeichen). **Wichtig: Firmen-Magazin eines Anbieters**, und der Artikel trägt selbst den Hinweis **„AI This article was created with the help of AI."** Er ist damit Marketing-Material zur eigenen Plattform, kein unabhängiger Beleg. + +Inhaltlich beschreibt der Artikel **nicht** TEE-Enklaven, sondern: + +- Die Unterscheidung **Standard API Policy / No-Training Policy / Zero Data Retention**: „A common misconception in enterprise procurement is conflating a ‚no training on customer data' clause with zero data retention." Die No-Training-Klausel regle nur Trainingspipelines, **nicht** Disk-Persistenz — Payloads könnten weiterhin in relationalen Datenbanken, Logging-Buckets und operationalen Caches landen. +- **Lyceums eigene Architektur:** „On Lyceum's platform these cached KV tensors are held in volatile GPU RAM for a few minutes at most and are scoped to the active session." LRU-Eviction, Block-ID und Hash werden entfernt, Speicher geht an die nächste Anfrage. „The tensors are never serialized to local NVMe drives, object storage buckets, or external databases." +- **vLLM/Prefix-Caching-Mechanik:** Blöcke fester Token-Größe, kryptographischer Hash (z. B. SHA-256) über Block und Vorgänger-Tokens, Tensoren in einem volatilen Block-Pool. +- **Jurisdiktion:** In-Memory-Ausführung in EU-Jurisdiktion als Souveränitätsargument gegen ausländische Herausgabebefehle. + +**Bewertung:** Die technische Unterscheidung (No-Training ≠ ZDR) ist korrekt und deckt sich mit Hannecke. Die Bezifferung der eigenen Plattform („a few minutes at most", „never serialized to disk") ist eine **Herstellerangabe über das eigene Produkt** — nicht verifizierbar, von einem KI-generierten Firmenartikel. Sie gehört ins Wiki nur mit dieser Kennzeichnung. Und: Der Artikel belegt **keine** TEE-Nutzung. + +### LLM-Redactor — arXiv:2604.12064 + +Abstract via web_fetch (200) verifiziert. Titel: **„An Empirical Evaluation of Eight Techniques for Privacy-Preserving LLM Requests"**. Autor laut Submission: **Justice Owusu Agyemang**, v1 eingereicht **13.04.2026**, Kategorie cs.CR (**Preprint**, kein Peer-Review-Status). Code/Benchmarks: [github.com/jayluxferro/llm-redactor](https://github.com/jayluxferro/llm-redactor). + +Verifizierte Angaben: + +- **Acht evaluierte Techniken:** (A) local-only inference, (B) redaction mit Placeholder-Restoration, (C) semantic rephrasing, (D) TEE-hosted inference, (E) split inference, (F) fully homomorphic encryption, (G) secret sharing via MPC, (H) differential-privacy noise. +- Implementiert in einem Open-Source-Shim, **kompatibel mit MCP und jeder OpenAI-kompatiblen API**. +- Empirisch evaluiert wurden die vier praktikablen Optionen (A, B, C, H) und Kombinationen, über vier Workload-Klassen, auf einem **Ground-Truth-Benchmark mit 1.300 Samples und 4.014 Annotationen**. +- **Kernergebnis:** „no single technique dominates: the combination **A+B+C** (route locally when possible, redact and rephrase the rest) achieves **0.6 % combined leak on PII and 31.3 % on proprietary code**, with **zero exact leaks on PII across 500 samples**." +- Entscheidungsregel aus Threat-Model-Budget und Workload-Charakterisierung. + +⚠️ **Präzisierung zum Post:** Der Post nennt LLM-Redactor als Beleg für „auf lokale Route umschalten bei sensiblen Themen". Das ist korrekt, aber unvollständig: Die Technik ist nur in **Kombination** stark (A+B+C); die Redaktions-/Rephrase-Komponente allein lässt Proprietary-Code-Leaks von **31,3 %** übrig. Die Zahl fehlte im Post und ist die eigentlich handlungsleitende. + +### StealthCloud — LLM Provider Privacy Scoreboard + +Abgerufen via web_fetch (200, 16.305 Zeichen; Autor **Donovan Vanderbilt**, zuletzt aktualisiert **18.05.2026**, „Reviewed and source-checked"). 12 Dimensionen, Skala 0–10, Basis: öffentliche Dokumentation, Stand März 2026. + +Verifiziert: + +- **Kernbefund:** „No major LLM provider scores above **72 %** on a comprehensive privacy assessment." Beste Werte: **Anthropic 72 %**, **Mistral 71 %**, **Cohere 70 %**; OpenAI API **58 %**; Google Gemini API **57 %**; Azure OpenAI **64 %**. Consumer-Tiers deutlich schwächer (ChatGPT Free 47 %, Google Gemini Consumer 43 %). Abstand bester/schlechtester **31 Prozentpunkte**. +- **Retention-Tabelle (API):** Anthropic „30 days (safety), then deleted"; Mistral „30 days (La Plateforme)"; OpenAI „30 days (default, configurable to 0)"; Google „Up to 18 months (Gemini API)"; Amazon Bedrock „0 days (not stored)"; Azure OpenAI „0-30 days (configurable)". +- **Training:** Anthropic/Mistral/Cohere/Amazon Bedrock/Azure OpenAI „No"; OpenAI „No (API ToS)" aber „Yes (free tier default)"; Google „No (paid API)" aber „Yes (consumer Gemini)". +- **Wichtig für unseren Fall:** **Ollama kommt im Scoreboard nicht vor.** + +⚠️ **Widerspruch in den Vergleichszahlen (nicht auflösbar):** Der Post nennt „Anthropic (7 Tage)"; therouter.ai nennt ebenfalls **7 Tage**; **StealthCloud nennt 30 Tage (Safety), dann gelöscht**. Für OpenAI (30 Tage) und Google (bis 18 Monate) decken sich die Quellen. Die Anthropic-Angabe ist damit **quellenabhängig** — im Wiki als Widerspruch geführt, nicht als Fakt. + +### TheRouter — LLM API Privacy & Data Retention Reference + +Abgerufen via web_fetch (200, 11.962 Zeichen; eigener Anbieter-Blog, Stand **August 2026**). Schnellreferenz über „die fünf Anbieter, durch die wir den meisten Traffic routen": + +| Anbieter | Default API Retention | Training auf API-Daten | ZDR verfügbar | +|---|---|---|---| +| OpenAI | 30 Tage | Nein | Ja (Org-Level opt-in) | +| Anthropic | **7 Tage** | Nein | Ja (Enterprise-Vertrag) | +| Google (Gemini API) | je nach Plan | Nein (bezahlte Pläne) | Ja (bezahlte Pläne) | +| DeepSeek | **nicht veröffentlicht** | nicht ausdrücklich zugesichert | Nein | +| DashScope (Alibaba) | **nicht veröffentlicht** | Nein (ausdrückliche Zusage) | nicht dokumentiert | + +Zusätzlich verifiziert: OpenAI forciert unter ZDR den `store`-Parameter auf `false`, auch wenn Code `true` setzt; ZDR deckt `/v1/chat/completions` und weitere Endpunkte ab. + +**Wichtig für unseren Fall:** Auch hier **kein Ollama**. Und: Für DeepSeek existiert **kein veröffentlichter Retention-Zeitraum**, nur die Zusage, nicht auf API-Daten zu trainieren. + +### vLLM RFC #16016 — Cache Salting + +Auf GitHub geprüft (200, spill 7.608 Zeichen). Titel: **„[RFC]: Cache Salting for Secure and Flexible Prefix Caching in vLLM"**. Bestätigt die Angabe aus dem Hannecke-Artikel und ergänzt eine Mitigation, die im Post fehlt: + +- Motivation zitiert ausdrücklich **arXiv:2411.18191** („Leaking Secrets from Prefix Caches") und benennt Timing-Seitenkanäle als bekannte Schwäche: „An attacker can infer cache reuse by guessing popular inputs and measuring latency — potentially compromising privacy especially in shared or multi-tenant environments." +- Vorschlag: **Salt der Block-Hashes** über ein optionales Top-Level-Feld pro Request. Durch Teilen des Salts lässt sich Prefix-Caching nutzen, **ohne** den Prompt für Fremde cachebar zu machen. +- Zwei Designs (Single-Barrier: ein Salt pro Request; sowie ein Mehr-Barrier-Design). +- Nebenbefund zur Einordnung: Das RFC nennt OpenAI als Beispiel für eingeschränktes Cache-Sharing („limiting cache sharing to organizations"). + +**Damit liegt eine praktikable, quelloffene Mitigation vor, die der Post nicht erwähnt:** `cache_salt` bzw. per-User-/per-Session-Isolation in vLLM/SGLang. Sie adressiert den Seitenkanal direkt, ohne Caching ganz abzuschalten. + +### Zusätzliche, im Post nicht genannte Primärquelle + +- [arXiv:2411.18191](https://arxiv.org/html/2411.18191v1) — „Leaking Secrets from Prefix Caches" (von vLLM selbst als Motivation zitiert). Verwandte Arbeit zum selben Angriffsvektor, nicht identisch mit Gu et al. oder PROMPTPEEK. + ## Nachtrag (Hector, gleicher Tag) -Zwei Korrekturen des Posts sind oben dokumentiert (IP-Zuordnung → Vercel; Issue #14279 = offene Frage, nicht Befund). Die Paper-Zitate und die Policy-Zitate des Posts sind vollständig verifiziert. Interpretation und Konsequenzen für den Stack liegen auf der Wiki-Seite `wiki/concepts/policy/inference-provider-data-retention.md`. +Der strukturell wichtige Punkt des Posts (KV-Tensoren als **Persistenz-**, nicht Trainingsproblem) ist durch die zitierte Quelle Hannecke vollständig gedeckt und war der Anlass für den Data-in-use-Abschnitt der Wiki-Seite. + +**Korrekturen (Teil 1):** IP-Zuordnung → Vercel, nicht Amazon; Issue #14279 = unbeantwortete Rückfrage, nicht Befund; PROMPTPEEK-Zuordnung → SUSTech/ByteDance, nicht Stanford. + +**Korrekturen (Teil 2):** (1) PROMPTPEEK-Link zeigt auf den Hannecke-Artikel statt auf das Paper. (2) Die TEE-Darstellung ist optimistischer als die vom Post selbst zitierte Quelle Hannecke, die TEE als noch nicht belastbar einordnet; zudem vermischt der Post Lyceums **flüchtiges VRAM** mit TEE-Enklaven. (3) Der Lyceum-Artikel ist **KI-generiertes Anbietermarketing** über das eigene Produkt und belegt keine TEE-Nutzung. (4) Bei LLM-Redactor fehlt die entscheidende Zahl (31,3 % Rest-Leak bei Proprietary Code ohne lokale Route). (5) Die Provider-Retention-Zahlen widersprechen sich zwischen StealthCloud (Anthropic 30 Tage) und TheRouter (7 Tage). (6) Ollama kommt in **keinem** der drei Vergleichsquellen vor — was den Befund „unabhängig ungeprüft" stützt. + +Interpretation und Konsequenzen für den Stack liegen auf der Wiki-Seite `wiki/concepts/policy/inference-provider-data-retention.md`. diff --git a/wiki/concepts/policy/inference-provider-data-retention.md b/wiki/concepts/policy/inference-provider-data-retention.md index 754886c..d3710ce 100644 --- a/wiki/concepts/policy/inference-provider-data-retention.md +++ b/wiki/concepts/policy/inference-provider-data-retention.md @@ -2,12 +2,12 @@ created: 2026-09-23 updated: 2026-09-23 sources: [other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md] -tags: [concept, policy, privacy, data-retention, zdr, cloud-inference, ollama, prompt-caching, kv-cache, side-channel, deepseek, third-party-routing] +tags: [concept, policy, privacy, data-retention, zdr, cloud-inference, ollama, prompt-caching, kv-cache, side-channel, deepseek, third-party-routing, data-in-use, gdpr, cloud-act, tee, confidential-computing, vllm, dpa] --- # Datenhaltung & Cache-Seitenkanäle bei Cloud-Inferenz -> **Kern:** Netbits (@NetLightning) recherchierte im OME-Topic „Openclaw mit lokalen Modellen" (23.09.2026) die Datenhaltung bei Cloud-Inferenz — Anlass war unser Tier-0-Modell `deepseek-v4.1-flash` auf Ollama Cloud. Ergebnis: Ollamas Zusagen sind ungewöhnlich stark, aber **vertraglich, nicht technisch** — Ollama verlangt Zero Data Retention von Partnern und weist selbst „model inference providers" als Dritte aus. Zweiter Befund: Prompt-Caching ist ein dokumentierter **Timing-Seitenkanal** — zwei peer-reviewte Arbeiten zeigen Cache-Sharing über Nutzergrenzen hinweg bei mehreren kommerziellen APIs. Prompt- und Policy-Zitate des Posts wurden vollständig verifiziert; **zwei Angaben des Posts sind falsch** (siehe Korrekturen unten). +> **Kern:** Netbits (@NetLightning) recherchierte im OME-Topic „Openclaw mit lokalen Modellen" (23.09.2026) die Datenhaltung bei Cloud-Inferenz — Anlass war unser Tier-0-Modell `deepseek-v4.1-flash` auf Ollama Cloud. Ergebnis: Ollamas Zusagen sind ungewöhnlich stark, aber **vertraglich, nicht technisch** — Ollama verlangt Zero Data Retention von Partnern und weist selbst „model inference providers" als Dritte aus. Zweiter Befund: Prompt-Caching ist ein dokumentierter **Timing-Seitenkanal** — zwei peer-reviewte Arbeiten zeigen Cache-Sharing über Nutzergrenzen hinweg bei mehreren kommerziellen APIs. Der dritte und wichtigste Punkt: Ein Cache ist **kein Trainingsleck, sondern ein Persistenz-Problem** — KV-Tensoren liegen als „data in use" auf fremder GPU-Hardware, und dafür haben weder DSGVO-Auftragsverarbeitung noch CLOUD Act eine Antwort. Prompt- und Policy-Zitate des Posts wurden vollständig verifiziert; **mehrere Angaben des Posts sind falsch oder zu stark** (siehe Korrekturen unten). ## Was Ollama zusagt (verifiziert am 2026-09-23) @@ -73,6 +73,113 @@ Prompt-Caching ist bei uns keine Randerscheinung, sondern Kern der Kostenstrateg ⚠️ **Korrektur zum Post:** Der Post attribuiert die Arbeit an einer Stelle der „Stanford-Studie". PROMPTPEEK stammt von **SUSTech/ByteDance**; die Stanford-Arbeit ist das ICML-Paper von Gu et al. Beide im Post getrennt genannt, in der Zuordnung aber vermischt. +## Data in use: der Persistenz-Blickwinkel + +Netbits' zweiter Teil schärft die Frage an der entscheidenden Stelle — und das ist der konzeptionell wichtigste Beitrag der ganzen Recherche: + +> Ein Cache ist **kein** Trainingsdatenleck. Es ist ein *Persistenz*-Thema. Was im Cache liegt, sind **KV-Tensoren** auf fremder GPU-Hardware, für Minuten bis Stunden. Nicht der Rohtext — aber eine mathematische Repräsentation davon, örtlich gebunden an eine bestimmte Maschine in einem bestimmten Rechenzentrum. + +Das ist die richtige Trennung. „Wir trainieren nicht auf deinen Daten" und „wir speichern nichts" sind **zwei verschiedene Zusagen** — und die erste sagt nichts über die zweite. Genau hier setzt die von Netbits empfohlene Aufarbeitung an. + +### Die Aufarbeitung: Hannecke, „The Hidden Data Residency Problem in Prompt Caching" + +Michael Hannecke, Medium, **11.02.2026** ([Artikel](https://medium.com/@michael.hannecke/the-hidden-data-residency-problem-in-prompt-caching-f99e6207451e)). Volltext geprüft (18.815 Zeichen). Die Empfehlung des Posts ist berechtigt — der Artikel ist die präziseste Aufarbeitung der „data in use"-Lücke, die im Wiki vorliegt. + +Kernaussagen, verifiziert: + +- **Die Lücke:** „Most AI governance frameworks cover data at rest and in transit. Almost none address what happens to your data during inference." +- **Was KV-Tensoren sind:** „a materialization of your prompt content on provider infrastructure. They are not the raw text. But they encode the semantic content of your input. They sit in VRAM on specific GPU nodes in specific datacenters." +- **TTL-Realität:** Default-Cache-Lebensdauern **5 Minuten bis 24 Stunden**. Bei **Google Gemini** (konfigurierbare TTLs) persistent gecachte Tensoren auf **GPU-lokalen SSDs bis zu 24 Stunden** — also nicht nur VRAM. +- **Ungeklärte Details:** Wird Speicher bei TTL-Ablauf sofort genullt oder lazy überschrieben? Wird Cache-Erzeugung/-Eviction geloggt? „Most documentation is silent on this." + +### Warum die Rechtssysteme keine Antwort haben + +Drei konkrete Lücken, die Hannecke benennt: + +| Rahmenwerk / Frage | Stand | +|---|---| +| **DSGVO Art. 17** (Recht auf Löschung) | Kein großer Anbieter bietet (Stand Anfang 2026) eine **Cache-Eviction-API für einzelne Einträge**. Ein Betroffenenantrag lässt sich damit nicht sauber bedienen. | +| **DSGVO Art. 6** (Rechtsgrundlage) | Offene Rechtsfrage: Wenn Anbieter X den Prompt von Nutzer A cacht und Nutzer B einen Cache-Hit auslöst — hat X dann A's Daten „für B" verarbeitet? „This is an open legal question that no provider has addressed publicly." | +| **US CLOUD Act** | Ob ein 5-Minuten-KV-Tensor auf einer GPU in Frankfurt unter „possession, custody, or control" fällt, ist **gerichtlich ungeklärt**. Die konservative Lesart — und die, zu der Juristen greifen — ist **ja**: Wer technisch zugreifen kann, kontrolliert im Sinne des Gesetzes. | + +**DPA-Realität:** „Based on a review of publicly available DPAs from major providers, **most do not mention KV-cache residency**. This is not necessarily malicious. It is an oversight born from the fact that prompt caching became standard faster than legal frameworks could adapt." + +Der Erfahrungsbericht aus dem Artikel: Bei einer Anbieter-Evaluierung mit einem großen EU-Region-Anbieter kam auf die Frage nach der Cache-Residency nur ein Verweis auf allgemeine Data-Residency-Bedingungen — „No mention of inference-time data. No mention of KV-cache. … **That gap is the norm, not the exception.**" + +### Der Datenumfang, der tatsächlich rausgeht + +Netbits listet für unseren Fall auf, was bei jedem Turn mitgeht: der komplette System-Prompt (inkl. Memory und User-Profil), der ganze Konversationsverlauf, **jeder Tool-Output** (Dateiinhalte, Logausgaben), Fachinhalte und der Intim-/Rollenspiel-Teil. „Das liegt alles als Klartext bei Ollama auf dem Weg. **Nicht geloggt laut ihrer Politik, aber übertragen.**" Das ist keine neue Enthüllung, sondern die korrekte Beschreibung dessen, was Cloud-Inferenz bedeutet — und der Grund, warum die Persistenzfrage überhaupt relevant ist. + +## Mitigationen — was tatsächlich hilft + +Die Recherche ergibt vier Wege, in absteigender Härte: + +### 1. Cache-Isolation konfigurieren (der praktikabelste Hebel) + +Der Befund, der im Ausgangspost **fehlt**: Für das Kernproblem existiert eine **quelloffene, direkte Mitigation**. + +- **vLLM RFC [#16016](https://github.com/vllm-project/vllm/issues/16016)** — „Cache Salting for Secure and Flexible Prefix Caching". Ein optionales Salt pro Request wird in den Block-Hash gemischt. Wer den Salt teilt, kann Prefix-Caching nutzen, **ohne** den Prompt für Fremde cachebar zu machen — Caching bleibt also aktiv, die Cross-User-Wiederverwendung entfällt. +- Das RFC zitiert als Motivation ausdrücklich [arXiv:2411.18191](https://arxiv.org/html/2411.18191v1) („Leaking Secrets from Prefix Caches") und benennt Timing-Seitenkanäle als bekannte Schwäche: „An attacker can infer cache reuse by guessing popular inputs and measuring latency — potentially compromising privacy especially in shared or multi-tenant environments." +- **vLLM und SGLang teilen KV-Caches per Default**; beide unterstützen per-User-/per-Session-Isolation **bei expliziter Konfiguration**. + +⚠️ **Selbst-Hosting ist keine automatische Lösung.** Hannecke bringt es präzise: „self-hosting does not eliminate KV-cache risk. **It shifts control.** You still need to configure isolation, monitor cache behavior, and enforce eviction policies. … The risk is the same. The accountability moves to your team." Wer SGLang mit Defaults betreibt, hat exakt das Setup, das PROMPTPEEK ausnutzt. + +### 2. Cache-Metriken als Security-Signal lesen + +`cache_read_input_tokens` und `cache_creation_input_tokens` sind nicht nur Billing-Werte. Ein **unerwartetes** Hit-Muster — Treffer auf Präfixe, die man selbst nicht kürzlich gesendet hat — ist ein Untersuchungsanlass. Damit wird Cache-Monitoring zum Detektionsmittel, nicht nur zur Kostenanzeige. + +### 3. PII-Redaktion vor dem Cloud-Aufruf + +**LLM-Redactor** (arXiv:[2604.12064](https://arxiv.org/abs/2604.12064)) — „An Empirical Evaluation of Eight Techniques for Privacy-Preserving LLM Requests", Justice Owusu Agyemang, v1 13.04.2026, cs.CR (**Preprint, nicht peer-reviewed**). Open-Source-Shim, kompatibel mit MCP und jeder OpenAI-kompatiblen API. + +Acht Techniken evaluiert: local-only inference, Redaktion mit Placeholder-Restoration, semantic rephrasing, TEE-Inferenz, split inference, FHE, MPC-Secret-Sharing, DP-Rauschen — praktisch getestet wurden A/B/C/H über vier Workload-Klassen auf einem Benchmark mit **1.300 Samples / 4.014 Annotationen**. + +**Die handlungsleitende Zahl** (im Post nicht genannt): Die Kombination **A+B+C** (lokal routen wo möglich, Rest redigieren und umformulieren) erreicht **0,6 % kombinierter Leak bei PII** und **31,3 % bei Proprietary Code**, bei **null exakten PII-Leaks über 500 Samples**. Heißt: Die lokale Route ist der starke Teil der Kombination — Redaktion/Rephrase allein lassen ein Drittel des Codes durch. + +⚠️ Preprint, ein Autor, kein Peer-Review. Die Richtung ist plausibel und deckt sich mit Hanneckes Tiered Approach, die Zahlen sind aber nicht unabhängig bestätigt. + +### 4. TEE / Confidential Computing (noch nicht belastbar) + +NVIDIA H100/H200 unterstützen Confidential Computing über TEEs. **In der Theorie** die direkte Antwort: Tensoren liegen in verschlüsseltem GPU-Speicher, den selbst der Infrastrukturanbieter nicht lesen kann — womit das CLOUD-Act-Argument technisch entfällt. Praktisch: + +> „In practice, this is still emerging. Few inference frameworks fully support TEE-based KV-cache isolation today. Performance overhead remains significant. And the question of whether KV tensors stay inside the enclave boundary during cache operations — or get offloaded to unprotected memory for performance — is an open implementation detail that varies by framework." + +Hannecke empfiehlt ausdrücklich: „**verify the implementation before trusting the marketing.**" + +⚠️ **Korrektur zum Post:** Netbits stellt TEE als „per Architektur statt per Vertrag" dar und belegt das mit dem Lyceum-Artikel. Das ist zu stark — die vom Post selbst als beste Quelle bezeichnete Aufarbeitung (Hannecke) bewertet TEE als **noch nicht belastbar**. Zudem vermischt der Post zwei verschiedene Dinge: Lyceum beschreibt **flüchtiges VRAM mit LRU-Eviction**, das ist **kein TEE**. + +### Lyceum — Herstellerangabe, kein TEE-Beleg + +Der [Artikel](https://lyceum.technology/magazine/zero-data-retention-in-llm-inference-how-to) (Abruf 200, 12.616 Zeichen) trägt selbst den Hinweis **„AI This article was created with the help of AI"** und stammt aus dem Firmen-Magazin eines Anbieters — Marketing über das eigene Produkt. + +Fachlich korrekt und nützlich ist die **Trennung der Policy-Typen**: Standard API Policy (bis 30 Tage Disk) / No-Training Policy (Training ausgeschlossen, Payloads aber weiter in DBs und Log-Buckets) / Zero Data Retention (nur volatiles GPU-RAM während der Generierung). Der Merksatz: „A common misconception in enterprise procurement is conflating a ‚no training on customer data' clause with zero data retention." + +Zur **eigenen** Plattform behauptet der Artikel: Tensoren „held in volatile GPU RAM for a few minutes at most and are scoped to the active session", LRU-Eviction, „never serialized to local NVMe drives, object storage buckets, or external databases". ⚠️ Das ist eine **nicht verifizierbare Herstellerangabe aus einem KI-generierten Werbetext** — im Wiki nur mit dieser Kennzeichnung geführt. + +## Anbieter-Vergleich (Sekundärquellen — mit Widerspruch) + +Zwei Vergleichsquellen, beide von **Anbietern** (StealthCloud bzw. TheRouter), beide **ohne Ollama**. Damit stützt sich der Befund „Ollamas Cache-Isolation ist unabhängig ungeprüft" auf drei unabhängige Quellen, die Ollama schlicht nicht erwähnen. + +**StealthCloud — LLM Provider Privacy Scoreboard** (Donovan Vanderbilt, aktualisiert 18.05.2026; 12 Dimensionen, Basis öffentliche Dokumentation Stand März 2026): + +- „No major LLM provider scores above **72 %**." Beste: Anthropic 72 %, Mistral 71 %, Cohere 70 %. OpenAI API **58 %**, Google Gemini API **57 %**, Azure OpenAI **64 %**. Consumer-Tiers deutlich schwächer (ChatGPT Free 47 %, Gemini Consumer 43 %). +- **Retention (API):** Anthropic „30 days (safety), then deleted"; Mistral 30 Tage; OpenAI „30 days (default, configurable to 0)"; Google „Up to 18 months"; Amazon Bedrock „0 days (not stored)"; Azure OpenAI „0-30 days (configurable)". +- Struktureller Befund: „The business model predicts the privacy posture more reliably than any stated commitment." Consumer-Advertising-Modelle (Google, Meta) haben die schwächsten Defaults, Enterprise-API-Anbieter die stärksten. + +**TheRouter — Cross-Provider Reference** (Anbieter-Blog, Stand August 2026): + +| Anbieter | Default API Retention | Training auf API-Daten | ZDR verfügbar | +|---|---|---|---| +| OpenAI | 30 Tage | Nein | Ja (Org-Level opt-in) | +| Anthropic | **7 Tage** | Nein | Ja (Enterprise-Vertrag) | +| Google (Gemini API) | je nach Plan | Nein (bezahlte Pläne) | Ja (bezahlte Pläne) | +| DeepSeek | **nicht veröffentlicht** | nicht ausdrücklich zugesichert | Nein | +| DashScope (Alibaba) | **nicht veröffentlicht** | Nein (ausdrückliche Zusage) | nicht dokumentiert | + +⚠️ **Widerspruch, nicht auflösbar:** Anthropic wird von TheRouter und vom Ausgangspost mit **7 Tagen** angegeben, von StealthCloud mit **30 Tagen (Safety)**. Beide Quellen sind Anbieter-Blogs, keine Primärdokumentation. Die Zahl gehört damit nicht als Fakt ins Wiki — der Vergleich mit „OpenAI 30 / Anthropic 7 / Google 18 Monate" im Post ist **auf einer wackligen Zeile gebaut**, auch wenn die Größenordnung stimmt. + +⚠️ **Zusätzlicher Caveat zum Post:** Netbits nennt diese Zahlen „stärker als OpenAI, Anthropic oder Google" und markiert sie nicht als Sekundärangaben. Nur Ollamas eigene Werte hat er an der Primärquelle geprüft — die Vergleichszahlen stammen aus Anbieter-Zusammenstellungen. + ## Netzwerk-Faktencheck — nicht reproduzierbar Netbits' Check behauptet, der Gateway habe **genau eine** ausgehende Verbindung (`192.168.100.4 → 76.76.21.123:443`) und die IP gehöre **Amazon** (Walnut, CA) und sei ollama.com. Eigene Prüfung aus dem Hector-Container (2026-09-23): @@ -91,6 +198,10 @@ Der **methodische** Wert des Checks bleibt: Die Frage „welche Endpunkte sprich - **Was wir wissen:** Unser Tier-0-Modell läuft als **offenes Gewichtsmodell** über Ollama Cloud auf NVIDIA-Cloud-Providern — nicht über die DeepSeek-API. Die datenschutzpolitisch problematische DeepSeek-Erklärung greift damit nicht. - **Was wir nicht wissen:** ob die ZDR-Anforderung bei jedem Partner und für jedes Modell tatsächlich eingehalten wird. Ollamas Cache-Isolation (und die jedes anderen Anbieters außerhalb des Stanford-Audits) ist **nicht unabhängig getestet**. Das ist eine offene Frage, keine Warnung. - **Prompt-Caching:** Wir nutzen es stark (Kostenhebel, siehe [[../prompt-caching.md]]). Der Seitenkanal-Risikofaktor ist **Cache-Sharing über Nutzergrenzen**. Per-User- bzw. per-Org-Isolation entschärft ihn; globales Sharing ist der problematische Fall. Für die eigenen Inhalte gilt: Was nicht in einen fremden Cache soll, gehört nicht in einen geteilten Präfix über einen Multi-Tenant-Dienst — oder auf lokale Hardware ([[../hardware/cloud-exit-and-local-superiority.md]], [[../../tools/ollama-cloud-deepseek-v4-flash-200tps-zdr.md]]). +- **Kein-Training ≠ Kein-Speichern:** Die beiden Zusagen sind unabhängig. Ollama gibt beide, was den Fall günstig macht — aber wer nur die Trainingszusage hat, hat zum Retention-Thema nichts gesagt. +- **Vertraglich vor technisch:** Der saubere Weg für sensible Workloads ist die **schriftliche** ZDR- und Cache-Isolationszusage im Enterprise-Vertrag. Ollama hat solche Verträge; die Policy-Zusage allein ist eine Behauptung, keine Audit-Tatsache. +- **Handlungsfähig heute:** Für sensible Inhalte auf lokale Modelle routen; PII vor Cloud-Aufrufen redigieren; Cache-Isolation dort konfigurieren, wo wir sie kontrollieren (vLLM/SGLang `cache_salt` statt Default-Sharing); Cache-Hit-Muster als Security-Signal beobachten. +- **Was wir bewusst nicht tun:** Wir bauen keine eigenen Enklaven und behandeln TEE nicht als gelöstes Problem. Der Stand ist „noch nicht belastbar" — siehe oben. ## Verwandte Seiten @@ -100,6 +211,8 @@ Der **methodische** Wert des Checks bleibt: Die Frage „welche Endpunkte sprich - [[../llm/ki-souveraenitaet-dezentralisierung.md]] — normativer Überbau: Cloud vs. lokal, Souveränität - [[../hardware/cloud-exit-and-local-superiority.md]] — lokale Ausführung als Antwort auf Provider-Abhängigkeit - [[../../tools/agentcloak-desktop.md]] — lokale PII-Redaktion vor Cloud-Aufrufen (praktische Gegenmaßnahme) +- [[../hardware/edge-inference-als-cloud-alternative.md]] — Hardware-Pfade für die lokale Route, auf die LLM-Redactor als stärksten Hebel verweist +- [[../../people/michael-hannecke.md]] — Autor der referenzierten Aufarbeitung zur Data-in-use-Lücke - [[../llm/chinese-model-cost-routing.md]] — warum chinesische Modelle überhaupt bei Dritt-Hostern laufen ## Quellen @@ -109,4 +222,11 @@ Der **methodische** Wert des Checks bleibt: Die Frage „welche Endpunkte sprich - GitHub Issue: https://github.com/ollama/ollama/issues/14279 (existiert, unbeantwortet) - Gu et al., ICML 2025: [arXiv:2502.07776](https://arxiv.org/abs/2502.07776) · [DOI](https://doi.org/10.48550/arXiv.2502.07776) - Wu et al., NDSS 2025: [Paper-Seite](https://www.ndss-symposium.org/ndss-paper/i-know-what-you-asked-prompt-leakage-via-kv-cache-sharing-in-multi-tenant-llm-serving/) · [PDF](https://www.ndss-symposium.org/wp-content/uploads/2025-1772-paper.pdf) -- Raw (Post + Verifikationsprotokoll): [raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md](../../../raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md) +- Hannecke, Medium (11.02.2026): [The Hidden Data Residency Problem in Prompt Caching](https://medium.com/@michael.hannecke/the-hidden-data-residency-problem-in-prompt-caching-f99e6207451e) — KV-Tensoren, TTLs, GDPR Art. 6/17, CLOUD Act, Tiered Approach (Volltext geprüft) +- LLM-Redactor (Preprint): [arXiv:2604.12064](https://arxiv.org/abs/2604.12064) · [Code](https://github.com/jayluxferro/llm-redactor) — acht Techniken, A+B+C = 0,6 % PII / 31,3 % Code +- vLLM RFC #16016: [Cache Salting for Secure and Flexible Prefix Caching](https://github.com/vllm-project/vllm/issues/16016) — die praktikable Mitigation +- arXiv:2411.18191: [Leaking Secrets from Prefix Caches](https://arxiv.org/html/2411.18191v1) — verwandte Arbeit, von vLLM als Motivation zitiert +- Lyceum (Anbieter-Magazin, KI-generiert): [Zero Data Retention in LLM Inference](https://lyceum.technology/magazine/zero-data-retention-in-llm-inference-how-to) — Policy-Typologie brauchbar, Plattform-Angaben unbelegt +- StealthCloud Scoreboard: [LLM Provider Privacy Scoreboard](https://stealthcloud.ai/data/llm-provider-privacy-scoreboard) — 12 Dimensionen, kein Ollama +- TheRouter (Anbieter-Blog): [Cross-Provider Retention Reference](https://therouter.ai/blog/llm-api-privacy-data-retention-cross-provider-reference) — kein Ollama; Anthropic-Widerspruch +- Raw (Post Teil 1+2 + Verifikationsprotokoll): [raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md](../../../raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md) diff --git a/wiki/index.md b/wiki/index.md index e3bc23b..b8b215b 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -2,7 +2,7 @@ *Auto-generated: 2026-07-07* -*Letzte Aktualisierung: 2026-09-23 (242. Update — Ollama-Cloud-Datenhaltung & Prompt-Caching-Seitenkanäle (Netbits @NetLightning, OME Topic „Openclaw mit lokalen Modellen", #15163). **Eigenrecherche eines Gruppenmitglieds** — kein Link-Ingest, sondern ein Analysepost, der sich nachprüfen ließ: Netzwerk-Faktencheck, Policy-Zitate, zwei peer-reviewte Paper. Raw: `raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md` (neu — Post im Volltext + eigenes Verifikationsprotokoll). Wiki: `concepts/policy/inference-provider-data-retention.md` (neu), `people/netbits.md` (neu). **Verifiziert an den Primärquellen:** Ollama-Zitate zur transienten Verarbeitung, „never logged or trained on", ZDR-Anforderung an Partner, Hosting „primarily in the United States … may route to Europe and Singapore", Partner = NVIDIA Cloud Providers (NCPs), native Gewichte. **Strukturbefund:** Die ZDR-Zusage ist eine Anforderung an Partner, keine eigene Messung — die Privacy Policy (§5) nennt „model inference providers" selbst als Dritte; Ollamas Cache-Isolation ist unabhängig ungetestet. **Paper (beide 2025, Volltexte geprüft):** Gu et al., ICML 2025 (Stanford, arXiv:2502.07776) auditierte 17 APIs — Caching bei 8, globales Cache-Sharing über Nutzergrenzen bei 7 (u.a. OpenAI text-embedding-3-small, Azure, Fireworks, Perplexity); nach Offenlegung änderten ≥5 Provider ihre Implementierung. Wu et al., NDSS 2025 („PROMPTPEEK", SUSTech/ByteDance): Prompt-Rekonstruktion Token für Token — 99 % (Input), 98 % (Template), 95 % ohne Vorwissen; PII-Nachweis (BMI-Prompt: Geschlecht/Alter/Gewicht/Größe) mit 60 Requests. **Korrekturen am Post (eigene Prüfung):** (1) `76.76.21.123` gehört nicht Amazon, sondern **Vercel, Inc** (ARIN-RDAP `NET-76-76-21-0-1`, Netname `VERCEL-01`); ollama.com löst hier zu `34.36.133.15` (Google Cloud) auf, api/registry über Cloudflare — der Check ist aus diesem Container nicht reproduzierbar. (2) GitHub Issue #14279 ist eine **unbeantwortete Rückfrage** (Label `question`, kein Assignee, keine Antwort), nicht die im Post behauptete „dokumentierte Lücke". (3) PROMPTPEEK ist SUSTech/ByteDance, nicht Stanford. **Ergänzt:** Apple-M6/M5-Ultra-Seite, Cloud-Exit, KI-Souveränität und die Ollama-Cloud-Tool-Seite um Cache-/Retention-Cross-Refs, `concepts/prompt-caching.md` um einen Sicherheitsabschnitt (Seitenkanäle, Isolationsgrade).)* +*Letzte Aktualisierung: 2026-09-23 (242. Update — Ollama-Cloud-Datenhaltung & Prompt-Caching-Seitenkanäle (Netbits @NetLightning, OME Topic „Openclaw mit lokalen Modellen", #15163). **Eigenrecherche eines Gruppenmitglieds** — kein Link-Ingest, sondern ein Analysepost, der sich nachprüfen ließ: Netzwerk-Faktencheck, Policy-Zitate, zwei peer-reviewte Paper. Raw: `raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md` (neu — Post im Volltext + eigenes Verifikationsprotokoll). Wiki: `concepts/policy/inference-provider-data-retention.md` (neu), `people/netbits.md` (neu). **Verifiziert an den Primärquellen:** Ollama-Zitate zur transienten Verarbeitung, „never logged or trained on", ZDR-Anforderung an Partner, Hosting „primarily in the United States … may route to Europe and Singapore", Partner = NVIDIA Cloud Providers (NCPs), native Gewichte. **Strukturbefund:** Die ZDR-Zusage ist eine Anforderung an Partner, keine eigene Messung — die Privacy Policy (§5) nennt „model inference providers" selbst als Dritte; Ollamas Cache-Isolation ist unabhängig ungetestet. **Paper (beide 2025, Volltexte geprüft):** Gu et al., ICML 2025 (Stanford, arXiv:2502.07776) auditierte 17 APIs — Caching bei 8, globales Cache-Sharing über Nutzergrenzen bei 7 (u.a. OpenAI text-embedding-3-small, Azure, Fireworks, Perplexity); nach Offenlegung änderten ≥5 Provider ihre Implementierung. Wu et al., NDSS 2025 („PROMPTPEEK", SUSTech/ByteDance): Prompt-Rekonstruktion Token für Token — 99 % (Input), 98 % (Template), 95 % ohne Vorwissen; PII-Nachweis (BMI-Prompt: Geschlecht/Alter/Gewicht/Größe) mit 60 Requests. **Korrekturen am Post (eigene Prüfung):** (1) `76.76.21.123` gehört nicht Amazon, sondern **Vercel, Inc** (ARIN-RDAP `NET-76-76-21-0-1`, Netname `VERCEL-01`); ollama.com löst hier zu `34.36.133.15` (Google Cloud) auf, api/registry über Cloudflare — der Check ist aus diesem Container nicht reproduzierbar. (2) GitHub Issue #14279 ist eine **unbeantwortete Rückfrage** (Label `question`, kein Assignee, keine Antwort), nicht die im Post behauptete „dokumentierte Lücke". (3) PROMPTPEEK ist SUSTech/ByteDance, nicht Stanford. **Ergänzt:** Apple-M6/M5-Ultra-Seite, Cloud-Exit, KI-Souveränität und die Ollama-Cloud-Tool-Seite um Cache-/Retention-Cross-Refs, `concepts/prompt-caching.md` um einen Sicherheitsabschnitt (Seitenkanäle, Isolationsgrade). **Erweiterung (Teil 2 des Posts, gleicher Tag):** Der konzeptionell wichtigste Punkt — ein Cache ist **kein Trainingsleck, sondern ein Persistenz-Problem**: KV-Tensoren liegen als „data in use" auf fremder GPU-Hardware (5 Min bis 24 Std TTL, bei Google Gemini zusätzlich auf GPU-lokalen SSDs), und weder DSGVO-Auftragsverarbeitung (Art. 6/17) noch CLOUD Act haben dafür eine Antwort — laut Hannecke (Medium, 11.02.2026, Volltext geprüft) erwähnen die meisten großen DPAs KV-Cache-Residency gar nicht. **Neue Quellen verifiziert:** Hannecke (KV-Materialisierung, Rechtlücken, Tiered Approach, TEE-Skepsis), LLM-Redactor/arXiv:2604.12064 (Preprint; A+B+C = 0,6 % PII-, aber **31,3 % Code-Leak**), vLLM RFC #16016 (**Cache Salting** — die praktikable Mitigation, die im Post fehlt), StealthCloud-Scoreboard und TheRouter-Referenz (beide **ohne Ollama**), Lyceum (Anbieter-Magazin, **KI-generiert**). **Weitere Korrekturen:** PROMPTPEEK-Link zeigt auf Hanneckes Artikel statt aufs Paper; TEE-Darstellung ist optimistischer als die zitierte Quelle; Lyceum beschreibt flüchtiges VRAM, **kein** TEE; Anthropic-Retention widersprüchlich (7 vs. 30 Tage). Neue Wiki-Seite `people/michael-hannecke.md`, Konzeptseite um Data-in-use- und Mitigations-Abschnitte erweitert.) *Vorherige Aktualisierung: 2026-09-23 (241. Update — Macbrow: Jev-Computer-Use-Build mit öffentlichem Code. Anlass: X-Link https://x.com/BhosalePratim/status/2101281829168792002 von Pit in OME Topic „JEV“ (23.09.). **Quelle:** Note-Tweet von Pratim Bhosale (@BhosalePratim, Paris, 42.523 Follower; 19.09.2026 12:06 UTC; 55.975 Views / 414 Likes / 488 Bookmarks; Bio: Education @GradiumAI — Interessenkonflikt bei Gradium, nicht bei TypeSafe) + **Repo volltextverifiziert:** https://github.com/timpratim/macbrow (MIT, 140 Stars / 15 Forks beim Abruf, created 18.09.2026) + **Demo-Video lokal ausgewertet** (15 Standbilder à 10 s + Grok-STT-Volltext, 152,4 s). **Wiki-Bedeutung:** der erste Jev-Computer-Use-Build mit öffentlichem Code — gegenüber Andy-Gao (kein Repo, keine Messung) dokumentiert: README, Safety-Policy (existiert wegen eines Desktop-Fehlers: „clean up my desktop“ verschob alle Dateien), **26 Offline-Tests**. **Jev-Rolle spezifiziert:** Routing als ein Choice (~300 ms, in der dokumentierten Spanne), **spekulative Arguments** (alle Enum-Argumente aller Kandidaten-Tools als eigene Choices im selben Request), Browser-Seite als **indizierte Tabelle der Controls** mit einem Jev-Request pro Schritt (click/type/select/scroll/wait/done), Follow-up-/Vollständigkeits-Urteile als Noul/Choice; LLM (GPT-5-mini oder lokal) schreibt nur Text. **Text-Only-Grenze konstruktiv aufgelöst:** „No screenshots in the loop“ — jev-ultrafast liest die Seite als Element-Tabelle; Freitext-Argumente durch Span-Auswahl im Diktat. **Eigenmessung:** Amazon-Warenkorb 4 Schritte/11 s; Follow-up 6 Schritte/3,7 s; Trailer „Love Hypothesis“ **1,6 s** von Sprachende bis Video — mit ~300-ms-Call konsistent, keine unvereinbaren Zahlen. **Demo:** Trailer → Shopping → Flüge Paris–Istanbul → Finder (Korrektur „Sorry, the desktop folder“ korrekt aufgelöst) → X-Suche; **Endpunkt = dokumentierter Misserfolg** („close this tab“ scheitert; Tester: „a lot of work to be done, but this is not bad“). Wiki: people/pratim-bhosale.md (neu); Update concepts/agents/jev-sprachsteuerung-computer-use.md (Abschnitt „Gegenstück: Macbrow“). Raw: raw/xpost/2026-09-19_bhosal-pratim-macbrow.md (neu).)* *Vorherige Aktualisierung: 2026-09-22 (239. Update — MacStories-Review „M5 Ultra Mac Studio Review: The Dream Mac for Local AI Agents" (Federico Viticci, 21.09.2026; geteilt von Kai @PWeber in OME Topic „Openclaw mit lokalen Modellen", #1744). **Erste unabhängige Verifikation der M5-Ultra-Versprechen** — schließt die Lücke „⚠️ nur Herstellerangaben" auf der Apple-Seite. Raw: `raw/blog/2026-09-21_macstories-m5-ultra-mac-studio-review.md` (neu; web_fetch vollständig, 21.401 Zeichen). Wiki: `people/federico-viticci.md` (neu), `institutions/macstories.md` (neu), Updates in `concepts/hardware/apple-m6-m5-ultra-mac-mini-studio-update.md` (neuer Messwert-Abschnitt: 256-GB-Gerät gegen M3 Ultra 512 GB und RTX 5090 — Generierung ~+70 %, Prefill ~+150 % (≈2,5×), Flash-Next >100 tok/s bei kurzem Prompt und 60–85 tok/s bei 64K–256K Kontext; Prefill bei 6.000-Token-Prompt ~1.700 tok/s vs. 5090 ~3.000 tok/s; Generierung 5090 konstant ~25 % voraus (1,79 vs. 1,2 TB/s), verliert aber oberhalb 32 GB VRAM), `concepts/llm/qwen3.8-flash-next-qwen4-preview.md` (erster dokumentierter Praxiseinsatz: Flash-Next als lokales Default-Modell in Open Minis und Hermes Agent, 5-Bit vollständig im RAM, bis zu 3 parallele Sessions mit Subagenten via oMLX), `concepts/hardware/cloud-exit-and-local-superiority.md` (Cross-Ref). **Produktivnachweis:** 99 Tage Dauerbetrieb mit DeepSeek-V4-Flash-Agenten + olmOCR über 310 Dokumente fürs iOS-/iPadOS-27-Review — Gesamtkosten 0 $, weil dieselbe Dauerlast per Cloud-API als untragbar eingeschätzt wurde. ⚠️ Einzelsetup (n=1), keine reproduzierte Benchmark-Suite.)* *Vorherige Aktualisierung: 2026-09-22 (238. Update — Unabhängiger Jev-vs.-GPT-5.6-Terra-Benchmark von N8 Programs, geteilt als r/ProAI-Repost. **Quelle vollständig aufgelöst:** Reddit-RSS (17.09., normale Seite/JSON blockiert) → [X-Thread](https://x.com/N8Programs/status/2100088523403432357) (16.09.; 179.846 Views beim Abruf) → vier Originalgrafiken lokal gelesen. **Methode:** neun Multiple-Choice-Bedingungen; Terra `reasoning=none`, Letter-only. **Resultate:** Jev gewinnt MMLU 90,91:87,89, GPQA 68,18:56,06, ARC-Easy/Challenge knapp und WinoGrande 91,63:78,69; Terra gewinnt HellaSwag 95,32:94,86, GSM8K deutlich (87,72:79,68 bzw. 69,83:54,59) und Schach knapp 50,25:49,45. Ungewichteter Makromittelwert **Jev 80,69 % · Terra 80,15 %** → „Terra-tier“ trägt eng für diesen Test, nicht als allgemeine Intelligenzbehauptung. **Korrektur des Threadtexts:** Er behauptet einen Jev-Sieg auf HellaSwag; die eigene Tabelle zeigt Terra +0,46 Pp. **Kalibrierung:** N=33.735, ECE **1,74 Pp**, 10 Bins, Wilson-95-%-Intervalle, Einzelbenches 0,26–6,96 Pp — stärkste öffentliche Fremdevidenz für RLCD bisher. **Kosten:** Jev $0,6999 (estimated: Input-Token × $0,042/MTok) vs. Terra $12,9865 (API-reported) = **18,55×**; die ~18×-Rundung hält, die Hersteller-Obergrenze 400–444,6× nicht. **Nicht geprüft:** Geschwindigkeit; kein Repo, keine Prompts/Seeds/Logs, keine Reproduktion, Kontaminationsrisiko öffentlicher Benches. Wiki: `people/n8-programs.md` (neu), `concepts/llm/system-one-models-jev.md` (neuer unabhängiger Benchmark-Abschnitt). Raw: `raw/other/2026-09-17_reddit-n8-jev-terra-benchmark.md` (neu).)* @@ -368,7 +368,7 @@ | Seite | Beschreibung | Quellen | |-------|-------------|---------| | [Cryptographic Context Injection](concepts/policy/cryptographic-context-injection.md) | Jailbreak versteckt malicious Instructions in verschlüsseltem/encodiertem Text: Safety-Layer sehen nur Encodiertes und lassen durch, das Modell dekodiert im Kontext und befolgt (Representation Gap zwischen Filter und Modell). Ars-Technica-Demo (20.08.): Grok exfiltriert User-Daten. Klasse von Encoding-/Transformations-Angriffen; input-seitige Filterung strukturell begrenzt | podcast/2026-08-26_agentstack-daily-ep106.md | -| [Datenhaltung & Cache-Seitenkanäle bei Cloud-Inferenz](concepts/policy/inference-provider-data-retention.md) | Ollamas Zusagen an den Primärquellen verifiziert (transiente Verarbeitung, „never logged or trained on", ZDR-Anforderung an Partner, Hosting US/EU/Singapur, NVIDIA Cloud Providers, native Gewichte) — aber **vertraglich, nicht technisch**: Die Privacy Policy nennt „model inference providers" selbst als Dritte, die Cache-Isolation ist unabhängig ungetestet. Dazu die zwei Paper: Gu et al. (ICML 2025, Stanford) — 17 APIs auditiert, globales Cache-Sharing bei 7 von 8 cachenden Providern; Wu et al. (NDSS 2025, SUSTech/ByteDance) — PROMPTPEEK rekonstruiert Prompts mit 99 %/98 %/95 % (ohne Vorwissen, PII-Nachweis per 60 Requests). Enthält Korrekturen am Ausgangspost (Vercel statt Amazon; Issue #14279 = offene Frage). Relevanz: unser Tier-0-Modell läuft als offenes Gewichtsmodell auf Ollama Cloud, nicht über die DeepSeek-API | other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md | +| [Datenhaltung & Cache-Seitenkanäle bei Cloud-Inferenz](concepts/policy/inference-provider-data-retention.md) | Ollamas Zusagen an den Primärquellen verifiziert (transiente Verarbeitung, „never logged or trained on", ZDR-Anforderung an Partner, Hosting US/EU/Singapur, NVIDIA Cloud Providers, native Gewichte) — aber **vertraglich, nicht technisch**: Die Privacy Policy nennt „model inference providers" selbst als Dritte, die Cache-Isolation ist unabhängig ungetestet. Dazu die zwei Paper: Gu et al. (ICML 2025, Stanford) — 17 APIs auditiert, globales Cache-Sharing bei 7 von 8 cachenden Providern; Wu et al. (NDSS 2025, SUSTech/ByteDance) — PROMPTPEEK rekonstruiert Prompts mit 99 %/98 %/95 % (ohne Vorwissen, PII-Nachweis per 60 Requests). Enthält Korrekturen am Ausgangspost (Vercel statt Amazon; Issue #14279 = offene Frage). Relevanz: unser Tier-0-Modell läuft als offenes Gewichtsmodell auf Ollama Cloud, nicht über die DeepSeek-API **Erweitert um „Data in use":** KV-Tensoren als Persistenz-, nicht Trainingsproblem — TTL 5 Min bis 24 Std (Google Gemini zusätzlich GPU-lokale SSDs), DSGVO Art. 6/17 und CLOUD Act ohne Antwort, die meisten großen DPAs erwähnen KV-Cache-Residency nicht. Mitigationen: vLLM `cache_salt` (RFC #16016) statt Default-Sharing, Cache-Hit-Muster als Security-Signal, PII-Redaktion (LLM-Redactor: A+B+C = 0,6 % PII / 31,3 % Code), TEE noch nicht belastbar. Anbieterscoreboard ohne Ollama. | other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md | | [AI Regulation 2026](concepts/policy/ai-regulation-2026.md) | Government Reviews, Anthropic-Pause-Forderung, Mythos-Kontroverse, Trump-Exportkontrollen, Amazon-Jailbreak, Roemmele's Intelligenz-Feudalismus-Kritik. **Update 19.08.:** EU-Compute-Rückstand (1,4 vs. 17 GW), US-Importverbot vernetzter Roboter >2 kg, KI-Rechtsperson als Point of No Return, Abu Dhabi KI-Regierung 2027 | 7 + youtube/2026-08-19_ki-experten-alles-zum-kippen.md | | [AI-Fear-Narrativ & Regulierungsdebatte](concepts/policy/ai-fear-narrative-regulierung.md) | Francois Chaubard (YC, 10.09.2026): Vier Thesen gegen die Fear-Erzählung — Hugging-Face-Vorfall als ExploitGym-Prompting (nicht „independent volition"), Navier-Stokes kein autonomer Durchbruch (10k Agenten Brute-Force mit Human-in-the-loop), China-Schutz statt US-Regulierung (Staatsakteure *benutzen* KI), Coxon/CNN als millionenschwere Fear-Kampagne. Thesen 1–3 als Position mit Gegenpositionen eingeordnet, These 4 ausdrücklich als unbelegte Behauptung markiert. Post verlinkt CNN-Interview (oEmbed-verifiziert) | xpost/2026-09-10_francois-chaubard-ai-fear-campaign.md | | [Unzensierte Modelle & die Grenze der Safety-Durchsetzbarkeit](concepts/policy/uncensored-models-safety-enforcement-limit.md) | Alex Finn (20.08.): Unzensiertes Qwen 3.8 27B läuft lokal auf Laptop ("Opus 4.6-Level mit 0 Alignment"). Drei Regulierungs-Sackgassen: Open Source nicht verbietbar, unzensierte Modelle nicht durchsetzbar, Bremsen bei Unternehmen nutzlos. Safety wird zunehmend unmöglich durchsetzbar. Pro-Leben-Einordnung: Resilienz statt Verhinderung, Verantwortung dort verankern wo Macht liegt | xpost/2026-08-20_alexfinn-uncensored-qwen3-27b.md | @@ -475,6 +475,7 @@ | [N8 Programs](people/n8-programs.md) | @N8Programs / GitHub `N8python`; laut Profil Student für angewandte Mathematik/Statistik an Johns Hopkins und In-Context-Learning-Forschung. Veröffentlichte den unabhängigen Jev-vs.-Terra-System-1-Benchmark: neun Multiple-Choice-Bedingungen, Terra `reasoning=none`; Makro nahezu Gleichstand (80,69 % vs. 80,15 %), ECE 1,74 Pp bei N=33.735, Kosten **18,55×** zugunsten Jev. ⚠️ Kein öffentliches Eval-Repo, keine Prompts/Seeds/Logs; HellaSwag-Textclaim widerspricht eigener Tabelle | other/2026-09-17_reddit-n8-jev-terra-benchmark.md | | [Ryan Vogel](people/ryan-vogel.md) | Entwickler/Unternehmer (@ryanvogel, 18.201 Follower): „ceo of @rebasetv / founding developer @opencode @anomalyco", Standort Florida. Gast der Episode „Jev is HERE. How to use it" bei Greg Isenberg (18.09.2026). Relevanz fürs Wiki v. a. über **OpenCode** (Open-Source-Coding-Agent, Partnermodus von DeepSeek V4.1 Flash). ⚠️ Episode-Inhalt nicht ausgewertet; Rebase-TV-Selbstbeschreibung ungeprüft | xpost/2026-09-18_gregisenberg-jev-vercel-gateway.md | | [Netbits ⚡️ Stachelbanane](people/netbits.md) | OME-Mitglied (@NetLightning), mehrfach mit **eigenständiger Analyse** statt Linksammlung im Wiki: Netzwerk-/Konfigurationsprüfungen, Policy-Auswertung, Primärquellen-Recherche. 23.09.: Ollama-Cloud-Datenhaltung + Prompt-Caching-Seitenkanäle (Policy-Zitate und Paper vollständig korrekt zitiert; zwei Netzwerkangaben fehlerhaft — im Wiki korrigiert). 02.09.: Free-AI-Models-Meetup-Liste | other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md | +| [Michael Hannecke](people/michael-hannecke.md) | Autor auf Medium zur Governance-Seite von Prompt-Caching. Sein Artikel „The Hidden Data Residency Problem in Prompt Caching" (11.02.2026) ist die präziseste Aufarbeitung der **„data in use"-Lücke**: KV-Tensoren als Materialisierung des Prompts auf fremder Hardware, DSGVO Art. 6/17 ohne Antwort, CLOUD Act ungeklärt, Tiered Approach (regulierte Daten nur self-hosted), Cache-Metriken als Security-Signal. Bemerkenswert: widerspricht der optimistischen TEE-Darstellung und relativiert Self-Hosting („It shifts control") | other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md | | [Tom Griffiths](people/tom-griffiths.md) | **Thomas L. Griffiths**, Henry-R.-Luce-Professor für Information Technology, Consciousness and Culture an [Princeton](institutions/princeton.md) (Psychologie + Informatik), Leiter des Computational Cognitive Science Lab; laut Klappentext Leiter des Princeton AI Lab. Australischer Kognitionswissenschaftler, bekannt für **Bayes'sche Modelle der Kognition** und *Algorithms to Live By* (mit Brian Christian, 2016). 2026: **„The Laws of Thought"** (Henry Holt, 10.02.2026, 400 S.; dt. „Die Gesetze des Denkens") — die drei Wege, Denken zu formalisieren: Regeln/Symbole, neuronale Netze, Wahrscheinlichkeit/Statistik. ⚠️ Video-Thesen („AI Researchers Are Wrong") stammen aus der Videobeschreibung, kein Transkript | youtube/2026-09-19_princeton-griffiths-ai-researchers-wrong.md | | [Brian Keating](people/brian-keating.md) | Kosmologe, Chancellor's Distinguished Professor of Physics an der UC San Diego (CMB, Simons Observatory, BICEP/POLARBEAR); Autor von *Losing the Nobel Prize* (2018) und *Into the Impossible*. Betreibt den Podcast/Kanal **„Into the Impossible"** ([@DrBrianKeating](https://www.youtube.com/@DrBrianKeating)) — im Wiki als **Interviewer/Distributionskanal**, nicht als KI-Forscher. Kanal mit eigenem Monetarisierungs-Setup (Patreon, Kanalmitgliedschaft, `.edu`-Aktion, Amazon-Kurzlinks); die Rahmung „AI Researchers Are Wrong" kommt vom Kanal | youtube/2026-09-19_princeton-griffiths-ai-researchers-wrong.md | @@ -578,7 +579,7 @@ | Datei | Typ | Titel | |-------|-----|-------| | `raw/blog/2026-09-21_xai-grok-47-official.md` | blog | Offizielle Grok-4.7-Akte: xAI-Release + API-Modellkarte + Cursor-Doku; 500k Kontext, vier Effort-Stufen, $2/$6 Basis-I/O, Long-Context-Tarif; Herstellerbenchmarks und Safeguard-Claims markiert | -| `raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md` | other | Netbits (@NetLightning): Ollama-Cloud-Datenhaltung + Prompt-Caching-Seitenkanäle — Post im Volltext plus Verifikationsprotokoll. Ollama-Policy-Zitate bestätigt; GitHub #14279 als unbeantwortete Rückfrage (16.02.2026) eingeordnet; Gu et al. ICML 2025 (17 APIs, 8 mit Caching, 7 mit globalem Sharing, DeepSeek per-user isoliert) und Wu et al. NDSS 2025 (PROMPTPEEK, 99 %/98 %/95 %, PII via 60 Requests) aus den Volltexten geprüft; Netzwerk-Faktencheck widerlegt (76.76.21.0/24 = Vercel, nicht Amazon) | +| `raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md` | other | Netbits (@NetLightning): Ollama-Cloud-Datenhaltung + Prompt-Caching-Seitenkanäle — Post im Volltext plus Verifikationsprotokoll. Ollama-Policy-Zitate bestätigt; GitHub #14279 als unbeantwortete Rückfrage (16.02.2026) eingeordnet; Gu et al. ICML 2025 (17 APIs, 8 mit Caching, 7 mit globalem Sharing, DeepSeek per-user isoliert) und Wu et al. NDSS 2025 (PROMPTPEEK, 99 %/98 %/95 %, PII via 60 Requests) aus den Volltexten geprüft; Netzwerk-Faktencheck widerlegt (76.76.21.0/24 = Vercel, nicht Amazon) Teil 2: KV-Tensoren als Persistenzproblem; Hannecke-Aufarbeitung (Rechtlücken, Tiered Approach, TEE-Skepsis) geprüft; LLM-Redactor-Preprint (1.300 Samples, A+B+C), vLLM-RFC #16016 (Cache Salting), StealthCloud-Scoreboard und TheRouter-Referenz (beide ohne Ollama), Lyceum als KI-generiertes Anbietermarketing eingeordnet; Widerspruch Anthropic 7 vs. 30 Tage | | `raw/xpost/2026-09-22_guillemant-ki-kein-bewusstsein.md` | xpost | **Philippe Guillemant (@Philippe2244, verifiziert)** — „Warum die KI kein Bewusstsein haben kann“ ([Post](https://x.com/Philippe2244/status/2102365377808224284), 22.09.2026 11:52 UTC; Kurzlink `tinyurl.com/2b4bmny3` löst per 301 auf; 207 Likes / 79 Reposts / 34 Replies / 6.152 Views beim Abruf; geteilt im OME-Topic „Theorie-Bildung“ als nb5-Briefing). **Volltext über fxtwitter-API** (Syndication nur 276 Zeichen), daher französischer Originaltext + inhaltstreue Übersetzung komplett im Raw. Struktur: vier zitierte anglophone Contra-Argumente (Penrose/Hameroff Mikrotubuli+Anästhesie; Chalmers hartes Problem; **Koch Simulation ≠ Simuliertes**; Penrose/Hoffman kein Rechenergebnis) → eigene Thesen: **~1-Sekunden-Zeitfenster in der nahen Zukunft** (Libet/Bem), Präsidieren der Quantenreduktion (Kastrup/Faggin), Zeitlinien-Wahl im Multiversum, Zeitdichten (~1 s/~1 h/~1 Jahr), Materie = schlafendes Bewusstsein, außerzeitliche Vakuumschwingungen + zweite Zeit (Connes), Dekohärenz in der Zukunft, Gleichungen als Hindernis. Angehängtes Bild = dekorative KI-Illustration (kein Diagramm). Sekundärquellen im Raw verifiziert (Cosmopolis-PDF, DOI 2019, Qeios-Preprint; je HTTP 200). Wiki: `people/philippe-guillemant.md` (neu), `concepts/agi/zukunftssensor-bewusstsein.md` (neu), `concepts/agi/ai-consciousness.md` (gemerged). ⚠️ Einzelpost/Meinungstheorie, kein peer-reviewtes Dokument; Video-Briefing nicht auswertbar | | `raw/blog/2026-09-21_macstories-m5-ultra-mac-studio-review.md` | blog | **MacStories / Federico Viticci — „M5 Ultra Mac Studio Review: The Dream Mac for Local AI Agents"** (21.09.2026; web_fetch vollständig, 21.401 Zeichen). Erste unabhängige Verifikation der M5-Ultra-Werte: 256 GB gegen M3 Ultra (512 GB) und RTX 5090; Generierung +70 %, Prefill +150 %, Flash-Next >100 tok/s kurz / 60–85 bei 64K–256K, 5-Bit vollständig im RAM, bis 3 parallele Sessions (oMLX); Prefill 6.000-Token ~1.700 vs. ~3.000 tok/s (5090), Generierung 5090 ~25 % voraus; Testmethodik (GPT-6-Astra-Harness, oMLX 0.7.0.dev2, LM Studio/CUDA) und offene Projekte (DwarfStar, Inco Splash, Exo) dokumentiert | | `raw/xpost/2026-09-21_cb-doge-grok-47-release.md` | xpost | DogeDesigner/@cb_doge Release-Zusammenfassung (113.071 Views beim Abruf); Werte gegen xAI geprüft, pauschales „2× fast/half price“ als Account-Verdichtung abgegrenzt | diff --git a/wiki/log.md b/wiki/log.md index 06cb01d..f6818b7 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -2,6 +2,37 @@ *Append-only changelog. Start: 2026-06-05* +## 2026-09-23 — Nachtrag Teil 2: Data in use, Cache-Persistenz & Mitigationen + +**Type:** ingest-Erweiterung + wiki-update | **Scope:** raw/other, wiki/concepts/policy, wiki/people, wiki/index, wiki/log +**Anlass:** Zweiter Teil von Netbits' Recherchepost im selben OME-Topic (#15163-#15164). Er verschiebt den Fokus von „Trainingsleck" auf **Persistenz**: KV-Tensoren als „data in use" auf fremder GPU-Hardware. + +**Der Kernpunkt (Aussage des Posts):** +> Ein Cache ist **kein** Trainingsdatenleck. Es ist ein *Persistenz*-Thema. Was im Cache liegt, sind **KV-Tensoren** auf fremder GPU-Hardware, für Minuten bis Stunden. Nicht der Rohtext — aber eine mathematische Repräsentation davon, örtlich gebunden an eine bestimmte Maschine in einem bestimmten Rechenzentrum. Die meisten Datenschutz-Rahmenwerke (DSGVO-Auftragsverarbeitung, CLOUD Act) haben dafür **keine Antwort**. + +Diese Trennung ist die konzeptionell wichtigste Aussage der ganzen Recherche und wurde als eigener Wiki-Abschnitt übernommen. + +**Neu verifizierte Quellen:** +- **Hannecke, „The Hidden Data Residency Problem in Prompt Caching"** (Medium, 11.02.2026, 18.815 Zeichen geprüft): KV-Tensoren sind „a materialization of your prompt content on provider infrastructure … not the raw text". TTL **5 Min bis 24 Std**; bei **Google Gemini** zusätzlich GPU-lokale SSDs bis 24 Std. **DSGVO Art. 17:** keine Cache-Eviction-API für Einzeleinträge bei großen Anbietern (Stand Anfang 2026). **Art. 6:** offene Rechtsfrage, ob ein globaler Cache-Hit die Verarbeitung fremder Daten ist. **CLOUD Act:** gerichtlich ungeklärt, konservative Lesart = ja. „most [DPAs] do not mention KV-cache residency" — Aufsichtsversäumnis, nicht Bosheit. Tiered Approach, vier Entscheidungsfragen, fünf Vendor-Fragen, Cache-Metriken als Security-Signal. **Relativiert Self-Hosting:** „self-hosting does not eliminate KV-cache risk. It shifts control." **TEE ausdrücklich als noch nicht belastbar.** DLA-Piper-Zahlen: 2025 ≈ 1,2 Mrd. EUR Bußgelder, +22 % Meldungen YoY auf 443/Tag, kumuliert ≈ 7,1 Mrd. EUR seit 2018. +- **vLLM RFC [#16016](https://github.com/vllm-project/vllm/issues/16016) — Cache Salting** (GitHub geprüft): die im Post **fehlende praktikable Mitigation**. Optionales Salt pro Request im Block-Hash — Prefix-Caching bleibt nutzbar, Cross-User-Wiederverwendung entfällt. Zitiert als Motivation arXiv:2411.18191 („Leaking Secrets from Prefix Caches"). vLLM und SGLang teilen Caches per Default; Isolation nur bei expliziter Konfiguration. +- **LLM-Redactor, arXiv:[2604.12064](https://arxiv.org/abs/2604.12064)** (Abstract geprüft; Justice Owusu Agyemang, v1 13.04.2026, cs.CR, **Preprint**): acht Techniken; empirisch A/B/C/H über vier Workload-Klassen, Benchmark 1.300 Samples / 4.014 Annotationen. **A+B+C = 0,6 % PII-Leak, 31,3 % Proprietary-Code-Leak, null exakte PII-Leaks über 500 Samples.** Diese Zahl fehlte im Post und ist die handlungsleitende. +- **StealthCloud Privacy Scoreboard** (18.05.2026, 12 Dimensionen): kein Anbieter über **72 %** (Anthropic 72, Mistral 71, Cohere 70; OpenAI API 58, Google Gemini API 57). **Kein Ollama.** +- **TheRouter Cross-Provider Reference** (August 2026): OpenAI 30 Tage / Anthropic **7 Tage** / Google plangesteuert / DeepSeek und DashScope **nicht veröffentlicht**. **Kein Ollama.** + +**Korrekturen Teil 2:** +1. **Falscher Link:** PROMPTPEEK (NDSS 2025) wird im Post auf Hanneckes Medium-Artikel verlinkt, nicht auf das Paper. +2. **TEE überzeichnet:** Der Post nennt TEE „per Architektur statt per Vertrag" — die von ihm selbst als beste Quelle bezeichnete Aufarbeitung (Hannecke) bewertet TEE als **noch nicht belastbar** (wenige Frameworks, erheblicher Overhead, offen ob Tensoren die Enklave verlassen). Empfehlung dort: „verify the implementation before trusting the marketing." +3. **Kategorienfehler:** Der Post belegt TEE mit dem Lyceum-Artikel — Lyceum beschreibt aber **flüchtiges VRAM mit LRU-Eviction**, das ist **kein TEE**. Lyceums technische Trennung (No-Training ≠ ZDR) ist brauchbar; die Angaben zur eigenen Plattform sind Herstellerangaben aus einem Artikel, der selbst **„created with the help of AI"** ausweist. +4. **Fehlende Zahl:** Bei LLM-Redactor fehlt der 31,3-%-Rest-Leak bei Proprietary Code — die lokale Route ist der starke Teil der Kombination, nicht die Redaktion allein. +5. **Widersprüchliche Retention-Zahlen:** Anthropic erscheint mit **7 Tagen** (TheRouter, Post) und **30 Tagen** (StealthCloud). Beide Quellen sind Anbieter-Blogs, keine Primärdokumentation. Der Vergleich „stärker als OpenAI/Anthropic/Google" steht damit auf einer wackligen Zeile — Größenordnung stimmt, die Anthropic-Zahl nicht als Fakt führbar. +6. **Ollama fehlt in allen drei Vergleichsquellen** — stützt den Befund „unabhängig ungeprüft" auf drei unabhängige Nicht-Erwähnungen. + +**Dateien:** +- raw (UPDATED): `raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md` — Teil 2 im Volltext + Verifikationsprotokoll (jetzt 31 KB) +- wiki (NEU): `wiki/people/michael-hannecke.md` +- wiki (UPDATED): `wiki/concepts/policy/inference-provider-data-retention.md` — neue Abschnitte „Data in use: der Persistenz-Blickwinkel", „Warum die Rechtssysteme keine Antwort haben", „Mitigationen", „Anbieter-Vergleich", erweiterte Stack-Konsequenzen +- wiki (UPDATED): `wiki/index.md` (242. Update erweitert um Teil 2, neue People-Zeile) + ## 2026-09-23 — Ollama-Cloud-Datenhaltung & Prompt-Caching-Seitenkanäle (Netbits) **Type:** ingest + wiki-update | **Scope:** raw/other, wiki/concepts/policy, wiki/people, wiki/concepts, wiki/tools, wiki/index, wiki/log diff --git a/wiki/people/michael-hannecke.md b/wiki/people/michael-hannecke.md new file mode 100644 index 0000000..039e755 --- /dev/null +++ b/wiki/people/michael-hannecke.md @@ -0,0 +1,38 @@ +--- +title: "Michael Hannecke" +created: 2026-09-23 +updated: 2026-09-23 +sources: [other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md] +tags: [person, author, privacy, governance, prompt-caching, data-residency, ai-compliance] +--- + +# Michael Hannecke + +Autor auf Medium, schreibt eine Serie zur Governance-Seite von Prompt-Caching für Enterprise-Architekten, CISOs und Governance-Verantwortliche. Sein Beitrag „The Hidden Data Residency Problem in Prompt Caching" (11.02.2026) ist im Wiki referenziert, weil er die **„data in use"-Lücke** präziser aufarbeitet als jede andere vorliegende Quelle: Was mit Prompts *während* der Inferenz passiert, fällt durch die Maschen der üblichen Rahmenwerke. + +## Warum im Wiki relevant + +Er liefert das Bindeglied zwischen zwei Dingen, die das Wiki getrennt dokumentiert: den **Paper-Befunden** (Gu et al., PROMPTPEEK — siehe [[../concepts/prompt-caching.md]]) und der **praxisnahen Konsequenz** für Architektur und Beschaffung. Konkret: + +- **Begriffliche Schärfung:** KV-Tensoren sind „a materialization of your prompt content on provider infrastructure" — kein Rohtext, aber eine semantische Repräsentation, gebunden an konkrete GPU-Knoten in konkreten Rechenzentren. +- **Die Rechtlücken benannt:** DSGVO Art. 17 (keine Cache-Eviction-API bei großen Anbietern), Art. 6 (ist ein globaler Cache-Hit die Verarbeitung fremder Daten?), CLOUD Act (ungeklärt, ob kurzlebige KV-Tensoren unter „possession, custody, or control" fallen). +- **Tiered Approach:** regulierte Daten nur self-hosted; PII vor caching-fähigen Endpunkten strippen; Cache-Metriken als Security-Signal. +- **Selbstkritische Note zum Self-Hosting:** „self-hosting does not eliminate KV-cache risk. It shifts control." — Der Punkt, den die meisten Diskussionen überspringen. +- **TEE-Skepsis:** Confidential Computing als mögliche, aber noch nicht belastbare Antwort — „verify the implementation before trusting the marketing." + +## Einordnung + +⚠️ **Medium-Artikel, kein Peer-Review.** Die technischen Aussagen stützt er auf die beiden peer-reviewten Arbeiten (Gu et al./ICML 2025, Wu et al./NDSS 2025) — die Zahlen sind damit auf solider Basis, die Interpretation und die Compliance-Einschätzungen sind seine eigene Analyse. Der Artikel ist ausdrücklich als Enterprise-Perspektive geschrieben, nicht als akademische Arbeit. Netbits hat ihn als beste Aufarbeitung des Themas empfohlen; die eigene Prüfung bestätigt das. + +**Bemerkenswert:** Er widerspricht der optimistischen TEE-Darstellung, die im Ausgangspost zu finden war — siehe [[../concepts/policy/inference-provider-data-retention.md]]. + +## Quellen + +- [The Hidden Data Residency Problem in Prompt Caching](https://medium.com/@michael.hannecke/the-hidden-data-residency-problem-in-prompt-caching-f99e6207451e) (Medium, 11.02.2026, 12 min read) +- Verwandter Artikel seiner Serie: „Prompt Caching Explained: What It Is, What It Isn't, and When to Use It" +- Raw mit Verifikationsprotokoll: [raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md](../../raw/other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md) + +## Verwandte Wiki-Seiten + +- [[../concepts/policy/inference-provider-data-retention.md]] — die Seite, auf der seine Aufarbeitung verarbeitet ist +- [[../concepts/prompt-caching.md]] — Technik und Sicherheitsabschnitt