Umgehung der Drosselung beim Herunterladen von YouTube-Videos

 (blog.0x7d0.dev)
6 Punkte von GN⁺ 2023-08-15 | 1 Kommentare | Auf WhatsApp teilen
  • Die YouTube-Datei-URL lässt sich über die API /youtubei/v1/player abrufen, aber beim direkten Herunterladen wird die Geschwindigkeit wegen einer inoffiziellen Download-Beschränkung extrem stark reduziert
  • Der seit Mitte 2021 an die URL angehängte n-Query-Parameter muss mit dem JavaScript-Algorithmus aus base.js umgewandelt werden; andernfalls drosselt YouTube die Geschwindigkeit stillschweigend
  • Selbst bei korrekter Verarbeitung von n wird die Download-Zeit an Länge und Größe des Videos angepasst; im Beispiel wird ein 1,5-GB-Video mit etwa 4,0 MB/s heruntergeladen
  • Mit dem HTTP-Header Range lässt sich die Datei in 10-MB-Stücke aufteilen und über neue Verbindungen abrufen, sodass jedes Stück schnell geladen werden kann, bevor die Drosselung greift
  • Die endgültige Datei muss aus separat bereitgestellten Video- und Audio-Streams mit ffmpeg zusammengeführt werden; yt-dlp, VLC media player, NewPipe und node-ytdl-core verwenden ähnliche Techniken

Ablauf zum Ermitteln der YouTube-Datei-URL

  • Die tatsächliche Medien-Datei-URL kann über einen Aufruf des Endpunkts /youtubei/v1/player abgerufen werden
  • Diese API gibt Videotitel, Beschreibung, Vorschaubild und Formatinformationen zurück; aus der Formatliste lässt sich die Datei-URL in der gewünschten Qualität auswählen
    • Die Beispiel-Video-ID ist aqz-KE-bpKQ
    • Im Request-Body stehen Werte wie videoId, context.client.clientName und context.client.clientVersion
    • Andere Werte im Objekt context sind Voraussetzungen, die von der API geprüft werden; zulässige Werte lassen sich durch Beobachten von Browser-Anfragen finden
  • Wenn man adaptiveFormats[0].url aus der API unverändert verwendet, ist der Download praktisch blockiert, weil er extrem langsam wird
    • Im Beispiel wird für eine 1,5-GB-Datei nur etwa 66,7 kB/s angezeigt
    • Die Geschwindigkeit ist meist auf 40–70 kB/s begrenzt
    • Das Herunterladen eines 10-Minuten-Videos kann dadurch etwa 6 Stunden und 30 Minuten dauern

Die erste Beschränkung durch den Parameter n

  • Seit Mitte 2021 fügt YouTube den meisten Datei-URLs den n-Query-Parameter hinzu
  • Dieser Wert muss mit dem JavaScript-Algorithmus aus base.js umgewandelt werden, das zusammen mit der Webseite ausgeliefert wird
  • YouTube verwendet den Wert n wie eine Challenge, um offizielle Clients von anderen zu unterscheiden
    • Fehlt n oder wird es nicht korrekt umgewandelt, wird die Download-Geschwindigkeit stillschweigend gedrosselt
  • Da der Umwandlungsalgorithmus verschleiert ist und sich häufig ändert, ist Reverse Engineering bei jeder Änderung in der Praxis unhandlich
  • Die Beispielimplementierung lädt base.js der aktuellen Player-Version herunter, extrahiert den Code zur n-Umwandlung und führt ihn dann mit dem ursprünglichen n-Wert aus
    • Die URL von base.js wird auf der YouTube-Embed-Seite gefunden
    • Per regulärem Ausdruck werden der Name der Challenge-Funktion und ihr Funktionskörper extrahiert
    • Mit vm.runInNewContext aus Node.js wird die Umwandlungsfunktion ausgeführt
    • Der n-Parameter der URL wird durch den umgewandelten Wert ersetzt

Geschwindigkeitsbegrenzung auch nach der n-Umwandlung

  • Wenn der Parameter n korrekt umgewandelt wird, verschwindet die anfängliche extreme Drosselung, aber YouTube setzt weiterhin eine variable Download-Beschränkung ein
  • Das Ausmaß der Begrenzung hängt von Größe und Länge des Videos ab und wird so angepasst, dass die Download-Zeit ungefähr die Hälfte der Videolänge beträgt
  • Würden Mediendateien immer so schnell wie möglich ausgeliefert, könnte das aus Sicht eines Streaming-Dienstes zu erheblicher Bandbreitenverschwendung führen
  • Im Beispiel wird die 1,5-GB-Datei mit etwa 4,0 MB/s heruntergeladen

