staging.inyokaproject.org

Hi zusammen!

Im Wiki steht zu den Scopes, dass man die Datenübermittlung an Canonical noch nicht abschätzen kann.

Nun haben die ersten von Euch schon die Geräten in den Händen. Mich interessieren daher Eure Feststellungen und was man aus Datenschutzgründen anpassen sollte.

Danke!

Achja: Mit der Versionsnummer bin ich mir unsicher. Wer weiß da schon mehr?

Die Frage, wie das einzuschätzen ist, interessiert mich auch. Bin mal gespannt, was sich da so ergibt.

Tendenziell bin ich beim OS eher konservativ und mag schlanke, übersichtliche Systeme. Daher habe ich die Scopes auf meinem Telefon erstmal alle deaktiviert. Das dauert ca. 10 Sekunden - und dann hat man nur noch den Scope mit den App-Icons. Damit ist die Bedienung dann sehr ähnlich zu Android.

Bei Gelegenheit werde ich mal mit einzelnen Scopes rumspielen - z.B. "Nearby", wenn es in den Urlaub geht.

Ist halt echt die Frage, ob die Scopes ständig alle laufen sollten. Ich fände es glaube ich gut, wenn man die Scopes genauso wie Apps vom Startbildschirm starten könnte. Dann wäre klar, wann ggf. Daten ins Internet übertragen werden und wann nicht.

In dem Sammelthread zu Touch fand ich den Hinweis auf die App "Permy" (Permy). Diese App zeigt die Berechtigungen für Apps und Scopes an und ist daher für die Eingangsfrage ein geeigneter Antwort-Partner.

Und schon hat man den ersten Kandidaten, den man hinterfragen muss. Das vom Heise-Verlag unabhängige Scope "Heise.de" (Heise.de) will gern den Standort erfahren. Bilder anbei. Einen Sinn mag ich auf den ersten Blick nicht erkennen. Ich habe vorhin kurz in die JSON-Datei zum Scope geschaut. Ich denke, da ist ein Ansatz. Mal später schauen, was passiert, wenn man die Datei anpasst.

Ich habe gerade eine interessante Info gefunden:

"Note: Even if you are used to the security policies of the platform, there is one more thing you need to know with scopes : if you need to use the network at some point, you won’t be able to access user data. This is a logical privacy policy to avoid user data extraction without explicit consent."

Quelle: https://developer.ubuntu.com/en/scopes/tutorials/write-a-json-scope-in-cpp/

Finde ich super!

Inzwischen musste ich lernen, dass ich zwischen drei Arten - sagen wir mal - Programmen auf Ubuntu Touch unterscheiden muss: Scopes, WebApps und Apps.

So muss ich korrigieren, dass "Heise.de" (s. o.) kein Scope, sondern eine WebApp ist. Diese werden von Touch anders behandelt. So haben diese z. B. eine vom Browser unabhängige Cookie- und Cache-Verwaltung ^[1]. Diese findet sich unter

1

/home/phablet/.local/share/[Name der WebApp]/

Das hat natürlich Einfluss auf Überlegungen zum Datenschutz. Während man bei Browsern geneigt ist, den Cache, die Cookies und den Verlauf mal ab und an zu löschen (z. B. mittels Skipt von trollsportverein) - an wie vielen Stellen muss man nun noch ansetzen?

Bei der genannten WebApp "Heise.de" werde ich mal in Kürze probieren, die relevanten Dateien zu sperren. Mal sehen, was dann passiert. Ich hoffe, dass man die Speicherung der Cookies & Co. einfach unterbinden kann.

^[1] https://developer.ubuntu.com/en/web/

^[1] https://developer.ubuntu.com/en/web/

Danke - habe es direkt ins Wiki übernommen.

So, ich habe jetzt mal die WebApp "DHL-Sendung" installiert und einmal gestartet, damit die Verzeichnisse und Dateien angelegt werden.

Die Zugriffsrechte sahen so aus:

1
2
3
4
5

phablet@ubuntu-phablet:~/.local/share/dhl.dampftux$ ls -l
total 20
drwx------ 2 phablet phablet 4096 Mai 19 06:54 Cache
-rw-r--r-- 1 phablet phablet 6144 Mai 19 06:54 cookies.sqlite
-rw-r--r-- 1 phablet phablet 4640 Mai 19 06:54 cookies.sqlite-journal

Nach Anpassung sehen sie nun so aus:

1
2
3
4
5

phablet@ubuntu-phablet:~/.local/share/dhl.dampftux$ ls -l
total 20
drwx------ 2 phablet phablet 4096 Mai 19 06:54 Cache
---------- 1 phablet phablet 6144 Mai 19 07:02 cookies.sqlite
---------- 1 phablet phablet 4640 Mai 19 07:02 cookies.sqlite-journal

Dann habe ich das Cache-Verzeichnis mal leergeräumt, die WebApp abgeschossen und neu gestartet. Das Ergebnis sah dann so aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

phablet@ubuntu-phablet:~/.local/share/dhl.dampftux/Cache$ ls -l
total 332
-rw------- 1 phablet phablet   45056 Mai 19 07:05 data_0
-rw------- 1 phablet phablet  270336 Mai 19 07:05 data_1
-rw------- 1 phablet phablet 1056768 Mai 19 07:05 data_2
-rw------- 1 phablet phablet 4202496 Mai 19 07:05 data_3
-rw------- 1 phablet phablet   32793 Mai 19 07:05 f_000001
-rw------- 1 phablet phablet   19097 Mai 19 07:05 f_000002
-rw------- 1 phablet phablet   24372 Mai 19 07:05 f_000003
-rw------- 1 phablet phablet  262512 Mai 19 07:05 index
phablet@ubuntu-phablet:~/.local/share/dhl.dampftux/Cache$ ls -l ..
total 20
drwx------ 2 phablet phablet 4096 Mai 19 07:05 Cache
---------- 1 phablet phablet 6144 Mai 19 07:02 cookies.sqlite
---------- 1 phablet phablet 4640 Mai 19 07:02 cookies.sqlite-journal

Noch ein Nachsatz: Wenn man in der Beispiel-App den Cache-Ordner blockiert, startet die WebApp nicht sondern schmiert ab. Startet man dann die App neu, wird der alte Ordner komplett entfernt und neu geschrieben. Gleiches gilt bei Rechteänderung. Der Cache lässt sich (derzeit?) also nicht deaktivieren.

Ergebnis: Also lässt sich gut steuern, ob WebApps die Cookies verwenden dürfen. Ob die WebApps dann noch vernünftig laufen, hängt natürlich von den Webseiten dahinter ab. Bleiben wir bei dem Beispiel: Wenn ich Cookies zulasse, kann ich bei jedem neuen Pakettracking das Update sofort sehen, ohne die Sendungsnummer neu eingeben zu müssen. Bei Webapps, die aber solch eine Funktion nicht gebrauchen, kann ich also mit einer einfachen Änderung der Rechte die weitere Nutzung von Cookies unterbinden. Dass sich das Cachen nicht unterbinden lässt, ist kein Beinbruch. Wir reden über mobile Geräte. Wer da ein begrenztes Budget hat, freut sich.

Finde ich 👍