ViUR - Feature Video: Es ist da !

Zusammen mit der Hochfarbe GmbH, die mit uns im Technologiezentrum in Schwerte sitzt und mit der wir gerade viele coole Projekte umsetzen, entstand über Weihnachten und Neujahr das ViUR - Feature Video.

Warum ein Feature Video ?

Mensch sollte den Aufwand solch ein Video zu produzieren nicht unterschätzen! Trotzdem wollten wir es zum Release der ersten Versionen von ViUR direkt schon richtig knallen lassen. Das Video ist daher nun an vielen Stellen ein zentraler Baustein unserer Kommunikationsstrategie, die vor allen Dingen erst einmal online und dort über die Socialmedia Kanäle laufen soll. Taucht das Video z.B. im Facebook oder Google+-Stream auf, so können die Nutzer mit einem klick das Video starten und müssen dazu nicht einmal ihren Stream verlassen. Wir haben somit einen niedrig schwelligen Einstieg geschaffen um die Markenwelt zu kommunizieren.

Durch die verspielten und an einigen Stellen auch effektvollen Animationen hoffen wir, dass das Video auch geteilt wird, wenn wir nicht auf die passende Zielgruppe treffen. Als Zielgruppe sehen wir natürlich vor Allem die von ViUR.is, also Einzelkämpfer, Gruppen sowie Agenturen/Unternehmen die sich schon sehr lange mit Web-Programmierung beschäftigen und die an vielen Stellen schon Erfahrungen mit Softwarearchitekturen gemacht haben und daher verstehen, warum wir nach festen/diesen Paradigmen unsere Projekte durchführen.

Das Feature Video kann nun an vielen weiteren Touchpoints auftauchen und einen guten Eindruck machen:

• Als Einstieg auf ViUR.is
• Auf der Mausbrand.de Technologieseite
• Im Youtube Channel von ViUR
• wie schon beschrieben in den sozialen Netzen
• auf den Bitbucket-Seiten von ViUR

Aber auch 

• auszugsweise (manchmal ganz ..) bei Kundenpräsentationen
• bei Präsentationen für technische Ansprechpartner von Kunden und Kooperationspartnern
• bei Messe/Kongress-Ständen (ohne Ton)

Wie haben wir das Video-Projekt umgesetzt ?

1. Zunächst haben wir die Zielgruppe und darauf aufbauend die groben Inhalte in einem Brainstorming in der Gruppe besprochen und anschließend eine aufeinander aufbauende Gliederung definiert,
2. anschließend mit Apple-Keynote uns einen Visuellen Ablauf modelliert.
3. Ergänzend dazu entstand in einem für alle Gruppenmitglieder freigegebenen Google-Doc. die ungefähre Beschreibung der Animationen und der damit verfolgten Kommunikationsziele.
4. Diese wurden dann um den Sprecher-Text erweitert. Der Text richtet sich natürlich nach den Corporate-Kommunikation-Vorgaben von ViUR.is, die z.B. eine direktere Ansprache (Du) nutzen als die von Mausbrand.
5. Nach vielen Iterationen, die vor Allem sehr gut von der Google-Docs Kommentarfunktion unterstützt wurden habe ich den Kollegen den Sprechertext laut vorgelesen worauf hin wir noch weiteren Feinschliff vorgenommen haben.
6. Dann ging der Sprechertext zu www.0700sprecher.de von denen dann Herr Hassinger mit mir noch die Aussprache von ViUR diskutierte.
7. Nach einem Tag hatten wir ein super Soundfile im Postkasten und schnürten daraufhin ein Paket: 
• Keynote Mockup der Visuellen Elemente
• Google Docs Datei mit Sprechertext und Animationsbeschreibungen
• den gesprochenen Text (Soundfile)
• und natürlich dazu die ganzen Bilder / Icons usw. vom ViUR Corporate          
8. Alex setze dann alles zusammen und renderte über Silvester das erste Preview raus.
9. Dieses ging dann bei uns durch eine Anmerkungen-/Kontrollschleife, die wir anhand des Google docs Dokuments wieder festhielten.
10. Gestern renderte dann die Hochfarbe Renderfarm das Video in Full-HD raus und seitdem könnt ihr es euch auf Youtube anschauen.

Fun with Google's Appengine: Surfin’ U.S.A.

Pünktlich zu Weihnachten gibts von uns dieses Jahr ein kleines Script für alle, die mal schnell eine "Ist in deinem Land nicht verfügbar" - Nachricht umgehen müssen.

Die Appengine bietet neben vielen Tutorials und Beispielanwendungen auch die Möglichkeit, über shell.appspot.com direkt Sachen innerhalb der GAE auszuprobieren. Das Script gaeproxy.py erzeugt einen lokalen HTTP-Proxy auf Port 4321, der alle Anfragen über diese Shell tunnelt. Damit werden die Anfragen von einer IP in den USA (74.125.182.35) an die jeweilige Webseite gestellt und umgehen so länderspezifische Webblockaden.

