Tja, gestern gab es ja einen grossen Aufruf wegen zweier Plugins für Google+, die im Verdacht standen, Malware einzuschleusen. Das hat sich nun nach einer Stellungnahme der Entwickler als Fehlalarm herausgestellt: Auch ich hatte nachdem ich die ersten Warnungen gelesen hatte meinerseits vor den Plugisn gewarnt. Aber ich werde mich hier entschuldigen, denn wie ich jetzt dank der Stellungnahme erfahren habe, hat der scheinbare „Aufdecker der Gefahr“ dies zuerst ins Netz posaunt, und sich gar nicht mit den Entwicklern in Verbindung gesetzt.
Sowas geht nun gar nicht, denn damit kann man einem Startup ganz schnell das Genick brechen. Und die Faktenlage, wie sie sich mir jetzt darstellt lautet. Gut, unsauber in Teilen programmiert. Aber ohne böse Absicht und vor allem. Die Schlagzeilen Richtung Malware sind hoffnungslos überzogen und so nicht akzeptabel!
Bitte, wenn man schon Sicherheitslücken aufdeckt, dann zunächst direkt an die Entwickler wenden. Nur wenn die nicht reagieren ist eine Warnung von solcher Tragweite gerechtfertigt. Und ich muss mir auch an die eigene Nase fassen. Weil mir die Sicherheit meiner Leser am Herzen lag, hab ich da auch „überreagiert“. Es hätte gereicht, den Link zunächst zu deaktivieren, bis der Malware Vorwurf verifiziert ist.
UPDATE: Es gibt mittlerweile eine offizielle Stellungnahme von crossider, der Firma, die die Plugins verfasst hat. Ganz beruhigt bin ich dennoch nicht, aber die Vorwürfe in Richtung Malware oder Trojaner sind definitiv übertrieben.
Insofern habe ich beide Links im ursprünglichen Artikel wieder aufgenommen mit einem Verweis auf diesen Artikel. Definitiv hat der Autor, der scheinbar diese Falle aufgedeckt hat nicht, wie ich das machen würde zunächst mit den Entwicklern gesprochen. Das ist für mich definitiv auch sehr schlechter Stil und auch in der Reaktion auf die Stellungnahme gefällt mir der Tonfall nicht wirklich. Ich werde das Thema weiter beobachten aber hebe meinen Bann für beide Plugins auf. Letztlich müsste jeder, der keine Einfallstore für Trojaner haben will, Javascript ausschalten oder noch besser, gar nix aus dem Internet installieren.
Hier sollten sich beide Seiten wohl eher etwas aufeinander zubewegen. Bugs, die als Exploit dienen können haben schliesslich sogar Betriebssysteme.
Ende Update:
Ich hatte ja in einem früheren Artikel zwei Plugins empfohlen, die Facebook und Twitter in Google+ integrieren.
Wer die Popups von Tweetdeck vermisst, sobald eine Aktion auf Google+ geschieht, in die man involviert ist wie z.B. die Aufnahme in einen Circle oder die Weiterleitung eines eigenen Beitrags sollte sich Surplus ansehen.
Ist diese Erweiterung aktiv, erscheint auf dem Desktop ein Popup, sobald eine Aktion mit eigener Beteiligung geschieht und auf Wunsch ertönt auch ein akustisches Signal.
Beispiel einer Notifikation, weil andere meinen Artikel weiter geteilt haben.
Meiner Ansicht nach sind beide Tools definitiv keine Trojaner und haben auch keine solche Intention. Offensichtlich ist man aber bei der Entwicklung, sagen wir mal etwas unglücklich vorgegangen.
Eigentlich ganz simpel. Man muss nur die beiden Plugins : Google+Tweet und Google+Facebook in Chrome installieren, (beides Erweiterungen) und schon sieht die Google+ Seite etwas anders aus:
Damit hat man jetzt zwei neue Reiter für die Streams von Twitter und Facebook. Elegant, einfach und spart den dauernden Wechsel.
Generell würde ich spätestens mit dem Einstieg in Google+ empfehlen, einen intensiven Blick auf Google Chrome zu werfen. Hier gibt es sehr viele sehr gute Plugins für Google+ und auch für andere Services. Zudem ist der Browser sehr schnell und leichtgewichtig.
Google der Facebook Killer? Mag sein, dass viele von Facebook zu Google abwandern werden. Aber Google ist für mein Gefühl weit mehr. Geht man den Migrationsweg zu Google+ konsequent, und vergisst man zunächst mal die Bedenkenträger mit ihrer Datensammelpsychose, so ist für mich Google+ wieder zu einer zentralen Einstiegsstelle und zu meiner Arbeitsplattform im Netz geworden. Schon lange nutze ich Google Reader, um mich über die aktuellen Themen des Netzes auf dem Laufenden zu halten, arbeite intensiv mit Google Docs und Google Mail und jetzt migriert mein soziales Netz, und auch wenn das etwas überheblich klinge mag, vor allem die „wertvollen Kontakte“ zu Google+. Dank des Google+Twitter und Google+Facebook Plugins für Chrome, bleibe ich dennoch auch über meine Communities auf Facebook und Twitter auf dem Laufenden. Dank Android und dessen Synchronisationsmöglichkeiten habe ich meine Terminplanung komplett auf Google Calendar umgestellt, so daß meine Familie immer weiß, wo ich wann beruflich erreichbar bin und wir private und berufliche Termine perfekt koordinieren können. Und ein Backup unserer wichtigen Familienfotos liegt als privates Album bei Picasa.
Mein Büro liegt schon seit längerem in der (Google-) cloud.
Warum ich alles so zentralisiere? Warum ich mich in die „Fänge“ von Google begebe?
Weil ich Service erwarte, und zwar für all meine Bedürfnisse. So umfassend, wie das Google jetzt dank Google+ als weitere Erweiterung schafft, finde ich das nirgendwo sonst im Netz. Und wer mich jetzt dafür verdammt, der sollte mal hinterfragen, ob nicht jeder Microsoft Nutzer sich auch „in die Fänge“ von Microsoft, jeder Apple Nutzer nicht in die Klauen von Steve begibt? Ich denke, das tun wir nicht. Stets habe ich auch lokale Backups auf Festplatte, so daß ich, sollte mir der Dienst doch zu bedenklich erscheinen, dort weg. (Wer seine Daten nicht selbstverantwortlich sichert, hat meiner Ansicht nach sowieso noch nicht begriffen, wie man sicher und datenerhaltend im Netz arbeitet)
Selbst mein WLan ist mobil.
Aber ich sage, Google hat dasselbe Problem wie McDonalds. Alle schimpfen, aber wegen der hohen öffentlichen Aufmerksamkeit kann sich Google viel weniger schwerwiegende Fehler leisten, als andere Dienste.
Ich für meinen Teil habe dank der Dienste von Google viele Aspekte meiner Arbeit im Netz optimiert, verbringe paradoxerweise oft gar weniger Zeit im Netz, weil ich mit den diversen Tools verschiedenste Prozesse automatisieren kann.
Google+ ist ein weiterer Teil, der für mich die Arbeit im Netz extrem erleichtert. Sollten die vermuteten Businessfunktionen wie Dashboard etc. tatsächlich kommen, dann noch einen Tick mehr.
Sorry, wenn ich nicht auf Google die Datenkrake bashe. Für mich stellt Google Dienste zur Verfügung, die meine Arbeit erleichtern. That’s what counts for me.
Ein Tag, konzentrierte News, Vorträge und viele Bekannte Gesichter (schön, dich wieder mal in Real Life getroffen zu haben @elektrojunge). Mein Fazit vom Javaforum ist gespalten.
Zum einen, viele gute Vorträge, eine top Organisation, Aussteller, die offensichtlich auch wieder vertärkt Java Entwickler suchen. Aber was gefühlt mein Eindruck war. Irgendwie fehlt die Vision, wie es mit Java weitergehen soll. Seit der Übernahme durch Oracle ist die Szene misstrauisch geworden.
Das zeigte für mich auch der Vortrag „Das nächste große (Java-) Ding. Das hier die Klammer um Java auftauchte, war sicher gewollt. Mittlerweile stößt Java an seine Grenzen, die Erweiterbarkeit ist längst nicht mehr so einfach und die Virtual Machine limitiert manche grammatikalischen Erweiterungen.
Die Idee der JVM wird sicher weiterhin Bestand haben, aber ob auch Java noch die zweistelligen Versionsnummern erleben wird. Ich wage es nicht zu prognostizieren.
Letztlich war ich aber am verblüfftesten von der geringen Zahl an Tracks zum Thema mobile Computing. Mittlerweile gehen knapp 20% der deutschen Nutzer via Smartphone ins Internet, jeder vierte Haushalt besitzt ein solches Device und der Markt für Tablets boomt gerade. Dann aber nur zwei Tracks dazu anzubieten war mir eindeutig zu wenig.
Es gibt so viele wichtige Aspekte zu berücksichtigen und wenn ein Bereich die Entwickler in den nächsten Jahren verstärkt beschäftigen wird, dann der mobile Endgerätebereich.
(Kleine Anmerkung am Rande: Schon auf dem Weg zum Veranstaltungsort vielen mir viele QR Codes an Litfaßsäulen oder in Schaufenstern auf und auch auf dem Javaforum waren viele QR Codes zu finden. Ein neuer Trend? Ich prognostiziere ja bereits länger dieses Jahr als das Jahr des QR Codes. Mal sehen, ob ich am Ende recht behalte?)
Ansonsten aber, danke für einen hochinteressanten, informativen und sehr gut organisierten Event, den ich nächstes Jahr sicher wieder besuchen werde.
Was ich mitgenommen habe, ein IT-Projekt braucht IT affine Mitarbeiter. Projektmanagement ist ein Full Time Job und kann nicht parallel zum Tagesgeschäft laufen. Mobile Endgeräte dürfen nicht vernachlässigt werden und es muss auch hier ein Bewusstsein für Datenschutz und saubere, sicherheitsbewusste Programmierung existieren. REST und ähnliche Technologien sind ein spannender neuer Ansatz, um Dienste auf mobile Endgeräte zu bringen, ohne komplizierte Zugriffschnittstellen und aufwändige Programmieranforderungen.
Java is here to stay but may leave in a few years.
Vortrag 6: Restful API design
Warum REST mehr als HTTP mit XML ist
REST= Representational State Transfer
Representational State Transfer. Bunt.
Als Beispiel wird „ein Büchershop (guess which one)“ genutzt.
Das ganze soll jetzt auf Mobile Endgeräte, „wir brauchen eine App“
Also braucht man eine Api.
die zu implementierenden Schnittstellen sind aus dem „Legacy“ System vorgegeben.
REST möchte:
Für eine Web API
http bewusst nutzen
Bedenken, das Web ist ein verteiltes Medium
Vorkenntnisse über APIs sollten minimiert werden (einfache Einarbeitung).
1 Methode ergibt eine REssource
also Buch Nr Buch-ID —-> http://site/api/book/book-id
2 Methoden, eine Ressource
addToCart
getCartInfo
http://site/api/cart/cart-id
Man muss sich immer die Frage stellen, was kommt in die URI, was in die Parameter
Alles was ein „Ding“ ist in die Uri, der Rest in die Parameter
Aktionen entsprechen Methoden
Aktionen auf Ressourcen sind nicht Teil der URI sondern http-Methoden
Dies ist später in
der API Doku zu beschreiben
Übliche Verhaltensmuster sind
GET->Anzeigen
Post Anlegen oder Ergänzen
PUT Anlegen oder Schreiben
Es sind pro Entity mehrere URI möglich
Http Möglichkeiten nutzen, Error Meldungen, Last Sharing etc.
Caching kann im Header eingestellt werden, also nutzen, gerade auch für mobile Geräte.
ETags definieren den Zustand einer Ressource. Auch diese sind sinnvoll!
Links: Echtes REST
Link-Semantik definieren
Ressourcen mit Referenzen verknüpfen
Wissen über die API also verlagern in die Link Annotation
Die Art des Links kann in einem Annotation type wie rel definiert werden.
Es gibt Dinge zu beachten, die nur für mobile Endgeräte gelten.
Android ist strukturiert wie ein Orchester mit vielen „Spielern“, verschiedensten Komponenten, die erst zur Laufzeit miteinander verknüpft durch die „Intents“ die Messengerkomponenten. Wie kann ich nun diese Komponenten absichern, wenn Intents schief laufen.
Es gibt das grobgranulare Sicherheitsmodell basierend auf der Sicherheit des Linux Kernels, der die Prozesse isoliert.
Desktop hat Single UID
Android hat UID per Application
Applikationen, die mit dem gleichen Schlüssel signiert sind, können mit der gleichen UID laufen.
Die Kommunikation zwischen Apps läuft über eine Binder IPC
Weiterer Schutz->Sandboxing von Applikationen
Ich kann nur meine eigenen Ressourcen ansprechen.
Jede App läuft in einer eigenen Instanz der Dalvik VM.
Kommunikation über spezielle Interfaces.
Weiterer Sicherheitsmechanismus
Signieren von Applikationen
Verantwortlich für die Signatur ist der Entwickler
Zertifizierung durch Entwickler und in Verantwortung des Entwicklers
Vertrauen in Entwickler durch Erstellung guter Anwendungen
Daneben Feingranulares Sicherheitskonzept
Basiert auf Permissions
Permissions schränken die Möglichkeiten ein, was Prozesse tun können.
Benutzer erkennt das an den angegebenen Rechten, die die App bei der Installation fordert.
Es gibt:
System permissions Erlaubnis auf Systemdienste zuzugreifen (z.B) Kalender oder Adressbuch
Custom permissions
Permission groups
Permission trees
Definiert werden die Permissions im Android Manifest.
Informationen über Apps und laufende Prozesse kann über PackageManager oder ActivityManager
PackageManager -> Installierte Programme
ActivityManager -> Laufende Programme
Wo sind die Verantwortlichkeiten des Entwicklers?
Per Default kann eine App vom „Umfeld“ nichts sehen.
Component wird exportiert durch android:exported im Intentsfilter
Intents sind vergleichbar mit Messengerobjekten
Niemals sensitive Daten in einen Intent
Ebenso von Anfang an angeben, wer den Intent sehen können soll.
Intentfilter filtern keine schädlichen Intents!
Ein Angreifer kann die Priorität seiner Intentfilter erhöhen.
Bei Intentfiltern spezifische Aktionen und Kategorien angeben und Datenfilter
Activities
Benuten von Activity android:permissions = „de.otw.android.HARM_USER_DATA“
Die Permissions werden in startActivity() bzw. startActivityforResult() geprüft.
Services
Client-> Intent.setComponent() um den Service eindeutig zu identifizieren.
Achtung bei der Verwendung von Binder Interface.
Genehmigung für ServiceConnection im Package Manager prüfen, vor dem Austausch sensitiver Daten.
Server: Genehmigung mit erzwingen
Feingranularere Zugriffskontrolle durch Verwendung von Binder und Context Hilfsfunktionen
Broadcast Receiver
Receiver: Wiederum eine Genehmigung erzwingen
Sender: Immer darüber nachdenken, wer den Intent empfangen können soll. Also einfordern einer Permission und Definieren des Empfängers des Intents.
Don’t user sticky broadcasts for sensitive data!
ContentProvider
Achtung, beim Verwenden eines ContentProvider intern, android:exported=“false“ explizit setzen.
Lese und Schreibrechte trennen
android:readPermission
android;writePermission
TAg schränkt zur Compiletime uri Zugriffe ein.
Mitkönne erlaubte Pfade für uri Zugriffe angegeben werden.
Tips:
Jegliche empfangene Daten aus einem Intent prüfen
SQL Statement und Daten die es enthält klar trennen.
Selection fields final machen um Kontaminierung aus Zufall zu vermeiden
Files, DB und geteilte Preferenzen könne mit Berechtigung installiert werden
Bei Zugriffsberechtigungen auf Datenbanken immer an die Konsequenzen denken und immer den User fragen.
Daten auf SD Karte NIE unverschlüsselt ablegen.
IMMER DRAN DENKEN Nutzerdaten SICHER speichern.
So wenig Permissions wie möglich, anstelle einer Permission manchmal besser ein Dialog.
Cookie-Zustimmung verwalten
Um dir ein optimales Erlebnis zu bieten, verwenden wir Technologien wie Cookies, um Geräteinformationen zu speichern und/oder darauf zuzugreifen. Wenn du diesen Technologien zustimmst, können wir Daten wie das Surfverhalten oder eindeutige IDs auf dieser Website verarbeiten. Wenn du deine Zustimmung nicht erteilst oder zurückziehst, können bestimmte Merkmale und Funktionen beeinträchtigt werden.
Funktional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
