Apps senden heimlich Daten raus

Anscheinend telefonieren weitaus mehr Apps nach Hause, als bisher angenommen:

http://www.physorg.com/news204978481.html

Mein Englisch ist leider nich des allerbeste, zumal ichs (hab grad Pause gemacht ;)) nur fix überflogen hab.
Werds mir zu Feierabend nochmal komplett und ausführlich gönnen und dann nochmal was dazu sagen ^^
Danke btw auch an Fefe für den Link :)

edit: Mittlerweile gibts auch deutschsprachige News dazu:
http://www.heise.de/newsticker/meldu...n-1100226.html
http://www.golem.de/1010/78377.html
http://www.n-tv.de/technik/Android-A...le1614311.html (Danke country1706)

wenn man sich die berechtigungen durchliest dann weiß man doch selber welche app das kann und welche nicht

Zitat:

---

Zitat von qvert

wenn man sich die berechtigungen durchliest dann weiß man doch selber welche app das kann und welche nicht

---

Naja - ich sag das auch immer - aber so einhundert prozentig klar, ist das halt leider nicht immer. Jede App die bsp. Werbung einbindet braucht "Netzwerkzugriff" wenn sie Wallpaper anbietet (wie im Beispiel des Artikels) dann eben auch "Zugriff auf Systemressourcen". Wenn ich das in den Berechtigungen lese, dann macht mich das nicht automatisch stutzig (mal abgesehen, vom alten Problem der Entwickler fordert mehr Rechte als die App benötigt... ). Mit diesen Berechtigungen können die Informationen aber schon gesendet werden. Die Frage ist eher: Wie nützlich sind die übermittelten Informationen?

Zitat:

---

Zitat von qvert

wenn man sich die berechtigungen durchliest dann weiß man doch selber welche app das kann und welche nicht

---

Dazu zitier ich einfach folgenden Abschnitt:

Zitat:

---

If the user chooses not to allow this access, the application cannot be installed. But if the user does install the app, the permission checks don't always explain how these services and data will be used. This forces users to blindly trust that applications will handle private data properly once they are installed, he says.

---

edit: Freie Übersetzung:

Zitat:

---

Wenn der Nutzer sich entschliesst, einen speziellen Zugriff nicht zu gewähren, wird die App nicht installiert. Wenn sie jedoch installiert wird ist nicht unbedingt ersichtlich, wofür ein spezieller Zugang und (persönliche) Daten genutzt werden. Dies verleitet den Nutzer dazu, der entsprechenden App, sobald sie einmal installiert ist, im Bezug auf den Umgang mit persönlichen Daten blind zu vertrauen.

---

Eins mal vorweg, ich möcht hier keine Panik verbreiten, nur ich finden das des trotzdem mal erwähnenswert ist ;)

Zitat:

---

Zitat von Ecki

Die Frage ist eher: Wie nützlich sind die übermittelten Informationen?

---

Genau das ist die Frage, die mich seit überfliegen des Artikels auch interessiert ^^

Hier auch noch mal:
http://www.n-tv.de/technik/Android-A...le1614311.html

LG
Dirk

Zitat:

---

Zitat von Frittenpiekse

Genau das ist die Frage, die mich seit überfliegen des Artikels auch interessiert ^^

---

Die sind sehr nützlich. Als Beispiel die App übermittelt Adressbucheinträge:

- Ich habe erst mal eine Liste mehr oder weniger Sicher existierender Namen und Telefonnummern
- Wenn das Adressbuch ordentlich geführt wird sind da noch Adressen, E-Mail-Adressen, Geburtsdaten usw. bei, die auch bei Pseudonymen zu einer Identifizierung ausreichen

Was kann ich jetzt damit anfangen? Ich kann z.B. die Identität einer Person klauen.
Als beispiel könnt ihr mal bei eurer Krankenkasse anrufen und nach einer Information oder einem Antrag fragen. Um euch zu identifizieren müsst ihr euer Geburtsdatum nennen, selten noch den Geburtsort.
Eine Freundin von mir ist Headhunter, sie sucht im Auftrag von Firmen neue Mitarbeiter und wirbt diese Aktiv von anderen Firmen ab. Dabei braucht sie möglichst viele Informationen die sie unter anderem durch Social Engineering bekommt. Dabei reichen ihr Geburtsdatum und Name in der Regel aus um genügend Informationen von Firmen oder anderen Einrichtungen zu bekommen.
So was funktioniert auch globalisiert, man glaubt gar nicht wie viele Deutsche Identitäten (Kreditkarten, Krankenkassendaten, ...) international verfügbar oder gehandelt werden.