z.Z. unterstütz das Script nur einfache HTTP-Gets mit einer maximalen Größe von c.a. 500KB.
Cookies, HTTP-Post und Antwort-Größen bis ~1Mb würden sich noch recht einfach implementieren lassen; für HTTPS-Unterstützung währe der Aufwand schon recht groß.
Hinweis: Die Verbindung vom Proxy->shell.appspot.com ist nicht verschlüsselt!

Proxy herunterladen

Sicherheit in der GAE - Teil 3

Die Sandbox

Alle Anwendungen der GAE werden in einer Sandbox ausgeführt. Diese stellt Anwendungen einen eingeschränkten Interpreter für die jeweilige Sprache sowie eine API für alle von der GAE bereitgestellten Zusatzdienste bereit. Gleichzeitig erzwingt sie die Abgrenzung zwischen der Anwendung und der darunter liegenden Plattform.

Anwendungen werden beim Upload in der GAE in einen Anwendungscontainer zusammengefasst. Dieser enthält alle Anwendungsdateien und Ressourcen, jedoch nicht die Verzeichnisse, die über die Konfigurationsdateien direkt als statischeVerzeichnisse nach außen freigegeben sind. Der Anwendungscontainer ist read-only, d.h. es ist nicht möglich aus einer Anwendung heraus in das Dateisystem zu schreiben. Dies schützt die Anwendung im Falle einer Kompromittierung vor Manipulationen des Programmcodes und der in diesem Container mitgelieferten Ressourcen [1]. Bis Version 1.7.2 war die Anzahl der Dateien aus der die Anwendung bestehen kann (inkl. der statischen Dateien und Ressourcen) auf 10.000 und die Gesamtgröße dieses Containers auf 1Gb beschränkt [2].

Abschirmung der Plattform

Die Sandbox verhindert den Zugriff auf die darunterliegende Plattform und das Betriebsystem, indem verschiedene Funktionen des Interpreters abgeschaltet sind. Im Gegensatz zur Java-Version der GAE, bei der einzelne Klassen der Standardbibliothek freigeschaltet sind [3], sind bei Python fast alle Module, die in Python selbst geschrieben sind, verfügbar. Allerdings sind nahezu alle Erweiterungen, die in C geschrieben sind, entfernt. So sind neben dem ctypes-Modul, das Zugriff auf Funktionen von externen Librarys ermöglicht, auch das _socket Modul nicht verfügbar.

Abschirmung des Internets

Neben dem Schutz der Anwendung und der Plattform selbst sind auch Maßnahmen ergriffen, um andere Systeme und Netzwerke im Internet vor Angriffen aus der GAE heraus zu schützen. So besteht keine Möglichkeit aus der GAE eine direkte Verbindung zu anderen Systemen im Internet aufzubauen. Für das abrufen von URLs steht ein Proxy zur Verfügung, der verschiedene HTTP-Header in der ausgehenden Anfrage erzwingt [4]. Für den Versand und Empfang von E-Mails steht ebenfalls eine API zur Verfügung, die die E-Mails über einen Proxy leitet und so beispielsweise Missbrauch durch eine gefälschte Absenderkennung verhindert [5]. Allerdings wird die Möglichkeit, direkt ausgehende IP-Verbindungen zu erlauben z.Z. von Google getestet [6, App Engine 1.7.2 Released]. Damit könnten diese Beschränkungen in einer zukünftigen Version entfernt werden.

[1] Python Runtime Environment
https://developers.google.com/appengine/docs/python/runtime

[2] Google App Engine Python SDK Release Notes
http://code.google.com/p/googleappengine/wiki/SdkReleaseNotes

[3] The JRE Class White List
https://developers.google.com/appengine/docs/java/jrewhitelist

[4] URL Fetch Python API
https://developers.google.com/appengine/docs/python/urlfetch/overview

[5] Mail Python API
https://developers.google.com/appengine/docs/python/mail/overview

[6] News, Notes, tips and tricks from the Google App Engine Team
http://googleappengine.blogspot.de

Sicherheit in der GAE - Teil 2

Funkionsweise der GAE

Die GAE ist ein verteiltes System zum Bereitstellen von Webanwendungen. Die GAE liegt z.Z. in drei Versionen vor: Python (wahlweise in den Versionen 2.5 oder 2.7), Java oder in der von Google selbst entwickelten Programmiersprache Go. Anwendungen werden zunächst lokal mittels einem von Google bereitgestellten Software development Kit (SDK) erstellt. Dieses simuliert die von der GAE bereitgestellten Application programming interfaces (APIs) und stellt einen lokalen Webserver bereit, auf dem die Anwendung getestet werden kann. Anschließend wird die Anwendung „deployed“, d.h. mittels eines mit dem SDK mitgelieferten Programms in die GAE hochgeladen. Hierbei werden die Anwendungsdaten in einem Container zusammengefasst, der beim Aufruf der Anwendung von einem Server der GAE geladen und die Anwendung hieraus ausgeführt wird. Für den Betrieb der Anwendung stellt Google verschiedene Dienste wie Datenbanken oder einen Dienst zum versenden von E-Mails bereit. Für die Nutzung dieser Dienste entstehen entsprechend dem Nutzungsvolumen Kosten. Allerdings stellt Google jeder Anwendung einen gewisse Menge an Ressoucen pro Tag kostenlos zur Verfügung, sodass die Appengine risikofrei getestet werden kann. Weiterhin gelten für verschiedene Dienste sogenannte Safety Quotas [1], die verhindern, dass einzelne Anwendungen einen Dienst überlasten und dieser so für andere Anwendungen der GAE vorübergehend nicht zur Verfügung steht. Diese Limits dienen ausschließlich zur Planung der benötigten Ressourcen und stellen keine technischen Beschränkungen dar, sodass diese auf Anfrage [2] erhöht werden können. Konkret sind folgende Ressourcen von Bedeutung, da diese von den meisten Webanwendungen verwendet werden.

