Um es gerade vorweg zu nehmen. Der Titel stimmt juristisch natürlich so nicht, technisch hingegen schon.
In der Vergangenheit, sprich vor 15 Jahren, war JavaScript eine Sprache für Hacker und Spieler. Javascript aus Sicherheitsgründen zu deaktivieren war normal. Die Business Logik einer Webseite fand ausschliesslich auf dem Server statt. In den vergangenen Jahren hat sich hier einiges geändert: Kaum eine Webseite, welche nicht irgend einen Schnipsel Javascript benötigt und mit HTML5 hat sie auch noch ein hübsches Logo bekommen. Javascript ist erwachsen und salonfähig geworden.
Flickr (http://www.flickr.com/photos/epstudios)
Krieg der Mobilen Technologien
In der Appszene herrscht eine wahre Technologie Schlacht. Da gibt es auf einen Seite die iOS vs Android Schlacht und damit die Java vs Objective-C und auf der anderen Seite die Native vs HTML5 Schlacht. Ich möchte hier weniger auf die Sprachschlacht eingehen sondern mir das HTML5 Camp ein bisschen genauer anschauen.
Was ist HTML5
Viele Laien denken immer noch, HTML5 sei eine Programmiersprache: «Wir möchten die App gerne in HTML5 geschrieben.» Falsch. HTML5 ist ein Konzept oder Framework, welches basierend auf HTML, Javascript und CSS ist. Jede dieser drei «Säulen» übernimmt einen Teil: HTML ist für die Struktur einer App zuständig, CSS für das Look and Feel und Javascript für die Logik.
In den meisten Fällen kommt auch noch irgend eine Serversprache hinzu: PHP, Ruby, Python oder Node.js für die coolen Kids (Randbemerkung: PHP und Python sind Dinosauriere und das sieht man den Seiten auch an. Die bräuchten mal einen Designer). Via REST Interface werden so Daten vom Server geholt, verarbeitet und verteilt. Diese klassische Client Server Architektur ist wohl bekannt und daher auch sehr einfach. Interessant wäre hier eine verteilte Peer-to-Peer Architektur für eine App, doch in den meisten Fällen würde das wenig Sinn machen, bzw. würde die Komplexität massiv erhöhen.
Entwicklung von HTML5
HTML5 entwickelt sich rasant weiter. Chrome ist der Treiber der Szene. Wenn irgendwelche neuen Spezifikationen hinzukommen, dann sind sie sehr oft die ersten, welche sie umsetzen.
Features, welche bereits gegeben sind, sind diverse Möglichkeiten für Offline speicher, Zugriff auf lokale Daten, GPU Unterstützung für Rendering, verschiedene Optionen, Form Element zu rendern und und und. Das Feld ist relativ unübersichtlich. Auf der Seite HTML5 Test, kannst du schauen, wie gut dein Browser HTML5 unterstützt.
Wenn die Entwicklung so weitergeht, dann sind die APIs bald schon sehr mächtig und werden von den meisten aktuellen Browsern auch unterstützt. HTML5 Apps steht dann also nichts mehr im Weg.
Was ist der Vorteil von HTML5
Ich gehe hier davon aus, dass alle Geräte die benötigten HTML5 Spezifikationen unterstützen. HTML5 hat dann den riesigen Vorteil, dass es wirklich Cross Plattform Kompatibel ist. Das heisst: Ich schreibe eine App und kann diese dann sowohl auf einem Blackberry, einem Notebook und einem iPad benützen, ohne grosse Modifikationen. Wahrscheinlich wird es noch die eine oder andere Anpassung brauchen, wie wir das seit jeher kennen.
HTML5 Apps sind also Native Browser Apps, welche halt einfach anstatt in einer VM in einem Browser laufen. Die Entwicklung geht jedoch weiter: Firefox OS Apps sind HTML5 Apps. Es ist also kein Browser notwendig, sondern die Apps laufen als solches Native im OS. Daher: Eine HTML5 App, welche ich geschrieben habe, kann ich problemlos auch gleich für Firefox OS verwenden.
via Flickr @doctorserone
Titanium, PhoneGap und Co.
Dann gibt es die Hybride: Appcelerator Titanium und PhoneGap, sind die, welche ich kenne. Ohne im Detail darauf einzugehen: Die eigentlich Logik der App wird in Javascript geschrieben (ja, es sind zwei komplett unterschiedliche Technologien, aber dazu vielleicht ein anderer Post).
Meine Vermutung hier ist, dass besonders Appcelerator Titanium eher eine mittelfristige Lösung ist. Ich kann mir gut Vorstellen, dass die in 5 Jahren nicht mehr in der aktuellen Form existieren (aber bis dahin baue ich noch darauf auf).
HTML5 = OpenSource
Nach dieser langen Einleitung und Ausschweifung komme ich endlich zum Punkt: HTML5 ist Open Source. Nicht Open Source als Lizenz sondern Open Source im buchstäblichen Sinn.
Wenn ich meine App im Browser Öffne, kann ich den Source Code und mir Schnipsel oder auch den ganzen Code herauskopieren. Mit PhoneGap und Titanium sieht das ein kleines bisschen anders aus: Zuerst muss ich an die App Datei herankommen, welche im Grunde genommen lediglich ein Zip File ist. Darin versteckt sich der ganze Code, welcher komplett offen ist. Um an die App Datei zu kommen brauche ich lediglich ein «gejailbraktes» Gerät.
Also meine streng geheime vielleicht patentierte Software kann von jedermann gelesen und kopiert werden (vergl. den riesigen Streit zwischen Google und Oracle, wegen neun Zeilen Java Code).
Möglichkeiten zum Schutz
Es gibt sogenannte Obfuscator. Diese verschleiern Javascript u.a. so dass es unlesbar wird. Beispiel dafür sind z.B. YUI Compressor. Hier ein kleines Beispiel, basierend auf jsobfuscate.com:
self._isNetworkConnectionAvailable = function() {
if (Titanium.Network.networkType === Titanium.Network.NETWORK_NONE) {
return false;
}
return true;
}
Und was der Obfuscator daraus macht sieht dann wie folgt aus:
eval(function(p,a,c,k,e,d){e=function(c){return c.toString(36)};if(!''.replace(/^/,String)){while(c--){d[c.toString(a)]=k[c]||c.toString(a)}k=[function(e){return d[e]}];e=function(){return'w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('b'+e(c)+'b','g'),k[c])}}return p}('6.4=3(){5(1.0.7===1.0.8){2 a}2 9}',11,11,'Network|Titanium|return|function|isNetworkConnectionAvailable|if|self|networkType|NETWORKNONE|true|false'.split('|'),0,{}))
Zugegeben, das wird definitiv unleserlich, doch stellen nicht wirklich ein Problem dar. Ein Copy & Paste auf jsbeautifier und schon ist der Code wieder schön. Ich habe mal den definitiv unleserlichen Code von Gmail reinkopiert, 2 Sekunden später habe ich leserlichen Javascript Code in der Hand.
Ist das der Weisheit letzter Schluss?
Ich kann mir nicht vorstellen, dass HTML5 Applikationen vor dem grossen Durchbruch stehen, solange hier nicht eine Lösung gefunden wird. Solange das nicht der Fall ist, ist die einzige Möglichkeit, Code zu schützen, die Logik auf den Server zu verlagern, wo er vor unbefugtem Zugriff geschützt ist. Das wiederum führt dazu, dass ich ständig eine Online Verbindung brauche. Mag sein, dass mit den heutigen WiFi und G3 bzw. LTE Netzen, das nicht mehr so eine Sache ist, aber spätestens wenn ich im Ausland bin, bin ich froh, wenn ich eine App auch Offline verwenden kann.
Es müsste daher eine Möglichkeit geben, Javascript Code als Bytecode abzuspeichern, welcher dann von der entsprechenden Javascript VM interpretiert werden kann. Ich bin überhaupt kein Experte auf diesem Gebiet, aber Axel von Javascript and more, ist der Meinung, dass es kaum realistisch ist, dass sich die verschiedenen Browserhersteller auf ein einheitliches Format einigen würden:
I don’t think we could get browser vendors to agree to a common bytecode for all JavaScript virtual machines, because there is no common ground.
Javascript zuerst in Bytecode zu kompilieren, wäre nicht mehr Javascript. Die Offenheit des Internets würde darunter leiden und es passt einfach nicht zu Javascript. Es wäre nicht mehr JavaSCRIPT, sondern JavaKOMPLIZIERT. Was würde die ganze Community rund um JSFiddle machen? Denn diese Dienste wären doch eher aufwändiger, wenn zuerst noch Bytecode erstellt werden muss.
Und die Lösung ist?
Mir noch unbekannt. Vielleicht kenne ich sie einfach noch nicht und sie liegt bereits da draussen irgendwo und vielleicht gibt es sie auch einfach noch nicht. Vielleicht ist es auch gar kein Problem und ich mache lediglich eines daraus?
Vielleicht wäre eine Möglichkeit, eine App mit einem Key zu packen und zu zertifizieren. Alle Browserhersteller kennen den Key und können den somit öffnen. Wahrscheinlich könnte man sich hier etwas von der Musik und Filmindustrie abschauen, welche mit relativ wenig Erfolg solche Digital Right Management (DRM) auf ihren Tonträgern einsetzen. Und vielleicht ist auch gerade das ein Beispiel dafür, dass ein DRM sowieso nichts bringt und man es daher auch gleich lassen soll.
Wahrscheinlich ist die Lösung ein Mix aus allen Faktoren:
- Die Hürde so hoch wie möglich setzen, z.B. durch einen Obfuscator
- Keine kritische Daten wie z.B. Passwörter in der App speichern
- Hochgeheime Algorithmen auf den Server verlagern.
Ich bin der Meinung, dass dies für gewisse Firmen nicht akzeptabel ist und daher gewisse Programme auch nicht als HTML5 App veröffentlicht werden, aber was noch nicht ist kann noch werden.