YouTube hat zwei populäre Kanäle dauerhaft gesperrt, die mit KI-generierten Fake-Trailern für noch nicht erschienene Filme Millionen Zuschauer angelockt hatten. Wie Deadline berichtet, traf es die Kanäle Screen Culture aus Indien und KH Studio aus Georgien. Zusammen hatten sie über zwei Millionen Abonnenten und mehr als eine Milliarde Views generiert.

Die Sperrung erfolgte wegen Verstößen gegen YouTubes Spam- und irreführende Metadata-Richtlinien. Die Kanäle hatten KI-generierte Trailer als echte Vorschauen ausgegeben, ohne diese ausreichend zu kennzeichnen. Zwar fügten die Betreiber zeitweise Hinweise wie „fan trailer“, „parody“ oder „concept trailer“ hinzu, entfernten diese aber laut Berichten später wieder, sobald die Videos Reichweite erzielt hatten.

Systematische Ausnutzung des YouTube-Algorithmus

Die Betreiber sollen dabei systematisch vorgegangen sein. Nikhil P. Chaudhari, Gründer von Screen Culture, beschäftigte ein Team von etwa zwölf Mitarbeitern. Sie kombinierten Ausschnitte aus offiziellen Trailern mit KI-generierten Bildern und nutzten den YouTube-Algorithmus gezielt aus. Für den Film „The Fantastic Four: First Steps“ lud Screen Culture beispielsweise 23 verschiedene Versionen eines Trailers hoch, von denen einige in den Suchergebnissen höher ausgespielt wurden als der offizielle Trailer. Ähnlich verfuhren die Kanäle bei der Harry-Potter-Serie von HBO oder „Wednesday“ von Netflix.

Besonders häufig nutzten die Kanäle Disney-Produktionen für ihre Fake-Trailer. Disney hatte erst kürzlich in einem Brief an Google massive Copyright-Verletzungen durch KI-Training und entsprechende Dienste vorgeworfen – explizit erwähnte der Konzern dabei auch YouTube. Parallel dazu hat Disney allerdings einen Lizenzdeal mit OpenAI geschlossen, der es der Video-KI Sora erlaubt, über 200 Disney-, Marvel- und Star-Wars-Charaktere einzusetzen. Ein anderer Ansatz: Warner Bros. Discovery und Sony forderten laut Deadline, dass die Werbeeinnahmen von KI-Videos mit ihren Inhalten direkt an sie fließen sollen.

Frühere Maßnahmen blieben erfolglos

Die beiden Kanäle waren YouTube bereits früher im Jahr 2025 aufgefallen. Laut Deadline hatte die Plattform damals den Kanälen die Möglichkeit genommen, Werbeeinnahmen zu kassieren. Nachdem Screen Culture und KH Studio daraufhin Kennzeichnungen wie „fan-made content“ hinzugefügt hatten, wurden sie wieder monetarisiert. Als sie die Labels später entfernten und zum alten Verhalten zurückkehrten, reagierte YouTube mit der permanenten Sperrung.

Weiterhin existieren andere Kanäle mit KI-Trailern, die fünf- bis sechsstellige Abonnentenzahlen aufweisen. Einige schützen sich durch deutliche Hinweise wie „fan-made content“. Ob diese Kennzeichnungen ausreichen, um Sperrungen zu vermeiden, bleibt abzuwarten.

YouTube selbst hat keine detaillierte Stellungnahme veröffentlicht, bestätigte gegenüber Deadline aber, dass die Rückkehr zu irreführenden Titeln und Beschreibungen gegen die Plattform-Richtlinien verstoße. Seit Juli 2025 geht YouTube verstärkt gegen solche Inhalte vor – massenproduzierte, repetitive oder KI-generierte Videos ohne erkennbaren Mehrwert können von der Monetarisierung ausgeschlossen werden.

KI-Fakes werden zum wachsenden Problem

