News Project Latte: Microsoft möchte Android-Apps auf Windows 10 bringen

[dasbene]

@Highspeed Opi da muss ich aber eher @deo zustimmen. Anwendungen mit einer anständigen Synchronization lassen sich deutlich besser verwenden als dann am Desktop in einer Android App rum zu klicken die portiert, emuliert oder von handy gestreamed wird.

Und zwar alles über eine Oberfläche... wie bei der "Your Phone" App und ohne sich extra auf mehreren Seiten registrieren zu müssen.

Auf was für Seiten meinst du? Für die einzelen Dienste muss man sich sowieso registrieren.

Ich habe derzeit mein Android Handy mit der Win10 Begleiter App angebunden und damit und den restlichen Diensten die ich verwende kann ich alles aus deiner Liste machen. Das cooles ist halt wenn der PC sich mit dem Smartphone über Bluetooth als Headset verbindet und man direkt über den PC telefonieren kann.

• Telefonieren über "Ihr Smartphone" und Bluetooth
• SMS über "Ihr Smartphone"
• Fotos über "Ihr Smartphone"
• Telegramm und Signal nativ über Windows Programme
• WhatsApp und Threema als Webapp übers Smartphone Relay
• Notizen über Google im Browser
• Routen über Google Maps im Browser, kommt aber drauf an welchen Funktionsumfang man haben will
• Netflix/Prime über Win10 App

Das sind die Dinge die ich jetzt schon in Nutzbarer Qualität kann. Was mir nur fehlt sind ist eine anständige Synchronization für Dokumente/Videos/Fotos mit meinem Heimserver.
Das mag mit manchen Cloud Diensten wie von Google nicht ganz meiner Wunschvorstellung entsprechen aber ich bin nicht dazu gezwungen aufzustehen um mein Smartphone zu holen wenn ich etwas machen will. Mal abgesehen davon sind dann auch die Anwendungen auf Tastatur + Maus ausgelegt und Apps wie Netflix können so viel besser die Anzeige ausnutzen, weil 4k+HDR+Sourroudsound werde ich bestimmt nicht über eine Emulierte Netflixapp an meinem PC bekommen.

 

[RoccoMD]

In Bezug auf neue Sicherheitslücken wäre es schön, wenn das ganze in einer Art Sandiebox laufen würde...

 

[foo_1337]

Das ganze muss in einer Sandbox laufen, anders ist dies gar nicht möglich.

 

[KitKat::new()]

@foo_1337 Wie kommst du darauf?

 

[foo_1337]

Dalvik bzw. ART basiert auf diversen Low Level Primitives des Linux Kernels bzw. hängt davon ab. Wenn du das einfach wegportierst, ist die Kompatibilität zu Apps nicht mehr gewährleistet. Das selbe gilt für die libc, gegen die ART gelinkt ist. Auch diese ist nicht einfach so auf native Windows Portierbar. Das Ganze wird sicherlich unterhalb des WSL ablaufen.

 

[icetom]

Microsoft könnte dann ja gleich mal ein performantes Android programmieren.

Google kriegt es nicht hin.

 

[KitKat::new()]

Das Ganze wird sicherlich unterhalb des WSL ablaufen.

Aber WSL ist keine Sandbox, sondern in Windows integriert.

 

[foo_1337]

Ein in einer Hyper-V VM bootender Linux kernel ist keine Sandbox?

 

[Ferax]

Wenn es dir darum geht, dann bist du bei einem Betriebssystem Service wie Windows eh falsch.

Das ist dann doch sehr parteiisch . Windows ist per se nicht schlecht. Wenn Linux in der Vielfallt Einsatz finden würde, müsste man sich im Service auch andere Gedanken machen.
Mit Vielfallt sind nun nicht die Aufgaben im Serverumfeld gemeint.

Wenn du keine Android- oder ARM-Apps auf deinem Windows nutzt, dann wird auch das Subsystem nicht genutzt und aktiviert, wozu auch?

Das dürfte wohl eine Frage der Integration sein. Das wozu hab ich schon öfter hinterfragt im Moment bekanntlich bei Windows. Ohne Wertung zu Linux da ich damit nicht arbeite.

Wer von Sicherheit und Fehleranfälligkeit redet, hat seine Daten eh auf einer anderen SSD/HDD als das Betriebssystem und ob Windows nun 25, 50 oder 75 GB auf seiner dedizierten SSD in Anspruch nimmt, ist doch völlig irrelevant.

Sofern man keine Verschlüsselung aller Bitlocker anhat klappt das noch ganz gut .
Abgesehen davon ist der Gewinn einer separierten HD im gleichen Geräte nur marginal im Vergleich zu einer parallelen externen Lösung.
Wer sagt ob die zweite HD im Geräte nicht fehleranfälliger als die des Systems ist?

 

[KitKat::new()]

Ein in einer Hyper-V VM bootender Linux kernel ist keine Sandbox?

Nein. Eine Sandbox wäre isoliert. WSL ist aber nicht isoliert. In der Tat kannst du dort ohne Probleme z.B. mit Windows Programmen oder Dateien interagieren.

 

[24601]

Ich weiß ja nicht...bei dem Namen "Project Latte" denke ich erst an etwas anderes...

An einen Kaffee? Ich persönlich wüsste nicht, welche Android App ich auf Windows vermisse.

 

[Topas93]

