hector-bot/knowledge-base

Fork 0

Hector 6551fb2d9e ingest(other): netbits ollama cloud data retention + prompt caching side channels

2026-09-23 15:18:52 +02:00

13 KiB

Raw Blame History

type

source_url

retrieved

title

author

posted_date

Netbits: Ollama-Cloud-Datenhaltung und Prompt-Caching-Seitenkanäle

Kontext

Recherchepost von Netbits (@NetLightning) im OME-Topic „Openclaw mit lokalen Modellen" (#1744), 2026-09-23 13:10 UTC. Anlass war die Frage nach Datenhaltung bei Cloud-Inferenz über Ollama Cloud (Hectors Tier-0-Modell deepseek-v4.1-flash läuft dort). Der Post enthält einen Netzwerk-Faktencheck, Zitate aus Ollamas Primärquellen, einen GitHub-Issue-Verweis und zwei peer-reviewte Paper.

Post-Inhalt (wörtlich, gekürzt um Höflichkeitsformeln)

Zuerst der Faktencheck an deiner eigenen Maschine: Der Gateway hat genau eine ausgehende Verbindung nach draußen — 192.168.100.4 → 76.76.21.123:443, und die IP gehört Amazon (Walnut, Kalifornien). Das ist ollama.com. Kein Nous-Telemetrie-Endpunkt, keine Analytics. Alles, was rausgeht, geht an einen einzigen Anbieter.

1. Was Ollama offiziell zusagt. Aus der Datenschutzerklärung wörtlich: „When using cloud-hosted models, we process this content transiently to provide the Service and this content is not stored beyond the time required to fulfill the request." / „We do not use your inputs or outputs to train any AI models." Und auf der Preisseite: „When Ollama partners with providers, we require no logging, no training, and zero data retention policies in place." Das ist stark — stärker als OpenAI (30 Tage), Anthropic (7 Tage) oder Google (bis 18 Monate).

2. Die Lücke, die dokumentiert ist. GitHub Issue #14279: Ollama betreibt nicht alle Cloud-Modelle auf eigener Hardware. Für manche Modelle wird an Drittanbieter-APIs geroutet — bei Qwen 3.5 war Alibaba der einzige Endpunkt. Ollamas eigene Datenschutzerklärung nennt in Abschnitt 5 ausdrücklich „model inference providers" als Dritte. Ollamas Zusage ist damit vertraglich, nicht technisch: Sie verlangen ZDR von ihren Partnern. Sie beweisen es nicht, und es gibt keine unabhängige Prüfung. Praktisch heißt das: Ob deine Daten wirklich nicht gespeichert werden, hängt davon ab, welches Modell du fährst und bei welchem Betreiber es landet. Bei deepseek-v4.1-flash ist das ein offenes Gewichtsmodell auf NVIDIA-Cloud-Hardware — nicht die DeepSeek-API. Die berüchtigte DeepSeek-Datenschutzerklärung gilt für deepseek.com — die App und die eigene API. Nicht für dich.

3. Die eigentliche Recherche. Gu et al., ICML 2025 (arXiv:2502.07776) — auditierte 17 kommerzielle LLM-APIs: 8 Anbieter nutzen Prompt-Caching, 7 dieser 8 teilten ihre Caches global über alle Nutzer hinweg. Angriff über Timing-Seitenkanal. Nebenbei entdeckten sie OpenAIs nicht-dokumentierte Architektur des Embedding-Modells. Nach der Veröffentlichung änderten mindestens 5 Anbieter ihre Implementierung.

