iTunes und Fairplay-DRM

Auch wenn ich keinen Mac besitze, höre ich regelmäßig den MobileMacs-Podcast. Darin hatte Tim Pritlove erwähnt, dass gekaufte Lieder, Programme und Videos erst im lokalen iTunes mit dem DRM versehen werden. Ich hatte das so verstanden, dass iTunes Dateien aus dem Store als unverschlüsselte Inhalte herunterläd.

Prima dachte ich mir, dann hab ich ja bald eine schöne Sammlung an DRM-freien M4A-Dateien auf meiner Festplatte rumzuliegen. Die erste Aktion war also Wireshark anzumachen und mir einen Song im iTunes-Store zu kaufen. Die heruntergeladene Datei wollte ich dann mittels Wireshark direkt speichern.

Das Ergebnis war relativ enttäuschend. So wie ich es mir vorgestellt hatte, funktioniert es nicht. Die iTunes-Server schicken, nach Austausch diverser Daten, zunächst unverschlüsselt das Coverbild als jpg und anschließend den Song. Dieser wird im m4p-Format geschickt. Eine M4P-Datei ist eine in einem MP4-Container verpackte und DRM-geschützte Datei.

Die englische Wikipedia stellt den Prozess ähnlich dar. Der Artikel über Apples DRM-System Fairplay sagt über die Funktionsweise folgendes:

FairPlay-protected files are regular MP4 container files with an encrypted AAC audio stream. The audio stream is encrypted using the AES algorithm in combination with MD5 hashes. The master key required to decrypt the encrypted audio stream is also stored in encrypted form in the MP4 container file. The key required to decrypt the master key is called the “user key.”

Each time a customer uses iTunes to buy a track a new random user key is generated and used to encrypt the master key. The random user key is stored, together with the account information, on Apple’s servers, and also sent to iTunes. iTunes stores these keys in its own encrypted key repository. Using this key repository, iTunes is able to retrieve the user key required to decrypt the master key. Using the master key, iTunes is able to decrypt the AAC audio stream and play it.

When a user authorizes a new computer, iTunes sends a unique machine identifier to Apple’s servers. In return it receives all the user keys that are stored with the account information. This ensures that Apple is able to limit the number of computers that are authorized and makes sure that each authorized computer has all the user keys that are needed to play the tracks that it bought.

When a user deauthorizes a computer, iTunes will instruct Apple’s servers to remove the unique machine identifier from their database, and at the same time it will remove all the user keys from its encrypted key repository.

The iPod also has its own encrypted key repository. Every time a FairPlay-protected track is copied onto the iPod, iTunes will copy the user key from its own key repository to the key repository on the iPod. This makes sure that the iPod has everything it needs to play the encrypted AAC audio stream.

Das hört sich durchaus so an als ob beim Abruf bereits ein mit dem Master-Key verschlüsseltes M4P-File empfangen wird. Der Master-Key ist in dem File mit dem User-Key verschlüsselt enthalten, so das man nur den User-Key benötigt um den Masterkey und damit das File zu entschlüsseln und abzuspielen. Den Key bekommt man dann von einem Apple-Server oder im Falle eines Offline-Devices, wie dem iPod, aus dem lokalen Repository.

Dennoch kann Tim mit seiner Aussage nicht ganz falsch liegen. iTunes verändert die Datei nach dem Herunterladen zumindest. Denn vergleicht man die M4P-Datei, die heruntergeladen wird und die M4P-Datei, die abgelegt wird, so sind die Dateien zwar größtenteils identisch - dennoch gibt es zwischen den beiden Dateien Unterschiede. So ist die abgelegte Datei im getesteten Fall um circa 140KB größer (die Gesamtgröße ist circa 3.3MB) .

Schaut man sich die beiden Dateien mit WinMerge an, so wird man feststellen, dass in der abgelegten M4P-Datei bei circa 48KB Inhalte eingefügt werden. Das sind die circa 140KB Unterschied. Im Anschluss daran sind die Dateien jedoch wiederum Identisch.

