Künstliche Intelligenz
VR-Brillen der 90er und 2000er: Ohne sie gäbe es heute keine Meta Quest
Nach den großen Konsolen- und Spielwarenherstellern Nintendo, Atari, Sega und Hasbro wagten sich in den Jahren nach dem ersten VR-Hype Anfang der 1990er mehrere Unternehmen an ein riskantes Unterfangen: Sie wollten Virtual Reality von den Arcade-Hallen in die Wohnzimmer bringen – erschwinglich, tragbar und für den Massenmarkt konzipiert. Doch fast alle dieser frühen VR-Headsets scheiterten an der Technik, am Preis oder an der fehlenden Nachfrage. Die Geschichte dieser Geräte ist allerdings nicht nur eine Geschichte des Scheiterns, sondern zugleich eine Chronik notwendiger Irrwege, die den späteren Erfolg moderner VR-Systeme vorbereiteten. Wir blicken zurück auf die VR-Ära vor Oculus Rift, Valve Index und HTC Vive.
Weiterlesen nach der Anzeige
VictorMaxx StuntMaster: Der erste Versuch
Den Anfang machte die Firma VictorMaxx mit der „StuntMaster“ schon 1993. Das Headset gilt als das erste kommerzielle VR-Gerät für den Heimgebrauch. Für rund 219 US-Dollar konnte es an gängige Konsolen wie das Super Nintendo oder Segas Mega Drive angeschlossen werden. Technisch war die StuntMaster jedoch kaum mehr als ein Gimmick: Eine einzelne, niedrig aufgelöste LCD-Anzeige (etwa 160 × 120 Pixel) erzeugte ein flaches Bild ohne echten 3D-Effekt. Dazu registrierte ein umständlich an der Seite angebrachter Stab Kopfbewegungen, übersetzte diese aber lediglich in Links- und Rechtsbefehle, als wäre der Kopf ein Joystick.

