hector-bot/knowledge-base
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
knowledge-base/wiki/concepts/policy/inference-provider-data-retention.md

12 KiB
Raw Blame History

created updated sources tags
2026-09-23 2026-09-23
other/2026-09-23_netbits-ollama-cloud-privacy-prompt-caching.md
concept
policy
privacy
data-retention
zdr
cloud-inference
ollama
prompt-caching
kv-cache
side-channel
deepseek
third-party-routing

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).

Was Ollama zusagt (verifiziert am 2026-09-23)

Abgerufen direkt von den Primärquellen — Privacy Policy und Pricing-Seite:

Zusage Wortlaut (Quelle)
Transiente Verarbeitung „we process this content transiently to provide the Service and this content is not stored beyond the time required to fulfill the request" (Privacy §2)
Kein Training „We do not use your inputs or outputs to train any AI models" (Privacy §2); „Prompt or response data is never logged or trained on" (Pricing-FAQ)
ZDR-Anforderung an Partner „When Ollama partners with providers, we require no logging, no training, and zero data retention policies in place" (Pricing-FAQ)
Hosting-Standorte „primarily in the United States. To serve global demand, we may route to Europe and Singapore for additional capacity" (Pricing-FAQ)
Partner „Ollama collaborates with NVIDIA Cloud Providers (NCPs) to host open models" (Pricing-FAQ)
Dritte (Privacy §5) „Third parties who help us operate (e.g., Stripe for payments, cloud infrastructure providers, model inference providers)"
Gewichte „Native weights, as released by the model provider"; Hardware-Formate wie NVFP4 auf Blackwell/Vera Rubin (Pricing-FAQ)

Der Vergleich mit anderen Anbietern (OpenAI 30 Tage, Anthropic 7 Tage, Google bis 18 Monate), den der Post zieht, ist hier nicht nachgeprüft — als Claim des Posts behandelt, nicht als Wiki-Fakt.

Die Lücke: vertraglich statt technisch

Zwei strukturelle Punkte, die beide durch Ollamas eigene Dokumente gedeckt sind:

  1. Ollama betreibt nicht alle Cloud-Modelle auf eigener Hardware. Die Privacy Policy nennt „model inference providers" ausdrücklich als dritte Partei, die am Betrieb beteiligt ist. Die ZDR-Zusage ist damit eine Anforderung an Partner, die Ollama nicht selbst messt — es gibt (Stand Ingest) keine unabhängige Prüfung.
  2. Ob Datenhaltung greift, hängt am Modell. Entscheidend ist, welches Modell man fährt und bei welchem Betreiber es landet. Genau diese Frage stellt offenbar auch die Community — siehe GitHub Issue unten.

GitHub Issue #14279 — offene Frage, nicht Befund

Der Post zitiert ollama/ollama#14279 als „dokumentierte Lücke". Die eigene Prüfung ergibt: Das Issue existiert (Titel „Qwen3.5-397B-A17B Cloud data retention and privacy concerns", eröffnet von asitwere am 16.02.2026), ist aber unbeantwortet — Label question, kein Assignee, kein Milestone, keine Antwort, keine verlinkten PRs. Der Volltext ist eine Rückfrage:

„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?"

⚠️ Korrektur zum Post: Dokumentiert ist die Rückfrage, nicht die Routing-Praxis. Netbits' Formulierung „die Lücke, die dokumentiert ist" ist zu stark. Die zugrunde liegende Beobachtung (Ollama nennt Dritte selbst) bleibt davon unberührt — sie ist durch die Privacy Policy belegt.

DeepSeek-Verwechslung — die eigentlich gute Nachricht

Die berüchtigte DeepSeek-Datenschutzerklärung (Speicherung in China, Keystroke-Patterns) gilt für deepseek.com — die App und die eigene API. Sie gilt nicht, wenn ein offenes DeepSeek-Gewichtsmodell bei einem Dritten läuft. deepseek-v4.1-flash auf Ollama Cloud ist laut Pricing-FAQ ein offenes Gewichtsmodell auf NVIDIA-Cloud-Hardware — nicht die DeepSeek-API. Das ist ein Unterschied, den viele verwechseln, und er ist für unseren Stack der relevanteste Punkt dieses Posts.

Prompt-Caching als Seitenkanal (zwei peer-reviewte Arbeiten)

Prompt-Caching ist bei uns keine Randerscheinung, sondern Kern der Kostenstrategie — siehe ../prompt-caching.md. Genau deshalb ist dieser Teil relevant.

Gu et al., ICML 2025 — Audit kommerzieller APIs