Die Sperrung reiht sich in eine Serie von Vorfällen ein, bei denen KI-generierte Inhalte für Verwirrung oder Kritik sorgten. McDonalds Niederlande entfernte kürzlich einen KI-generierten Weihnachtswerbespot nach massiver Kritik. Ein KI-Video über einen angeblichen Staatsstreich in Frankreich erreichte Millionen Views auf Facebook, bevor es als Fake entlarvt wurde – selbst andere Staatschefs fielen darauf herein.

Welche KI-Tools Screen Culture und KH Studio konkret einsetzen, ist nicht bekannt. Infrage kommen Systeme wie Google Veo, OpenAI Sora 2 oder Kling AI, die Videos mit Ton erzeugen können. Ein Vergleichstest von heise online zeigte, dass insbesondere Sora 2 und Veo 3.1 visuell überzeugende Ergebnisse liefern, auch wenn sie noch mit Logikfehlern kämpfen.

(mki)

Die Entwickler rund um Lucas Holt haben MidnightBSD 4.0 freigegeben. MidnightBSD ist ein ursprünglich von FreeBSD 6.1 abgeleitetes BSD, das auf den Einsatz als Desktop-System fokussiert ist. Anfangs sahen die Entwickler einen auf GNUstep, Window Maker und GWorkspace basierenden grafischen Desktop vor, der MidnightBSD damals recht speziell und optisch schick erscheinen ließ. Seit 2021 sind sie auf den verbreiteten Xfce-Desktop umgestiegen.

(Alte) Neuigkeiten in MidnightBSD 4.0

Der Kernel unterstützt jetzt die W^X-Memory-Mapping-Policy für Benutzerprozesse. Diese Richtlinie ist standardmäßig nicht aktiviert, kann aber durch Setzen der sysctl-Variablen kern.elf32.allow_wx und kern.elf64.allow_wx eingeschaltet werden. Einzelne Programme können von dieser Richtlinie ausgenommen werden, indem sie mit elfctl(1) über die Funktion wxneeded entsprechend gekennzeichnet werden.

Die Funktion des Automount-Daemon amd(8) übernimmt nun autofs(5). NFS-Client und -Server unterstützen jetzt NFSv4.2, Extended Attributes sowie NFS über TLS, wobei für TLS zusätzliche Userland-Daemons mit einer KTLS-fähigen OpenSSL neu gebaut werden müssen. Außerdem erlaubt der NFS-Server bei -maproot und -mapall nun mehr als 16 Gruppen, und mit nfsv4_server_only=YES kann ein reiner NFSv4-Server ohne rpcbind(8) betrieben werden. Für einige moderne Intel-Netzwerkkarten sind Treiber hinzugekommen.

Durch mports(8) nicht kompatibel zu FreeBSD

Die Entwickler von MidnightBSD verwenden eigene Repositories und einen dazugehörigen Paket- und Port-Manager namens mport(8). Er wurde auf Version 2.7.3 aktualisiert und bietet nun besseres Fehler-Handling, schönere Terminalfarben und neue Prüf-/Reparaturfunktionen (mport verify).

Das native FreeBSD nutzt pkg(8) als binären Paketmanager, der vorgebaute Pakete aus offiziellen Repositories installiert, aktualisiert und entfernt. Die Ports-Sammlung erlaubt es dagegen, eben diese Software aus Quellcode mit eigenen Optionen zu bauen, wobei pkg(8) die daraus erzeugten Pakete anschließend wie gewohnt verwalten kann. Mit Poudriere lässt sich das unter nativem FreeBSD leicht automatisieren, während MidnightBSD auch hier mit Ravenports einen anderen und in der Praxis leider steinigen Weg beschreitet.

Die GPL-Versionen von grep(1) und des Device Tree Compiler dtc(1) wurden durch BSD-lizenzierte Varianten ersetzt und können so ohne Lizenzbestätigung automatisch installiert werden. Das historische Werkzeug ctm(1) (CVS-through-Mail), mit dem in Urzeiten Quellcode-Updates von BSD-Systemen per E-Mail-Diffs verteilt und eingespielt wurden, ist aus dem Basissystem in die mports verschoben worden.

MidnightBSD hinkt der FreeBSD-Entwicklung leider massiv hinterher