Dass weckt meine Hoffnung, dass Andoid Apps besser für Tablets optimiert werden

 

[foo_1337]

Natürlich kann ich mit Dateien interagieren. Aber eben nicht mit systemrelevanten Dateien. Außer man mounted die sich explizit in die VM. Und ich kann eben nicht auf den kernel memory usw. Zugreifen. Sprich ich kann keinen Keylogger oder sonstiges installieren.
Ein Security Problem gibt es nur umgekehrt, sprich vom Windows "Host" auf alles, was in WSL2 läuft. SSH private keys usw.

Warum regt sich eigentlich jeder so wegen des Namens auf? Java -> Bohne -> Kaffee -> Latte... Vermutlich ein deutsches Problem

 

[Pitt_G.]

Ist doch jjcht nötig oder baucht mans für Winodpws 10 on Arm
Dachte Google forciert,PWA um den Apps aus dem Chrome Webstore zu bekomme .
Da der neue edge drauf basiert, sollte das ja auch kein Thema mehr sein.
Chrome OS ?

 

[FreddyMercury]

Ich warte ja darauf das Windows den Kernel mit einem Linux Kernel ersetzt

 

[KitKat::new()]

Natürlich kann ich mit Dateien interagieren. Aber eben nicht mit systemrelevanten Dateien.

Du kannst alles machen was du in Windows auch machen kannst. Da kannst als normaler Nutzer auch keine systemrelevanten Dateien manipulieren.

In einer Sandbox hättest du eine Isolation dazwischen, welche hier bewusst aufgehoben ist.

Und ich kann eben nicht auf den kernel memory usw. Zugreifen. Sprich ich kann keinen Keylogger oder sonstiges installieren.

Mit Privilege Escalation (wie es auch typisch in Windows erforderlich ist), schon.

Hier gibts Details: WSL2 – the other ”other” attack surface - F-Secure Blog (f-secure.com)

 

[foo_1337]

Ja der F-Secure Artikel ist lustig. Der Complaint im Wesentlichen ist, dass das WSL2 dank der Virtualisierung den Netzwerkstack des Windows Kernel Bypassed und ihre "tollen" Tools dann nicht mehr funktionieren. Das it ja auch völlig klar. Aber man kann eben NICHT auf den Windows Kernel Space zugreifen, das ist schlicht nicht möglich. Außer es gibt ein Hyper-V Exploit. Und auch als root in der WSL2 VM kann ich keine Windows Systemrelevanten Dateien manipulieren. Außer ich mounte die z.B. via CIFS vorher bewusst rein. Wer das macht, bohrt sich aber absichtlich ein Loch in die Box.

 

[SVΞN]

Das ist dann doch sehr parteiisch .

Nein ist es nicht. Windows wird nun einmal seit dem Release von Windows 10 „as a Service“ betrieben und beglückt den Anwender halbjährlich mit neuen Funktionen.

Das hab ich mir ja nicht ausgedacht und zudem nutze ich Windows 10 selbst für Adobe und Gaming und habe Windows 10 2010 mehrfach als bislang beste Version bezeichnet.

Abseits der GUI des Grauens, die an allen Ecken anders aussieht und Icons nutzt die teils bis Windows 3.x zurückreichen, sowie der fragmentierte Systemsteuerung wird Windows 10 ja langsam solide.

Man kann aber auch etwas nutzen ohne es als heiligen Gral abzusehen. Die diversen Linux Distributionen haben für mich genauso ihre Schwächen.

Das mein Betriebssystem alle 6 Monate oder sei es auch nur alle 12 Monate komplett auf den Kopf gestellt wird, kann ich bei einem Produktivsystem dennoch nicht gebrauchen.

Das darf gern jeder anders sehen und nutzen was er mag. Es gibt ja genug Alternativen.

 

[KitKat::new()]

ber man kann eben NICHT auf den Windows Kernel Space zugreifen, das ist schlicht nicht möglich.

Also ich kann in WSL keine privilege Escalation Lücke ausnutzen?
Warum?

Ich finde es ja schon schlimm genug, dass ich via WSL alle Dateien des Benutzers löschen kann.
Wie man das dann als Sandbox bezeichnen kann, finde ich echt fragwürdig.
Zum Vergleich:
Die Windows Sandbox erstellt eine separate VM ohne Zugriff auf das Hostsystem - ganz im Gegensatz zu WSL.

 

[foo_1337]

Du kannst in WSL2 natürlich eine privilege escalation ausnutzen. Dies passiert und bleibt dann aber in der VM. es kann dadurch nicht auf weiteren Dateien vom Hostsystem zugegriffen werden, außer auf die, auf die man sowieso zugriff erhält.

Zum Begriff Sandbox: Es ist eine Sandbox, in die eben gewisse Files via P9 reingemounted sind. Es wäre auch witzlos, wenn nicht. Denn dann könntest du auch einfach eine Linux VM via Hyper-V installieren. Ohne jegliche Interaktion. Aber genau das ist ja bei WSL nicht gewünscht.
Das ganze ändert jedoch nix an der Sache, dass es sich um eine Sandbox handelt. Das kannst du drehen und wenden wie du willst. Der Zugriff auf die Files kommt von Extern und nicht per direktem Dateisystemzugriff. Sonst müsstest du auch jede VM auf einem ESXi Host/Cluster, die sich ein NFS oder CIFS Share mit anderen VMs teilt anzweifeln.