Das jemand bei einem anruft und ungefragt Werbung macht, ist da schon eher das kleinste übel.

Zitat:

---

Zitat von KnightNoir

Die sind sehr nützlich. Als Beispiel die App übermittelt Adressbucheinträge:

- Ich habe erst mal eine Liste mehr oder weniger Sicher existierender Namen und Telefonnummern
- Wenn das Adressbuch ordentlich geführt wird sind da noch Adressen, E-Mail-Adressen, Geburtsdaten usw. bei, die auch bei Pseudonymen zu einer Identifizierung ausreichen

Was kann ich jetzt damit anfangen? Ich kann z.B. die Identität einer Person klauen.
Als beispiel könnt ihr mal bei eurer Krankenkasse anrufen und nach einer Information oder einem Antrag fragen. Um euch zu identifizieren müsst ihr euer Geburtsdatum nennen, selten noch den Geburtsort.
Eine Freundin von mir ist Headhunter, sie sucht im Auftrag von Firmen neue Mitarbeiter und wirbt diese Aktiv von anderen Firmen ab. Dabei braucht sie möglichst viele Informationen die sie unter anderem durch Social Engineering bekommt. Dabei reichen ihr Geburtsdatum und Name in der Regel aus um genügend Informationen von Firmen oder anderen Einrichtungen zu bekommen.
So was funktioniert auch globalisiert, man glaubt gar nicht wie viele Deutsche Identitäten (Kreditkarten, Krankenkassendaten, ...) international verfügbar oder gehandelt werden.


Das jemand bei einem anruft und ungefragt Werbung macht, ist da schon eher das kleinste übel.

---

In der App wurden nur ganz andere Daten übermittelt, als du gerade aufführst.

Zitat:

---

Zitat von Ecki

In der App wurden nur ganz andere Daten übermittelt, als du gerade aufführst.

---

Das war nur ein Beispiel, genauso wie die Angaben aus dem Artikel nur Beispielhaft sind, für das was möglich ist und das was auch im Paper genannt wird.
IMEIs und Handynr. füllen die bereits bekannten Datensätze und wenn Apps daran kommen, dann kommen sie auch an mehr. Dann gibt es auch noch ein paar Spoofing und Abhörmethoden bei denen man die IMEI benötigt.

Du hast prinzipiell schon Recht. Mit diesen Daten ist schon mehr möglich. Nur für deine Beispielerweiterung hätte die App auch wieder andere Berechtigungen (Zugriff auf Kontakte) gebraucht und da sollte es dann spätestens auffällig werden, wenn eine Wallpaper-App auf deine Kontakte zugreifen will.
Mir ging es mehr darum, was man mit den Daten aus der Bsp.-App anfangen kann. Ich bewahre meine IMEI bspw. auch gut auf, aber ich weiss nicht mal warum ich das tue... Der Rest der Informationen sollte ziemlich nutzlos sein, nicht?

Zitat:

---

Zitat von Ecki

Du hast prinzipiell schon Recht. Mit diesen Daten ist schon mehr möglich. Nur für deine Beispielerweiterung hätte die App auch wieder andere Berechtigungen (Zugriff auf Kontakte) gebraucht und da sollte es dann spätestens auffällig werden, wenn eine Wallpaper-App auf deine Kontakte zugreifen will.
Mir ging es mehr darum, was man mit den Daten aus der Bsp.-App anfangen kann. Ich bewahre meine IMEI bspw. auch gut auf, aber ich weiss nicht mal warum ich das tue... Der Rest der Informationen sollte ziemlich nutzlos sein, nicht?

---

Um mal genau auf die genannten Daten einzugehen:

Telefonnummer - Nervfaktor. Die wird stumpf verkauft.
IMEI - Telefonfrisierung, bzw. Fälschung. Um gefälschte Telefone zu bauen, benötigt man gültige IMEIs. Das klappt auch mit hochwertigen geklauten Telefonen. Kann ärgerlich werden, wenn die IMEI vom Zoll anschließend gesperrt wird.
ICCID - Das ist schon so eine Sache, die identifiziert genau die SIM-Karte im Telefon eindeutig. Da stecken Informationen drin, wie z.B. dein Mobilfunkanbieter und das Heimatland der Sim-Karte.
Lokalisierung - Ist nicht selten der Wohnort oder aber Orte umzu

Da entsteht dann ein Datensatz:

Der BenutzerXY hat die Handynummer 01511234567 ein XY Handy (aus der IMEI entnommen) mit der Seriennummer 123456 (auch aus der IMEI), er benutzt die Deutsche Telekom als Anbieter (ICCID) und zwar in Deutschland (ICCID)mit IMEI und ICCID
Am 01.01. er bei 53° 54'N 42°23' W
Am 02.01. ....

Mit etwas Aufwand könnte daraus noch der Wohnort ermittelt werden. Aber an sich reicht der Datensatz so schon aus um damit Geld zu verdienen. Dazu kommt dann eben noch die Möglichkeit die IMEI zu Missbrauchen, wobei das schon viel Aufwand wäre, die kann man leichter aus nem Laden bekommen. Bei der ICCID kann ich nicht ganz sicher sagen ob man die wirklich missbrauchen kann. Ich habe mal ein Paper gelesen, dass man mit einer gewissen Paarung von ICCID und anderen Kennungen (IMEI?) durchaus Anrufe abfangen kann, aber da müsste ich auch erst mal den Experten befragen.

Am Ende nervt mich eigentlich schon der Datensatz, eben weil andere Leute Geld an mir verdienen einerseits prinzipiell und andererseits ohne das ich dem einwillige oder irgendwie etwas davon habe, auch wenn es für mich in diesem Moment eher wenig Relevante Daten sind.

Übrigens, ist das beim iPhone genauso ;)

http://www.heise.de/mobil/meldung/Vi...r-1100547.html

Ich habe genau vor diesem Problem ja schon die ganze Zeit gewarnt und niemand nahm mich ernst.

Hier noch mal mein Appell: Wir brauchen unbedingt eine port- und adressgenaue Firewall für Android (mit Regelassistent).

oder nen regulierten markt wie apple.... aber bringt ja auch nichts wie man an meiner news sieht... und ne firewall wäre ja nur ne software firewall... und wie wir alle wissen sind die mehr schlecht als recht...

aber wäre gut wenn direkt im android system die möglichkeit bestehen würde bestimmte apps nicht aufs internet zuzulassen... dann hat man aber auch das problem das man nicht weiß ob das nun sinnvoll oder nicht ist

TaintDroid lässt Android-Lauscher auffliegen

Ein Problem ist, dass manche Apps aufs Netzwerk zugreifen nur um die Werbung in der App anzuzeigen. Kann Google denn nicht einen Dienst oder eine App im Android implementieren, die diesen Werbezugriff zentral vom Handy aus steuert. Also jede App die Werbung einblenden will greift nicht auf das Netzwerk sondern auf einen lokalen Werbedienst im Handy zu. Dieser Werbedienst besorgt dann die entsprechende Werbung und gibt sie an die App weiter. Bei der Installation einer werbefinanzierten App steht an Stelle von Netzwerkzugriff Werbezugriff. Und wenn dann einen App, z.B. eine werbefinanzierte Wasserwaage immer noch den Netzwerkdienst verlangt, dann muss man sich halt die Frage stellen: Was will diese App immer noch im Netzwerk?

Zitat:

---

Zitat von thp

Ein Problem ist, dass manche Apps aufs Netzwerk zugreifen nur um die Werbung in der App anzuzeigen. Kann Google denn nicht einen Dienst oder eine App im Android implementieren, die diesen Werbezugriff zentral vom Handy aus steuert. Also jede App die Werbung einblenden will greift nicht auf das Netzwerk sondern auf einen lokalen Werbedienst im Handy zu. Dieser Werbedienst besorgt dann die entsprechende Werbung und gibt sie an die App weiter. Bei der Installation einer werbefinanzierten App steht an Stelle von Netzwerkzugriff Werbezugriff. Und wenn dann einen App, z.B. eine werbefinanzierte Wasserwaage immer noch den Netzwerkdienst verlangt, dann muss man sich halt die Frage stellen: Was will diese App immer noch im Netzwerk?

