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
This commit is contained in:
@@ -5,7 +5,7 @@ paginate: true
|
|||||||
backgroundColor: #fff
|
backgroundColor: #fff
|
||||||
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
header: "Dateiformate, Schnittstellen, Speichermedien & Distributionswege (223015b)"
|
||||||
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
footer: "Michael Czechowski – HdM Stuttgart – SoSe 2026"
|
||||||
title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
title: Distribution und Metadaten
|
||||||
---
|
---
|
||||||
|
|
||||||
<style>
|
<style>
|
||||||
@@ -14,31 +14,18 @@ title: Dateiformate, Schnittstellen, Speichermedien & Distributionswege
|
|||||||
--color-highlight: #1e5f8a;
|
--color-highlight: #1e5f8a;
|
||||||
--color-dimmed: #4a4a6a;
|
--color-dimmed: #4a4a6a;
|
||||||
}
|
}
|
||||||
section.invert {
|
section.invert { --color-foreground: #fff; }
|
||||||
--color-foreground: #fff;
|
section { font-size: 1.7rem; }
|
||||||
}
|
h1 { color: #1e5f8a; }
|
||||||
section {
|
section.invert h1 { color: #fff; }
|
||||||
font-size: 1.7rem;
|
h2 { color: #1f2937; }
|
||||||
}
|
|
||||||
h1 {
|
|
||||||
color: #1e5f8a;
|
|
||||||
}
|
|
||||||
section.invert h1 {
|
|
||||||
color: #fff;
|
|
||||||
}
|
|
||||||
h2 {
|
|
||||||
color: #1f2937;
|
|
||||||
}
|
|
||||||
pre {
|
pre {
|
||||||
background: #0f0f23;
|
background: #0f0f23;
|
||||||
color: #5fb3e4;
|
color: #5fb3e4;
|
||||||
border-radius: 8px;
|
border-radius: 8px;
|
||||||
border-left: 3px solid #1e5f8a;
|
border-left: 3px solid #1e5f8a;
|
||||||
}
|
}
|
||||||
pre code {
|
pre code { background: transparent; color: inherit; }
|
||||||
background: transparent;
|
|
||||||
color: inherit;
|
|
||||||
}
|
|
||||||
code {
|
code {
|
||||||
background: #0f0f23;
|
background: #0f0f23;
|
||||||
padding: 0.15em 0.4em;
|
padding: 0.15em 0.4em;
|
||||||
@@ -47,9 +34,7 @@ code {
|
|||||||
}
|
}
|
||||||
section code:not(.hljs) { color: #5fb3e4 !important; }
|
section code:not(.hljs) { color: #5fb3e4 !important; }
|
||||||
section code.hljs { color: #f8f8f8 !important; }
|
section code.hljs { color: #f8f8f8 !important; }
|
||||||
a {
|
a { color: var(--color-highlight); }
|
||||||
color: var(--color-highlight);
|
|
||||||
}
|
|
||||||
section.klausur {
|
section.klausur {
|
||||||
background: repeating-linear-gradient(
|
background: repeating-linear-gradient(
|
||||||
135deg,
|
135deg,
|
||||||
@@ -60,83 +45,585 @@ section.klausur {
|
|||||||
) !important;
|
) !important;
|
||||||
}
|
}
|
||||||
@media print {
|
@media print {
|
||||||
section.klausur {
|
section.klausur { background: #e3f2fd !important; }
|
||||||
background: #e3f2fd !important;
|
|
||||||
}
|
|
||||||
}
|
|
||||||
section.aufgabe {
|
|
||||||
background: #e3f2fd !important;
|
|
||||||
}
|
|
||||||
section.aufgabe footer {
|
|
||||||
display: none;
|
|
||||||
}
|
}
|
||||||
|
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>
|
</style>
|
||||||
|
|
||||||
<!-- _class: invert -->
|
|
||||||
<!-- _header: '' -->
|
|
||||||
<!-- _footer: '' -->
|
|
||||||
<!-- _backgroundColor: #000 -->
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
# 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: '' -->
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
<!-- _class: lead -->
|
<!-- _class: lead -->
|
||||||
|
|
||||||
# Kapitel 5 – TBA
|
# Kapitel 5
|
||||||
## Vertiefung & Offene Fragen
|
## 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
|
|
||||||
|
|
||||||
<!--
|
<!--
|
||||||
Flexibler Termin für Nachholbedarf
|
Eine Datei reist + erzählt. Smartphone-Foto Stuttgart → Tokyo zeigt drei Schichten:
|
||||||
Themen nach Interesse der Studierenden
|
|
||||||
|
- 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 -->
|
<!-- _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
|
Statt von **einem zentralen Server** in Kalifornien wird die Datei von einem **Edge-Server** in eurer Nähe geliefert.
|
||||||
- Adaptionen müssen unter gleicher Lizenz geteilt werden
|
|
||||||
|
|
||||||
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.
|
||||||
|
-->
|
||||||
|
|||||||
Reference in New Issue
Block a user