Rich Internet Applications

Rich Internet Applications

Posts 1-9 of 9
  • Dr. Friedger Müffke
    Dr. Friedger Müffke    Group moderator
    The company name is only visible to registered members.
    Sicherheitsrisko AIR?
    Hallo,

    ich verfolge gerade ein Diskussion über das Sicherheitsrisiko von AIR Anwendungen in einem Blog von Curl (http://developers.curl.com/blogs/community_blog/2008/04/16/w...).

    Es würde mich interessieren, was andere darüber denken? Ist es egal, ob AIR Anwendungen beliebige Dateien lesen und schreiben können, da sie als Desktop-Anwendungen heruntergeladen werden? Oder wäre es für RIA wichtiger, das Sicherheitsrisiko zu minimieren, da sie aus dem Web installiert werden und leicht zu manipulieren sind?

    Spielt das eine Rolle bei der Entscheidung für oder gegen AIR, bzw ähnlichen Technologien?

    Gruß,
    Friedger
    • 27 Apr 2008, 11:57 pm
  • User photo
    Sebastian Schmidt
    The company name is only visible to registered members.
    Re: Sicherheitsrisko AIR?
    Hallo,

    die in dem Blog aufgeführten Security Issues betreffen nicht nur AIR. Ich kann auch mit Visual Basic, Delphi, C#, Python oder Java Anwendungen schreiben, die nach dem Download aus dem Internet vom Desktop des User aus schädliche Aktionen starten. Die anderen sind eigentlich noch gefährlicher. Mit Air kann man zwar "format c:" ausführen, mit den anderen sogar Ports der Firewall öffnen, also Backdoors schaffen. Mit Air geht das leider (noch) nicht. Auch kann man mit Air keine custom DLL's einbinden, die weiteren Schadcode enthalten könnten. Weiterhin kann man keine ActiveX-Komponenten in Html einbetten und mit den erhältlichen Html-Komponenten ausführen. Das ist nur mit den MS Software Tools und der IE-Komponente möglich.

    Da also insgesamt die Desktop-Funktionalität von Air im Vergleich zu anderen Sprachen (noch) eingeschränkt ist, sehe ich hier kein Risiko, das es nicht auch bei anderen Sprachen gibt.

    Eine viel größere Gefahr geht wohl von Windows selbst aus: ActiveScripting, Silverlight(???), Internet Explorer mit ActiveX, ...

    Letztlich ist es der Benutzer, der darüber entscheidet, was er sich aus dem Internet herunterlädt und auf seinem Rechner installiert. Ich glaube nicht, dass es Aufgabe von Adobe ist dem User diese Denksportaufgabe abzunehmen. Aber vielleicht arbeitet man ja bereits in den Labs daran für Air 2.0 .

    Aus Sicht der Desktop-Entwicklung hoffe ich aber eher darauf, dass man daran arbeitet, die Desktop-Features zu erweitern: Custom DLL's, Eval for ActionScripting oder native PythonScripting Support, Socket Server (nicht nur Client), ggf. auch Html mit ActiveX-Support ...

    Gruß

    Sebastian
    • 28 Apr 2008, 08:35 am
  • Dr. Friedger Müffke
    Dr. Friedger Müffke    Group moderator
    The company name is only visible to registered members.
    Re^2: Sicherheitsrisko AIR?
    Wenn AIR nur zur Verwendung von Desktopanwendungen verwendet wird, stimme ich Dir zu. Dann ist diese Technologie (genauso wie Java und Delphi,etc.) aber nicht in die Rubrik Rich Internet Applications einzuordnen, oder?
    Ich verstehe unter RIA, dass sich die Anwendung wie ein Desktopanwendung anfühlt, aber Daten, Programmlogik, etc. aus dem Internet lädt. Insofern halte ich die ausgeführten Bedenken für durchaus berechtigt und das Sicherheitskonzept von Curl viel besser.

    Wenn aber z.B. RIAs sowieso nur aus dem Intranet geladen werden oder wie Dektopanwendungen verkauft werden, muss der User tatsächlich selber denken wie bisher auch. (Aber wo ist dann der Fortschritt?)

    Gruß,
    Friedger
    • 28 Apr 2008, 09:27 am
  • User photo
    Sebastian Schmidt
    The company name is only visible to registered members.
    Re^3: Sicherheitsrisko AIR?
    Also wenn ich mir die "Arbeitsdefinition" zu Rich Internet Applications bei wikipedia anschaue, dann ist Air im engeren Sinne kein RIA-Tool:

    "Eine RIA erkennt man daran, dass:
    * sie nicht installiert werden muss
    * auf sie über Internet-Techniken zugegriffen wird
    * sie mit dem Nutzer interagiert [...]"

    (1) Air App muss installiert werden. Flex oder Flash App muss nicht installiert werden.
    (2) Auf Air Apps kann man nicht mit Internet Technologien zugreifen (weil keine Socket Server Implementierung vorhanden ist). Bei Flash/Flex-Anwendungen geht der Zugriff z.B. über REST-Style, LocalConnection oder per JavaScript/Ajax Commandos an das Flash-Plugin senden (flashvars).
    (3) Interaktion mit dem Nutzer: Ist wohl bei Air, Flex und Flash gegeben.

    Also für mich ist Flash/Flex RIA-Technologie; Air dagegen einfach nur Desktop-Entwicklung auf Basis der Flex-Technologie mit der man ganz einfach Rich Media(!) Anwendungen erstellen kann. Dass Adobe das ganze als "RIA Tool" bezeichnet, dafür dürfte die Marketing-Abteilung des Unternehmens verantwortlich sein. (Die erzählen aber auch, dass AIR PDF-kompatibel ist - native pdf support?. Dabei hat AIR keine PDF-Komponente integriert, sondern das läuft über Acrobat-Reader, der von einer Html-Komponente geladen wird. Großartig.)

    Dennoch der riesen Vorteil ist, dass Flash-/Flex-Programmierer nicht mehr nur Online-Apps in der Flash Sandbox, sondern jetzt auch Desktop-Anwendungen in einer anderen Sandbox bauen können. Schön wäre es, wenn ich zukünftig nur noch ActionScript/MXML benötigen würde und damit Webclients, Desktop-Anwendungen oder sogar serverseitige Scripts erstellen könnte. Alternativ wäre z.B. ein integrierter Python-Interpreter eine "schnelle" Lösung für die bislang noch begrenzten Desktop-Funktionen (siehe Silverlight). Aber dann hätten wir wieder das Problem mit den Security Issues einer Desktop Application.

    Gruss

    Sebastian
    • 28 Apr 2008, 12:29 pm
  • User photo
    Sebastian Schmidt
    The company name is only visible to registered members.
    Re^4: Sicherheitsrisko AIR? - Curl als Alternative?
    Ich habe mir mal oberfläch Curl angeschaut. Kannte ich vorher nicht - und mein erster Eindruck ist, dass Curl Inc. es ganz schwer haben wird, sich auf dem RIA Markt gegen Adobe, Microsoft oder Google zu behaupten.

    Die Lizenzmodelle sind ähnlich restriktiv wie Flex vor der Version 2.0. (Bevor Adobe die "Macht" der open source community für sich entdeckt hatte.)

    Das Curl-Plugin habe ich heruntergeladen, aber im Firefox taucht es als Addon nicht auf. Kann Firefox Curl-Apps anzeigen oder muss man Curl-Apps herunterladen und vom Desktop starten?

    Letzlich ist da noch die Frage, was kann Curl, was Flex nicht auch kann? Also Objektorientierung, Socket Requests (inkl. SOAP) ... Das kann Flex auch. Socket Server? Scheint weder Flex noch Curl zu können.

    ActionScript ist mittlerweile weit verbreitet - Curl wirkt (noch) ein wenig proprietär.
    Flex-Anwendungen kann man (wie Curl Apps) downloaden. Sie werden dann vom lokalen Flash Player in der Flash Sandbox (ohne echten Desktop-Zugriff) relativ sicher ausgeführt. Flash Player gibts für Windows, Apple und Linux-Rechner. Gleiches gilt für die AIR Runtime. Das ganze ist Plattformübergreifend und Browserunabhängig. Letzteres war ja immer ein Problem bei Html/CSS/Ajax (und selbst bei Java.)

    Da ich immer offen bin für neue Webtechnologien, bin ich sehr gespannt darauf, herauszufinden wo die Stärken von Curl sind und welche echten Vorteile es gegenüber Flex hat . Zuletzt hatte ich mich mit ruby on rails und python befasst. Es sind beides sehr mächtige Spachen, die ganz eindeutig Bereiche abdecken, die Flex/Air bislang nicht beherrscht.

    Gruss

    Sebastian
    • 28 Apr 2008, 1:16 pm
  • Dr. Friedger Müffke
    Dr. Friedger Müffke    Group moderator
    The company name is only visible to registered members.
    Curl als Alternative?
    Da wir mit AIR abgeschlossen und als nicht RIA identifiziert haben, sollten wir vielleicht einen neuen Thread "Curl als Alternative" aufmachen.

    Da es Curl schon mehrere Jahre gibt, die dot-com-Blase überlebt hat und einige Erfahrung hat, bin ich einigermaßen zuversichtlich, dass es Curl auch noch ein paar Jahre weiter schafft. Das Produkt wird auch an anderen Stellen aus ausgereift bewertet.

    Firefox kann Curl-Anwendungen ohne weiteres anzeigen, es erscheint aber nichts im Add-on Ordner, einfach Url nach der Installation des Plugins aufrufen, z.B. http://www.curl.com/demos/wealthcalculator/start.curl

    Zur Frage, welche Vorteile Curl bringt, kann ich nur beschränkt Antwort geben, da ich Flex nicht besonders gut kenne.

    Hier eine Liste aus der API Dokumentation, was Curl kann. Vielleicht macht das den Vergleich einfacher:
    - (einfache) Audio Wiedergabe, Generierung
    - Kryptographie/Digests
    - Abstraktion von Datenquellen (siehe RecordSet, RecordView)
    - Clipboard
    - Drag&Drop
    - low-level Unterstützung für Maus, Tastatur, Eingabegeräte
    - Trennung in SubApplets/Verbindung zwischen Applets
    - 2D/3D Grafik, Szene
    - ausgewachsene GUI/Controls, Ereignisroutinen
    - I/O: Dateien, Http, Json, (komprimierte) Streams, Socket (auch AcceptorTCPSocket in privilegierten Applets!), SOAP
    - Macros, also neue Sprachkonstrukte, wie {after 0s do ...}
    - DLL-integration in privilegierten Applets
    - Reflexion, Code Parser
    - Reguläre Ausdrücke
    - Rechnen mit Einheiten (kg, m, s, ..)
    - SAX parser
    - parametrisierte Klassen
    - Nicht-Null Typen
    - Offline-Modus (gelegentlich verbundener Client - OCC)

    (Siehe auch einen Artikel von 2005, der einen guten Überblick gibt: http://www.curl.com/pdf/content-language.pdf)

    Curl sieht seinen Schwerpunkt in Business-Anwendungen, deshalb werden Datenverarbeitung, -analyse, Reports und das Darstellen von Informationen besonders unterstützt. Von der Performance soll Curl im Vergleich zu Flex bis zu 10 Mal schneller sein (laut Curl). Wäre vielleicht noch bei http://www.jamesward.org/census/ zu beweisen(?).

    Curl ist eine Programmiersprache (vom Sprachumfang ist Curl mit Java, Ruby und Python vergleichbar) UND eine Beschreibungssprache (wie HTML/CSS) zur Darstellung von Informationen. Zusammen wird das (bei Curl) als "content language" bezeichnet.

    Im Gegensatz zu Flex können Curl Anwendungen wie Desktop-Anwendungen aussehen (Startmenü, Deinstallation), jedoch ohne zusätzliche Sicherheitsriskos einzugehen, da die Anwendungen das gleiche Sicherheitsmodel hat wie Curl Anwendungen im Browser (genau wie Flex). Wenn der Rechner mit dem Internet verbunden ist, wird auf aktuellere Versionen der Anwendung geprüft.

    Die Curl-Plattform gibt es für Windows, Linux und (in beta) für Macs und ist browserunabhängig und (fast) plattformübergreifen (wie Flex).

    Sebastian, sind aus meiner Beschreibung Bereiche zu erkenne, die Curl interessant machen? Im Vergleich zu Flex oder anderen RIA-Technologien?

    Gruß,
    Friedger
    • 28 Apr 2008, 10:17 pm
  • User photo
    Sebastian Schmidt
    The company name is only visible to registered members.
    Re: Curl als Alternative?
    Hallo Friedger,

    danke für den Tipp. Nach Download und Installation der Curl RTE hat's geklappt: Firefox zeigt CurlApps an.

    Vielleicht sollten wir wirklich einen neuen Thread aufmachen. Das Thema ist spannend.

    Überrascht war ich von der Curl Console, die es dem User ermöglicht Whitelists für Urls, lokale Verzeichnise oder Signatures zu erstellen und damit die Sandboxes zu verwalten. Ist ein sehr guter Ansatz. Aber reicht es dem Nutzer lediglich zu unterscheiden zwischen "privilegierten" und "nicht provilegierten" Applets? Ich für meinen Teil für mir wünschen, dass man dort wie in den Internetoptionen des Internetexplorers detailliert einstellen kann, was die App darf und was nicht: z.B. Zugriff auf lokale Dateien in einem Verzeichnis, Zugriff auf Urls im Netz, Ausführen von lokalen Skripten, Anwendungen etc.
    Beim Flash-Player ist es zumindest so gelöst, dass der User einstellen kann, ob eine SWF lokal Daten speichern kann (in einem bestimmten Verzeichnis des FlashPlayers) und z.B. ob die Anwendung Zugriff auf die lokale Camera, Microphone etc. haben darf. Dafür ist bei Curl die Console in der Taskleiste intuitiver. Sie zeigt mir sofort, welche Apps in welcher Sandbox laufen.

    Jetzt wollte ich mir mal die IDE runter laden, um mal ein kleines Beispiel zu schreiben. Habe es aber erstmal gelassen, nachdem ich die Bedingungen der Deployment Licence gelesen habe. Vielleicht habe ich diese beim schnellen Überfliegen nicht richtig verstanden, daher meine Frage:

    Kann ich selbst entwickelte CurlApps auf meinem eignen Webserver veröffentlichen ohne Lizenzgebühren an Curl Inc. zu zahlen? Könnte ich diese Apps sowohl open source als auch kommerziell anbieten? Was hat es auf sich mit den rechtlichen Beschränkungen zur Verwendung von HTTPS-Protokoll und hidden urls?:

    "[...] Curl Customer Applications for use in a publicly accessible Internet environment that does not (i) include a fee-based application; or (ii) use a secure connection protocol such as HTTPS. [...]"

    Darüber hinaus bin ich auch eher nicht bereit, dem sich aus dem Lizenzvertrag ergebenden Auskunftsanspruch gegenüber Curl nachzukommen:

    "Licensee agrees to, upon request by Curl, (a) test and evaluate the Package; (b) cooperate with Curl in evaluations of the Package; (c) provide Curl with prompt reports of any errors, problems, defects or suggestions for change, modification or improvement to the Package; and (d) provide Curl with a written report concerning Licensee’s overall evaluation of the Package."

    Friedger, habe ich die Lizenzbedingungen falsch verstanden?


    Ansonsten schon mal ein paar kurze Gedanken zum Vergleich der API-Features von Curl mit denen von Flex/Air:

    - (einfache) Audio Wiedergabe, Generierung: Flex, Flash, Air - haben hier richtige Stärken.

    - Kryptographie/Digests: Mittlerweile sind zahlreiche Klassen (open source) verfügbar.

    - Abstraktion von Datenquellen (siehe RecordSet, RecordView): Ja.
    - Clipboard: Ja.

    - Drag&Drop: Flash/Flex nur innerhalb der Anwendung; Air zusätzlich auch Drag&Drop zwischen Desktop und App.

    - low-level Unterstützung für Maus, Tastatur, Eingabegeräte: Eher "high level" Unterstützung. Camera auch low level.

    - Trennung in SubApplets/Verbindung zwischen Applets: Ja

    - 2D/3D Grafik, Szene: "Szene" / "MovieClip" nur bei Flash, wg. der Verwurzelung mit der Videoschnitttechnik. Flex / Air sind mit Absicht nicht mehr "Videostudio-orientiert." 2D-Grafik/-Vektoranimation ist klassische Stärke von Flash. (Flash-Movies kann man in Air/Flex-Apps einbauen). Aber 3D-Grafik gehört sicher nicht zu den Stärken. Es gibt wohl open source Projekte (Swift ???) mit denen man 3D-Animationen erstellen kann. Sie werden dann als 2D-Vektoranimation (Flash-Movie) gerendert, falls ich mich recht erinnere.

    - ausgewachsene GUI/Controls, Ereignisroutinen: Ja, absolute Stärke. Selbst die SAP benutzt für ihr Netweaver Portal (oder wie auch immer das jetzt genannt wird) die Flex-Componenten als WebGui.

    - I/O: Dateien, Http, Json, (komprimierte) Streams, Socket (auch AcceptorTCPSocket in privilegierten Applets!), SOAP: Http/Https=Ja, Json=Ja, Streaming=ich glaube nur das Adobe-eigene FLV-Format, Mp3 und alles was sonst noch vom Adobe Media Server ausgeht. Socket=Ja. SocketServer=Nein. Dateien=Flash/Flex wie JavaScript/Hmtl. Air=volle Desktop-Funktionalität (ausser: Execute=Nein)

    - Macros, also neue Sprachkonstrukte, wie {after 0s do ...}: Nein

    - DLL-integration in privilegierten Applets: Nein. Nur bei anderen (kommerziellen) Entwicklungsumgebungen wie z.B. http://www.northcode.com/swfstudio.php

    - Reflexion, Code Parser: Eval? (Nein), wird aber bald eine open source implementierung eines AS3-Lexers/Parsers geben. Ausserdem hat Adobe ein Plugin für IIE und Apache veröffentlicht (kostenlos), dass MXML-Code in SWF-Dateien compiliert.

    - Reguläre Ausdrücke: Ja

    - Rechnen mit Einheiten (kg, m, s, ..): Nein

    - SAX parser: Bin mir nicht sicher, ob der Standard-DOM-Parser nicht gleichzeitig auch ein SAX-Parser ist. (Callbacks für Nodes gehen da auch - glaube ich.) Ansonsten kann man den relativ einfach selbst schreiben.

    - parametrisierte Klassen: Nein.

    - Nicht-Null Typen: NULL, UNDEFINED, VOID etc?
    - Offline-Modus (gelegentlich verbundener Client - OCC): ich glaube nur über Integration von GoogleGears möglich.

    - Ausserdem: Layout-Definition per StyleSheets möglich.
    - Ansonsten ist ActionScript-Syntax ähnlich wie Java, JavaScript. MXML ist anfangs ein wenig gewöhnungsbedürftig - aber letztlich leicht zu erlernen.
    - AIR-Apps: kommen mit Installer, Uninstaller, Startmenü-Eintrag, Taskleisten-Symbol, Update-Service etc. Während der Installation wird auch die AIR-Runtime mit installiert.
    Ein Beispiel ist: Adobe Media Player: http://www.adobe.com/products/mediaplayer/


    Also Friedger, da bin ich mal gespannt, wie es weiter geht. Ich werde auf jeden Fall mal Curl ausprobieren und dafür halte ich einen neuen Thread für sinnvoll.

    Gruss

    Sebastian
    • 29 Apr 2008, 1:44 pm
  • Dr. Friedger Müffke
    Dr. Friedger Müffke    Group moderator
    The company name is only visible to registered members.
    Re^2: Curl als Alternative?
    Zu den rechtlichen Hintergründen kann ich nicht viel sagen, außer dass die kostenlose Lizenz für private und kommerzielle Anwendungen genutzt werden kann, sofern keine Gewinn daraus gezogen wird, etwa durch Gebühren und sie öffentlich zugänglich sind. Https-Verbindungen werden wohl schon als gewinnbringend angesehen, wenn auch der Gewinn hier nicht monetär ist.
    Für die Pro-Lizenz gilt diese Einschränkung nicht, Anwendungen können dann zum Beispiel (und vor allem) auch im Intranet verwendet werden.

    Aus meiner Erfahrung kann ich sagen, dass man mit der Sales-Abteilung von Curl gut reden kann und eine angemessene Lösung im Einzelfall gefunden werden kann.

    Gruß,
    Friedger
    • 04 May 2008, 01:56 am
  • Dr. Friedger Müffke
    Dr. Friedger Müffke    Group moderator
    The company name is only visible to registered members.
    Re^3: Curl als Alternative?
    Bezüglich der Auskunftsregel in der Lizenzvereinbarung hat Curl geantwortet, dass dies sich nur auf die 60-Tage-Evaluierungsphase der Pro Lizenz bezieht. (Siehe http://developers.curl.com/message/1413)

    Sie arbeiten daran, die Lizenzierung zu vereinfachen, derzeit wird mit einem Lizenzdokument alle Fälle (Pro, Deploy, RTE, IDE) abgedeckt.

    Gruß,
    Friedger
    This post was modified on 05 May 2008 at 07:03 pm.
    • 05 May 2008, 7:02 pm