---

Das macht es nicht besser oder einfacher, denn damit weiß man immer noch nicht, was an den werbenden übermittelt wird. Das Problem muss radikaler behoben werden, in dem der Zugriff auf solche Informationen gesperrt wird. IMEI, ICCID, UDID - das sind alles Sachen die für Werbung oder die meisten Apps nicht relevant sind, daher sollte der Zugriff darauf auch abgeschnitten sein. Entweder komplett untersagt, oder aber durch entsprechende Sperren wie eine Abfrage die man abnicken muss. Und dabei muss genau klar sein, dass die IMEI oder so übertragen wird. Ersteres wäre mir eindeutig lieber, denn der/die Entwickler werden dadurch quasi gezwungen diese Sachen nicht abzufragen. Der Benutzer hat ja keine Wahl: App installieren und Informationen senden oder App nicht benutzen können.

Das ist aber bei allen Betriebssystemen so, iOS lässt sogar JavaScript Anwendungen aus dem Safari auf die UDID zugreifen, die zu nichts anderem Dient, als einen Benutzer direkt und eindeutig zu identifizieren. Unter Windows Mobile 6.5 kommt man ebenfalls an solche Informationen (ohne Abfrage übrigens) und bei Windows Phone 7 wird es nicht anders sein.

So lange aber die Hersteller der Apps und des OS genügend an der Werbung verdienen wird das Maximum an Informationen gesammelt. Interessant wären daher Apps, die das verhindern, z.B. die bei entsprechendem API-Aufruf dynamisch generierte IMEIs, ICCIDs, UDIDs, raushauen, was eine identifizierung unmöglich macht, oder aber die falsche zufällige Koordinaten für die Werbung raushauen. Oder aber den Netzwerkzugriff komplett abfangen, wo wir wieder bei einer Firewall wären, die müsste allerdings anhand des Zieles entscheiden ob das Paket durchgelassen wird oder nicht...

Zitat:

---

Zitat von KnightNoir

Das macht es nicht besser oder einfacher, denn damit weiß man immer noch nicht, was an den werbenden übermittelt wird. Das Problem muss radikaler behoben werden, in dem der Zugriff auf solche Informationen gesperrt wird. IMEI, ICCID, UDID - das sind alles Sachen die für Werbung oder die meisten Apps nicht relevant sind, daher sollte der Zugriff darauf auch abgeschnitten sein.

---

Das ist klar. Ich meinte, dass eine entsprechende App einfach nur ein Werbebanner über einen lokalen Dienst anfordert und das sämtliche anderen Abfragen natürlich ignoriert bzw. gefiltert werden. Der Dienst leitet keine weitern Abfragen weiter und sendet nur ein Werbebanner an die App. Das ganze lässt sich noch auf SMS-, Telefondienste... erweitern. Oftmals ist es so, das Apps nur eine Notification oder einen Preview einer E-Mail, SMS oder eines Anrufes zeigen. Dazu brauchen die Apps im bisherigen Model natürlich den Zugriff auf diese Dienste. Wenn an dieser Stelle aber ein Dienst dazwischengeschaltet wird, der nur limitierte Anfragen oder Informationen weiter gibt, dann würde das schon für mehr Transparenz und Sicherheit sorgen.

Hiernochmal ein Video zum Thema. Hab ich zufällig grad entdeckt:

http://www.youtube.com/watch?v=qnLuj...?v=qnLujX1Dw4Y

Danke, aber das Video stammt aus dem ursprünglichen Artikel über den hier gerade diskutiert wird... ;)

Man sollte einfach im klaren sein, dass es "gratis" nicht gibt.

Man zahlt immer für eine App. Sei es in Geld oder eben mit seinen Daten bzw. Werbung.

Irgendwie müssen die Firmen ja was verdienen.