Wu et al., NDSS 2025 („PROMPTPEEK"): Bei Multi-Tenant-Serving (SGLang) ließ sich der Prompt Token für Token rekonstruieren — bis 99% Genauigkeit bei bekanntem Prompt-Template, 95% ohne Vorwissen. Sie extrahierten tatsächlich personenbezogene Daten aus gecachten Gesundheits-Prompts: Geschlecht, Alter, Gewicht.

Für dich relevant: In derselben Stanford-Studie wurde DeepSeek als per-user isoliert validiert — also sauber. Für Ollama selbst liegt keine solche Prüfung vor. Niemand hat Ollamas Cache-Isolation unabhängig getestet.

Primärquellen-Verifikation (Abruf 2026-09-23)

Ollama Privacy Policy — Zitate bestätigt

Abgerufen via web_fetch (https://ollama.com/privacy, 200, vollständig). Wortlaut bestätigt:

§2: „When using cloud-hosted models, we process this content transiently to provide the Service and this content is not stored beyond the time required to fulfill the request."
§2: „We do not use your inputs or outputs to train any AI models or request prompt or response content in support requests."
§5 „Information Sharing" nennt als Dritte unter „To provide you the Service": „Third parties who help us operate (e.g., Stripe for payments, cloud infrastructure providers, model inference providers)."
§5: „Data may be transferred to and processed in the United States."
§6 Data Retention: Kategorien Account / Billing / Support / Metadata+Analytics — Prompt- und Response-Inhalte werden dort nicht als eigene Kategorie geführt.
Data Controller laut §12: Ollama Inc.

Ollama Pricing-Seite / Privacy-FAQ — Zitate bestätigt

Abgerufen via web_fetch (https://ollama.com/pricing, 200, vollständig). Wortlaut bestätigt:

„Where are models hosted? — Ollama hosts models and compute resources primarily in the United States. To serve global demand, we may route to Europe and Singapore for additional capacity."
„Is my prompt or response data trained on? — Prompt or response data is never logged or trained on."
„Who does Ollama partner with to host models? — Ollama collaborates with NVIDIA Cloud Providers (NCPs) to host open models. When Ollama partners with providers, we require no logging, no training, and zero data retention policies in place."
„What quantization or data format do cloud models use? — Native weights, as released by the model provider. On modern NVIDIA hardware, models may use accelerated data formats supported by Blackwell and Vera Rubin architectures (e.g. NVFP4)."

Damit bestätigt sich die strukturelle Einordnung des Posts: Gehostet werden offene Gewichte von NVIDIA-Cloud-Providern, nicht die DeepSeek-API. Die ZDR-Zusage ist eine Anforderung an Partner, keine eigene Messung.

GitHub Issue #14279 — existiert, ist aber unbeantwortet

Abgerufen via web_fetch (200). Titel: „Qwen3.5-397B-A17B Cloud data retention and privacy concerns". Eröffnet von asitwere am 16.02.2026. Volltext des Eröffnungsposts:

„It looks like Alibaba is currently the only endpoint available for Qwen3.5, but Ollama's docs/advertising for Ollama Cloud provide data privacy assurances. Since Alibaba retains prompts & responses, can it be confirmed that users are not being routed to Alibaba APIs via Ollama Cloud?"

Metadaten: Label question, kein Assignee, kein Milestone, keine Antwort, keine verlinkten PRs/Branches. Das Issue dokumentiert also eine offene Frage, nicht einen bestätigten Befund. Netbits' Formulierung „die Lücke, die dokumentiert ist" ist insofern zu stark: dokumentiert ist die Rückfrage, nicht die Routing-Praxis. Zugleich ist die zugrunde liegende Beobachtung (Ollama nennt „model inference providers" selbst als Dritte) durch die Privacy Policy gedeckt.

Netzwerk-Faktencheck — nicht reproduzierbar, IP-Zuordnung falsch

Eigene Prüfung aus dem Hector-Container (2026-09-23):

Behauptung im Post	Prüfergebnis
`192.168.100.4` ist „deine Maschine"	Nein. Der Container hat 172.20.0.10, 172.21.0.8, 100.80.221.60. `192.168.100.4` ist eine private LAN-Adresse außerhalb dieses Containers.
`76.76.21.123` gehört Amazon (Walnut, Kalifornien)	Falsch. ARIN-RDAP für `76.76.21.0/24`: Handle `NET-76-76-21-0-1`, Netname `VERCEL-01`, Registrant Vercel, Inc (Walnut, CA). Kein PTR-Eintrag. Die Adresse gehört Vercel, nicht Amazon.
Die IP „ist ollama.com"	Nicht bestätigt. Auflösung von hier: `ollama.com → 34.36.133.15` (ARIN: `GOOGL-2`, Google Cloud). `api.ollama.com` und `registry.ollama.ai` laufen über Cloudflare (`server: cloudflare`). `ollama.com` antwortet mit `server: Google Frontend`.
„genau eine ausgehende Verbindung, alles geht an einen einzigen Anbieter"	Aus diesem Container nicht reproduzierbar; die Beobachtung stammt offenbar von einem anderen Host/Netzwerk. Zudem sind laut Ollama-Pricing-Seite Routing nach Europa und Singapur möglich — „ein einziger Anbieter" wäre auch bei korrekter IP nur eine Momentaufnahme.

Der methodische Wert des Checks bleibt: Die Frage „welche Endpunkte spricht der eigene Agent tatsächlich an" ist sinnvoll und nachprüfbar. Die konkrete Zuordnung im Post ist fehlerhaft.

Gu et al., ICML 2025 — arXiv:2502.07776

Abgerufen: Abstract-Seite (200) und HTML-Volltext v2 (527 KB). Titel: „Auditing Prompt Caching in Language Model APIs". Autoren: Chenchen Gu, Xiang Lisa Li, Rohith Kuditipudi, Percy Liang, Tatsunori Hashimoto — alle Stanford University. Accepted ICML 2025.

Verifizierte Zahlen aus dem Volltext:

Auditiert wurden 17 API-Provider: Anthropic, Amazon Bedrock, Microsoft Azure OpenAI, Cohere, Deep Infra, DeepSeek, Fireworks AI, Google, Groq, Hyperbolic, Lepton AI, Mistral, OctoAI, OpenAI, Perplexity, Replicate, Together AI (Table 1/2).
Prompt-Caching nachgewiesen bei 8 Providern (Tabelle 1 führt Azure, Deep Infra, Fireworks, Lepton, OpenAI, Perplexity, Replicate, Anthropic).
Globales Cache-Sharing über alle Nutzer nachgewiesen bei 7 von ihnen (Azure text-embedding-3-small, Deep Infra, Fireworks, Lepton, OpenAI text-embedding-3-small, Perplexity, Replicate). Bei Anthropic Claude 3 Haiku und OpenAI GPT-4o mini nur per-org, dort kein globales Sharing.
Methode: statistischer Timing-Audit (Kolmogorov-Smirnov-Test, einseitig) auf Time-to-First-Token von Cache-Hit vs. Cache-Miss.
OpenAIs Embedding-Modell war zuvor nicht öffentlich bekannt als decoder-only Transformer — per Timing-Seitenkanal hergeleitet.
Nach verantwortungsvoller Offenlegung (60-Tage-Frist) änderte mindestens fünf Provider ihre Implementierung, z. B. Abschaltung globalen Cache-Sharings und Doku-Updates.
DeepSeek: Das Paper konnte Caching nicht über Antwortzeiten nachweisen (Tabelle 2) und stellt fest: „DeepSeek states that the cache is isolated per-user, and we empirically verified that this is the case based on the number of cache hit tokens returned in the API responses." Die Aussage des Posts stimmt, beruht aber auf den gemeldeten Cache-Hit-Token-Zählern, nicht auf Timing.
Nebenbefund des Papers: Dokumentiertes per-organisation Cache-Sharing (OpenAI, Anthropic) wird von den Autoren nicht als Sicherheitslücke gewertet.

Wu et al., NDSS 2025 — „PROMPTPEEK"

Abgerufen: NDSS-Paper-Seite (200) und PDF-Volltext. Titel: „I Know What You Asked: Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving". Autoren: Guanlong Wu, Weili Wang, Jianyu Niu, Yinqian Zhang (Southern University of Science and Technology, SUSTech) sowie Zheng Zhang, Yao Zhang, Ye Wu (ByteDance Inc.).

Verifizierte Angaben aus dem PDF:

Attacke: PROMPTPEEK. Ausnutzung des KV-Cache-Sharings identischer Token-Präfixe in Multi-Tenant-Serving-Systemen (SGLang, vLLM); ein Cache-Hit ist über Serving-Reihenfolge bzw. TTFT beobachtbar.
Drei Szenarien: (1) Whole Prompt Reconstruction, (2) Input Reconstruction, (3) Template Reconstruction.
Ergebnisse: 99 % durchschnittliche Erfolgsrate bei vollständiger oder teilweiser Rekonstruktion des Prompt-Inputs (Reversal Ratio 99 %); 98 % bei der Prompt-Template-Rekonstruktion (Reversal Ratio 91 %); 95 % bei Whole-Prompt-Rekonstruktion ohne Vorwissen (Reversal Ratio 81 %).
Personenbezogene Daten: Aus einem Cloze-Prompt (BMI-Beispiel mit Platzhaltern für Geschlecht, Alter, Gewicht, Größe) ließen sich alle Platzhalter mit 60 Requests rekonstruieren — die konkreten Werte im Beispiel: „male", „35", „90kg", „5 feet 9 inches".
Testumgebung: Llama-2-13B auf einer A100 80 GB.
Verantwortungsvolle Offenlegung: Die Autoren geben an, mit SGLang über Gegenmaßnahmen im Gespräch zu sein; das Paper diskutiert Obfuskation mit seltenen Tokens, Randomisierung der Longest-Prefix-Matching-Scheduling-Policy sowie die Anforderung von M>1 gemeinsam genutzten Tokens.
Handlungsempfehlungen an Provider (Lessons Learnt): Lebenszyklus des KV-Cache vollständig modellieren, Cache-Aktivität vor Clients verschleiern, Request-Anzahl/-Inhalt pro Client kontrollieren.

Einordnung durch den Post-Autor

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.

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.

13 KiB Raw Blame History Unescape Escape