Da der Großteil der Datei nicht verändert wird - also der Audiostream definitiv nicht lokal verschlüsselt wird - nehme ich nicht an, dass das DRM lokal wesentlich verändert wird. Dennoch interessiert mich, was genau passiert.

Falls jemand von euch Informationen dazu hat - bitte postet entsprechende Infos in die Comments. Danke

Hier noch kurz ein Screenshot der Wireshark-Session. Die beiden M4P-Dateien kann ich auf Anfrage gerne auch bereitstellen.

Wireshark-Session eines iTunes Downloads

Edit : Das Cover ist auch so circa 140KB groß. Und wenn man sich das Cover und die zusätzlichen 140K anschaut sieht man, dass zumindest ein Teil der 140K das Cover sind.

Google Chrome und Datenschutz

Da ich die letzen Tage im Urlaub war hab ich den Launch und auch die ersten Reaktionen auf Googles Browser Chrome verpasst. Er befindet sich derzeit in der Betaphase und ich hab mir gedacht - den guckste dir mal an.

Grundsätzlich ist das Ding garkeine so schlechte Idee. Speziell die Ausrichtung auf Webapps finde ich sehr sinnvoll. So kann man z.B. Starter für Webapps auf dem Desktop ablegen und auch Google Gears ist standardmäßig integriert. Auch die aufgeräumte Oberfläche macht durchaus Sinn. Was auch Sinn macht ist auf einen Core für das Rendering zu setzen der schon weitflächig eingesetzt wird. Dabei handelt es sich um Webkit (was übrigens ursprünglich mal KHTML aus dem KDE-Projekt war), welches in Apples Safari und einigen Mobilbrowsern eingesetzt wird.

Den Oberflächentest hat es also bestanden. Die einzelnen Features kann man sich ja im Netz anschauen - darauf werde ich jetzt nicht mehr eingehen.

Dann habe ich mir gedacht - Google - da war doch was. Ach ja -  Google is Evil. Also machen wir mal den Wireshark an beim Browsen und das hab ich dann auch mal gemacht.

Hallelujah kann ich nur sagen.  Fangen wir mal mit einem frischinstallierten Browser in den Standardeinstellungen an. Und auf welcher Webseite waren wir heute noch nicht? Nehmen wir doch einfach mal Heise.de

Und siehe da - Google Chrome fängt auch prompt an nach www.heise.de zu suchen. Damit schickt der Browser also eine Anfrage an clients1.google.de in der die URL, die ich besuchen möchte enthalten ist.

Wunderbar. Das bedeutet, dass Google jede Eingabe in die Such/Adress-Leiste mittels einer Anfrage an ihre eigenen Server mitprotokolliert. Natürlich kann man das umgehen. Dazu muss man schließlich nur statt einen normalen neuen Tab ein Inkognito-Tab aufmachen. Sinnvolles Defaultverhalten oder?
Achso - Cookies werden natürlich bei der Suchanfrage an Google auch verwendet, damit man weiß wer gerade wohin gesurft ist und wer wonach gesucht hat.

Es geht sogar noch weiter. Klickt man auf einer Seite einen Link an der auf eine andere Seite führt prüft Google ersteinmal ob es sich dabei um eine böse Malware-Seite handelt. Das macht es indem es indem es eine Anfrage an safebrowsing.clients.google.com schickt in dem die URL oder ein anderes Identifikationsmerkmal der Seite (das habe ich nicht genauer überprüft) wahrscheinlich gehasht enthalten ist. Das bedeutet letztendlich dass man gezielt nachschauen könnte welcher User eine bestimmte Webseite aufgerufen hat, denn der Hash für die angesurfte Seite sollte ja eindeutig sein.

Ich bin mir sicher, da steckt noch einiges mehr drin. Über die AGBs wurde ja auch schon breit diskutiert.

Also - bitte liebe Leute - nutzt diesen Browser nicht!

Die Eingabe/Ausgabe-Suppe