Ein zentraler Werbedienst kann bei den vielen unterschiedlichen Anbietern und Verrechnungsmodellen nicht wirklich funktionieren.

Apple geht da mit seiner eindeutigen ID schon den richtigen Weg. Diese beinhaltetn keine userspezifischen Daten und kann für Kopierschutz, ... verwendet werden.


@Tiz

Welche features fehlen dir bei IpTables?

Es geht hier also um Apps, die Daten leaken. Diese Apps sind selbst installiert, man könnte - aber auch nur "könnte" - den Leuten jetzt vorwerfen, das sie der App diese Rechte gegeben haben.

Einen anderen Aspekt bei der Sicherheits-Duskussion haben wir hier bisher aber außer Acht gelassen: Fehler im Betriebssystem.

In FroYo 2.2 gibt's zum Beispiel 'n Bug im Browser, der sämtliche gespeicherte Passwörter an eine Webseite übermittelt, wenn man sie aufruft. Dumm, oder?
Google hat reagiert und 2.2.1 herausgegeben. Damit ist das Problem behoben.

Aber auch 2.1 und ältere Versionen hatten bugs. Was machen also die Leute, die von ihrem Provider oder Hersteller kein Update mehr bekommen? Die haben Sicherheitslücken auf ihren Geräten. Und die bleiben auch da, die Lücken.

Die sich daraus entwickelnden Szenarien gefallen mir garnicht:
Man besucht eine präparierte oder verseuchte Webseite --> Durch einen Bug wird unbemerkt Software installiert --> Viele teure Anrufe in der DomRep --> Extrem hohe Telefonrechnung.

Und jetzt wiederleg' mal den Provider, der Deine 3000€ aus der Telefonrechnung haben möchte.

Oder, etwas polemisch, aber theoretisch möglich:
Schnell eine App mit adb installiert, die App gab's ja auf XDA - muss also OK sein --> Handy vertreibt im Internet Musik.

So, und jetzt wiederleg' mal den Ankläger, der Dich als Filesharer hinstellt. Klar, in dubio pro reo. Gibt's de facto nur nicht immer, gab's neulich mal 'n Artikel in c't dazu.

Zitat:

---

Zitat von marktwain

Man besucht eine präparierte oder verseuchte Webseite --> Durch einen Bug wird unbemerkt Software installiert --> Viele teure Anrufe in der DomRep --> Extrem hohe Telefonrechnung.

---

Halte ich an sich für unmöglich, da man beim Installieren von Software die Rechtevergabe jedesmal bestätigen muss, sonst bekommt die "unbemerkt" installierte App keine Rechte in ihre Sandbox gelegt ^^

Zitat:

---

Zitat von Frittenpiekse

Halte ich an sich für unmöglich, da man beim Installieren von Software die Rechtevergabe jedesmal bestätigen muss, sonst bekommt die "unbemerkt" installierte App keine Rechte in ihre Sandbox gelegt ^^

---

Prizipiell richtig, nur wenn's nen Bug gibt und jemand einen 0day exploit ausnutzt der das ermöglicht? VMware hatte mal was ähnliches, da konnte eine VM durch 'n Bug ausbrechen und vollständig auf das Host-Dateisystem zugreifen.
Theoretisch möglich, oder?

Zitat:

---

Zitat von marktwain

Prizipiell richtig, nur wenn's nen Bug gibt und jemand einen 0day exploit ausnutzt der das ermöglicht? VMware hatte mal was ähnliches, da konnte eine VM durch 'n Bug ausbrechen und vollständig auf das Host-Dateisystem zugreifen.
Theoretisch möglich, oder?

---

Also theoretisch schon. Aber das ist nicht so einfach vergleichbar. VMWare war darauf ausgelegt, bei Bedarf auf das Host-Dateisystem zugreifen zu können, bei Android ist es ja genau anders rum.
Die App wird ja nicht in die Sandbox installiert, sondern darin ausgeführt. Und die Sandbox stellt dann das/die Api zur Verfügung. Eine App die sich also heimlich installiert, ist auch erst mal auf die Sandbox beschränkt und die Sandbox öffnet dann entsprechend auch die Rechteabfrage.