Spätestens bei der Ankündigung, dass ZFS von der nativen (in FreeBSD 12 verwendeten) auf die OpenZFS-Variante umgestellt wurde, wird klar, wie weit MidnightBSD der aktuellen Entwicklung hinterherhinkt:

  zfs version
   zfs-2.1.15-FreeBSD
   zfs-kmod-2.1.15-FreeBSD

Auch die Midnight-Implementation von Intel Speed Shift wurde in Windows und Linux bereits vor einer Dekade implementiert, FreeBSD selbst nutzt es seit November 2018 (FreeBSD 12). Insgesamt befindet sich MidnightBSD 4.0 damit irgendwo auf dem Stand von FreeBSD 13.5, das im April nächsten Jahres EoL sein wird. Die Installation ist in der Praxis problematisch, und auch die eigene mport(8)-Paketverwaltung zusammen mit Ravenports läuft nicht immer rund:

  mport upgrade
   Segmentation fault

Mit GhostBSD und NomadBSD gibt es zwei aktuelle Live-Systeme auf Basis von FreeBSD, die sich auch leicht fest installieren lassen. In Kürze werden beide auf FreeBSD 15 aktualisiert. MidnightBSD 4.0 ist darüber hinaus kein Live-System, das man vor der Installation ausprobieren kann, sondern ein Installer für ein BSD mit grafischem Desktop. Das kann ein natives FreeBSD mit dem Paket desktop-installer(1) ebenfalls – und sogar zuverlässiger und flexibler.

Ausblick

Im Dezember 2005 begann Lucas Holt mit der Entwicklung der wohl ältesten FreeBSD-Distributionen, die er nach seiner Katze Midnight benannte. Zwanzig Jahre später wirkt MidnightBSD leider ein wenig wie gefangen im Dornröschenschlaf. Schade, denn es stecken offensichtlich viel Arbeit und einige gute Ideen in dem System. MidnightBSD 4.0 ist ab sofort kostenlos auf der Projektseite verfügbar.

(fo)

Das europäische Satellitennavigationssystem Galileo hat Zuwachs durch zwei neue Satelliten bekommen. Ins All gebracht wurden sie von der europäischen Trägerrakete Ariane 6.

Start der Mission VA266 war am 17. Dezember um 6.01 Uhr unserer Zeit vom Startplatz Kourou im französischen Übersee-Departement Französisch-Guayana aus. An Bord hatte sie die Galileo-Satelliten SAT 33 und SAT 34, die das Bremer Raumfahrtunternehmen OHB gebaut hat.

Für die Mission war die Rakete mit zwei Boostern ausgestattet – diese Ariane 62 genannte Konfiguration sei eigens für Galileo entwickelt worden, sagte Toni Tolker-Nielsen, Leiter des Bereichs Raumtransporte bei der Europäischen Raumfahrtagentur (European Space Agency, ESA). Nach knapp vier Stunden habe die Ariane die beiden Satelliten in einer Höhe von etwa 23.000 Kilometern ausgesetzt, teilte Arianespace mit.

Höchster Flug der Ariane 6

Der fünfte Flug der Ariane war in doppelter Hinsicht eine Premiere: Es war der erste Start der Ariane 6 für das Galileo-Programm; der Erstflug der Rakete fand im Juli vergangenen Jahres statt. Zudem war es der bislang höchste Flug der Rakete.

Die beiden Satelliten sollen in etwa drei Monaten einsatzbereit sein. Dann wird die Galileo-Konstellation aus 29 aktiven Satelliten bestehen. Zwei weitere Starts der Ariane 6 mit je zwei Galileo-Satelliten an Bord sind laut ESA „in naher Zukunft geplant.“

In diesen Missionen werden die letzten vier Galileo-Satelliten der ersten Generation ins All gebracht. „Bald stehen die Galileo-Satelliten der zweiten Generation bereit, die noch genauere und zuverlässigere Ortungs-, Navigations- und Zeitbestimmungsdienste bieten werden“, sagte Francisco-Javier Benedicto Ruiz, Leiter des Bereichs Navigation bei der ESA.

(wpl)