Hier mal wieder ein kleiner Linktipp. Wer die Seite schon kennt wird den Blogtitel nicht merkwürdig finden.

Es handelt sich um die Seite soup.io . Der Name Soup also Suppe beschreibt das ganze schon ganz gut. Es handelt sich um einen Microbloggingdienst. Wer jetzt “twitter” schreit ist mittelweit entfernt. Man ist nicht auf 140 Zeichen begrenzt und es wird dort multimedial gebloggt. Oftmals wird nur ein einzelnes Bild oder eine einzelnes Youtube-Video gebloggt.  Vollständige Blogbeiträge finden sich dort kaum.

Die Suppe eignet sich sehr gut wenn man ein schönes / lustiges / merkwürdiges Bild braucht. Man findet dort unter Garantie eins. Wenn man etwas sieht was man mag kann man sich natürlich auch anschauen, was derjenige der das gepostet hat sonst noch so postet und kann seine Posts (wie bei Blogs üblich) auch über seinen Feedreader lesen.

Soup.io ist auch sehr gut wenn man auf Arbeit nichts zu tun hat - Es hilft gegen Langeweile und man kann ewig in der Suppe schwimmen und interessante Sachen finden. Und viel Sinnloses - Massig Lolkatzen zum Beispiel.

So - weil ich Soup toll finde hab ich mich entschlossen rechts ab und zu einen RSS Feed von jemandem, der auf Soup postet einzubinden. Ich kenne die Leute nicht sondern sie sind mir nur bei der Gesamtübersicht über den Weg gelaufen. Die Links in den Einträgen sind übrigens meist Bilder.

Und eines noch - versucht mal auf der Hauptseite von Soup.io ganz nach unten zu scrollen

Solangsam nervts…

Hallo Leute.

Da ich gerade am gesundwerden bin (hatte letzte Woche Dienstag ne OP) komm ich nicht so viel zum schreiben sondern bin eher dauernd am schlafen. Heute hab ich allerdings mal wieder geschrieben - undzwar in der Wikipedia. Und - ratet mal was passiert ist: Ich hab mal wieder Löschantragkeule auf den Kopf bekommen.

Naja und irgendwie muss man seinem Ärger ja Ausdruck verleiehen und ich tue es in dem ich mal (ironisch) den Standardprozess zur Artikelerstellung in der deutschen Wikipedia darstelle:

(Bitte klicken )

Rumwikipedianern

Seit etwas über einem Monat bin ich nun etwas intensiver in der Wikipedia aktiv und nun will ich mal ein bisschen darüber schreiben wie das Rumwikipedianern denn nun so ist.

Für mich als Blogger drängt sich natürlich der Vergleich zwischen Bloggen und dem Arbeiten in der Wikipedia (auch WP bzw. de-WP, ohne Artikel genannt) auf. Aber es ist ein doch beachtlicher Unterschied, der daher kommt, dass man nicht wie beim Bloggen einfach nur seine Artikel über Kram, der einen interessiert schreibt, sondern auf einiges achten muss. Es gibt da so mehrere Grundregeln, die auch alle tolle Abkürzungen haben (das mit den Abkürzungen ist so eine Wikipediakrankheit ) :

• AGF (”Assume Good Faith” also “Unterstelle gute Absichten”)
• NPOV (”Neutral Point Of View” also “Neutrale Sichtweise”) - sagt dass Artikel neutral geschrieben werden sollen
• Was Wikipedia nicht ist
• RK (Relevanzkriterien) - für jedes Themengebiet gibt es Relevanzkriterien die zu beachten sind
• OMA (Ohne mindeste Ahnung) - besagt dass ein Artikel (meist durch einen Einleitungssatz) auch für jemanden, der keine Ahnung vom Themengebiet hat grob verständlich sein sollte

Das sind nur einige der Sachen, die man kennen und beachten sollte bevor man los schreibt, editiert, Änderungen rückgängig macht, über Artikel diskutiert, Löschanträge stellt, an Löschdiskussionen teilnimmt, oder, oder, oder …

