Hallo und Humppa! nach Deutschland,

ein salatreiches Mittagsessen mit verschiedenen Nudelsorten fand ich recht unamerikanisch. Geschmeckt hat es wunderbar ( und BBQ ist für heute Abend geplant ).
Giorgio Natili berichtet in seinem Nachmittagsvortrag über „Flex and Accessability“. Dabei stellt er kurz die grundlegenden Möglichkeiten des Flash Players vor, die sich im Wesentlichen auf die Microsoft Active Accessibility (MSAA) beschränken. Bei der entsprechenden Verwendung können Screenreader damit auf die einzelnen Flash Komponenten zugreifen und entsprechenden Inhalt vorlesen. Dem Entwickler stellen sich dabei allerdings eine Reihe von Problemen.

Zum einen ist für eine bestmögliche Unterstützung mindestens der Flash Player 9.0.115 ( gleichzeitig die erste Version die auch den Firefox mit Accessability versorgt, früher Versionen waren beschränkt auf den IE ) erforderlich. Auf der anderen Seite muss aber auch ein möglichst aktueller Screenreader stehen. Was nicht unbedingt Teil des Vortrags war wir aber hinterher durchaus diskutiert haben, ist gerade die aktuelle Software nicht das was der Entwickler auf dem Client zu erwarten. Häufig sind entsprechende Systeme relativ „konservativ“ konfiguriert.
Unabhängig davon, dass aktuell nur Windows als Host unterstützt wird, der Mac aber in Vorbereitung zu sein scheint, kann der Accessability anstrebende Entwickler noch lange nicht auf eine ausgereifte Tastatursteuerung zurückgreifen. Für Standardkomponenten funktioniert dies wunderbar, sofern man das tabEnable-Attribute entsprechender Komponenten auf true setzt.
Spätestens wenn eigene Komponenten zum Einsatz kommen, innerhalb derer eine Tastatursteuerung möglich sein soll, muss der Entwickler Hand anlegen, da ansonsten die inneren Elemente der eigenen Komponente übersprungen werden. Giorgio entfernt dazu z.B. dynamisch alle tabEnable-Attribute umliegender Elemente und setzt sie dafür an alle Elemente der eigenen Komponente. Wird das letzte Element der eigenen Komponente verlassen werden alle anderen wiederum neu belegt.
Das gleiche Problem, dass auch AJAX-Webseiten haben, nämlich dem Screenreader mitzuteilen, dass sich der Inhalt eines Elementes verändert hat lässt sich über die Methode sendEvent() der Accessability Klasse lösen. Diese kaum dokumentierte, aber existente Methode feuert entsprechende Events über die MSAA-API an den Screenreader, der darauf hin die entsprechenden Änderungen wahrnimmt.

Unter dem Titel „Encrypting Flex, Protecting Revenue, and Making Cash!“ stellt Andrew Westberg für den Sponsor Simplified Logic deren Produkt Nitro-LM vor. In weiten Teilen der Flex Community wird Code freizügig zur Verfügung gestellt und die viele Lösungen sind frei verfügbar. Aber es soll ja auch Unternehmen geben, die damit tatsächlich Geld machen wollen. Aber was wenn das SWF-File einmal im Internet verwendet und für den Rest der Menschheit ansurf- und herunterladbar ist ?! Nachdem ich das erste mal einen SWF-Decompiler in Action gesehen habe und wie der mein komplettes Projekt aus einer SWF-Datei wiederherstellte war klar, dass es sich bei SWF-Files im Grunde um Open Source handelt. Nicht zuletzt da SWF in der Tat ein offenes Format ist.
Stufe 2 des Code Hiding, nach dem kompilieren als SWF, ist der Versuch den Code soweit unlesbar zu machen – Obfuscating – sodass zumindest ein menschlicher Entwickler nichts mehr damit anfangen kann. Nachdem Andrew 3 verschiedene Tools vorgestellt hat, die meinten diese Aufgabe zu übernehmen, und zwei unterschiedliche Tools sogar ein identisches Resultat lieferten, der Code aber trotzdem noch „gut“ lesbar war, oder zumindest mit Suchen und Ersetzen lesbar gemacht werden konnte, schienen auch das nicht Mittel der Wahl zu sein.
Einen interessantern Ansatz verfolgte Stufe 3. Diese macht sich den Umstand zur Nutze, dass entsprechende Decompiler in der Regel nicht eingebettete Inhalte durchsuchen. Das vorgehen ist also wie folgt: Erstelle ein Libraryfile, das z.B. ein Interface implementiert, mit all dem Code den du schützen möchtest. Verschlüssel dieses File z.B. durch Bytearray-Operationen. Baue eine Factory die das Laden und entschlüssel übernimmt; nutze das Interface. Dies geht leider in diesem Sinne nur für AS-Code nicht aber für umgebendes MXML.
Stufe 4 ist nun die angepriesene Lösung von Simplified Logic. Diese stellen eine Komponente bereit die Flex-Module nachlädt. Nach dem Erstellen der Module werden diese durch eine bereitgestellte AIR-Anwendung mit einem privaten Schlüssel der Komponente und einem öffentlichen Schlüssel von mir als Nitro-LM Kunde. Nun übernimmt Nitro-LM ein komplettes User-Handling für mich. Den im meinem Kundenaccount kann ich nun für meine verschiedenen Module User anlegen und ihnen Zugang auf die Module gewähren. Den im Client ist eine das Einloggen notwendig um entsprechende Nutzer zu verifizieren.
Der letzte Teil der Überschrift „…and Making Cash!“ ist nun der Big Brother Teil. Den ein Service ist die Nutzerüberwachung, indem mir die Möglichkeit gegeben wird – ich muss es ja nicht einsetzen, aber ich könnte, so die Meinung – Alerts zu generieren, wenn z.B. die Lizenz eines Nutzers demnächst ausläuft und ich ihn anrufen sollte. Oder wenn der User sich lange nicht mehr eingeloggt hat, oder was auch immer Nutzer so gerade tun … muss man ja nicht, könnte man aber …

cheers,
Sebastian

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert