uni/slides/223015b/05-vertiefung-offene-fragen.md

---
marp: true
theme: gaia
paginate: true
backgroundColor: #fff
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
title: Distribution und Metadaten
---

<style>
:root {
  --color-foreground: #1a1a2e;
  --color-highlight: #1e5f8a;
  --color-dimmed: #4a4a6a;
}
section.invert { --color-foreground: #fff; }
section { font-size: 1.7rem; }
h1 { color: #1e5f8a; }
section.invert h1 { color: #fff; }
h2 { color: #1f2937; }
pre {
  background: #0f0f23;
  color: #5fb3e4;
  border-radius: 8px;
  border-left: 3px solid #1e5f8a;
}
pre code { background: transparent; color: inherit; }
code {
  background: #0f0f23;
  padding: 0.15em 0.4em;
  border-radius: 4px;
  font-family: ui-monospace, "SF Mono", Menlo, Consolas, monospace;
}
section code:not(.hljs) { color: #5fb3e4 !important; }
section code.hljs { color: #f8f8f8 !important; }
a { color: var(--color-highlight); }
section.klausur {
  background: repeating-linear-gradient(
    135deg,
    #e3f2fd,
    #e3f2fd 40px,
    #fff 40px,
    #fff 80px
  ) !important;
}
@media print {
  section.klausur { background: #e3f2fd !important; }
}
section.aufgabe { background: #e3f2fd !important; }
section.aufgabe footer { display: none; }
section.erklaerung :not(header),
section.erklaerung :not(footer) { font-size: 1.1rem; }
section.erklaerung h1 { font-size: 1.5rem; color: #1e5f8a; margin-bottom: 0.3rem; }
section.erklaerung ul, section.erklaerung ol { font-size: 1.0rem; line-height: 1.4; }
section.erklaerung p { font-size: 1.0rem; line-height: 1.4; }
section.erklaerung table { font-size: 0.9rem; }
</style>

<!-- _class: lead -->

# Kapitel 5
## Distribution und Metadaten

<!--
Eine Stunde, eine Frage: *Wie kommen die Bytes von der Quelle zur Endnutzerin — und was verraten sie auf dem Weg?*

Anschluss an Kap 4: dort haben wir gesehen, wo Bytes wohnen und über welche Schnittstellen sie reisen. Jetzt: WIE reisen sie (Distribution) und WAS verraten sie dabei (Metadaten)?

Bogen:
1. CDN-Prinzip (warum Netflix sofort startet)
2. REST-APIs (wie Apps Daten austauschen)
3. PIVOT zu Metadaten
4. EXIF, ID3, PDF-Metadaten (was Dateien über sich verraten)
5. Vendor-Lockin (Adobe, Apple)
-->

---

<!-- _header: '' -->
<!-- _footer: '' -->

![bg fit](./assets/demos/kap05-eroeffner.png)

<!--
Eine Datei reist + erzählt. Smartphone-Foto Stuttgart → Tokyo zeigt drei Schichten:

- INHALT (links blau): das visuelle Foto, HEIC 4032×3024, 3,2 MB. Was der Empfänger sieht.
- GEPÄCK (rechts lila): die EXIF-Daten, die mitkommen — Kamera iPhone 15 Pro, Zeitstempel, GPS-Koordinaten (pink: Stuttgart, Königstraße), iOS-Version, Farbprofil. Was die Datei über sich weiß.
- WEG (unten orange): Route Stuttgart → DNS → TLS 1.3 → CDN-Edge Tokyo → Tokyo. HTTP-Headers: 200 OK, RTT 47 ms, cache HIT bei Edge tok-7.

Eine Datei = Inhalt + Gepäck + Weg. Drei Schichten, eine Datei.

In dieser Stunde gehen wir durch alle drei: wie reist die Datei (CDN, REST), was bringt sie mit (EXIF, ID3, PDF-Meta), und wann ist das ein Privacy-Problem (McAfee, Tony Blair).
-->

---

<!-- _class: lead -->

# Sub-Sektion A: Distribution — wie reist die Datei?

<!--
Reihenfolge:
1. CDN-Prinzip (Netflix-Beispiel)
2. REST-APIs (Wetter-App fragt Daten ab)
3. JSON als Datenformat
-->

---

# CDN — Content Delivery Network

**Idee:** Daten dort speichern, wo die Nutzer:innen sind.

Statt von **einem zentralen Server** in Kalifornien wird die Datei von einem **Edge-Server** in eurer Nähe geliefert.

Beispiel: Netflix nutzt **Open Connect** — eigene Server in 1.000+ ISP-Rechenzentren weltweit. ~15 % des globalen Internet-Verkehrs.

**Latenz** von Stuttgart zu Stuttgart: ~5 ms.
**Latenz** von Stuttgart nach Kalifornien: ~150 ms.

<!--
CDN-Logik:
- Origin Server: das echte Heimatverzeichnis der Datei (z.B. Netflix-Headquarters)
- Edge Server (PoPs = Points of Presence): Kopien, geographisch verteilt
- Wenn ein User eine Datei anfordert: DNS leitet zur nächsten Edge-Kopie
- Edge prüft Cache: HIT → liefert sofort. MISS → holt von Origin, cached für nächste Anfrage

Bekannte CDNs:
- Cloudflare: 300+ Standorte, viele freie Websites
- AWS CloudFront: Amazon
- Akamai: ältester großer CDN
- Netflix Open Connect: eigene Hardware in ISP-Rechenzentren

Konsequenz: ohne CDN würde Netflix einen Server in CA haben, jeder europäische Stream müsste den Atlantik queren. Mit CDN: lokal in München, Stuttgart, Hamburg.
-->

---

# Wie sieht das im DevTools aus?

DevTools (F12) → Tab **Network** → reload eine Seite

Was ihr seht:
- **DNS-Lookup:** ~30 ms (oder gecacht: 0)
- **TLS-Handshake:** ~50 ms
- **TTFB** (Time to First Byte): ~80 ms wenn CDN, sonst 300+
- **Cache-Status:** Header `x-cache: HIT` oder `cf-cache-status: HIT`

→ **Selbstlernen:** öffnet eine populäre Seite, schaut die Response-Header an.

<!--
DevTools-Demo live in der Vorlesung:
1. Eine bekannte Seite öffnen (z.B. github.com)
2. F12, Tab Network
3. Reload
4. Eine Request anklicken → Headers
5. Suche nach `x-cache`, `cf-cache-status`, `age` Headers

Konsequenz für Studis: das ist nicht Magic — man kann es sehen.
-->

---

<!-- _class: lead -->

# REST-APIs — wie Apps Daten austauschen

<!--
API = Application Programming Interface = "Stelle, an der eine App mit einer anderen App redet".

Beispiel:
- Wetter-App auf dem Handy braucht aktuelle Daten
- Stellt eine HTTP-Anfrage an die Wetter-API (z.B. https://api.wetter.com/aktuell?ort=stuttgart)
- API antwortet mit JSON-Daten
- App rendert die Daten als hübsche Oberfläche

Im Hintergrund läuft das überall: Instagram (Daten von Server), Spotify (Tracks), Banking-Apps.

Heute: REST. Das ist DAS Standardparadigma.
-->

---

# Was ist eine API?

**Application Programming Interface.** Eine standardisierte Stelle, an der zwei Programme Daten austauschen.

```
            HTTP-Request (GET /aktuell?ort=stuttgart)
   ┌─────────────────────────────────────────────────┐
   │                                                 ▼
[App auf dem Handy]                       [API-Server]
   ▲                                                 │
   │           JSON-Response                         │
   └─────────────────────────────────────────────────┘
        { "temperatur": 14, "regen": false, ... }
```

**Beispiele:** Wetter, Maps, Banking, Twitter, jede Spotify-Anfrage.

<!--
APIs sind die Klebstoffschicht zwischen Anwendung und Daten.

Frontend (App, Website): rendert die Daten
Backend (Server): hält die Daten, beantwortet API-Anfragen

REST-Konvention: jede Ressource hat eine URL. Aktion drückt sich in der HTTP-Methode aus (GET = lesen, POST = neu erstellen, PUT = updaten, DELETE = löschen).

Konsistente Methoden + URLs → REST = "Representational State Transfer".
-->

---

<!-- _class: klausur -->

# REST: GET · POST · PUT · DELETE

| Methode | Was tut sie | URL-Beispiel |
|---------|-------------|--------------|
| **GET** | lesen | `GET /users/42` (User mit ID 42 abfragen) |
| **POST** | neu erstellen | `POST /users` mit Daten als Body |
| **PUT** | überschreiben | `PUT /users/42` mit kompletten neuen Daten |
| **PATCH** | teilweise ändern | `PATCH /users/42` mit Änderungen |
| **DELETE** | löschen | `DELETE /users/42` |

CRUD = **C**reate · **R**ead · **U**pdate · **D**elete.

<!--
Klausurfähig: welche HTTP-Methode für welche Operation?

Trick-Frage: was ist der Unterschied zwischen PUT und PATCH?
- PUT: ersetzt komplett. User wird kompletter neu gesetzt.
- PATCH: ändert nur die mitgegebenen Felder. Rest bleibt.

In der Praxis nehmen viele APIs PUT auch für partielle Updates — kein RFC-konforme Strenge.

Werkzeuge zum Testen: curl, Postman, Hoppscotch (browser-basiert), VS-Code REST-Client-Plugin.
-->

---

<!-- _class: aufgabe -->

# Selbstlernen — eine API im Browser anfragen

JSONPlaceholder ist eine kostenlose Fake-API zum Üben:

```
https://jsonplaceholder.typicode.com/users
https://jsonplaceholder.typicode.com/posts/1
https://jsonplaceholder.typicode.com/posts?userId=2
```

**Aufgabe:** Im Browser öffnen. Was kommt zurück? Welcher Content-Type-Header?

Bonus: mit `curl https://api.github.com/users/torvalds` in der Konsole.

<!--
JSONPlaceholder = beste Spielwiese für API-Anfänger. Liefert fiktive Daten zu Users, Posts, Comments, Albums, Photos, Todos.

Live-Demo im Hörsaal:
1. URL in den Browser-Adress-Bar eingeben
2. JSON-Antwort sehen (Firefox/Chrome rendern es hübsch)
3. F12, Network: Headers anschauen — content-type: application/json
4. Curl in Terminal: ähnlich, ohne Browser-Pretty-Print

Daraus folgt: hinter jeder Web-App stecken API-Anfragen wie diese. Manchmal komplexer (Authentifizierung), aber im Kern dasselbe.
-->

---

# JSON — das Standard-Datenformat

```json
{
  "name": "Torvalds",
  "alter": 56,
  "projekte": [
    { "name": "Linux", "stars": 180000 },
    { "name": "Git",   "stars": 50000 }
  ],
  "aktiv": true
}
```

- **Objekte** (`{ ... }`), **Listen** (`[ ... ]`), **Strings** (`"..."`), **Zahlen**, `true`/`false`, `null`
- Universell: jede Programmiersprache hat JSON-Support
- Lesbar: Mensch + Maschine

<!--
JSON = JavaScript Object Notation. Erfunden 2001 von Douglas Crockford.

Hat XML als Standard-Datenformat im Web fast vollständig abgelöst:
- Weniger Boilerplate als XML
- Direkt von JavaScript-Engines parsbar
- Streng aber einfach

Heute praktisch jede REST-API liefert JSON. Manchmal noch XML, selten YAML oder Protobuf.

Sub-formate: JSON5 (mit Kommentaren), JSONC (mit Trailing Commas), JSON-LD (für Schema.org).
-->

---

<!-- _class: lead -->

# Sub-Sektion B: Metadaten — was Dateien über sich verraten

<!--
PIVOT. Wir haben gesehen, wie Daten reisen (CDN, REST). Jetzt: WAS reist mit?

Die meisten Studis denken: "Eine JPEG-Datei ist ein Bild." Stimmt nur teilweise.

Tatsächlich enthält jede JPEG-Datei:
- Das Bild selbst (visueller Inhalt)
- EXIF-Metadaten: Kamera, Zeit, GPS, Software, Belichtung, Linse
- Diese Metadaten reisen mit, wenn die Datei verteilt wird

Konsequenz: wer ein Foto verschickt, verschickt oft viel mehr als das Bild. Das ist die "Gepäck"-Seite des Bogens.
-->

---

# EXIF — was ein Foto über sich verrät

**Exchangeable Image File Format.** Standard seit 1995, in JPEG/HEIC/TIFF.

Typische EXIF-Daten in einem Smartphone-Foto:

| Feld | Beispiel |
|------|----------|
| Kamera-Hersteller | Apple |
| Kamera-Modell | iPhone 15 Pro |
| Linse, Brennweite | 24 mm, ƒ/1.78 |
| Belichtung, ISO | 1/250 s, ISO 100 |
| **Aufnahme-Zeitstempel** | 2026-04-12 18:47:12 +02:00 |
| **GPS-Koordinaten** | 48.7847°N 9.1825°E (Stuttgart, Königstraße) |
| Software-Version | iOS 18.4.1 |
| Bearbeitungs-Spuren | Photoshop CC 2025 |

<!--
EXIF macht Fotos detektiv-tauglich.

Die GPS-Information ist die kritischste. Smartphones (auch Drohnen-Kameras) speichern standardmäßig die GPS-Koordinaten in jedem Foto.

Auch dabei: Datum/Uhrzeit auf die Sekunde genau, Software-Version (kann bei einem Hack als Forensik dienen).

Tools zum Auslesen:
- `exiftool` (CLI, perl)
- ExifTool GUI (mehrere Implementierungen)
- Browser: exifdata.com, jeffrey.exif

Demo im Hörsaal: ein Foto vom Smartphone exportieren, exiftool drauf, GPS-Koordinaten in Google Maps eintippen.
-->

---

<!-- _class: klausur -->

# Der John-McAfee-GPS-Fall

**Dezember 2012.** John McAfee (Antivirus-Erfinder) flieht aus Belize, wo er als Mordverdächtiger gesucht wird.

**Vice Magazine** veröffentlicht ein Interview mit einem Foto: McAfee im T-Shirt, scheinbar in einer geheimen Location.

**EXIF-Koordinaten im Foto:** `15.6541° N, 88.9939° W` → **Hotel Nana Lodge, Guatemala.** Bekannt.

McAfee wird 36 Stunden später festgenommen.

<!--
Diese Story zeigt:
1. Smartphones speichern GPS-Daten standardmäßig
2. Online-Plattformen STRIPPEN diese Metadaten oft NICHT (Vice damals nicht)
3. Wer ein Bild mit GPS hochlädt, kann seinen Aufenthaltsort verraten

McAfee hat sich danach öffentlich darüber lustig gemacht ("yes that was the actual location"), aber der Fall wurde zum Lehrbuch-Beispiel für EXIF-Privacy.

2026: die meisten großen Plattformen strippen EXIF (Twitter/X, Instagram, WhatsApp), aber:
- WhatsApp-Originaldatei via "Dokument" senden: behält EXIF
- E-Mail-Anhang: behält EXIF
- Direkt-Upload zu Drittpartei-Webseiten: oft mit EXIF
-->

---

# Social-Media-EXIF-Stripping (Übersicht)

| Plattform | Stripped EXIF? | Vorbehalte |
|-----------|----------------|------------|
| **Instagram** | Ja | (komplett entfernt + neu komprimiert) |
| **Facebook** | Ja | |
| **Twitter / X** | Ja | nur bei Foto-Upload, nicht bei Direktnachricht |
| **WhatsApp** | Ja, *wenn als Foto* gesendet | NEIN bei "Dokument senden" |
| **iMessage** | Ja | |
| **E-Mail (Outlook, GMail)** | Nein | Original-Datei bleibt original |
| **Slack / Discord** | Nein bzw. teilweise | Original-Datei bleibt original |

**Faustregel:** Plattform-Upload = wahrscheinlich Stripped. Datei direkt teilen = unsicher.

<!--
Diese Tabelle ist nicht klausurrelevant, aber lebensweltlich wichtig.

Sub-Frage: warum strippen manche Plattformen, andere nicht?
- Social: re-komprimieren sowieso → verlieren EXIF dabei
- Messenger: oft komplett re-komprimieren (besseres Streaming)
- E-Mail/Dokumenten-Sharing: schickt Original-Bytes durch

Privacy-Tipp: Geo-Tagging in Smartphone-Settings ausschalten, wenn ihr Fotos teilen wollt. Oder mit Apps wie "ExifEraser" reinigen.
-->

---

# ID3 — Metadaten in MP3-Dateien

```
ID3v2.4 Header:
Titel:    "Hotel California"
Artist:   "Eagles"
Album:    "Hotel California"
Jahr:     1976
Genre:    Rock
Cover-Art: [JPEG embedded, 250 × 250 px]
```

Plus: Lyrics, Komponist, Track-Nr, ReplayGain, manchmal **ganze Lyric-Videos als Embedded-Bilder.**

→ Daher ist eine 4-Min MP3 manchmal **5 MB groß** statt 3 MB.

<!--
ID3-Tags = Metadaten-Standard für MP3 seit 1996.

Versionen:
- ID3v1: 128 Byte am Ende. Sehr begrenzt.
- ID3v2: variabel große Tags am Anfang. Standard heute.

Datenbanken:
- MusicBrainz: offene Musik-DB, vollständige Metadaten
- AcoustID: erkennt Songs anhand Audio-Fingerprint
- LastFM: scrobbling + Metadaten

Verwendet von: iTunes, Spotify, jeder Audio-Player.
-->

---

<!-- _class: klausur -->

# Der Tony-Blair-Fall (PDF-Metadaten)

**Februar 2003.** Britische Regierung veröffentlicht PDF-Dokument zur Begründung des Irakkriegs.

Ein britischer Akademiker findet im **PDF-Revisionsverlauf**: das Dokument wurde aus einer studentischen Doktorarbeit von 1991 kopiert.

**Plagiats-Skandal.** Plus Hinweise auf welche Mitarbeiter:innen welche Sätze überarbeitet hatten.

→ **PDF-Metadaten** verraten oft mehr als der Inhalt.

<!--
PDF-Metadaten:
- Autor, Erstell-Zeit, letzte Änderung
- Software (Microsoft Word, LibreOffice, Adobe Acrobat)
- Manchmal Revision History
- Manchmal versteckter Text (z.B. weiße Schrift auf weißem Hintergrund)

Sicherheitsrelevant:
- Schwärzungen werden manchmal nur als schwarzer Layer DRÜBER gelegt — Text bleibt extrahierbar
- NSA-Dokumente, FBI-Reports, US-Gerichtsdokumente: viele berühmte Beispiele für gescheiterte Schwärzungen
- Auch bei Microsoft Word: "Schwärze" via schwarzes Highlight → Text bleibt im Stream lesbar

Klausurfähig: ein Beispiel für PDF-Metadaten-Privacy-Verstoß nennen + Begründung.
-->

---

<!-- _class: lead -->

# Vendor-Lockin — wenn das Format zum Käfig wird

<!--
Manche Formate sind absichtlich proprietär. Hersteller behält die Spezifikation für sich.

Konsequenz:
- Nur deren Software kann die Datei voll öffnen
- Wer die Software lizenziert (oder ein Abo zahlt), kann arbeiten
- Wer aus dem Ökosystem aussteigt, verliert evtl. die Daten

Klassiker:
- Adobe Photoshop PSD
- Adobe InDesign INDD
- Apple Pages, Numbers, Keynote
- Microsoft Word DOC (alt, vor DOCX)
-->

---

# Beispiele: proprietäre Formate

| Format | Hersteller | Was nervt |
|--------|-----------|-----------|
| **PSD** (Photoshop) | Adobe | nur Photoshop liest Layer-Daten voll. Abo-Pflicht. |
| **INDD** (InDesign) | Adobe | gleiches Problem |
| **.pages** | Apple | nur in Apple-Apps voll editierbar |
| **.numbers** | Apple | gleiches |
| **DOC** (alt) | Microsoft | bis 2007 closed-source |
| **PSP, AI** | Adobe | proprietäre Editor-Formate |

→ **Offene Alternativen:** PNG, TIFF, ODT (LibreOffice), HTML/Markdown, SVG.

<!--
Vendor-Lockin-Logik:
- Hersteller hat hohe Marktmacht
- Hersteller-eigenes Format ist „besser" als offene Standards (richtiger oder gefühlt)
- Migrations-Kosten sind hoch → User bleibt
- Lock-in als Geschäftsmodell

Beispiel Adobe:
- Photoshop ist standardmäßig in der Industrie
- PSD ist DAS Format für Designer
- Abonnement Creative Cloud: ~30€/Monat
- Wer Photoshop kündigt: kann PSD-Dateien nicht mehr voll editieren

Gegenstrategien:
- Open-Source-Tools: GIMP, Inkscape, LibreOffice
- Export in offene Formate: PSD → TIFF (verlustlos) für Archiv
- "Open Source Forever": Wikipedia, Sci-Hub, IPFS
-->

---

<!-- _class: klausur -->

# Vendor-Lockin als Risiko

**Szenario:** Du arbeitest 5 Jahre lang mit Adobe InDesign. Dann steigt der Abo-Preis um 200 % oder Adobe ändert das Format.

**Konsequenz:**
- Bestehende INDD-Dateien öffnen sich noch — aber nur in Adobe-Produkten
- Migration zu Affinity Publisher / Scribus: Daten müssen konvertiert werden, manche Details gehen verloren
- Bei einigen Formaten gibt es keine Konverter — Vendor entscheidet komplett

**Schutz:** Wichtige Daten in **offenen Formaten** parallel speichern.

<!--
Klausurfähig: was ist Vendor-Lockin? Beispiel + warum problematisch?

Diskussion: Open-Source-Tools sind oft "fast so gut" — manchmal sogar besser. Aber Industrie-Standards halten den Status quo.

Heimlich-Lockin: auch "Bug-für-Bug-Kompatibilität". Microsoft Office hat sich in den 90ern als Standard durchgesetzt, weil Konkurrenz-Office-Suites die exakten Bugs/Quirks nicht reproduzieren konnten.
-->

---

<!-- _class: aufgabe -->

# Selbstlernen — exiftool auf eigene Fotos

**Installation:**
- macOS: `brew install exiftool`
- Linux: `sudo apt install libimage-exiftool-perl`
- Windows: [exiftool.org](https://exiftool.org)

**Aufgabe:**
```sh
exiftool DEIN_FOTO.jpg
```

Schaut, was alles drin steht. **Findet ihr GPS-Koordinaten?** Bonus: in [maps.google.com](https://maps.google.com) eintippen.

**Optional:** EXIF entfernen mit `exiftool -all= DEIN_FOTO.jpg`.

<!--
Diese Übung ist die zentrale Aha-Erkenntnis für Studis: ihr eigenes Smartphone-Foto verrät GPS-Koordinaten.

Erwartung:
- iPhone-Aufnahme: EXIF mit GPS, Kamera-Modell, Linsen-Daten
- Foto von Android: ähnlich
- Foto von einem Web-Download: oft schon EXIF-stripped

Diskussion: was bedeutet das für: einen unbekannten Hostessen-Service, ein Anonymous-Tweet mit Foto, ein Verkaufs-Foto auf eBay mit dem Foto vom Wohnzimmer?

Privacy-Empfehlung: Geo-Tagging im Smartphone abschalten ODER vor Upload mit exiftool/ExifEraser/Squoosh.app reinigen.
-->

---

# Zusammenfassung

**Distribution — wie reist die Datei:**
CDN bringt sie zur Edge. REST-API liefert Daten on-demand. JSON ist die Sprache.

**Metadaten — was bringt die Datei mit:**
EXIF (Fotos), ID3 (Audio), PDF-Meta (Dokumente). GPS + Zeitstempel + Software.

**Privacy:** EXIF kann Aufenthaltsort verraten. PDF kann Revision-History verraten.

**Vendor-Lockin:** proprietäre Formate als Käfig. Offene Alternativen wo möglich.

→ Eine Datei ist nie nur Inhalt. **Inhalt + Gepäck + Weg.**

<!--
Recap des Kapitels — und implizit auch des ganzen Kurses:

Distribution (Weg):
- CDN: Daten dort speichern wo Nutzer sind
- REST: standardisierte API über HTTP
- JSON: das Datenformat

Metadaten (Gepäck):
- EXIF: was Fotos verraten (GPS, Kamera, Zeit)
- ID3: was MP3 verraten (Artist, Titel, Album)
- PDF-Meta: Revision History, Autor, Software
- Privacy-Cases: McAfee (GPS), Tony Blair (Revision History)

Vendor-Lockin:
- Proprietäre Formate als Geschäftsmodell
- Adobe, Apple, Microsoft
- Schutz: offene Formate parallel

Synthese: Eine Datei = Inhalt + Gepäck + Weg.
- Inhalt: was wir sehen/hören
- Gepäck: was die Datei über sich weiß (Metadaten)
- Weg: wie sie reist (CDN, Protokolle)

Alle drei sind Teil der Datei. Studis können jetzt eine JPEG/MP3/MP4/PDF als das verstehen, was sie wirklich ist: nicht ein Bild oder Song oder Dokument, sondern ein strukturierter Byte-Stream mit Inhalt + Metadaten + Distribution-Pfad.

Damit endet der Kurs. Die Klausur wird zeigen, was hängen geblieben ist.
-->