Mit diesen Grundsätzen gibt es natürlich auch einige Probleme. So ist zum Beispiel zu Fragen was denn ein neutraler Standpunkt ist. Bei manchen Themen ist dieser Standpunkt nur sehr schwer zu bestimmen. Ist ein neutraler Standpunkt bei Artikeln über UFOs bspw. der, der davon ausgeht, dass alle solche Phänomene mit uns bekannten Dingen zu erklären sind?

Ein weiteres Problem ist meiner Meinung nach das OMA-Prinzip. Es gibt Themen, die nicht für jeden verständlich sind, da sie sehr komplex sind. Artikel über bestimmte Proteine, sind für viele Menschen zum Beispiel nicht verständlich, da es ein enormes Vorwissen braucht um die Artikel zu verstehen.

Man sieht schon, dass manche Fragen auch darauf hinauslaufen zu fragen - Was ist die Wikipedia? Die Wikipedia selbst weiß was sie nicht ist, kennt aber auf die Frage was sie ist nur eine Antwort: Sie ist eine Online-Enzyklopädie.

Die unterschiedlichen Sichtweisen auf Themen und Grundsätze sind das was das Arbeiten in der Wikipedia, abseits des puren Schreibens und Erweitern von Artikeln (für mich zumindest) sowohl spannend als auch anstrengend macht.

Link-Prefetching - Nee lieber nich

Mal wieder was, was ich bisher noch nicht wusste.

Firefox lädt verlinkte Seiten vor auch wenn man sie garnicht klickt. So weit so alarmierend. Geht man aber ins Detail ist es weniger scary als es klingt. Es werden nämlich keine <a href=”…”> Links vorgeladen, sondern nur Links die speziell gekennzeichnet sind. Die Kennzeichung im (X)HTML-Quellcode sieht folgendermaßen aus: <link type=”prefetch” href=”…” />. Statt dem Type Prefetch kann auch der Type Next gesetzt werden.

Von dieser Möglichkeit machen bisher nur wenige Seiten gebrauch. Eine Seite, die das tut ist - Google. Suchergebnisse von Google werden von Firefox per Default vorgeladen.

Was man vielleicht auch noch dazu sagen muss, ist dass Firefox das Vorladen dann durchführt wenn es gerade “idle ist”.

Vielleicht sollte man auch noch kurz erklären, warum das Ganze etwas bedenklich ist. Der Vorteil liegt klar auf der Hand - kürzere Ladezeiten wenn man den Link wirklich anklickt. Nachteile gibt es gleich mehrere. Fangen wir mal bei einer praktischen Überlegung an:

Man stelle sich vor man hätte einen UMTS-Datentarif mit dem man auf dem Laptop surft. Wenn Firefox auf die glorreiche Idee kommt verlinkte Suchergebnisse vorzuladen, die man nicht anklicken wird, wirds möglicherweise recht teuer.

Nun kann man sich auch ein anderes Szenario vorstellen. Vielleicht enthalten ja die Suchergebnisse auch eine Seite, die man lieber nicht anklicken will und vllt auch sollte - Tierkinderpornos von Nazis oder so. Das weiß ja nun der Firefox nicht. Er “besucht” die Seite trotzdem. Die IP steht trotzdem in den Logfiles der Seite.

So nachdem ich nun ein wenig rumgejammert habe jetzt noch ein Tipp wie man das Ganze verhindert und trotzdem den geliebten Firefox nutzen kann Man tippt in seinen Browser einfach mal about:config ein (und sagt seinem Browser, dass man weiß was man tut) und setzt dann den Wert von network.prefetch-next auf false. Fertig is

A new spare time killer

Hallo Leute,

in letzter Zeit habe ich etwas weniger geschrieben und das hat auch einen Grund. Erstens is es warm draußen wie Hölle und da is mein Gehirn immer ein bisschen im Idiotenmodus und zweitens bin ich seit ein paar Tagen bei der Wikipedia angemeldet und schreibe dort auch.