Das was natürlich passieren könnte, ist das etwas wie ein "Jailbreak" gefunden wird, also die Möglichkeit direkt einen Dienst auf Systemebene außerhalb einer Sandbox zu starten. So was wäre auch mit einer Sicherheitslücke im Browser möglich, oder mit Sicherheitslücken in anderen Apps.

Aber das ist alles schon weit weg von dem Problem. Auch das es sich um Gratis Apps handelt macht es nciht besser, das ist eigentlich ein ziemlich billiges Argument. Die Entwickler werben mit der App-Funktion und nicht mit der Werbung die dahinter steht. Nach dem Motto "es ist doch klar, das die sich irgendwie anders finanzieren müssen" entspricht nicht unbedingt einem Kaufvertrag/Lizenzvertrag den man auch bei Gratisapps eingeht.

Natürlich sehe ich vor der Installation einer App, auf welche Dienste sie zugreifen kann. Ich habe aber keine Möglichkeit herauszufinden, was diese App mit diesen Diensten anstellt. Dabei ist es völlig egal ob die App kostenlos oder kostenpflichtig ist. Sprich: dass Freeware- und Verdienst-Argument zieht hier überhaupt nicht. Bei namhaften Apps wie Navigon, CoPilot, LauncherProPlus … werden eine Menge Dienste angezeigt. Bei den meisten aufgeführten Diensten ist mir völlig klar, warum diese Apps darauf zugreifen oder zugreifen müssen. Navigon hat Zugriff auf meine Kontakte- klar ich möchte den Luxus, dass ich direkt zu einem meiner Kontakte geleitet werde ohne das ich mir die Adresse aufschreibe um Sie dann im Navigon einzutippen- oder alternativ das Ganze per copy & paste realisiere. Somit habe ich „eigentlich“ kein Problem der Installation zuzustimmen. Aber wer sagt mir, dass Navigon meine Kontakte, meine GPS-Daten und sämtliche Netzwerkkommunikation nicht missbräuchlich verwendet? Hier bleibt nur eins, Userwertungen lesen, oder wie im Fall Navigon auf eine jahrelange gute Erfahrung vertrauen. Ich glaube nicht, dass die oben genannten Apps mich ausspionieren. Sollte das die Runde machen, dann sinkt das Vertrauen in diese Apps derart, dass die sich gleich vom Markt verabschieden können. Und ich glaube, dass die Entwickler der genannten Apps so clever sind, dass sie wissen, dass sie über den Verkauf der Apps mehr Geld verdienen können als über Datenweitergabe, geschweige denn möchte ich den Entwicklern auch nicht unterstellen derartige Gedanken zu hegen. Argumente wie, wenn du dich für ein offenes System entscheidest dann gehst du auch gewisse Risiken ein, finde ich etwas platt. Weil ich der Meinung bin, dass dir das auf jedem System passieren kann.

Zitat:

---

Zitat von thp

Argumente wie, wenn du dich für ein offenes System entscheidest dann gehst du auch gewisse Risiken ein, finde ich etwas platt. Weil ich der Meinung bin, dass dir das auf jedem System passieren kann.

---

Genau so ist es. Und genau das führt zu meinem Punkt:
Auf anderen Systemen werden zeitnah Informationen und Patches bereitgestellt.
Informationen gibt Google nicht heraus (weder Security Bulletins noch Changelogs) und Patches gibt's wenn Dein Hersteller 'ne neue Firmware bereitstellt.
Und wenn der das nicht tut? Dann bleibt die Sicherheitslücke auf Euren Handies drauf.
Das Handy hat dann ungeschützt Verkehr *g
Aber so lustig ist das garnicht mal, denn damit wird surfen zu einem finanziellen Risiko.

Jeder sollte für sich die Frage beantworten: Wie wahrscheinlich ist es, das die Sandbox 100% bugfrei programmiert ist?

Zitat:

---

Zitat von marktwain

Genau so ist es. Und genau das führt zu meinem Punkt:
Auf anderen Systemen werden zeitnah Informationen und Patches bereitgestellt.
Informationen gibt Google nicht heraus (weder Security Bulletins noch Changelogs) und Patches gibt's wenn Dein Hersteller 'ne neue Firmware bereitstellt.
Und wenn der das nicht tut? Dann bleibt die Sicherheitslücke auf Euren Handies drauf.
Das Handy hat dann ungeschützt Verkehr *g
Aber so lustig ist das garnicht mal, denn damit wird surfen zu einem finanziellen Risiko.