Kleine Stücke per HTTP Range schnell abrufen

  • Der Kern des Umgehungsansatzes besteht darin, die Datei per HTTP-Header Range in viele kleine Bereiche aufzuteilen und herunterzuladen
  • Der Header Range gibt bei jeder Anfrage den abzurufenden Dateibereich an
    • Beispiel: Range: bytes=2000-3000
  • Der Beispielcode verarbeitet die Mediendatei in 10-MB-Segmenten
    • Eine vorhandene Ausgabedatei wird gelöscht
    • Auf Basis der bereits empfangenen Byte-Anzahl wird der nächste 10-MB-Bereich berechnet
    • Jede Anfrage enthält den Header Range und wird mit responseType: 'stream' empfangen
    • Die empfangenen Daten werden an das Dateiende angehängt
    • Fortschritt, Gesamtgröße und Segmentgeschwindigkeit werden ausgegeben
  • Das funktioniert, weil die Drosselungsregeln erst nach einiger Zeit greifen und kleine Segmente über eine neue Verbindung sehr schnell geladen werden können
  • In der Testausgabe für eine Datei mit 1464,99 MB erscheinen unter anderem folgende Geschwindigkeiten
    • Bei 0,68 %: 46,73 MB/s
    • Bei 1,37 %: 60,98 MB/s
    • Bei 2,05 %: 71,94 MB/s
    • Bei 6,14 %: 104,17 MB/s
  • Einige Downloads nutzten eine 1-Gb/s-Verbindung nahezu vollständig aus; die durchschnittliche Geschwindigkeit lag meist bei 50–70 MB/s, also 400–560 Mb/s

Zusammenführen von Video und Audio sowie bestehende Implementierungen

  • YouTube liefert Video- und Audiokanäle als separate Dateien aus
  • Diese Struktur spart Speicherplatz, weil HD- oder UHD-Videos dieselbe Audiodatei wiederverwenden können
  • Manche Videos bieten zusätzlich unterschiedliche Audiokanäle je nach Sprache an
  • Im letzten Schritt werden die Video- und Audiodatei mit ffmpeg zu einer Datei zusammengeführt
    • Mit -c copy werden die Streams ohne Re-Encoding kopiert
    • Mit -map 0:v:0 wird der Video-Stream aus der ersten Eingabe ausgewählt
    • Mit -map 1:a:0 wird der Audio-Stream aus der zweiten Eingabe ausgewählt
    • Nach dem Zusammenführen werden die temporären Video- und Audiodateien gelöscht
  • Der vollständige Beispielcode ist als youtube-download.js verfügbar
  • Mehrere Projekte verwenden ähnliche Techniken, um die YouTube-Beschränkungen zu umgehen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-08-15