So wurde die „Stuntmaster“ von VictorMaxx 1993 beworben.
(Bild: Retro Scan of the Week)
Stereoskopie, Positionsverfolgung oder echte Immersion bot das System nicht. Die Bildqualität war schwach, das Sichtfeld eng, der Ton blechern und das Tragen der Brille unangenehm. Viele Nutzer klagten über Unwohlsein und Kopfschmerzen. Spezielle Software gab es praktisch nicht, und die Integration in bestehende Spiele war nur oberflächlich. Nach kurzer Zeit verschwand die „StuntMaster“ vom Markt, doch sie markierte einen frühen Meilenstein: Erstmals war VR-Hardware für Konsolenbesitzer verfügbar, auch wenn sie kaum hielt, was sie versprach.
CyberMaxx: Techniksprung ohne Markt
VictorMaxx ließ sich jedoch nicht beirren und legte 1994 mit der „CyberMaxx“ nach, einer deutlich weiterentwickelten VR-Brille mit zwei LC-Displays und stereoskopischem 3D-Bild. Die Auflösung lag bei 505 × 230 Pixel pro Auge, was für die damalige Zeit beachtlich war. Headtracking war zwar vorhanden, allerdings funktionierte es vor allem zur Steuerung von Kamera oder Mauszeigern. Der Preis: stolze 699 US-Dollar.
Trotz verbesserter Technik blieb der Erfolg aus. Nur wenige Spiele unterstützten das Headset nativ, und auch als universelle Anzeigeeinheit war es zu teuer. 1995 erschien mit der „CyberMaxx 2.0“ eine überarbeitete Version mit erweiterten Anschlussmöglichkeiten. Doch auch CyberMaxx war kein Erfolg vergönnt, und VictorMaxx verschwand kurz darauf vom Markt.
Weiterlesen nach der Anzeige
iGlasses von Virtual i-O: Ambition trifft Realität
Im Mai 1995 erschien die VR-Brille, die den eigentlich viel passenderen Namen für die knapp 30 Jahre später erscheinende Apple Vision Pro belegte: Die „iGlasses“ des Start-ups Virtual i-O waren eines der technisch ausgereiftesten VR-Headsets dieser Ära. Für 499 US-Dollar bot das Gerät zwei LCDs mit VGA-Auflösung in stereoskopischer Darstellung (je 640 × 480 Pixel). Zwei Varianten standen zur Auswahl: eine für Composite-Videoquellen wie Spielekonsolen, VHS- oder später DVD-Player, und eine PC-Version mit integriertem Headtracking. Die Bildqualität war dank der hohen Auflösung deutlich besser als bei älteren Geräten. Auch der Tragekomfort war höher und die Brille leichter.
heise online XR-Briefing abonnieren
Jeden zweiten Montag, liefern wir Ihnen die wichtigsten Entwicklungen der XR-Branche. Damit Sie alles im Blick behalten.
E-Mail-Adresse
Ausführliche Informationen zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten erhalten Sie in unserer Datenschutzerklärung.
Die Video-Version diente vor allem als persönliche „Großbildleinwand“, wie sie heute Display-Brillen von Viture oder Xreal anbietet. In der PC-Ausführung lieferten die „iGlasses“ hingegen mehr „VR-Feeling“ durch Kopfsteuerung der Kamera. Trotz guter Kritiken blieb der kommerzielle Erfolg aus. Der Umsatz lag 1995 bei rund fünf Millionen Dollar und damit weit unter dem erhofften Potenzial. Zwar verdoppelte sich der Absatz 1996, doch das Produkt blieb ein Nischenphänomen. Kurioserweise entfiel rund ein Viertel der Verkäufe auf Zahnarztpraxen, die das Gerät zur Ablenkung von Patienten nutzten. Die Konsumenten hingegen zögerten vor allem wegen des Preises und der geringen Softwarebasis. 1997 folgte die Insolvenz.
Forte VFX1: Der „High-End-PC-Helm“
Ebenfalls 1995 erschien mit dem VFX1 Headgear von Forte Technologies ein VR-Helm für ambitionierte PC-Nutzer. Für rund 695 US-Dollar bot das System zwei 0,7-Zoll-Displays mit 263 × 230 Pixeln, Stereo-Audio, Mikrofon und Headtracking in drei Achsen (Drehung, Neigung, Kippen). Ein spezieller Controller namens „CyberPuck“ ergänzte das System.
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.
Linus Tries VR From 1994
Der Helm gilt trotz seines Gewichts von rund einem Kilogramm als überraschend bequem, erforderte allerdings den Einbau einer proprietären ISA-Steckkarte sowie umfangreiche Konfiguration. Offiziell sollen zwar über 100 Spiele die VR-Brille direkt unterstützt haben – darunter „Descent“ und „Quake“. Allerdings gab es nur eine Handvoll Spiele, die wirklich stereoskopisches 3D lieferten. Viele Nutzer experimentierten mit dem „VR-Mausmodus“ unter Windows, doch die große Softwarebasis fehlte und somit ein überzeugender Grund, den PC aufwendig umzurüsten. 1997 übernahm Interactive Imaging Systems (IIS) die Technik von Forte und entwickelte sie weiter.
VFX3D: Später Versuch mit modernisierter Technik
Um 2000 versuchte ILS mit dem VFX3D, die Technologie des VFX1 zu modernisieren, und erhöhte die Auflösung auf 380 × 337 Pixel pro Auge und die Bildrate auf 75 Hz. Erstmals war auch eine gewisse Vor- und Rückwärtsbewegung im Raum möglich, wenn auch noch ohne echtes Positionstracking. Allerdings blieb die Softwarebasis ähnlich begrenzt wie beim Vorgänger. ILS zielte primär auf professionelle Anwender, denn der VR-Konsumentenmarkt war zu diesem Zeitpunkt praktisch tot. Auch wenn die VFX3D kein Erfolg war, blieb der Hersteller als einer der wenigen weiter in der Branche aktiv. Aus IIS wurde später der Smartbrillen-Hersteller Vuzix, der auch heute noch spezialisierte Geräte für die Industrie anbietet.
Takara Dynovisor & Philips Scuba: Atari-Erbe ohne Tracking
Eine Besonderheit sind die Headsets „Dynovisor“ von Takara und „Scuba Visor“ von Philips, die zwischen 1996 und 1998 erschienen. Beide basierten auf einem VR-Headsetprototyp, den Virtuality ursprünglich für die Atari Jaguar-Konsole entwickelt hatte. Deren Technologie wurde von Philips und Takara übernommen und leicht angepasst.
Beide Geräte nutzten Sonys TFT-LCDs mit etwa 263 × 230 Pixeln pro Auge, boten aber ein sehr geringes Sichtfeld von ungefähr 50 Grad. Headtracking fehlte vollständig. Dennoch erzeugten sie in Filmen oder Spielen ein für damalige Verhältnisse eindrucksvolles, riesiges Bild. Der Preis lag bei etwa 300 US-Dollar und Philips verkaufte angeblich rund 55.000 Exemplare. Damit können die „Scuba Visors“ zwar als Achtungserfolg gewertet werden, sie waren aber weit entfernt von einem Massenmarktprodukt. Ein Grund für das Scheitern dürften die immer wieder aufkommenden Beschwerden über Augenbelastung und fehlende Inhalte gewesen sein.
Z800 und Trimersion: Der letzte Atemzug vor Oculus
In den 2000er-Jahren erschienen noch zwei weitere VR-Brillen, bevor Palmer Luckey mit seinem Start-up „Oculus“ den Grundstein für den heutigen VR-Markt legte. 2005 brachte eMagin den „Z800 3DVisor“ auf den Markt, ein Headset mit OLED-Displays, 800 × 600 Pixeln, 3-DoF-Tracking und USB-Anschluss. Der „Z800 3DVisor“ diente allerdings mehr als persönlicher Bildschirm und verzichtete auf komplette Bewegungserfassung. Der Preis von 899 US-Dollar zum Launch war zu hoch für die nach wie vor kleine Zielgruppe.
2006 folgte das Trimersion-Headset, ein kabelloses System für Ego-Shooter mit Kopftracking und einer Lightgun als Controller. Die Idee: Spieler sollten mit dem Kopf zielen und mit einem Stick an der Plastikpistole laufen. In der Praxis erwies sich das Konzept als unpraktisch, und viele Tester berichteten von Nackenverspannungen und Orientierungsproblemen. Auch hier blieb der Erfolg aus und die Firma verschwand kurz darauf vom Markt.
Scheitern mit Lerneffekt
Die VR-Brillen der 90er und frühen 2000er waren technisch und konzeptionell unterschiedlich, aber sie scheiterten fast alle aus denselben Gründen: zu geringe Auflösung, zu hoher Preis, fehlende Inhalte und mangelnder Komfort. Viele Nutzer reagierten mit Ablehnung, und der Begriff „Virtual Reality“ war innerhalb der Tech-Branche jahrelang negativ konnotiert. Und doch hinterließen diese Geräte Spuren: Sie zeigten, was nötig ist, damit Virtual Reality funktioniert, und was nicht.
2012 griff der VR-Neustart durch ein Kickstarter-Projekt der Oculus-Gründer genau diese Lehren auf: höhere Auflösung, breites Sichtfeld, präzises Tracking, vertretbarer Preis und eine wachsende Softwarebasis. Die gescheiterten Systeme von damals waren also keine Sackgasse, sondern notwendige Schritte auf dem Weg zur heutigen VR.
(joe)
Künstliche Intelligenz
Eigene Passkeys (ohne US-Cloud) | c’t 3003
Passkeys versprechen mehr Sicherheit als Passwörter: Der private Schlüssel bleibt auf dem Gerät, Phishing läuft ins Leere. Doch Apple, Google und Microsoft binden die Passkeys ans eigene Ökosystem – wer einen iPhone-Passkey hat, steht am Windows-Rechner dumm da. c’t 3003 zeigt zwei Open-Source-Alternativen: Mit Vaultwarden lassen sich Passkeys auf dem eigenen Homeserver hosten, mit KeePassXC sogar komplett offline in einer Datei sichern.
Weiterlesen nach der Anzeige
Transkript des Videos
(Hinweis: Dieses Transkript ist für Menschen gedacht, die das Video oben nicht schauen können oder wollen. Der Text gibt nicht alle Informationen der Bildspur wieder.)
Guck mal hier, meine Passkeys chillen jetzt nicht mehr auf den großen Hersteller-Clouds, sondern die liegen total entspannt auf meinem eigenen Homeserver und als Backup noch in dieser KeePass-Datei. Alles Open-Source, alles lokal und vor allem alles super sicher.
In unserem letzten Video zu Passkeys haben wir das Problem ja schon angesprochen. Viele Anbieter wie Apple und Google bieten zwar einen einfachen Sync eurer Passkeys an, allerdings nur auf ihrer eigenen Plattform. Klar, wir haben da auch schon so ein paar Lösungen gezeigt, aber in diesem Video gehen wir noch einen Schritt weiter. Wir zeigen hier, wie man Passkeys wirklich lokal speichert, also ohne große Cloud, und in diesem Video beschäftigen wir uns auch mit der Möglichkeit, wie ihr die auf dem eigenen Homeserver hosten könnt.
Ihr habt ja immer gefragt, was passiert eigentlich, wenn ich meinen Passkey verloren habe? Und ja, da ihr mehrere Passkeys für einen Account erstellen könnt, könnt ihr eben auch easy eine Datei anlegen, in der einfach Backups von allen wichtigen Zugängen drin sind. Wie das genau geht, bleibt dran.
Liebe Hackerinnen… Achso, ja, ja, ja, ne, ist jetzt ein Video mal ohne… äh… Ja, ja, ne, wir können auch Videos ohne KI. Ja, und Linux kommt auch nicht vor in diesem Video. Andere Themen haben wir auch. Ja, ja. Herzlich Willkommen hier bei…
Ja, ein Hinweis noch aus dem heise-Universum: Mein lieber Kollege Jörg macht ja den YouTube-Channel Phasenlage, wo es um die Energiewende geht. Da könnt ihr Videos sehen zu Themen wie Balkonsolar.
Weiterlesen nach der Anzeige
Ganz kurz zur Erinnerung, damit wir alle auf dem gleichen Stand sind: Was sind Passkeys überhaupt? Wir haben darüber ja schon mehrere Videos gemacht, die verlinken wir euch natürlich in der Beschreibung. Passkeys ersetzen Passwörter. Und was ihr euch auf jeden Fall merken könnt: Passkeys sind vom Sicherheitsstandpunkt her definitiv besser als Passwörter. Warum? Weil euer privater Schlüssel immer auf eurem Gerät bleibt. Nur der öffentliche geht an den Dienst, bei dem ihr euch anmelden wollt. Das heißt also, auch wenn der Dienst gehackt wird, braucht ihr euch keine Gedanken zu machen, dass eure Accounts gekapert werden.
Und noch ganz wichtig: Passkeys sind prinzipbedingt gegen Phishing geschützt. Also die funktionieren nur auf der Website, auf der ihr euch anmelden wollt. Also auf youtube.com und eben nicht auf youtubee.com oder so. Und ganz klar ein Riesenvorteil: Ihr müsst euch keine Passwörter mehr merken. Ihr könnt euch einfach mit Fingerabdruck oder Gesichtserkennung anmelden. Also eigentlich alles ganz einfach. Das ist ganz nice.
Aber es gibt halt auch Probleme. Die großen Tech-Konzerne nutzen Passkeys nämlich gerne, um euch an ihre Plattform zu binden. Ein Passkey auf dem iPhone bringt euch auf dem Windows-Rechner herzlich wenig, außer ihr scannt halt ständig QR-Codes. Und genau deshalb gucken wir uns heute an, wie wir das selbst in die Hand nehmen können. Beide Möglichkeiten bieten natürlich nicht nur Passkey-Unterstützung, sondern auch ganz klassisch Passwörter an.
Möglichkeit 1: Vaultwarden (Self-Hosted)
Ihr hostet auf eurem Homeserver Vaultwarden. Das ist eine Open-Source-Lösung, die eure Passwörter und eben auch Passkeys abspeichert und mit den ganz normalen Bitwarden-Apps funktioniert. Und die gibt es ja für die meisten Browser und auf Android und iOS.
Vaultwarden könnt ihr einfach als Docker-Container auf eurem Homeserver installieren. Hier als Beispiel habe ich das in CasaOS gemacht. Da kriegt ihr das direkt aus dem CasaOS-App-Store. Einfach installieren klicken. Aber auch bei anderen Homeserver-Systemen könnt ihr das einfach als Docker-Container installieren.
Aber Achtung! Hier kommt direkt Hürde Nummer 1: SSL-Zertifikate. Wichtig für Vaultwarden: Ihr müsst zwingend ein SSL-Zertifikat hinterlegen, sonst funktioniert das mit den Passkeys nicht. Der Browser sagt sonst einfach „Nö“. Denn die Browser hantieren wirklich nur mit Passkeys rum, wenn ihr in einem sogenannten Secure Context seid. Und das ist eben HTTPS. Und dafür braucht man ein SSL-Zertifikat.
Um das zu kriegen, gibt es mehrere Möglichkeiten. Wir haben da ziemlich lange drüber diskutiert, was denn jetzt der beste Sweetspot zwischen „Einfach zu installieren“ und „Okaye Sicherheit“ ist. Und wir haben uns für Cloudflare entschieden. Das ist zwar ein kommerzieller Anbieter, der auch in den USA ist. Ist uns klar nicht die allersauberste Lösung. Aber es ist eben in diesem Fall die einfachste Lösung. Wenn ihr das nicht wollt, sage ich aber gleich auch noch was dazu. Gibt es natürlich noch tausend Alternativen.
Um Cloudflare zu nutzen, braucht ihr nur einen kostenlosen Account und könnt dann hier unter dem Punkt „Zero Trust“ einen neuen Tunnel anlegen. Cloudflare erstellt euch einen Tunnel, der dann auch über Cloudflare geroutet wird. Es gibt aber auch noch ganz viele andere Möglichkeiten. Zum Beispiel Pangolin war zumindest in letzter Zeit mal sehr angesagt. Das würde hier wirklich in diesem Video zu weit gehen. Aber wenn ihr da Interesse daran habt, dann guckt euch das doch mal genauer an.
So, aber jetzt wieder zurück zu Cloudflare. Wenn ihr das damit machen wollt, kopiert ihr diesen Befehl, der mit „docker run“ anfängt, in euer Terminal auf eurem Homeserver, also bei uns bei CasaOS. Oder noch entspannter: Ihr installiert euch, wenn ihr zum Beispiel CasaOS habt oder auch Unraid, die Cloudflared-Anwendung einfach auf der grafischen Benutzeroberfläche. Und dann gebt ihr da euren Token ein aus eurem Cloudflare-Account. Kurz danach läuft das als Container bei euch im Hintergrund. Und die Anzeige hier im Cloudflare-Dashboard sollte auf „Healthy“, also grün, umschalten.
Unter dem Punkt „Public Hostname“ wählt ihr dann eine Subdomain. In dem Fall nennen wir sie mal „vault“. Wenn ihr eine Domain bei Cloudflare habt, könnt ihr die verwenden. Sonst bekommt ihr so eine lange von Cloudflare zugeteilt. Bei „URL“ gebt ihr dann die lokale IP von eurer Docker-Installation ein. Und fertig.
So, dann holt ihr euch noch die Bitwarden-Browser-Erweiterung und/oder die App für Android oder iOS. Und das läuft dann alles so wie bei einem von Bitwarden gehosteten Tresor. Ihr müsst nur beim Einloggen hier auf das Zahnrad klicken oder „Selbst gehostet“ auswählen und dann euren Server, also beispielsweise vault.3003-homeserver.de eingeben. Und zack, läuft das.
Und ab dann ist das wirklich identisch mit einem bei Bitwarden gehosteten Zugang. Ihr könnt einfach Passkeys hinzufügen und euch per Passkey anmelden. Und zwar über die App auf eurem Smartphone, genauso wie in Firefox, auf eurem Linux-Rechner oder in Windows. Da geht das mittlerweile sogar direkt mit Windows Hello zusammen. Aber nur, wenn ihr die App nicht aus dem Windows Store, sondern direkt von der Bitwarden-Seite runtergeladen habt.
Möglichkeit 2: KeePassXC (Lokal & Datei)
Und wenn ihr wirklich so richtig lokal mit euren Passkeys sein wollt, also auf Wunsch sogar komplett ohne Netzwerk, dann schaut euch mal KeePassXC an. Ich sag ehrlich, das ist optisch jetzt nicht die allerschönste Oberfläche, aber dafür macht es eben auch genau das, was es soll.
Das Gute ist: Für KeePass gibt es für alle Plattformen Apps und ihr bekommt die Passkeys auch als Datei, die ihr einfach auf einem USB-Stick zum Beispiel backupen könnt. Zusätzlich könnt ihr die KeePass-Dateien natürlich auch direkt über die Cloud automatisch zwischen euren Geräten synchron halten. Das geht dann entweder über große Hersteller-Clouds wie iCloud, Google Drive oder Dropbox. Aber da kommt ihr natürlich vom Regen in die Traufe. Denn genau das wollten wir ja vermeiden, dass die Dateien bei den großen Herstellern gehostet werden. Aber ihr könnt natürlich auch euren eigenen Cloud-Dateispeicher verwenden, wie zum Beispiel Nextcloud auf eurem Homeserver.
Um Passkeys bei KeePassXC zu verwenden, braucht ihr mindestens Version 2.7.7. Wenn ihr das Ding zum ersten Mal startet, legt ihr eine neue Datenbank an, ihr wählt ein Masterpasswort. Das sollte so lang sein, dass ihr es euch gerade noch merken könnt. Schreibt es euch sicherheitshalber auf einen Zettel und packt das dann an einen sicheren Ort. Das ist ja nun wirklich euer absolutes Masterpasswort. Das wäre blöd, wenn ihr das vergesst. Am besten in einen unsprengbaren Tresor.
Dann speichert ihr die Datenbank-Datei irgendwo auf eurem Rechner. Ich habe die Dateien in einem Ordner, der sich automatisch mit meiner Nextcloud synchron hält. Dann habe ich die direkt auch auf meinen anderen Geräten.
Damit der Browser jetzt mit KeePassXC reden kann, braucht ihr noch die Erweiterung KeePassXC-Browser. In KeePassXC selbst klickt ihr oben auf das Zahnrad, dann auf „Browser-Integration“ und setzt den Haken bei „Browserintegration aktivieren“. Zum Schluss wählt euren Browser aus der Liste aus.
Und jetzt im Browser auf das KeePass-Icon klicken und „Verbinden“. Gebt der Verbindung einen Namen. Und wichtig: Geht in der Browser-Erweiterung nochmal in die Einstellungen, scrollt runter bis „Passkeys“ und setzt da unbedingt das Häkchen bei „Passkeys aktivieren“. Sonst wundert ihr euch, warum nichts passiert.
Ja, probieren wir es mal aus. Ich gehe auf eine Testseite wie WebAuthn.io, trage einen Nutzernamen ein, klicke auf „Register“ und seht ihr das? KeePassXC meldet sich sofort. Willst du einen Passkey erstellen? Ja, will ich. Bestätigen.
Beim Login genau das Gleiche. „Authenticate“ klicken. KeePassXC fragt kurz nach. Ich bestätige und ich bin drin.
Und das Beste: Wenn ihr in KeePassXC auf „Datenbank“ und „Passkeys“ geht, dann habt ihr direkt so eine Übersicht. Ihr könnt Passkeys sogar exportieren. Aber Vorsicht: Wenn ihr die exportiert, liegen die privaten Schlüssel im Klartext vor. Also ist ganz cool, wie so ein Passkey aussieht. So, ne? So, so. Aber macht das wirklich nur, wenn ihr wisst, was ihr tut.
Wenn ihr die KeePass-Datei auch noch auf anderen Geräten verwenden wollt, dann könnt ihr die, wie gesagt, über die Cloud synchron halten oder ihr übertragt die manuell per Kabel oder AirDrop. Für zusätzliche Sicherheit könnt ihr auch noch eine Schlüsseldatei erzeugen. Die braucht ihr dann auch auf allen Geräten, aber kopiert die eben per Kabel und legt die nicht in die Cloud.
Ja, und dann ladet ihr euch noch die entsprechende App auf euer Smartphone oder Tablet. Mittlerweile gibt es auch Apps für Android und iOS, die die KeePass-Passkeys unterstützen. Auf iOS sind da KeePassium und Strongbox ganz gut. Auf Android wäre da KeePass DX. XC, DX. Ist ein bisschen verwirrend. Naja.
Die Apps sind relativ ähnlich aufgebaut. Ihr wählt eure Datenbank aus euren Dateien, gebt euer Passwort ein und gegebenenfalls die Schlüsseldatei. Bei iOS wählt ihr die App dann in den Einstellungen noch unter „Automatisch ausfüllen“ und „Passwörter“ aus. Bei Android das Gleiche unter „Passwörter, Passkeys & Konten“.
Fazit
Also, ich finde Passkeys nach wie vor super und verwende die, wo immer es geht. In der Praxis habe ich die schon alleine aus Testgründen auf mehreren Geräten und mehreren Accounts und es ist auch wirklich sinnvoll, da nicht nur bei einem Anbieter mit zu sein. Also bei so wichtigen Accounts, wo es weh tut, nicht mehr reinzukommen, erstelle ich einfach gleich mehrere Passkeys.
Ja, wie sieht es bei euch aus? Traut ihr euch dran an Vaultwarden oder KeePass? Oder bleibt ihr lieber bei den Komfortlösungen wie Apple und Google? Oder haltet ihr Passkeys generell für Teufelszeug und arbeitet weiterhin mit Passwörtern und zweitem Faktor? Gerne gute Argumente in die Kommentare schreiben. Wenn euch das Video geholfen hat, lasst gerne ein Abo da und drückt die Glocke, damit ihr das nächste Video nicht verpasst. Achso, Podcast haben wir auch und Newsletter. Alles in der Beschreibung. Tschüss.
c’t 3003 ist der YouTube-Channel von c’t. Die Videos auf c’t 3003 sind eigenständige Inhalte und unabhängig von den Artikeln im c’t Magazin. Die Redakteure Jan-Keno Janssen, Lukas Rumpler, Sahin Erengil und Pascal Schewe veröffentlichen jede Woche ein Video.
(rum)
Künstliche Intelligenz
Fritzbox 5690 Pro und XGS bekommen FritzOS 8.20
Fritz (früher AVM) reicht die aktuelle FritzOS-Version 8.20 für die beiden Fritzboxen 5690 XGS und 5690 Pro nach. Für das XGS-Modell ist es das erste Update seit der Markteinführung im Oktober 2025 mit FritzOS 8.02. Im Falle der Fritzbox 5690 Pro erscheint die Version 8.20 ziemlich genau ein Jahr nach dem Update auf FritzOS 8.03.
Weiterlesen nach der Anzeige
Die normale Fritzbox 5690 (ohne Namenszusatz) hat FritzOS 8.20 schon Ende Januar erhalten. Alle 5690er-Fritzboxen befinden sich damit jetzt auf dem gleichen Firmware-Stand. Die Neuerungen sind identisch zu den diversen bereits veröffentlichten FritzOS-8.20-Updates für andere Fritzboxen.
Mit dabei ist ein neuer Online-Monitor, der die Internetauslastung verschiedener Geräte im Heimnetz anzeigt. Zudem gibt es einen sogenannten Failsafe: Per WAN, LAN oder USB können Nutzer ein Ausfallschutzgerät anschließen, auf das der Router bei Internetproblemen zurückgreift. Das Ausfallschutzgerät kann ein Modem, ein Router oder ein Mobilfunkstick für eine alternative Internetverbindung sein. Bei der Fritzbox 5690 Pro ist eine zweite Verbindung besonders einfach, da der Router sowohl an DSL- als auch an Glasfaseranschlüssen läuft.
Die Updates lassen sich wie gehabt über die Weboberfläche anstoßen. Standardmäßig lässt sie sich über die IP 192.168.178.1 im Browser öffnen. Alternativ stellt Fritz die Images über einen Download-Server bereit.
Labortest ausgeweitet
Fritz macht außerdem auf den ausgeweiteten Test der Labor-Vorabversion FritzOS 8.24 aufmerksam, die für die Fritzboxen 7690, 7590 AX, 7590, 7530 AX, 7530, 6860, 6690, 6660, 6591 und 5530 bereitsteht. Das Update enthält ausschließlich Fehlerbehebungen und Optimierungen; unter anderem soll die Stabilität steigen.
(mma)
Künstliche Intelligenz
VirtualBox erhält experimentellen KVM-Support | heise online
Oracle hat in den aktuellen Entwickler-Builds von VirtualBox experimentellen Support für KVM (Kernel-based Virtual Machine) integriert. Wie aus dem VirtualBox-Issue-Tracker auf GitHub hervorgeht, ermöglicht die neue Funktion den Einsatz des nativen Linux-Hypervisors als Backend. Die Integration erfolgt über den Native Execution Manager (NEM), der bereits Hyper-V (Windows) und den Apple Hypervisor (macOS) unterstützt.
Weiterlesen nach der Anzeige
Die Implementierung ist derzeit nur in manuell erstellten Development-Builds verfügbar. Nutzer müssen dazu Patches auf den VirtualBox-Quellcode anwenden und das System mit den Configure-Flags --with-kvm --disable-kmods kompilieren. Das KVM-Backend eliminiert dabei die Abhängigkeit von den eigenen VirtualBox-Kernel-Modulen, die unter Linux-Kernels ab Version 6.12 zunehmend Probleme verursachen können.
Vorteile bei Kernel-Konflikten
Besonders nützlich erweist sich der KVM-Support, wenn die proprietären VirtualBox-Module Schwierigkeiten bereiten. Dies betrifft etwa Systeme mit aktivierter Kernel-Signaturprüfung oder Umgebungen, in denen Konflikte zwischen den VirtualBox- und KVM-Modulen auftreten. Ein von Oracle im Oktober 2025 veröffentlichter Kernel-Patch ermöglicht zudem die Koexistenz beider Systeme, indem die Funktionen kvm_enable_virtualization() und kvm_disable_virtualization() re-exportiert werden.
Parallel zu Oracles Entwicklung existiert bereits das unabhängige Open-Source-Projekt virtualbox-kvm von Cyberus Technology. Es bietet seit 2024 ein KVM-Backend für VirtualBox, das Features wie Nested Virtualization unterstützt. Der letzte Release erschien Anfang Februar 2026 (Support von VirtualBox 7.1.6a).
Sicherheitsaspekte und Ausblick
Aus Sicherheitsperspektive reduziert das KVM-Backend die Angriffsfläche, da es als Type-1-ähnlicher Hypervisor direkt in den Kernel integriert ist. Dies verringert potenzielle Schwachstellen gegenüber Type-2-Hypervisoren mit eigenen Kernel-Modulen. Bekannte Schwachstellen in VirtualBox betreffen häufig GPU- und 3D-Komponenten, ähnliche Probleme existieren auch bei QEMU/KVM in der virtio-gpu-Implementation.
Weiterlesen nach der Anzeige
Ob und wann Oracle den KVM-Support in eine stabile VirtualBox-Version integriert, ist derzeit offen – schließlich befindet sich die Funktion explizit in einem frühen experimentellen Stadium. Für Nutzer, die vollständig auf KVM setzen möchten, bleibt QEMU/KVM die ausgereifte Alternative mit nativer KVM-Integration und hoher Performance.
Oracle folgt mit dem Schritt dem Konkurrenten VMware: Broadcom begann bereits Ende 2024, den Einsatz von KVM in seiner Virtualisierungssoftware vorzubereiten. Seitdem gab es jedoch keinerlei Updates oder einen offiziellen Zeitplan für diesen Umbau.
(fo)
-
Entwicklung & Codevor 3 MonatenKommandozeile adé: Praktische, grafische Git-Verwaltung für den Mac
-
Künstliche Intelligenzvor 1 MonatSchnelles Boot statt Bus und Bahn: Was sich von London und New York lernen lässt
-
Apps & Mobile Entwicklungvor 2 MonatenHuawei Mate 80 Pro Max: Tandem-OLED mit 8.000 cd/m² für das Flaggschiff-Smartphone
-
Apps & Mobile Entwicklungvor 2 MonatenFast 5 GB pro mm²: Sandisk und Kioxia kommen mit höchster Bitdichte zum ISSCC
-
Entwicklung & Codevor 2 MonatenKommentar: Anthropic verschenkt MCP – mit fragwürdigen Hintertüren
-
Social Mediavor 2 MonatenDie meistgehörten Gastfolgen 2025 im Feed & Fudder Podcast – Social Media, Recruiting und Karriere-Insights
-
Datenschutz & Sicherheitvor 2 MonatenSyncthing‑Fork unter fremder Kontrolle? Community schluckt das nicht
-
Künstliche Intelligenzvor 3 MonatenWeiter billig Tanken und Heizen: Koalition will CO₂-Preis für 2027 nicht erhöhen