Jeder sollte für sich die Frage beantworten: Wie wahrscheinlich ist es, das die Sandbox 100% bugfrei programmiert ist?

---

Ich glaube, dass du hier zwei Probleme vermischst. Natürlich reicht es nicht, dass Problem mit den Apps, den genutzten Diensten, der fehlenden Transparenz und der damit verbundenen Gefahr zu lösen. Das Macht das ganze System noch lange nicht sicher. Ich habe gelesen, dass Google an einer neuen Struktur arbeitet und dass die Auslagerung von zum Beispiel Googlemail aus dem ROM ein bescheidener Anfang ist. Prinzipiell wäre eine neue Anordnung und Zugriffsberechtigung der Layer, wie könnten auch Schubladen oder sonst wie dazu sagen sinnvoll. Es macht einfach keinen Sinn, alles ins Betriebsystem oder auch ins ROM zupacken. Das führt bei der Vielzahl von Herstellern zu Problemen. Wir Alle können sehen was für Verzögerungen und Probleme beim Update auf Froyo aufgetreten sind. Das nervt und wird über lange Zeit die Kunden vergraulen. Keiner weiß, wie lange sein Handy supported wird und hofft auf die Gnade der Hersteller.

Layer 1: Der Kernel, da hat weder der Hersteller des Handys noch der Mobilfunkprovider was suchen. Die Rootrechte sollten weiterhin nicht so einfach zu erlangen sein. Jeder der sein Handy rooted sollte sich halt mit der Materie auskennen. Wenn nach dem Root was schief läuft ist der User halt selber schuld.

Layer 2: Hier befindet sich das Betriebssystem. Auch hier hat weder der Hersteller des Handys noch der Mobilfunkprovider was suchen. Goggle könnte jederzeit das Betriebssystem patchen, austauschen oder sonst wie modifizieren, ohne das sie auf die Hersteller und deren Support angewiesen sind. Einzig die Schnittstelle zum nächsten Layer (3) muss vorhanden und abwärtskompatibel sein.

Layer 3: Ist ein Hardwarelayer, der ganz klar definierte Schnittstellen zwischen den ersten zwei Layern hat. In diesem Layer dürfen die Hersteller nur ihre Hardwarespezifikationen (Treiber…) packen. Der Mobilfunkprovider darf hier keinen Zugriff haben.

Layer 4: Hier kommt die Software drauf. Hier könne die Hersteller ihre Oberflächen (Sense…) gerne vorinstallieren. Die GUIs gehören einfach nicht ins Betriebssystem oder aufs ROM- was die bisherige Praxis beweißt. Permanent ist der User darauf angewiesen, dass der Hersteller Lust hat das System anzupassen. LauncherPro und Andere beweisen das ein GUI/Homescreen Replacement … auch ganz normal als App installiert werden kann und trotzdem tadellos läuft. Selbst das Update von Android 2.1 auf 2.2 hat Apps wie zum Beispiel LauncherPro nichts ausgemacht. Ich musste nicht darauf warten, dass der Entwickler eine Version speziell für Froyo releast.

Natürlich sind das nicht alle Layer. Aber von der Struktur her könnte das doch funktionieren und die derzeitige Updateproblematik verbessern. Die Mobilfunkprovider wollen bestimmt auch noch ne Schublade. Damit sie uns die heißgeliebten Bootscreens, Favoriten… reinpacken können. Solange das nicht in den Kernel, das Betriebsystem und das Rom greift ist das kein Problem. Die Provider können dann gerne Monate damit verbringen ihren ungeliebten Quatsch anzupassen.

Die reale und Linuxarchitektur kennst du?

Layer 1: Hardware
Layer 2: kernel (3 Schichten)
Layer 3: BS

Der Hardwarelayer kann nicht über dem Kernel liegen. Es kann ja sonst nicht auf die Hardware zugegriffen werden.

Zitat:

---

Zitat von marktwain

Jeder sollte für sich die Frage beantworten: Wie wahrscheinlich ist es, das die Sandbox 100% bugfrei programmiert ist?

