Wir hatten gestern ein paar Freunde zu Besuch und da versteht es sich von selbst, dass es etwas leckeres, aber nicht zu kompliziertes gibt. Gestern fiel die Wahl auf ein gefülltes Baguette, das Rezept stammt von meiner Mutter, kleine Abwandlungen von mir. Zunächst die Zutaten:
Blog
-
Nokia — Chance verpasst
Zwei Neuigkeiten hat Nokia in den letzten Tagen vorgestellt, beziehungsweise wird sie demnächst auf der Nokia World vorstellen: Ein schlankes, schickes Netbook mit integrierter 3G-Unterstützung, sauberer Verarbeitung und einem Softwareumfang, der auf Geschäftsleute zielt. Und das RX51 — oder wahrscheinlich eher N900 genannte — Tablet, welches das N810 beerbt. Auf den ersten Blick eine Evolution, auf den zweiten Blick der iPhone-Killer, der eigentlich das N97 hätte sein sollen: Im Gegensatz zu seinen Vorgängern lässt sich das N900 auch im Hochformat nutzen und es bietet Telefonfunktionen.
Mit all den Neuerungen der letzten 12 Monate wird das größte Problem von Nokia deutlich: Die schier unüberschaubare Anzahl an Plattformen. Im Lowend-Bereich hat Nokia seine Series30-Oberfläche, die sich an die teureren Geräte anlehnt, aber keine Softwareinstallation bietet und meines Wissens kein Multitasking beinhaltet. Darüber steht Series40, schlank schnell, UMTS-tauglich und für einfache Telefone im Midrangebereich gedacht, aber auch für Edel-Telefone wie das 8800, bei denen neben Design die Telefonfunktion anerster Stelle steht. Darüber kommt Series60 auf SymbianOS in einer Version für Tastaturbedienung und einer Version für Touchscreens (wie das N97, 5800 oder 5230). Die Tablets 770, 800, 810 und jetzt das telefoniefähige N900 verwenden die Linux basierte Distribution Maemo, welche derzeit traditionell auf Gtk+ als Toolkit setzt. Nun kommt mit Windows 7 auf Netbooks eine weitere Plattform hinzu. Diese ist relevant, weil Nokia beispielsweise Programme wie den Ovi-Client auch auf der Netbook-Plattform anbieten muss. (more…)
-
Akoya E1210 und Kernel 2.6.30.5
Mittlerweile ist der Ralink-Treiber für den 802.11n-Chipsatz des Medion Akoya E1210 im Mainline-Kernel gelandet. Zwar nur im experimentellen Staging-Zweig, aber zumindest für die Chipsatz-Revision des E1210 stabil genug für den täglichen Einsatz. Die Installation des separaten Ralink-Treibers entfällt damit. Unter Ubuntu 9.04 ist die Installation recht schnell bewerkstelligt:
-
Kopieren der Konfigurationsdatei: Zuerst wird die Konfigurationsdatei /boot/config-2.6.28-xx-generic als .config in das entpackte Kernel-Quellcode-Verzeichnis kopiert.
-
Neubau der Konfiguration: Hier rufen Sie das Kommando make oldconfig auf. Sie müssen nun einen Haufen Fragen beantworten. Falls Sie keine Lust haben, sich mit dem Inhalt der Fragen zu Treibern und Features auseinanderzusetzen, antworten Sie mit m (neue Funktion als Modul bauen) oder n (neue Funktion weglassen).
-
Aktivierung der Staging-Treiber: Rufen Sie make menuconfig auf und navigieren Sie zu “Device Drivers -> Staging Drivers”, wo Sie “Staging Drivers” aktivieren, indem Sie das Sternchen bei “Omit staging drivers from being built” herausnehmen. Jetzt können Sie den Treiber für Ralink 2860 aktivieren.
-
Bau und Installation des Kernels: Nach mehrfachem “Exit” wird die neue Kernelkonfiguration gespeichert. Bauen Sie mit make und installieren Sie den neuen Kernel mit make modules_install && make install.
-
Neubau der Bootloader-Konfiguration: Ich habe in der Datei /etc/initramfs-tools/initramfs.conf auf MODULES=list umgestellt und in der Folge in /etc/initramfs-tools/modules nur die Zeile i915 eingefügt. Anschließend baut mkinitramfs -o /boot/initrd.img-2.6.30.5 2.6.30.5 das neue Initramfs und update-grub erstellt die Bootloader-Konfiguration neu.
That’s it. Natürlich muss man bei Sicherheits-Updates am Kernel mit frischen Patches (und alter Config) neu bauen, aber diese Konfiguration läuft bei mir unter Ubuntu 9.04 stabil. Unter 9.10 wird sie wohl nicht mehr nötig sein.
-
-
Randnotizen, 26. Juni 2009: LessLinux, Android, SkyOS
Nach langer Abstinenz wieder einmal ein paar Randnotizen zu Dingen, die in den letzten Tagen so aufgefallen sind:
-
LessLinux: Auch mit “meiner” eigenen, lose auf Linux From Scratch aufbauenden Live-Distribution LessLinux ging es in den letzten Wochen in vielen kleinen Schritten weiter. Mittlerweile wird viel Standard-Netzwerk-Hardware automatisch erkannt, WLAN kann mit WICD angesprochen werden, einige eigene Ruby-Gtk-Scripte sorgen für eine komfortable Installation auf USB-Stick oder die Erstellung von Containern mittels Cryptsetup.
Jetzt kommt die Stelle, an der Ihr helfen könnt: Bitte ladet Euch den aktuellsten Build herunter und erstellt ein Hardware-Protokoll. Mit diesem Hardware-Protokoll (es enthält die Ausgaben von lspci, lsusb und lshw), habe ich es leichter, die Hardwareerkennung zu verbessern.
-
Android: Das Handy-Linux kommt nun auch mit einem Native Development Kit, mit dem sich native Linux-Anwendungen erstellen lassen, die direkt auf dem Linux des Android und nicht auf der aufgesetzten Dalvik VM laufen. Insbesondere die Portierung von Emulatoren und einigen Spielen, die SDL verwenden, dürfte vom NDK profitieren.
Unterdessen zeigt Android bereits erste Fragmentierungserscheinungen: HTC stellte auf dem eigenen Telefon eine erweiterte Oberfläche “Sense UI” vor, die leider nicht auf die Telefone mit Google Branding kommen soll. Mal gespannt, ob das Resultat bald drei verschiedene Adressbuch-APIs sind.
-
SkyOS: Bei SkyOS handelte es sich bislang um proprietäres ein Ein-Mann-Betriebssystem. Ein C++-lastig implementiertes OS für 32-Bit-x86, das mit einer gut durchdachten Architektur glänzen kann. Als Problem stellte sich in den letzten Jahren jedoch die Treiber-Unterstützung heraus, zuletzt kam die Entwicklung fast zum Erliegen. Nun hat der Entwickler Robert Szeleney einen radikalen Schritt gewagt und SkyOS auf einen Linux-Kernel und ein minimales Linux-Userland gestellt. Die Vorgehensweise erinnert etwas an NeXTstep bzw. MacOS X. Auf jeden lohnt es sich, ein Auge auf die weitere Entwicklung zu werfen. Mehr im Blog von Robert Szeleney
-
Netbooks: In den letzten Monaten hat sich hier wenig getan. Netbooks sind beinahe eine Commodity und unterscheiden sich nur noch im Preis. Die letzten Juli für 399 Euro verkauften Medion Akoya E1210 gibt es nun als B-Ware für 219 Euro. Da fällt es umso positiver auf, dass HP mit dem hübschen, wenn auch nicht ganz billigen HP 5101 zeigt, dass Alu und Magnesium im Understatement-Gehäuse noch ihre Berechtigung haben. Nachtrag, 30. Juni: Golem hat Details und Bilder der hierzulande verkauften Version mit UMTS.
-
-
Mal wieder: Mattias und Mobiltelefone
Ach, wenn es doch so einfach wäre: Im letzten Jahr bin ich zum richtigen Mobiltelefon-Afficionado gereift, lieb gewonnen habe ich besonders das minimalistische F3 und mein ständig E71, das — dank wunderbarer Daumen-Tastatur — auch als mobile Blog- und Twitter-Maschine dient.
Dennoch juckt es mich irgendwie in den den Fingern und ich hätte gerne ein zweites, etwas weniger vernünftiges “modernes” Telefon. Ein Spielzeug, an dem man sehen kann, was zur Zeit Stand der Technik ist: Location Based Services, Social Networking, Medienplayer, aber auch Geek-Spielzeug und ein wenig Testumgebung für eigene Programme. Heiss sind derzeit:
- iPhone 3GS
- Palm Pre
- Nokia N97
- T-Mobile G1
- HTC Magic
Dumm nur, dass alle irgendwie nerven: (more…)
-
Zur Technologieneutralität der geplanten Sperren
Ich wurde in den letzten Tagen mehrfach darauf hingewiesen, dass die Sperrlisten ja komplette URLs enthalten und damit die Kollateralschäden hinsichtlich Unzustellbarkeit von Emails oder des Overblockings nicht vorkommen müssen. Tatsächlich heisst es im Gesetzentwurf:
Für die Sperrung dürfen vollqualifizierte Domainnamen, Internetprotokoll-Adressen und Zieladressen von Telemedienangeboten verwendet werden. Die Sperrung erfolgt mindestens auf der Ebene der vollqualifizierten Domainnamen, deren Auflösung in die zugehörigen Internetprotokoll-Adressen unterbleibt.
Demnach sollen die Provider Listen nicht nur der Domainnamen, sondern tatsächlich komplette URLs, wohl auch mit GET-Parametern erhalten. Sehen wir uns die Alternativen an:
-
Sperrung auf IP-Ebene:
Es gibt keine Möglichkeit, zuverlässig herauszufinden, ob hinter einer IP-Adresse nur eine Domain gehostet wird oder zu erkennen, wann eine Site auf einen Server umzieht oder von ihm wegzieht. Nicht einmal das Ausbleiben von HTTP-Verkehr auf eine bestimmte Domain könnte als Indiz gewertet werden, dass bestimmte Hosts einer Domain nicht auf dem Server liegen — schließlich muss eine Domain nicht zwangsläufig zum Hosten von Webseiten verwendet werden oder kann momentan einfach brach liegen. Selbst wenn man beim Aussprechen der Sperrverfügung für eine IP-Adresse sicher ist, dass hinter ihr nur illegale Inhalte gehostet werden, kann es sich um einen Shared Hosting Server handeln, der grade erst befüllt wird.
Wie schnell es zum Overblocking kommen kann, hat die Youporn-Sperre durch Vodafone bewiesen, dort haben einige Provider auf IP-Ebene geblockt, ohne zu berücksichtigen, dass Youporn zu dieser Zeit sich Server mit anderen Inhalten teilte. Die Kollateralschäden dieser Form der Sperrung sind nicht zu überblicken.
-
Sperrung auf Ebene der vollständigen Zieladresse:
Der einzig technisch praktikable Ansatz, dies zu realisieren ist die in Großbritannien gebräuchliche Cleanfeed-Methode. Hier werden “verdächtige” Hostnamen entweder per DNS- oder per Router-Manipulation auf einen transparenten Proxy umgeleitet. Dieser filtert angefragte HTTP-Requests und liefert nur bei bestimmten Mustern das “Stoppschild” zurück. Eine derartige Filterung wirkt auf den ersten Blick eleganter (weil weniger anfällig gegen Overblocking), hat jedoch den Beigeschmack, dass hier Privatunternehmen beauftragt wären, die Kommunikation ihrer Kunden zu überwachen. Nicht schön: Ein HTTP-Request kann persönliche Daten sichtbar in GET-Parametern, aber ebenso unsichtbar in Cookies oder POST-Requests transportieren. Ich habe wenig Vertrauen, dass ein Privatunternehmen wie die T-Com die anfallenden Daten vertraulich behandelt.
Die vermeintlich “technologieneutrale” Formulierung hält einige massive Problematiken aus grundrechtlicher Sicht bereit:
-
Freie Wahl der Sperrmethodik:
Den Providern werden keine Auflagen gemacht, Overblocking zu vermeiden. Ein Provider, der per Routingtabelle sperrt und täglich die IP-Adressen der auf der Sperrliste verzeichneten Domains ins Nirvana oder zum eigenen Stoppseitenserver routet, kann nicht für Overblocking verantwortlich gemacht werden, er erfüllt nur den Wortlaut des Gesetzes, auch wenn nur eine Domain auf einem Shared-Hosting-Server mit 50.000 anderen Domains nur eine kurzzeitig kinderpornografische Inhalte enthielt. Beschwerden sind zwar nachträglich übers Verwaltungsgericht möglich, doch möchte ich nicht wissen, wie lang ein Verfahren dauert, wenn plötzlich eine sehr große Anzahl versehentlich mitblockierter Seiteninhaber klagt.
-
Analyse des kompletten (unverschlüsselten) Datenverkehrs des Kunden:
Warum nicht einfach auf die erste Stufe von Cleanfeed verzichten und stattdessen den gesamten HTTP-Verkehr über einen transparenten Proxy schicken? Neben einer Vereinfachung der Sperrinfrastruktur hat dies für den Provider den Vorteil, dass häufig angeforderte Inhalte gecachet werden können. Dies ist keine Zukunftsvision: Wer via Vodafones Websessions surft, bekommt (je nach Wal des Access-Points, Stand Januar 2009) von diesem transparenten Proxy Grafiken in schlechterer Qualität ausgeliefert, um den Traffic gering zu halten. Jene Mechanismen, die zur Identifikation von angeforderten Grafiken dienen, können ohne Änderungen dazu benutzt werden, die Sperrverfügungen umzusetzen. Während es bislang möglich ist, durch die Wahl des Access Points einen mobilen Internetzugang ohne Proxy zu verwenden, wird dies nach Implementierung der Sperrtechnologien nicht mehr möglich sein und sämtlicher ein- und ausgehende HTTP-Verkehr wird von einem Privatunternehmen analysiert werden.
Analog zur Welt der Post bedeutet der gegenwärtige Gesetzentwurf in etwa: Wir machen Listen mit den Adressen von bösen Leuten, die kinderpornografische Inhalte per Versandhandel vertreiben und die Post muss dann alle Postkarten prüfen, ob diese an die bösen Leute gerichtet sind. Ist das der Fall, behaltet Ihr die Postkarte und liefert die Stopkarte zurück. Wie Ihr das macht ist uns egal: Ihr dürft alle Postkarten, die über Euer System laufen, komplett lesen, wenn das einfacher erscheint oder Ihr dürft (analog zur IP-Adresse) gerne die Postkarten an einen ganzen Postleitzahlbezirk einkassieren.
Wir diskutieren momentan hauptsächlich über die Sperrung per manipuliertem DNS-Server, weil diese einerseits am einfachsten umzusetzen ist (wo nicht bereits transparente Proxies existieren) und andererseits viele Befürworter des Gesetzes sagen, dass die Nameserverabfrage vor dem Kommunikationsaufbau liegt. Ich an dieser Stelle einmal an die Juristen ab: In der gegen Overblocking anfälligen Sperrung auf IP-Ebene und der Analyse sämtlicher HTTP-Anfragen sehe ich einen klaren Verstoß gegen Artikel 5 und 10 unserer Verfassung. Selbst nach Streichen dieser Passagen bliebe noch die DNS-Sperre, die zumindest das Potential hat, den Email-Verkehr massiv zu behindern und damit auch in den Schutzbereich von Artikel 10 eingreift.
Selbst wenn es gelänge, das Gesetz dennoch — ausschließlich mit DNS-basierten Sperren — umzusetzen, bleibt die Frage nach der Verhältnismäßigkeit: Aus Bundesmitteln wird derzeit die Einführung von DNSSEC gefördert, welche das Gesetz mittelfristig wirkungslos machen wird. Eine Verhältnismäßigkeit zwischen den wenigen Seiten, auf denen die Sperre in zwei oder drei Jahren noch nutzt, dem Aufwand für den Aufbau der Sperrinfrastruktur und den gebundenen Personalkapazitäten von BKA-Mitarbeiter, die statt zur Sperrlistenpflege mit besserer Schulung effizienter zur tatsächlichen Verfolgung von kinderpornografischen Angeboten eingesetzt werden sollten, ist nicht gegeben.
Auf das Mißbrauchspotential von Cleanfeed oder anderen Lösungen, die auf transparenten Proxies beruhen, gehe ich später ein…
-
-
Stoppseiten: Was passiert mit E-Mails?
Gastbeitrag von mir im Lawblog:
DNS-basierte Internetsperren kinderpornografischer Inhalte galten bislang als der einzig praktikable Weg, ohne Verfassungsänderung schnell ein symbolträchtiges Sperrgesetz auf den Weg zu bringen: Befürworter des Gesetzes argumentieren, dass eine manipulierte Nameserver-Antwort noch in die Phase vor dem Kommunikationsaufbau fällt und deshalb keinen grundrechtsrelevanten Eingriff in die Kommunikation selbst darstellt.
Die Funktionsweise der im “Gesetz zur Bekämpfung der Kinderpornografie in Kommunikationsnetzen” geplanten Sperren ist am ehesten mit einer manipulierten Telefonauskunft zu vergleichen: Ruft ein Surfer eine Webseite auf, wird zunächst bei einem Nameserver die einem Hostnamen zugehörige IP-Adresse angefragt. Bei den hierzulande geplanten und in einigen skandinavischen Ländern umgesetzten Sperren liefert der – auf staatliches Geheiß – manipulierte Nameserver des Internetproviders einfach die IP-Adresse des “Stoppseitenservers”, der entweder beim BKA oder beim Provider stehen wird.
Bislang konzentriert sich die Debatte lediglich auf die Sperrung von Webseiten, fast jeder Diskussionsbeitrag und jedes Rechtsgutachten geht davon aus, dass der Anfrage an einen Nameserver zwangsläufig ein HTTP-Aufruf, also die Abfrage einer Webseite folgt.
-
Zu meiner Privatmeinung…
…bitte hier entlang:http://blog.mattiasschlenker.de/
(nur für den Fall, dass jemand über www.lawblog.de hier landet und weitere Beiträge zur Sperrdebatte sucht)
-
Internetsperren für Killerspiele?
Was möchte uns Thomas Strobl mit diesem Satz sagen?
In jedem Fall sollte aber meines Erachtens in der Debatte, welche Maßnahmen zur Gewaltprävention ergriffen werden, die von den Bundesministern von der Leyen und Schäuble vorgeschlagene Sperrung von kinderpornografischen Seiten im Internet mit Blick auf Killerspiele neu diskutiert werden.
Ich weiss es nicht. Vielleicht, dass die Internetsperren auch für “Killerspielewebsites” und “Killerspieleportale” genutzt werden sollten? Oder dass Killerspieler leichter zu KiPo-Konsumenten werden? Dass KiPo-Konsumenten erst virtuell, dann real töten wollen?
Mir scheint eher, als wolle Thomas Strobl einfach bei beiden emotionsgeladenen Themen medial präsent sein. Das ist ihm gelungen, ich schreibe drüber.
Nachtrag: Auch Netzpolitik nimmt sich des Themas an und das Lawblog.
Nachtrag, 19. Juni: Thomas Strobl hat seine Forderungen bekräftigt und möchte nun offenbar die nächste Sau durchs Dorf treiben. Artikel bei Golem.
-
Brief ans Familienministerium: DNSSEC vs. Kinderpornosperren
So, der Brief ans Familien- und Wirtschaftsministerium ist raus, morgen folgen die Ausschüssen respektive Arbeitsgruppen “Wirtschaft und Telekommunikation” sowie “Soziales”.
Worum geht es? Um die Wirkungslosigkeit von Internetsperren auf DNS-Ebene vor dem Hintergrund der Einführung von DNSSEC, einem Signaturverfahren für Nameservereinträge. Brisant: Das Bundesamt für Sicherheit in der Informationstechnologie unterstützt derzeit in einem Feldversuch die Einführung von DNSSEC . Hier wird also mit Bundesmitteln und damit Steuergeldern eine absolut begrüßenswerte Technologie eingeführt, welche aber gleichzeitig die Sinnlosigkeit des Sperransatzes im “Gesetz zur Bekämpfung der Kinderpornographie in Kommunikationsnetzen” entlarvt.
Ich argumentiere hauptsächlich auf technischer Ebene, die rechtlichen und gesellschaftspolitischen Argumente wurden von verschiedenen Seiten — auch in den von Familien- und Wirtschaftsministerium eingeholten Gutachten — mehrfach vorgebracht.
Nachtrag, 11. Juni: Heise hat einen älteren, sehr lesenswerten Artikel zu DNSSEC und Sperren per Nameservermanipulation. Es dürfte mittelfristig darauf hinauslaufen, dass der Client einen Resolver bekommt und der manipulierte Nameserver des Providers gar nicht mehr angefragt wird.