Genauer gesagt ist das seit Montag der Fall. Am Montag war WWDC-Beginn - also Keynote. Und wie das so auf der Keynote ist, wurden viele bunte glitzernde Sachen vorgestellt. Darunter der neue MobileMe-Service, der .Mac ablösen wird.

Also hab ich meinen ersten Beitrag dort geschrieben. Der hat zwar gleich mal nen Löschantrag gekriegt, aber das ist wohl nichts ungewöhnliches und er hat auch ganz gute Chancen durchzukommen denk ich.

Und solangsam findet man sich dort auch ganz gut rein und lernt die Gepflogenheiten kennen. Man lernt dass man das Thema über das schreiben möchte erstmal gegen die Relevanzkriterien abprüfen sollte. Man kriegt mit, dass es Löschregeln gibt und dass sich an die meisten dieser Regeln kein Mensch hält. Und dabei hilft es wenn man jemanden kennt, der schon lange WIkipediaadmin ist.

Trotzdem hoff ich in der nächsten Zeit auch wieder mehr Zeit und vor Allem interessante Themen zum bloggen zu haben.

Es gibt was neues - und du weißt davon…

… denn NoMule 2008.05.16 ist draußen und es unterstützt Updatenotifications.

Das heißt, dass dir das Programm wannimmer eine neue NoMuleversion da ist darüber bescheid geben wird. Oder auch nicht. Denn du kannst dieses Verhalten auch über Einstellungen ausschalten.

Zu den Einstellungen, die du jetzt über ein Configfile machen kannst gehören:

• Automatische Updatesuche ein/ausschalten
• Den Familyfilter, der die Anzeige von Porncommunities unterdrückt, ein oder ausschalten

Kürzlich gab es ein paar Probleme mit YouTube, Google Video und Dailymotion, da die Seite die für die Linkumwandlung genutzt wird ihre URL geändert hat. Diese Probleme wurden mit der neuen Version behoben.

Es wurde auch ein neuer Medienprovider hinzugefügt. MySpass (dämlicher Name oder?!). Das ist die Videocommunity von Brainpool. Da gibts dann so Commedians wie Bastian Pastewka oder Axel Stein.

Wie immer könnt ihr NoMule nun hier herunterladen.

Nee oder?!

Also ich mein dass Bild jetz nich grad das Premium-Medium ist is klar.

Aber sowas hier auf Bild.de:

Das geht ja nun mal garnicht.

Insulting sourcecode explained

(…) [S]ince SVN revision r4027 quodlibet’s source code is personally insulting me (…)

Wenn man das ließt denkt man erstmal - WTF?! Aber dahinter steckt eine Geschichte, die zeigt, dass es bei großen Projekten genauso zugehen kann wie im Kindergarten.

Dabei geht es darum, dass ein gewisser Sebastian Dröge wohl codetechnischen Mist gebaut hat undzwar in GStreamer, dem Mediaframework von GTK. GStreamer wird unteranderem benutzt von einem Audioplayer namens Quod Libet. In diesem Audioplayer musste herausgefunden werden, welcher Code sich um das Protokoll “file://” kümmert. Dazu wurde einfach “file://” an eine bestimmte Funktion übergeben. Durch den Bug in GStreamer hat das aber nicht mehr gefunzt.

Soweit so gut. Statt file:// kann man wohl auch irgendeine nicht existente URI mit dem Fileprotokoll übergeben um das gleiche zu erreichen. Was haben sie also gemacht? Sie haben file:// durch

file:///Sebastian/Droge/please/choke/on/a/bucket/of/cocks

ersetzt.

So und davon fühlte sich der Typ nun beleidigt. Verständlich - und man fragt sich nochmals - WTF?! Kindergaten?!

Auf der anderen Seite- wenn man mal eine Google Code Search nach “Bill Gates” macht kommt da auch nicht viel schönes raus.

Update: Was einmal war ist nun komplett anders. Und Schwänze werden zu Keksen.