223015b phase 4: kap5 slide-MD (filename misleading: 05-vertiefung-offene-fragen.md hält jetzt 'distribution und metadaten'). 20 slides nach bogen (etwas gekürzt von 25)

struktur: - 2 intro: kapitel-lead, kap05-eroeffner als advance organizer (foto stuttgart→tokyo mit inhalt+gepäck+weg) - 8 DISTRIBUTION: lead, CDN-prinzip mit netflix open connect (~15% globaler internet-traffic), wie-im-devtools (selbstlernen), lead REST-APIs, was-ist-API mit schema-diagramm, klausur REST-methods-tabelle (GET/POST/PUT/PATCH/DELETE + CRUD), selbstlernen JSONPlaceholder, JSON-syntax als beispiel - 7 METADATEN: lead 'was dateien über sich verraten', EXIF-tabelle mit konkreten feldern (kamera/linse/belichtung/GPS/software), klausur mcafee-GPS-fall (festnahme via EXIF in vice-foto 2012), social-media-stripping-übersicht (insta/facebook/whatsapp/email), ID3-tags MP3 mit beispiel hotel-california, klausur tony-blair-fall (PDF-revisionsverlauf 2003 plagiat), lead vendor-lockin, proprietäre-formate (PSD/INDD/.pages/.numbers/DOC), klausur vendor-lockin-risiko-szenario - 2 selbstlernen + summary: exiftool-aufgabe (GPS am eigenen foto), zusammenfassung distribution+metadaten=inhalt+gepäck+weg reuse-demos: kap05-eroeffner (zentral) no neu-demos für kap5 (alle 8 NEU-demos aus bogen durch inline-content ersetzt — CDN als prosa, REST/JSON als code-block, EXIF/ID3/vendor-lockin als tabellen) klausur-marker (5): REST-methods (10), mcafee-GPS-fall (15), tony-blair-fall (18), vendor-lockin-risiko (20) streichungen vs altem 04-distribution-apis-zukunft.md (1871 zeilen): - BitTorrent/P2P-details: eingedampft auf hinweis (klausurirrelevant) - IPFS: raus (nicht klausurthema, kein berührungspunkt) - WebSockets, gRPC, GraphQL: raus (zu speziell, gehört in internettechnik 223015c) - gesamte zukunfts-sektion (AI-kompression, JPEG XL, DNA-storage, 8K-VR, web3, sustainability): raus per D2-lock - AWS-snowball / sneakernet: raus (klausurirrelevant) build geht durch
2026-05-14 12:08:50 +02:00
parent f41dd51e5c
commit e7f19e68fa
1 changed files with 565 additions and 78 deletions
@@ -5,7 +5,7 @@ paginate: true
 backgroundColor: #fff
 header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
 footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
-title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
+title: Distribution und Metadaten
 ---

 <style>
@@ -14,31 +14,18 @@ title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
  --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;
-}
+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;
-}
+pre code { background: transparent; color: inherit; }
 code {
  background: #0f0f23;
  padding: 0.15em 0.4em;
@@ -47,9 +34,7 @@ code {
 }
 section code:not(.hljs) { color: #5fb3e4 !important; }
 section code.hljs { color: #f8f8f8 !important; }
-a {
-  color: var(--color-highlight);
-}
+a { color: var(--color-highlight); }
 section.klausur {
  background: repeating-linear-gradient(
    135deg,
@@ -60,83 +45,585 @@ section.klausur {
  ) !important;
 }
@media print {
-  section.klausur {
-    background: #e3f2fd !important;
-  }
-}
-section.aufgabe {
-  background: #e3f2fd !important;
-}
-section.aufgabe footer {
-  display: none;
+  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: invert -->
-<!-- _header: '' -->
-<!-- _footer: '' -->
-<!-- _backgroundColor: #000 -->
-
-![bg cover opacity:0.2](./assets/radek-grzybowski-eBRTYyjwpRY-unsplash.jpg)
-
-# Dateiformate, Schnittstellen, Speichermedien & Distributionswege
-
-**223015b** · Modul "Technik 1" · 1. Semester
-Digital- und Medienwirtschaft
-Hochschule der Medien Stuttgart
-
-**Sommersemester 2026**
-
-[https://librete.ch/hdm/223015b/](https://librete.ch/hdm/223015b/)
-
---
-
-<!-- _header: '' -->
-<!-- _footer: '' -->
-
-![bg fit](./assets/qr/slides-223015b.png)
-
---
-
 <!-- _class: lead -->

-# Kapitel 5 – TBA
-## Vertiefung & Offene Fragen
+# 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)
+-->

 ---

-# Ersatztermin
+<!-- _header: '' -->
+<!-- _footer: '' -->

-**Dieser Termin wird noch bekannt gegeben.**
-
-Mögliche Inhalte:
- Vertiefung von Themen nach Wunsch
- Praxisübungen & Hands-On
- Offene Fragen & Diskussion
- Prüfungsvorbereitung
+![bg fit](./assets/demos/kap05-eroeffner.png)

 <!--
-Flexibler Termin für Nachholbedarf
-Themen nach Interesse der Studierenden
+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 -->

-# Fragen & Diskussion
+# Sub-Sektion A: Distribution — wie reist die Datei?

-**Kontakt:** lb-czechowski@hdm-stuttgart.de
-**Folien:** Online verfügbar unter https://librete.ch/hdm/223015b
+<!--
+Reihenfolge:
+1. CDN-Prinzip (Netflix-Beispiel)
+2. REST-APIs (Wetter-App fragt Daten ab)
+3. JSON als Datenformat
+-->

 ---

-# Lizenz & Attribution
+# CDN — Content Delivery Network

-Diese Präsentation ist lizenziert unter **Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)**
+**Idee:** Daten dort speichern, wo die Nutzer:innen sind.

- Erlaubt Teilen & Anpassen mit Namensnennung
- Adaptionen müssen unter gleicher Lizenz geteilt werden
+Statt von **einem zentralen Server** in Kalifornien wird die Datei von einem **Edge-Server** in eurer Nähe geliefert.

-Vollständige Lizenz: https://creativecommons.org/licenses/by-sa/4.0/
+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.
+-->