arXiv:2502.07776, „Auditing Prompt Caching in Language Model APIs" — Chenchen Gu, Xiang Lisa Li, Rohith Kuditipudi, Percy Liang, Tatsunori Hashimoto (alle Stanford University), ICML 2025. Volltext und Abstract selbst geprüft.

  • 17 API-Provider auditiert (Anthropic, Amazon Bedrock, Azure OpenAI, Cohere, Deep Infra, DeepSeek, Fireworks, Google, Groq, Hyperbolic, Lepton, Mistral, OctoAI, OpenAI, Perplexity, Replicate, Together).
  • 8 Provider mit nachgewiesenem Prompt-Caching.
  • 7 davon mit globalem Cache-Sharing über Nutzergrenzen — Azure, Deep Infra, Fireworks, Lepton, OpenAI (text-embedding-3-small), Perplexity, Replicate. Bei Anthropic (Claude 3 Haiku) und OpenAI (GPT-4o mini) nur per-org, kein globales Sharing.
  • Methode: statistischer Timing-Audit (einseitiger Kolmogorov-Smirnov-Test) auf Time-to-First-Token von Cache-Hit vs. Cache-Miss.
  • Nebenbefund: Sie leiteten per Timing ab, dass OpenAIs Embedding-Modell ein decoder-only Transformer ist — vorher nicht öffentlich bekannt.
  • Wirkung: Nach verantwortungsvoller Offenlegung (60-Tage-Frist) änderten mindestens fünf Provider ihre Implementierung, z. B. Abschaltung globalen Cache-Sharings.
  • DeepSeek: Caching war über Antwortzeiten nicht nachweisbar (Tabelle 2). Das Paper stellt fest, dass DeepSeek per-user-Isolation angibt und sie „empirically verified ... based on the number of cache hit tokens returned in the API responses". Die Zuschreibung „DeepSeek ist sauber" stimmt also — beruht aber auf gemeldeten Cache-Hit-Zählern, nicht auf Timing-Messung.
  • Dokumentiertes per-Organisation-Sharing (OpenAI, Anthropic) wird von den Autoren nicht als Sicherheitslücke gewertet.

Wu et al., NDSS 2025 — PROMPTPEEK

„I Know What You Asked: Prompt Leakage via KV-Cache Sharing in Multi-Tenant LLM Serving" — Guanlong Wu, Weili Wang, Jianyu Niu, Yinqian Zhang (SUSTech) und Zheng Zhang, Yao Zhang, Ye Wu (ByteDance). PDF und NDSS-Seite selbst geprüft.

  • Angriff: PROMPTPEEK. KV-Cache-Sharing identischer Token-Präfixe in Multi-Tenant-Serving (SGLang, vLLM); Cache-Hits sind über Serving-Reihenfolge bzw. TTFT beobachtbar, der Angreifer ist einfach ein zweiter Tenant.
  • Drei Szenarien: Whole Prompt Reconstruction, Input Reconstruction, Template Reconstruction.
  • Ergebnisse (Llama-2-13B, A100 80 GB): 99 % Erfolgsrate bei Prompt-Input-Rekonstruktion (Reversal Ratio 99 %); 98 % bei Prompt-Templates (91 % Reversal); 95 % bei Whole-Prompt ohne Vorwissen (81 % Reversal).
  • PII-Nachweis: Aus einem Cloze-Prompt (BMI-Beispiel mit Platzhaltern für Geschlecht, Alter, Gewicht, Größe) ließen sich alle Platzhalter mit 60 Requests rekonstruieren — Beispielwerte „male", „35", „90kg", „5 feet 9 inches".
  • Offenlegung/Mitigation: Die Autoren geben Gespräche mit SGLang an; diskutiert werden Obfuskation mit seltenen Tokens, Randomisierung des Longest-Prefix-Matching und das Anfordern von M>1 gemeinsamen Tokens. Lessons Learnt an Provider: KV-Cache-Lebenszyklus modellieren, Cache-Aktivität vor Clients verschleiern, Request-Volumen pro Client kontrollieren.

⚠️ 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.

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):

Behauptung Prüfergebnis
192.168.100.4 = „deine Maschine" Nicht dieser Container. Er hat 172.20.0.10, 172.21.0.8, 100.80.221.60 — 192.168.100.4 ist eine LAN-Adresse außerhalb.
76.76.21.123 gehört Amazon 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.
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 über Cloudflare; ollama.com antwortet mit server: Google Frontend.
„genau eine Verbindung, ein einziger Anbieter" Nicht reproduzierbar; laut Ollama-Pricing ist Routing nach Europa und Singapur möglich — „ein Anbieter" wäre ohnehin nur eine Momentaufnahme.

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

Konsequenzen für unseren Stack

  • 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).

Verwandte Seiten

Quellen