Das ist korrekt. War im Artikel mit jenem Satz wirklich das gemeint? Mich deucht nicht.
Es war unter Linux doch schon zuvor der Fall. Der Browserprozess, ja jeder Prozess, eines Nutzers kann nicht schreiben, wo das Betriebssystem dem Nutzer keine Schreibrechte erteilt (DAC). Webseiten hatten bisher nur relativ eingeschränkte Möglichkeiten (falls vorhanden): Cookies, Caches, Flash, Java-Applets, ActiveX(?) (Downloads/Uploads sind ja explizit nutzerinitiiert via Klicks oder Auswahldialog und werden seit eh und je vom Browser-Prozess umgesetzt; die Webseite hat keine weiteren Zugriffsmöglichkeiten)
Aber hier im Artikel geht es ja darum, Zugriffe per Browser-API zu verwalten und zu regulieren, sodass WebApps prinzipiell Dateizugriffsrechte anfragen und erhalten können (lesend bzw. schreibend), aber eben nur, falls der Nutzer diesem im Falle des Falles explizit via einer leicht erkennbaren Abfrage zustimmt, um die Zugriffsmöglichkeiten jeder WebApp auf einem Minimum zu reduzieren. Bestehende Nutzerrechte des Betriebssystems können ohnehin nicht umgangen werden, selbst wenn der Nutzer und dessen Browser-Sitzungsprozess es wollten, unter der Annahme keine entsprechende Sicherheitslücke, d.h. privilege escalation, im System existiert. Es geht also darum, den Nutzer vor bösartigen WebApps zu schützen, indem einer WebApp nur diejenigen Dateien des Nutzers preisgegeben oder zur Verfügung gestellt werden (möglicherweise nur temporär), für die es eine explizite Zustimmung des Nutzers gab.
Also was genau hat das mit der/dem im Artikel erwähnten neuen API/Feature zu tun? Was ändert sich in diesem Zusammenhang?
Ist etwa gemeint, dass die Browser-API die Klienteneinstellungen des Nutzers dahingehend berücksichtigt, gewissen oder allen WebApps Zugriffe (lesend/schreibend) auf bestimmte Dateien, auf die er Zugriff hat, generell zu verweigern bzw. die Gewähr einzuschränken? Falls ja, warum wäre das unter Linux unnötig? Wie lösen die Dateizugriffsrechte dieses Problem bzw. setzen das Feature um? Die klassische Zugriffsrechteverwaltung unter Linux (DAC) schafft das meiner Ansicht nach nicht - jedenfalls nicht ohne ein zweites (ggf. virtuelles) Nutzerkonto.
Bisher konnte man per Javascript über Windows.localStorage Daten local ablegen. Das ist aber kein Zugriff auf das Dateisystem; wo der Browser die Daten ablegt und wie er sie verwaltet, darauf hat der Webentwickler keinen Einfluß (und kann es auch nicht abfragen/ändern )
Über die neue Api besteht dann von Javascript aus ein echter Zugriff auf das Dateisystem, das ist natürlich extrem gefährlich, weshalb man den Zugriff dann reglementieren kann. Ob die meisten USer vertehen, was sie dann da freigeben ist ein anderes Problem.
Danke für die Erklärungen. Ja, so hatte ich das auch aufgefasst/vermutet.
Aber wie passt das mit dem Zitat im Eingangskommentar zusammen? Wieso machen unter Linux die Zugriffsrechte ein Untersagen von Schreibrechten auf der Ebene dieser Browser-API für WebApps unnötig? Will man denn, dass dem Anwender nur die Wahl bleibt, einer WebApp entweder alle oder gar keine Schreibrechte seines Benutzers des Browser-Prozesses erbt/erhält, frei nach dem Motto "ganz oder gar nicht"? Ist die Idee dieser Browser-API nicht, dass über explizite Abfragen die Schreibrechte der WebApp auf eine Teilmenge des Benutzers des Browser-Prozesses minimiert werden, sozusagen eine Whitelist über den bestehenden Schreibrechten des Nutzers?
Das ist korrekt. War im Artikel mit jenem Satz wirklich das gemeint? Mich deucht nicht.
Es war unter Linux doch schon zuvor der Fall. Der Browserprozess, ja jeder Prozess, eines Nutzers kann nicht schreiben, wo das Betriebssystem dem Nutzer keine Schreibrechte erteilt (DAC). Webseiten hatten bisher nur relativ eingeschränkte Möglichkeiten (falls vorhanden): Cookies, Caches, Flash, Java-Applets, ActiveX(?) (Downloads/Uploads sind ja explizit nutzerinitiiert via Klicks oder Auswahldialog und werden seit eh und je vom Browser-Prozess umgesetzt; die Webseite hat keine weiteren Zugriffsmöglichkeiten)
Aber hier im Artikel geht es ja darum, Zugriffe per Browser-API zu verwalten und zu regulieren, sodass WebApps prinzipiell Dateizugriffsrechte anfragen und erhalten können (lesend bzw. schreibend), aber eben nur, falls der Nutzer diesem im Falle des Falles explizit via einer leicht erkennbaren Abfrage zustimmt, um die Zugriffsmöglichkeiten jeder WebApp auf einem Minimum zu reduzieren.
Bestehende Nutzerrechte des Betriebssystems können ohnehin nicht umgangen werden, selbst wenn der Nutzer und dessen Browser-Sitzungsprozess es wollten, unter der Annahme keine entsprechende Sicherheitslücke, d.h. privilege escalation, im System existiert.
Es geht also darum, den Nutzer vor bösartigen WebApps zu schützen, indem einer WebApp nur diejenigen Dateien des Nutzers preisgegeben oder zur Verfügung gestellt werden (möglicherweise nur temporär), für die es eine explizite Zustimmung des Nutzers gab.
Also was genau hat das mit der/dem im Artikel erwähnten neuen API/Feature zu tun? Was ändert sich in diesem Zusammenhang?
Ist etwa gemeint, dass die Browser-API die Klienteneinstellungen des Nutzers dahingehend berücksichtigt, gewissen oder allen WebApps Zugriffe (lesend/schreibend) auf bestimmte Dateien, auf die er Zugriff hat, generell zu verweigern bzw. die Gewähr einzuschränken? Falls ja, warum wäre das unter Linux unnötig? Wie lösen die Dateizugriffsrechte dieses Problem bzw. setzen das Feature um?
Die klassische Zugriffsrechteverwaltung unter Linux (DAC) schafft das meiner Ansicht nach nicht - jedenfalls nicht ohne ein zweites (ggf. virtuelles) Nutzerkonto.
Bisher konnte man per Javascript über Windows.localStorage Daten local ablegen. Das ist aber kein Zugriff auf das Dateisystem; wo der Browser die Daten ablegt und wie er sie verwaltet, darauf hat der Webentwickler keinen Einfluß (und kann es auch nicht abfragen/ändern )
Über die neue Api besteht dann von Javascript aus ein echter Zugriff auf das Dateisystem, das ist natürlich extrem gefährlich, weshalb man den Zugriff dann reglementieren kann.
Ob die meisten USer vertehen, was sie dann da freigeben ist ein anderes Problem.
Danke für die Erklärungen. Ja, so hatte ich das auch aufgefasst/vermutet.
Aber wie passt das mit dem Zitat im Eingangskommentar zusammen? Wieso machen unter Linux die Zugriffsrechte ein Untersagen von Schreibrechten auf der Ebene dieser Browser-API für WebApps unnötig? Will man denn, dass dem Anwender nur die Wahl bleibt, einer WebApp entweder alle oder gar keine Schreibrechte seines Benutzers des Browser-Prozesses erbt/erhält, frei nach dem Motto "ganz oder gar nicht"? Ist die Idee dieser Browser-API nicht, dass über explizite Abfragen die Schreibrechte der WebApp auf eine Teilmenge des Benutzers des Browser-Prozesses minimiert werden, sozusagen eine Whitelist über den bestehenden Schreibrechten des Nutzers?