---

Das die Sandbox zu 100% bugfrei programmiert ist, ist unmöglich zu beweisen. Naja unmöglich nicht, aber es dauert sicher die nächsten Jahrtausende um das zu prüfen.


Das Schichtmodell von thp ist nicht korrekt und GalaxyS_User hat das schon schön geschrieben. Google denkt sicherlich darüber nach, aber nicht so.

Edit. Ich verkürze das ganze mal.

Edit2.

@thp Das Modell so ist Mumpitz.

Layer 0: Die unterste Schicht muss die Hardwareschicht sein. Und da auch nur die Abstraktion, also Buscontroller und entsprechend Adressen und Steuerbytes.

Layer 1 muss auch der Kernel bleiben, denn der Kernel soll ja die Hardware steuern und der Software die Hardware zur Verfügung stellen über entsprechende Schnittstellen.
Hier müssen auch immer die Hersteller der Telefone zugriff haben. Ich glaube du hast keine Vorstellung davon wie ein Rechner so wirklich funktioniert und was der Kernel macht. Es ist einfach nicht möglich aus einer oberen Schicht per dubioser Schnittstelle auf die Hardware einfach so zuzugreifen, ohne das der Kernel da nichts zur Verfügung stellt. Ein Treiber stellt auch immer ein entsprechendes Kernelmodul das geladen werden muss um die Hardware anzusprechen. Das enthält z.B. die Adressen der einzelnen Methodenregister und auch noch andere Zugriffsschnittstellen.

Der Kernel ist der Betriebssystemkern und das Betriebssystem ist die Software, die den Betrieb des Gerätes ermöglich.

Und gerade bei so Hochintegrierten Systemen ist die GUI ein wesentlicher Bestandteil. Das einfach so "aufgesetzt" zu lassen führt nicht aus dem Debakel, dass die Oberflächen lahm sind. Und eine Lahme weil in Sandbox laufende Oberfläche ist der Tod des Systems.


Es gibt nur zwei Möglichkeiten tatsächlich eine schnelle Updatekultur zu erstellen:

1. Wenn man die Hardwaretrennung will, dann muss seitens der Hardware ein Standardcontroller her. Der Controller bietet an den Kernel eine Standardschnittstelle an. Der Kernel muss so nicht verändert werden. Den Controller selbst programmiert dann der Hersteller.
Das ist natürlich nicht mehr so schnell und auch nicht so flexibel. Teuerer ist es auch ne ganze Ecke.

2. (Und diese Variante finde ich viel Sinniger) Google ändert den Lizenzvertrag, dass ein Update so schnell wie möglich umgesetzt werden muss, zur Not unter Konventionalstrafe. Viele Updates sind für die Hersteller kein Problem, gerade wenn es um Sicherheitslücken geht muss häufig der Kernel nicht neu kompiliert werden. Da reicht es bestimmte Patches einzusetzen und dann ein entsprechendes Rom herzustellen.
Das verhindert auch "Fire and Forget"-Phones, also Hersteller die Handys auf den Markt bringen und danach einfach vergessen, keine Updates herausbringen usw.

Zitat:

---

Zitat von KnightNoir

2. (Und diese Variante finde ich viel Sinniger) Google ändert den Lizenzvertrag, dass ein Update so schnell wie möglich umgesetzt werden muss, zur Not unter Konventionalstrafe. Viele Updates sind für die Hersteller kein Problem, gerade wenn es um Sicherheitslücken geht muss häufig der Kernel nicht neu kompiliert werden. Da reicht es bestimmte Patches einzusetzen und dann ein entsprechendes Rom herzustellen.
Das verhindert auch "Fire and Forget"-Phones, also Hersteller die Handys auf den Markt bringen und danach einfach vergessen, keine Updates herausbringen usw.

---

Ganz genau das wäre auch mein Vorschlag. Vertraglich einfach umzusetzen, technisch höchstens kleine Probleme. Das wäre eine schnell zu implementierende Idee, die nur leider von den Herstellern wenig akzeptiert würde. Denn genau wie Du sagst, es würde ihnen die Firmenpolitik des "Fire and Forget" verhageln!