• Ein- und ausgehender Traffic: Für freie Anwendungen gelten Limits von je 1GB Traffic/Tag sowie maximal 56MB/Minute. Bezahlte Anwendungen haben z.Z. unbegrenzten, kostenlos eingehenden Traffic sowie ausgehenden Traffic für 0.12$/GB (je 1GB/Tag kostenlos; Maximum 10GB/Minute).
• Datenbank: Freie Anwendungen erhalten je 50.000 Schreib-, Lese- und Small-Ops1 pro Tag. Bezahlte Anwendungen können diesen Dienst beliebig für 0,1$/100k Schreiboperationen, 0,07$/100k Leseoperationen und 0,01$ 100k Smallops nutzen. Dies sind jedoch low-level Operationen; das Einfügen eines Eintrags benötigt ggf. mehrere dieser Schreiboperationen [3].
• URL-Fetch: Freie Anwendungen können diesen Dienst zum Abruf entfernter URLs höchstens 657.000 mal pro Tag nutzen. Weiterhin gelten für sie Beschränkungen von maximal 3.000 Zugriffen/Minute mit je maximal 22MB/Minute gesendete oder empfangene Daten. Die über diesen Dienst übertragenen Daten zählen ebenfalls zum ein- und ausgehenden Traffic der Anwendung. Für bezahlte Anwendungen gelten die gleichen Vorraussetzungen, jedoch besteht hier ein Tageslimit von 46.000.000 Zugriffen/Tag sowie maximal 32.000 Zugriffe/Minute mit je maximal 740MB übertragenen Daten pro Minute.
• Instanzstunden: Die GAE startet Instanzen der Anwendung nach Bedarf. Sinkt der Bedarf, wird eine Instanz 15 Minuten nach dem letzten Zugriff auf sie entweder abgeschaltet oder weiterhin vorgehalten, jedoch bis zum nächsten Zugriff nicht weiter angerechnet. Freie Anwendungen erhalten 28 Instanzstunden/Tag, bezahlte Anwendungen können darüber hinaus weitere Instanzstunden für 0.08$/Stunde nutzen.

[1] Quotas and Safetylimits
https://developers.google.com/appengine/docs/quotas

[2] Quota Increase Request
http://support.google.com/code/bin/request.py?\&contact_type=AppEngineCPURequest

[3] Billing and Budgeting Resources
https://developers.google.com/appengine/docs/billing

Einführungsinterview zu ViUR

Gestern haben wir das Einführungs-Interview zu ViUR bebildert und auf den neuen Youtubechannel: weloveViUR gestellt. Über Weihnachten sollen noch 2-3 Videos folgen zu:

• Inbetriebnahme von ViUR-Projekt unter Windows
• Installation und Kurzeinführung zu ViUR Admin
• Ändern der Nutzerauthentifizierung bei ViUR-Projekt von von ViUR verwalteten zu Googlekonten

... und vielleicht gibt es ja vor Weihnachten noch eine kleine Überraschung....

Sicherheit in der GAE - Teil 1

Webanwendungen stellen inzwischen eine Kernkomponente des Internets dar. Ein Großteil des Umsatzes im E-Commerce wird über Webanwendungen abgewickelt. Allein in Deutschland wird der Umsatz im E-Commerce für 2012 auf 29,5 Milliarden Euro geschätzt, 13% mehr als in 2011 [1]. Bedingt durch diese rasant steigende, gesamtwirtschaftliche Bedeutung von Webanwendungen rückt deren Sicherheit und Verfügbarkeit zunehmend in den Fokus.

Die GAE ist deshalb mit mehren Sicherheitsaspekten versehen, die Angriffe auf Anwendungen erschweren und im Falle von erfolgreichen Angriffen die Auswirkungen auf die Anwendung minimieren sollen. Weiterhin wurden diverse Maßnahmen ergriffen, um die GAE selbst zu schützen und negative Effekte von einer Anwendung auf andere Anwendungen zu minimieren.

 Im Laufe dieser Serie werden mögliche Angriffe auf die Verfügbarkeit einer Anwendung der GAE (Python) aufgezeigt und Gegenmaßnahmen vorgestellt.

[1] Handelsverband Deutschland: E-Commerce-Umsatz in Deutschland von 1999 bis 2011
http://de.statista.com/statistik/daten/studie/3979/umfrage/e-commerce-umsatz-in-deutschland-seit-1999