Meinungen auf Hacker News

  • Soweit ich es in der Diskussion im yt-dlp-Repository gesehen habe, ließ sich diese Beschränkung nicht über den HTTP-Range-Header umgehen, sondern schon dadurch, dass man einen Query-Parameter range=xxx anhängt.
    Selbst wenn man den Bereich auf die gesamte Datei setzte, kam wieder die volle Geschwindigkeit heraus, und wenn ich mich richtig erinnere, hat YouTube diese Beschränkung inzwischen bereits aufgehoben.
    Siehe: https://github.com/yt-dlp/yt-dlp/issues/6400

  • Bei YouTube habe ich es nicht ausprobiert, aber Videos von dubioseren Streaming-Websites habe ich schon einmal mit den Webentwickler-Tools heruntergeladen.
    Meist nutzen sie Schutzmechanismen, bei denen beim Öffnen der Entwickler-Tools nicht überspringbare debugger-Anweisungen erzeugt werden und CPU-intensive Codeabschnitte laufen — vermutlich Endlosschleifen oder Krypto-Miner —, sodass das Video angehalten wird.
    Wichtiger ist, dass dieser Code auch die Informationen zu Netzwerk-Requests löscht und damit die Analyse des bis dahin gesendeten Traffics erschwert; Firefox’ „Logs beibehalten“ sollte die Logs wirklich beibehalten.
    Ein perfekter Schutz ist es nicht, am Ende gab es kein Video, das ich nicht bekommen hätte, aber ich würde gern Material sehen, das diese Funktionsweise genauer erklärt.

    • Vor Kurzem gab es einen Beitrag, der genau diese Methode umging, und die Lösung war einfach, aber effektiv: Den Browser neu bauen und dabei den Namen des debugger-Keywords ändern.
      Das war schon fast zum Lachen.
      https://news.ycombinator.com/item?id=36961445
    • Um solche Anti-Debugging-Techniken zu umgehen, ist Anti-Anti-Debug [0] einen Versuch wert.
      Aus einem ähnlichen Grund habe ich diese einfache Erweiterung früher in ein paar Stunden gebaut.
      0: https://chrome.google.com/webstore/detail/anti-anti-debug/mn...
    • Dass eine Seite überhaupt erkennen kann, ob die Entwickler-Tools geöffnet sind, wirkt für mich wie ein großer Fehler auf Browser-Seite.
      Eine Webseite sollte niemals herausfinden können, ob die Entwickler-Tools geöffnet sind, und das sollte sich eigentlich korrekt implementieren lassen.
    • Eine Methode, die in Firefox manchmal funktioniert, ist beim Video Shift+Rechtsklick → This Frame → Open Frame in New Tab zu wählen.
      Im neuen Tab funktionieren die Entwickler-Tools.
    • Wenn eine Seite versucht, die Browser-Entwickler-Tools zu erkennen, würde ich für die Traffic-Analyse zuerst an Wireshark denken.

  • In der Endphase wird man wohl mit WorldCoin bezahlen müssen, um weiter auf den Bildschirm schauen zu dürfen, und diesen nicht handelbaren WorldCoin wird man nur verdienen können, indem man Werbung ansieht.
    Ein kleiner, im Bildschirm eingebauter Orb überwacht das dann; ihr habt doch nicht wirklich geglaubt, dass es dabei um Grundeinkommen geht.
    Das Problem Grundeinkommen wurde schon vor langer Zeit mit Bankkonten und Know Your Customer (KYC) gelöst.

    • Hat das gar nichts mit Augen zu tun?

  • Ich frage mich, ob derzeit noch jemand Probleme mit der yt-dlp-Drosselung hat.
    Ich schaue YouTube immer mit mpv, das intern yt-dlp nutzt, und seit letzter Woche ist der Zustand ziemlich schlecht geworden.
    Anfangs startet es so schnell, wie ich es mit 500 kB/s begrenzt habe, aber nach einer Weile werden in 3 Sekunden Download nur noch 1 Sekunde Wiedergabe geladen, sodass ich es vor dem Abspielen lange in die Warteschlange legen muss.
    Ich nutze die Git-Version von yt-dlp, habe aber kein entsprechendes Issue gesehen.

    • mpv holt sich über yt-dlp nur die Video-URL und reicht diese URL an ffmpeg weiter.
      ffmpeg implementiert den Workaround rund um den Range-Header nicht und läuft deshalb in die Drosselung.
      Man kann yt-dlp direkt herunterladen lassen und das Ergebnis per Pipe an mpv übergeben, damit es von der Standardeingabe abspielt, aber dann geht das Springen zu noch nicht heruntergeladenen Stellen kaputt.
      Im Issue-Tracker von mpv gibt es viele Issues zu diesem Problem.

  • YouTube ändert in diesem Prozess ständig kleine Details.
    Früher habe ich ein internes Bearbeitungstool für YouTube-Videos gebaut, das MP4-Dateien brauchte, und ungefähr einmal im Monat ging der Editor wegen einer YouTube-Änderung kaputt, sodass ich im Debugger nachsehen musste, was sich geändert hatte, und es anpassen musste.

  • Ein kleiner Abstecher, aber ich frage mich, ob es Einbildung ist, dass Videos auf YouTube ein ganz klein wenig besser aussehen
    Ich lade mir Videos herunter, die ich gern schaue, und sehe sie in VLC oder Infuse auf dem Apple TV an; über YouTubes „nerd stats“ kann ich bestätigen, dass ich denselben Video-/Audiostream anschaue
    Trotzdem wirkt es so, als würde YouTube einen sehr subtilen Filter anwenden, der blockartige Kompressionsartefakte weicher erscheinen lässt
    Es ist nicht so, dass Kanten nachgeschärft würden; eher scheint es Bereiche mit Farbverläufen ohne Kanten zu finden und blockartige Artefakte weniger auffällig zu machen
    Vielleicht ist es Einbildung, aber auf YouTube wirkt das Bild lebendiger und stabiler, während ich bei der heruntergeladenen Version in Hintergründen oder Schatten sehr subtile, aber sichtbare Artefakte und leichtes Zittern sehe, sodass selbst 1440p-Videos am Ende weniger gut aussehen
    Auch beim Ton ist der Unterschied deutlich: YouTube hat meist eine gleichmäßige Lautstärke, während ich bei heruntergeladenen Videos die Lautstärke hochdrehen muss, was umständlich ist
    Ich wünschte, VLC oder Infuse würden Videos ähnlich wie YouTube angenehmer aufbereiten; es scheint weniger um Farb- oder Schärfefilter zu gehen, sondern eher um etwas wie Audio-Leveling, das das Erlebnis kanalübergreifend konsistent macht

    • Zum Audio kann ich etwas sagen
      Die meisten Streamingseiten wie YouTube und Spotify verwenden etwas namens ReplayGain
      Das ist ein Tag, der die durchschnittliche Lautstärke eines Videos oder Songs berechnet und beim Upload ermittelt wird
      Der offizielle YouTube-Client nutzt dieses Tag bei der Wiedergabe, um die Lautstärke anzupassen; beim Herunterladen kann das Tag aber fehlen, oder MKV unterstützt ReplayGain-Tags möglicherweise nicht standardmäßig
    • Die vom Player verwendeten Scaling-Filter und die Art des Chroma-Scalings beeinflussen die Schärfe
      Wenn man einen Stream in Originalauflösung im Vollbild abspielt, sollten Unterschiede an Schwarz-Weiß-Kanten verschwinden
      Je nach Betriebssystem kann man den Unterschied testen, indem man schnell zwischen zwei Vollbild-Apps umschaltet; ISO 29170-2 empfiehlt dafür 5 Hz
      Farbveränderungen können vom Farbraum des Videos oder von fehlerhafter Verarbeitung des Monitorprofils kommen; in diesem Fall kann ein Screenshot anders aussehen als das tatsächliche App-Bild
      Zittern kann durch Frame Drops entstehen, und wenn an den Kanten farbiger Objekte Pixelbildung zu sehen ist, liegt wahrscheinlich Nearest-Neighbor-Chroma-Upscaling vor
    • Ein einzelnes YouTube-Video besteht aus mehreren Video-, Audio- und kombinierten Streams
      Der vom Browser gewählte Stream kann sich von dem unterscheiden, den youtube-dl oder ein Fork standardmäßig auswählt
      Früher wurde eine Zeit lang standardmäßig der beste kombinierte Stream gewählt, aber getrennte beste Audio- und Videostreams haben eine höhere Qualität
    • Player wie VLC können es besser machen, und man kann mit GLSL auch eigene Korrekturen bauen
      Besonders mag ich das Shader-Paket anime4k; es basiert auf Machine Learning, läuft aber in mpv in Echtzeit und dürfte vermutlich auch in VLC funktionieren
      Wie der Name andeutet, ist es auf Animationen abgestimmt, aber Rausch- und Unschärfereduktion sind ordentlich, sodass YouTube-Inhalte oft besser aussehen, und die Rekonstruktionsstufe geht ziemlich gut mit Kompressionsartefakten um
      Allerdings ist es stark auf Animationen zugeschnitten, funktioniert also nicht immer gut und kann es sogar verschlechtern
      https://github.com/bloc97/Anime4K/releases
    • Die Videopipeline des Browsers kann sich von der unterscheiden, die VLC verwendet
      Man kann zum Vergleich ein einfaches HTML-Dokument mit einem video-Element erstellen, das auf eine lokale Datei zeigt

  • Ich bin jedes Mal überrascht, wenn YT wieder eine halbherzige Maßnahme gegen Downloader ausrollt
    GOOG besitzt doch auch Widevine; ich frage mich, warum sie es nicht einsetzen

    • Die Softwareversion von Widevine wäre innerhalb kürzester Zeit vollständig geknackt und ließe sich sogar mit Ein-Klick-Download-Add-ons umgehen
      Für Nutzer würde sich nichts ändern, und YouTube hätte nur den Betriebsaufwand für Widevine
      Wenn sie die hardwarebasierte Version einsetzen, kann das auf nicht unterstützten Geräten viele Probleme verursachen
    • YouTube scheint sich nicht besonders darum zu kümmern, ob Inhalte raubkopiert oder Third-Party-Clients verwendet werden
      Worum es ihnen geht, ist verschwendete Bandbreite
      Bei werbefinanzierten Video-Streamingseiten sind die Bandbreitenkosten normalerweise höher als die Einnahmen; Google bekommt Bandbreite nur deshalb so billig, dass es gerade aufgeht, weil es ISPs zu kostenlosem Peering drängen kann
      Solche Geschwindigkeitsbegrenzungen sollen den Großteil der Bandbreite echten Nutzern überlassen, nicht Leuten, die sämtliche Inhalte abgrasen
    • Sie verwenden Widevine nicht, weil es durch den zusätzlichen Entschlüsselungsschritt langsam ist, Software-Videodecoding erzwingt und damit langsam ist, und weil Webbrowser nur die schwächste Form von Widevine unterstützen, die wenig bewirkt
      Es wäre nicht besonders effektiv, um das Ziel zu erreichen, und würde zugleich wahrscheinlich viele Nutzer von der Plattform drängen
    • Der Hauptgrund ist, dass es die CDN-Cache-Effizienz etwas verschlechtert und damit Kosten verursacht, außerdem müsste ein zusätzliches Key-Management-System betrieben werden
      In der Größenordnung von YouTube möchte man solche Systeme so weit wie möglich reduzieren
      Außerdem würde man Widevine Level 3 zu einem sehr großen Angriffsziel machen
      Am Ende ist es eine finanzielle Gleichung: Das durch Adblocking verlorene Geld reicht noch nicht, um den Widevine-Schalter umzulegen, aber es reicht für schwächere Maßnahmen; zudem dürfte es Druck von Musiklabels geben, sodass eine breitere Einführung in den nächsten Jahren möglich ist
      Meine Prognose: Zuerst beginnt es mit Videos, die von Content ID erkannte Label-Musik oder Studio-Clips enthalten, und für andere Creator könnte es ein optionales Tag geben
      Solche Videos sind für die Monetarisierung nützlicher, und man verliert nicht auf einen Schlag die CDN-Vorteile
    • Google möchte Third-Party-Clients wahrscheinlich eindämmen, zugleich aber zulassen, dass Leute Dinge archivieren
      Solche halbherzigen Maßnahmen im Stillen zu ergreifen, ist die perfekte und einzige Lösung, um dieses Ziel zu erreichen

  • Ich habe mich immer gefragt, wie YouTube seine Videos ausliefert
    Selbst wenn das Internet mies war, funktionierte es gut; in Südamerika laufen längst nicht alle Plattformen zuverlässig, aber YouTube ist die mit Abstand reibungsloseste Videoplattform
    Am nächsten kommt noch Netflix, liegt aber immer noch deutlich zurück

    • Sie platzieren Cache-Server im Netz des ISP in der Nähe deines Zuhauses
      Für den ISP ist das ebenfalls vorteilhaft, deshalb erlaubt er es
      Der Engpass eines ISP ist die Verbindung vom eigenen Netz hinaus ins breitere Internet-Backbone, und Cache-Server großer CDNs nehmen diesem Engpass viel Last ab
      Dokumentation zu einer ähnlichen Konfiguration bei Netflix: https://openconnect.netflix.com/

  • Haben Sie schon einmal versucht, ein Video direkt von YouTube herunterzuladen?
    Wenn man es manuell macht, ohne sich auf youtube-dl, yt-dlp oder solche Websites zu verlassen, ist es viel komplizierter, als man denkt.

    • Vor sehr langer Zeit habe ich einmal an einem Perl-Skript gearbeitet, das genau so etwas machte: https://www.perlmonks.org/?node_id=636777
      Das Problem solcher Skripte ist natürlich, dass man ständig den Änderungen hinterherlaufen muss, mit denen YouTube das Herunterladen von Videos verhindern will.
    • Ich löse das, indem ich direkt ein Userscript injiziere.
      Mit Blick auf WEI ist das ein Ansatz, der meinen USER AGENT nutzt und vielleicht nicht mehr lange funktionieren wird.
      Statt mich abzumühen, Signaturen, n-Decoding und Rate-Limiting-Funktionen neu zu implementieren, suche ich player.js mit match(/(?:player\/([a-zA-Z0-9_-]+)\/)?(?:html5player|(?:www|player(?:_ias)?))[-\.]([^/]+?)(?:(?:\/html5player(?:-new)?)?|(?:\/[a-z]{2,3}_[A-Z]{2})?\/base)\.js/), greppe darin die relevanten Funktionen heraus und rufe sie direkt auf.
      Aus Sicht von YouTube könnte man sagen, dass die eigenen DRM-Funktionen mir den .mp4-Link öffnen – das wirkt also zu 100 % legitim.
    • Meinen Sie die Variante, bei der man auf den „Download“-Button klickt und für Premium bezahlt?

  • Technisch ist das alles interessant, aber wenn man ethisch nicht nur „Scheiß auf Google“ denkt, fühlt es sich vernünftig an, bei der ersten Optimierung aufzuhören: also die echte Browser-Prüfung zu bestehen und normale Browser-Geschwindigkeit zu bekommen.
    Damit verschwendet man nicht mehr YouTube-Ressourcen als Nutzer eines Browsers mit Adblocker.
    Ohne irgendetwas zu bezahlen die volle Gb/s-Geschwindigkeit auszunutzen, fühlt sich an, als würde man das Glück aller Adblock-Nutzer aufs Spiel setzen.
    Natürlich kann es am Ende trotzdem heißen: Scheiß auf Google.

    • Technisch gesehen zahlen alle für ihre Netzwerkanbindung.
      Ich würde nicht so weit gehen, zu sagen, dass es unethisch ist, YouTube mit maximaler Geschwindigkeit zu belasten, aber ich würde YouTube auch nicht dafür kritisieren, Gegenmaßnahmen zu ergreifen.
      Ich nutze eine Browser-Erweiterung, die Bilder in sozialen Medien beim Darüberfahren in Originalgröße anzeigt, und Instagram hat mir eine Warnung vor ungewöhnlicher Aktivität und die Drohung einer Kontosperre angezeigt.
      Ich habe geprüft, ob die Erweiterung im Hintergrund Scraping betreibt, aber es sah unproblematisch aus; vermutlich sieht Meta nur eine andere Reihenfolge der Requests als beim Standard-Client und wertet das als Data Scraping.
      Es ist ein Hin und Her aus Maßnahmen und Gegenmaßnahmen, und auch YouTube wird seine Gegenmaßnahmen implementieren und Scraper dazu bringen, erneut zu reagieren. Da legitimer Konsum im offiziellen Client aber niemals schneller als mit doppelter Wiedergabegeschwindigkeit läuft, wird man Downloads irgendwann wohl auf ungefähr dieses Niveau begrenzen können.
      Trotzdem finde ich, dass Downloads an sich nicht eingeschränkt werden sollten.
      Inhalte sind bereits gesetzlich geschützt, und die meisten laden Videos aus legitimen Gründen herunter, etwa zur Archivierung, Analyse oder zur Erstellung von Review-Videos.
      YouTube-Inhalte entstehen nicht im luftleeren Raum; nachdem sie veröffentlicht wurden, schaffen sie ein Umfeld, in dem neue Videos entstehen können. Deshalb ist diese künstlerische Freiheit wichtig.
    • Ich bin mir nicht sicher, wie sehr das wirklich Missbrauch ist.
      Am Ende erhält man nur dieselbe Datenmenge in kürzerer Zeit; man nutzt also mehr Bandbreite, ist aber schneller wieder weg.
      Der normale Browser-Anwendungsfall scheint auf die häufige Situation optimiert zu sein, dass man ein Video nicht bis zum Ende schaut.
      Wenn man von Anfang an das ganze Video ansehen und aufbewahren will, verbraucht man dadurch schwerlich mehr Bandbreite von Google; höchstens der Overhead kann wegen der Anzahl der Verbindungen größer sein.
    • Unternehmen haben keine Ethik, sondern nur Interessen.
      Dass ich mich ähnlich verhalte, ist naheliegend.
    • Man spricht zwar von YouTube-Ressourcen und Gb/s, aber in den meisten Fällen wird das Video innerhalb desselben ISP-Netzes ausgeliefert.
      Das liegt daran, dass YouTube bei fast allen ISPs und Internet Exchanges weltweit Caches betreibt – vielleicht ist es das größte CDN, das je gebaut wurde.
      Die YouTube-URL des Autors verweist zum Beispiel auf den kanadischen ISP Videotron.
      https://bgp.he.net/dns/rr1---sn-8qu-t0aee.googlevideo.com
    • Technisch sollte man Videos herunterladen können, und das sollte nicht blockiert werden.
      Das ist schon nötig, um Beweise zu sichern, wenn jemand Hassrede verbreitet oder mich und meine Familie beleidigt.
      Man könnte den Bildschirm auch mit einem Camcorder abfilmen, aber das klingt nach einer Lösung aus der Steinzeit.
      Auf dem Mac kann man zum Beispiel in Netflix im Browser keine Screenshots machen, sodass einem sogar die Meme-Erstellung, die unter Fair Use fällt, genommen wird.