Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Android-Schwachstelle: Stagefright…

Paketbasiert statt ROM-basiert

  1. Thema

Neues Thema Ansicht wechseln


  1. Paketbasiert statt ROM-basiert

    Autor: zwangsregistriert2 04.08.15 - 18:12

    Ist doch klar dass es keine updates gibt, wenn man ein OS als ROM verteilt, das dann von verschiedenen Seiten noch monatelang verschlimmbessert und verwurstet wird.

    Paketbasiert wie eine 'richtige' Distribution waere einfach 'apt-get upgrade' und innerhalb von ein paar Stunden nach Verfuegbarkeit der patches waere die Sache groesstenteils erledigt.

  2. Re: Paketbasiert statt ROM-basiert

    Autor: Anonymer Nutzer 04.08.15 - 18:34




  3. Re: Paketbasiert statt ROM-basiert

    Autor: Anonymer Nutzer 04.08.15 - 18:40

    Mal davon angesehen,sollte man es tunlichst vermeiden auf die ganz gewöhnlichen Standardnutzer irgendwelche Shells samt Root-Berechtigungen loszulassen.

  4. Re: Paketbasiert statt ROM-basiert

    Autor: billyx 04.08.15 - 19:59

    zwangsregistriert2 schrieb:
    --------------------------------------------------------------------------------
    > Ist doch klar dass es keine updates gibt, wenn man ein OS als ROM verteilt,
    > das dann von verschiedenen Seiten noch monatelang verschlimmbessert und
    > verwurstet wird.
    >
    > Paketbasiert wie eine 'richtige' Distribution waere einfach 'apt-get
    > upgrade' und innerhalb von ein paar Stunden nach Verfuegbarkeit der patches
    > waere die Sache groesstenteils erledigt.

    Ist es nicht irgendwann langweilig immer die selben Trollpostings zu schreiben?!?
    1.) Gibt es diesen Mechanismus, er nennt sich OTA Update. Schon mal gehört?
    *****
    3.) Ist es mit einem Package nicht getan. Bei ARM gibt es wesentlich mehr unterschiedliche Prozessoren als bei x86. Und gerade bei einem embedded Mediencodec ist es sinnvoll eine auf den Prozessor optimierte Version zu verwenden.



    1 mal bearbeitet, zuletzt am 04.08.15 20:06 durch bk (Golem.de).

  5. Re: Paketbasiert statt ROM-basiert

    Autor: Mingfu 04.08.15 - 20:52

    billyx schrieb:
    --------------------------------------------------------------------------------
    > 1.) Gibt es diesen Mechanismus, er nennt sich OTA Update. Schon mal
    > gehört?

    Nützt aber nichts, weil die gesamten Systemupdates unter die Regie der Hardwarehersteller fallen und die kein Interesse daran haben, ein verkauftes Telefon länger als eine mehr oder weniger lange Schamfrist zu pflegen.

    > 3.) Ist es mit einem Package nicht getan. Bei ARM gibt es wesentlich mehr
    > unterschiedliche Prozessoren als bei x86. Und gerade bei einem embedded
    > Mediencodec ist es sinnvoll eine auf den Prozessor optimierte Version zu
    > verwenden.

    Prinzipiell geht das schon einiges. Die ARM-Linux-Distributionen machen es ja vor, wie man auch die Systemsoftware weitgehend hardwareunabhängig aktualisieren kann. Es bleiben in der Regel nur Bootloader, Kernel und dessen proprietäre Treiber außen vor.

    Android dagegen ist ein einziger monolithischer Block, der immer nur eine Aktualisierung insgesamt kennt und dabei in das Problem läuft, dass die Hardwarehersteller keine Lust haben, die Treiber dafür zu aktualisieren, ihre gefrickelten Zusatzdienste und Benutzeroberflächen anzupassen und schließlich den Testaufwand erneut zu leisten. Google ist darüber vermutlich aber gar nicht böse, denn das spart erheblich Aufwand. Ansonsten müsste man sich nämlich zum einen sehr viele Gedanken über eine sinnvolle Hardwareabstraktionsschicht machen, damit der Einfluss der Hardwarehersteller auf ein Minimum beschränkt wird. Und - viel schlimmer - man müsste vermutlich mehrere Android-Zweige parallel pflegen. Denn immer, wenn man neue Funktionen einführt, die Änderungen an der Hardwareabstraktionsschicht bedingen, müsste man einen Fork machen und ab dann zumindest den alten Zweig weiter mit Sicherheitsupdates versorgen.



    2 mal bearbeitet, zuletzt am 04.08.15 20:55 durch Mingfu.

  6. Re: Paketbasiert statt ROM-basiert

    Autor: Anonymer Nutzer 04.08.15 - 22:52









    Wenn ich mir dann hier http://developer.android.com/reference/android/media/MediaCodec.html mal die MediaCodec Situation ansehe, scheint es so als wäre das Problem tatsächlich relativ leicht zu beheben. Allerdings können hier halt wirklich nur die Hersteller ran.

  7. Re: Paketbasiert statt ROM-basiert

    Autor: billyx 04.08.15 - 23:25

    Mingfu schrieb:
    --------------------------------------------------------------------------------
    > billyx schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > 1.) Gibt es diesen Mechanismus, er nennt sich OTA Update. Schon mal
    > > gehört?
    >
    > Nützt aber nichts, weil die gesamten Systemupdates unter die Regie der
    > Hardwarehersteller fallen und die kein Interesse daran haben, ein
    > verkauftes Telefon länger als eine mehr oder weniger lange Schamfrist zu
    > pflegen.

    Das ist aber kein technisches Problem, sondern, wie ich im zweiten Punkt der vom Admin entfernt wurde erläutert habe, ein Problem von dummen Nutzern, die bei Herstellern kaufen die keine Updates liefern und auch ihr Handy nicht beim Händler zurückgeben.

    > > 3.) Ist es mit einem Package nicht getan. Bei ARM gibt es wesentlich
    > mehr
    > > unterschiedliche Prozessoren als bei x86. Und gerade bei einem embedded
    > > Mediencodec ist es sinnvoll eine auf den Prozessor optimierte Version zu
    > > verwenden.
    >
    > Prinzipiell geht das schon einiges. Die ARM-Linux-Distributionen machen es
    > ja vor, wie man auch die Systemsoftware weitgehend hardwareunabhängig
    > aktualisieren kann. Es bleiben in der Regel nur Bootloader, Kernel und
    > dessen proprietäre Treiber außen vor.

    Ja, man kann es theoretisch. Allerdings will ich auf meinem Handy für mein Handy optimierte Bibliotheken und nicht irgendwelche haben.

    > Android dagegen ist ein einziger monolithischer Block,

    Nein, das sind sehr wohl einzelne .so Dateien die ausgetauscht werden können. Nur sind die .so Dateien eben teilweise gerätespezifisch.

    > der immer nur eine
    > Aktualisierung insgesamt kennt

    Auch nicht, siehe oben Punkt 1.)

    > und dabei in das Problem läuft, dass die
    > Hardwarehersteller keine Lust haben, die Treiber dafür zu aktualisieren,
    > ihre gefrickelten Zusatzdienste und Benutzeroberflächen anzupassen und
    > schließlich den Testaufwand erneut zu leisten.

    Da muss eben der Benutzer daraufhinwirken.

    > Google ist darüber
    > vermutlich aber gar nicht böse, denn das spart erheblich Aufwand.

    Google hat damit gar nichts zu tun.

    > Ansonsten
    > müsste man sich nämlich zum einen sehr viele Gedanken über eine sinnvolle
    > Hardwareabstraktionsschicht machen,

    Ein HAL auf einem Embedded-Gerät nur weil die Käufer zu faul sind? Nein danke. Ich will für mein Gerät optimierte Implementierungen.

    > damit der Einfluss der
    > Hardwarehersteller auf ein Minimum beschränkt wird. Und - viel schlimmer -
    > man müsste vermutlich mehrere Android-Zweige parallel pflegen. Denn immer,
    > wenn man neue Funktionen einführt, die Änderungen an der
    > Hardwareabstraktionsschicht bedingen, müsste man einen Fork machen und ab
    > dann zumindest den alten Zweig weiter mit Sicherheitsupdates versorgen.

    Ja.

  8. Re: Paketbasiert statt ROM-basiert

    Autor: redmord 04.08.15 - 23:39

    Wozu eigentlich? So wie Android heute ist, passt es prima in den Businessplan von Samsung, HTC und Co. Andernfalls wäre es vielleicht gar nicht so groß angenommen worden. Breit unterstütztes, individualisierbares OS und Systempflege gänzlich in eigener Hand. Besser geht es nicht so lange man am Drücker ist.

    1) Man hat nachvollziehbare Argumente gegen Systempflege
    2) Man kann dem Kunden Systempflege durch Hardware verkaufen
    3) Man wird für sein Verhalten in Foren verteidigt

    Warum etwas ändern wollen? Um Neuanschaffungen weniger Attraktiv zu stellen? Ein Hardware-Hersteller hat nur so lange etwas von Systempflege wie es die Kundenbindung sichert. Alles darüber hinaus schmälert den Absatz. Das hat jetzt nichts ausschließlich mit Android zu tun. So funktioniert unsere Konsumgesellschaft rund um allen Technologieprodukten und jeder Hersteller trickst wo er nur kann.

  9. Re: Paketbasiert statt ROM-basiert

    Autor: Jasmin26 05.08.15 - 00:51

    es spielt überhaupt keine Rolle wie das OS aufgebaut ist ! Android ist an Googles bedürftigkeiten angepasst (expirience) was den Hersteller fast keinen Spielraum lässt und eine vernünftige updatepolitik fast unmöglich macht ! das es auch völlig anderes geht sieht man an diversen forks (aosp) WP, salifisch,meego, selbst bada und natürlich Apple ! die bestehende Sicherheitslöcher haben zudem fast ausschließlich mit dem system selbst zu tun und in der Regel nicht mit Software der Hersteller der hardware !
    cynogen hat alle löchetr mit den letzten nighlys gestopft , trotz unterschiedlicher Hardware .... die müssen zaubern können, oder Google ?

  10. Re: Paketbasiert statt ROM-basiert

    Autor: billyx 05.08.15 - 01:27

    Jasmin26 schrieb:
    --------------------------------------------------------------------------------
    > Android ist an
    > Googles bedürftigkeiten angepasst (expirience) was den Hersteller fast
    > keinen Spielraum lässt und eine vernünftige updatepolitik fast unmöglich
    > macht !

    Haha, der war gut.

    > cynogen hat alle löchetr mit den letzten nighlys gestopft , trotz
    > unterschiedlicher Hardware .... die müssen zaubern können, oder Google ?

    Cyanogenmod hat das Loch in ihren eigenen Systemen mit den von Google bereitgestellten Patches gefixt.

    Im übrigen ist sehr wahrscheinlich genau dieser Fix durch die intelligenten Cyanogenmod-Jungs die Ursache für die jetzt auftretenden Attacken.

  11. Re: Paketbasiert statt ROM-basiert

    Autor: Mingfu 05.08.15 - 07:12

    Tzven schrieb:
    --------------------------------------------------------------------------------
    > Allerdings können hier halt wirklich nur die Hersteller ran.

    Jedoch nur, weil Android falsch designt ist. Denn eigentlich befindet sich das Problem noch im hardwareunabhängigen Teil. Normalerweise wäre lediglich der OMX-Integration-Teil Herstellersache. Alles andere müsste unabhängig von den Herstellern zu aktualisieren sein, wenn man die grundlegende Systemarchitektur richtig aufgebaut hätte.

  12. Re: Paketbasiert statt ROM-basiert

    Autor: Mingfu 05.08.15 - 07:43

    billyx schrieb:
    --------------------------------------------------------------------------------
    > Allerdings will ich auf meinem Handy für mein Handy optimierte Bibliotheken und
    > nicht irgendwelche haben.

    Das ist Quatsch. Der größte Teil des Android-Quellcodes wird durch die Hersteller 1:1 von Google übernommen. Da ist überhaupt nichts optimiert, da wird einfach nur der Compiler angeworfen. Und da gibt es im Moment selbst für ARM nur zwei gängige Befehlssätze: ARMv7 und ARMv8. Dazu eventuell noch x86 und x86-64 und fertig ist.

    Das, was wirklich hardwareabhängig und optimiert ist, das sind die Treiber. Aber genau dafür wäre die Hardwareabstraktionsschicht da, damit dort gegen ein mehr oder weniger festes Interface implementiert wird und somit eine klare Trennung der Zuständigkeitsbereiche existiert.

    > Nein, das sind sehr wohl einzelne .so Dateien die ausgetauscht werden
    > können. Nur sind die .so Dateien eben teilweise gerätespezifisch.

    Sicher, aber das ginge nur, wenn die Hardwarehersteller selbst aktiv würden und anfangen, Sicherheitsupdates in die von ihnen verwendeten Android-Versionen einzupflegen. Wobei ich das für eine ganz schlechte Idee halte, denn die wenigsten dürften im Android-Code dermaßen fit sein, dass sie dort zuverlässig und verantwortlich arbeiten können. Ich sage nur Debian und "weak keys" - dieser Fehler war das Paradebeispiel dafür, wenn Code-Maintainer nicht wissen, was sie eigentlich tun. Google pflegt dagegen Sicherheitsupdates öffentlich nur in den aktuellen Android-Zweig ein und man erhält sie demzufolge nur mit der nächsten Android-Version - also monolithisch.

    > Da muss eben der Benutzer daraufhinwirken.

    Das kann er gern versuchen. Es gibt allerdings keinen einzigen Hersteller, der ein derartiges Angebot macht. Selbst Fairphone musste kapitulieren (obwohl sie genau mit dem Ziel angetreten waren), weil letztlich nicht einmal die Smartphonehersteller die Kontrolle haben, sondern die Prozessorhersteller überall die Hände drauf halten und sich weigern, Quellcode herauszugeben und Treiber für neue Kernelversionen zu entwickeln.

    > Google hat damit gar nichts zu tun.

    Oh doch. Denn wenn man die Zuständigkeit der Hardwarehersteller sinnvollerweise auf die Treiberebene einschränkt, dann müsste natürlich die Zuständigkeit für das System darüber bei einer anderen Instanz liegen. Und da Google die Kontrolle über Android hat, wäre es selbstverständlich dann Google, welches dort in der Pflicht wäre.

    > Ein HAL auf einem Embedded-Gerät nur weil die Käufer zu faul sind? Nein
    > danke. Ich will für mein Gerät optimierte Implementierungen.

    Das Märchen von den optimierten Implementierungen hatten wir schon geklärt.

  13. Re: Paketbasiert statt ROM-basiert

    Autor: Jasmin26 05.08.15 - 08:01

    billyx schrieb:
    --------------------------------------------------------------------------------
    > Jasmin26 schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Android ist an
    > > Googles bedürftigkeiten angepasst (expirience) was den Hersteller fast
    > > keinen Spielraum lässt und eine vernünftige updatepolitik fast unmöglich
    > > macht !
    >
    > Haha, der war gut.
    >
    > > cynogen hat alle löchetr mit den letzten nighlys gestopft , trotz
    > > unterschiedlicher Hardware .... die müssen zaubern können, oder Google ?
    >
    > Cyanogenmod hat das Loch in ihren eigenen Systemen mit den von Google
    > bereitgestellten Patches gefixt.
    >
    > Im übrigen ist sehr wahrscheinlich genau dieser Fix durch die intelligenten
    > Cyanogenmod-Jungs die Ursache für die jetzt auftretenden Attacken.

    sicher, sind immer die anderen, es darf ja nicht sein das dem fanboys dad Weltbild zerstört wird .. gel !

  14. Re: Paketbasiert statt ROM-basiert

    Autor: billyx 05.08.15 - 13:47

    Mingfu schrieb:
    --------------------------------------------------------------------------------
    > billyx schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Allerdings will ich auf meinem Handy für mein Handy optimierte
    > Bibliotheken und
    > > nicht irgendwelche haben.
    >
    > Das ist Quatsch. Der größte Teil des Android-Quellcodes wird durch die
    > Hersteller 1:1 von Google übernommen. Da ist überhaupt nichts optimiert, da
    > wird einfach nur der Compiler angeworfen. Und da gibt es im Moment selbst
    > für ARM nur zwei gängige Befehlssätze: ARMv7 und ARMv8. Dazu eventuell noch
    > x86 und x86-64 und fertig ist.

    Und woher kommt es dann, dass auf meinem Nexus 5 und dem Nexus 10 (beide 5.1.1, ca gleich alt) die Stagefreight-Dateien unterschiedlich groß sind?
    Der Quellcode wird natürlich in den meisten Fällen (obwohl er das jederzeit könnte) nicht umgeschrieben, aber zB mit unterschiedlichen Compilereinstellungen compiliert.

    > > Nein, das sind sehr wohl einzelne .so Dateien die ausgetauscht werden
    > > können. Nur sind die .so Dateien eben teilweise gerätespezifisch.
    >
    > Sicher, aber das ginge nur, wenn die Hardwarehersteller selbst aktiv würden
    > und anfangen, Sicherheitsupdates in die von ihnen verwendeten
    > Android-Versionen einzupflegen.

    Die Hardwarehersteller müssen sogar die Sicherheitsupdates selber einpflegen. Google liefert NUR den gefixten Source-Code, den muss der Hersteller in seine Sourcen übernehmen und dann für seine Geräte kompilieren.
    Wenn es wie du behauptestet so wäre, dass es nur Armv7 und Armv8 zu unterscheiden gäbe könnte der Benutzer einfach die .so Datei aus dem CM Projekt nehmen und seine ersetzen. Ich würde davon abraten.

    > Wobei ich das für eine ganz schlechte Idee
    > halte, denn die wenigsten dürften im Android-Code dermaßen fit sein, dass
    > sie dort zuverlässig und verantwortlich arbeiten können. Ich sage nur
    > Debian und "weak keys" - dieser Fehler war das Paradebeispiel dafür, wenn
    > Code-Maintainer nicht wissen, was sie eigentlich tun.

    Ich hoffe es gibt bei den Geräteherstellern jemand der git bedienen kann. Mehr ist nämlich nicht notwendig.

    > Google pflegt dagegen
    > Sicherheitsupdates öffentlich nur in den aktuellen Android-Zweig ein und
    > man erhält sie demzufolge nur mit der nächsten Android-Version - also
    > monolithisch.

    Und ich kann sogar verstehen bzw befürworte es sogar wenn Google den Fix nur in der aktuellsten Version beteitstellt und die Hardwarehersteller den Backport (weil sie ihre Geräte noch nicht aktualisiert hsben) selbst durchführen müssen.

    > > Da muss eben der Benutzer daraufhinwirken.
    >
    > Das kann er gern versuchen. Es gibt allerdings keinen einzigen Hersteller,
    > der ein derartiges Angebot macht. Selbst Fairphone musste kapitulieren
    > (obwohl sie genau mit dem Ziel angetreten waren), weil letztlich nicht
    > einmal die Smartphonehersteller die Kontrolle haben, sondern die
    > Prozessorhersteller überall die Hände drauf halten und sich weigern,
    > Quellcode herauszugeben und Treiber für neue Kernelversionen zu
    > entwickeln.

    Der Hersteller hat kein "Angebot" zu machen.
    Der Benutzer muss nur die entsprechenden Hetsteller boykottieren bzw noch besser das Handy auf Gewährleistung zurückgeben.


    > > Google hat damit gar nichts zu tun.
    >
    > Oh doch. Denn wenn man die Zuständigkeit der Hardwarehersteller
    > sinnvollerweise auf die Treiberebene einschränkt, dann müsste natürlich die
    > Zuständigkeit für das System darüber bei einer anderen Instanz liegen. Und
    > da Google die Kontrolle über Android hat, wäre es selbstverständlich dann
    > Google, welches dort in der Pflicht wäre.

    Genau das macht Google auch. Nur kompilieren und ausliefern müssen die Hersteller.

    > > Ein HAL auf einem Embedded-Gerät nur weil die Käufer zu faul sind? Nein
    > > danke. Ich will für mein Gerät optimierte Implementierungen.
    >
    > Das Märchen von den optimierten Implementierungen hatten wir schon geklärt.

    Du hast behauptet es wäre so, aber noch keinen Beweis dafür geliefert. Darf ich daran erinnern, dass es vor einigen Jahren sogar auf PCs noch üblich war den Kernel für seine Maschine entsptechend zu kompilieren?

  15. Re: Paketbasiert statt ROM-basiert

    Autor: matok 05.08.15 - 16:44

    billyx schrieb:
    --------------------------------------------------------------------------------
    > Genau das macht Google auch. Nur kompilieren und ausliefern müssen die
    > Hersteller.

    Und warum wird nicht einfach der Source der Patches von Google an die Geräte ausgeliefert und auf den Geräten kompiliert? Würde je nach Patch vielleicht eine Weile dauern, aber in Zeiten, in denen Quadcores schon fast Standard sind....

    Wenn Google wirklich wollte, könnten sie einiges für die Sicherheit der Plattform Android tun. So dürfen sie sich aktuell nicht beschweren, wenn alle Sicherheitsprobleme mit Android auf sie zurückfallen.
    Wie jemand anders schon schrieb. Die Hersteller befinden sich in einer äußerst komfortablen Situation, weil es oberflächlich betrachtet nicht ihr OS ist, sondern das von Google.

  16. Re: Paketbasiert statt ROM-basiert

    Autor: FreiGeistler 06.08.15 - 00:07

    > wäre das Problem tatsächlich relativ leicht zu beheben. Allerdings können hier halt wirklich nur die Hersteller ran.
    Verstehe selbst noch nicht so viel von tieferen Android-Interna.
    .so sind Treiber in der APK für den Zugriff auf die jeweilige Hardware?
    Könnte man die mit dem Xposed-Framework importieren/exportieren?

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Schöck Bauteile GmbH, Baden-Baden
  2. Marienhaus Dienstleistungen GmbH, Neustadt an der Weinstraße
  3. HYDRO Systems KG, Biberach
  4. UmweltBank AG, Nürnberg

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. (u. a. Nikon D5600 Kit 18-55 mm + Tasche + 16 GB für 444€ statt 525€ ohne Tasche und...
  2. (heute u. a. iRobot Roomba 960 für 399€ statt ca. 460€ im Vergleich)
  3. 399€ + Versand oder kostenlose Marktabholung (Vergleichspreis ab 443€)


Haben wir etwas übersehen?

E-Mail an news@golem.de


Google Maps: Karten brauchen Menschen statt Maschinen
Google Maps
Karten brauchen Menschen statt Maschinen

Wenn Karten nicht mehr von Menschen, sondern allein von Maschinen erstellt werden, erfinden diese U-Bahn-Linien, Hochhäuser im Nationalpark und unmögliche Routen. Ein kurze Liste zu den Grenzen der Automatisierung.
Von Sebastian Grüner

  1. Kartendienst Google bringt AR-Navigation und Reiseinformationen in Maps
  2. Maps Duckduckgo mit Kartendienst von Apple
  3. Google Maps zeigt Bikesharing in Berlin, Hamburg, Wien und Zürich

Nachhaltigkeit: Bauen fürs Klima
Nachhaltigkeit
Bauen fürs Klima

In Städten sind Gebäude für gut die Hälfte der Emissionen von Treibhausgasen verantwortlich, in Metropolen wie London, Los Angeles oder Paris sogar für 70 Prozent. Klimafreundliche Bauten spielen daher eine wichtige Rolle, um die Klimaziele in einer zunehmend urbanisierten Welt zu erreichen.
Ein Bericht von Jan Oliver Löfken

  1. Klimaschutz Großbritannien probt für den Kohleausstieg
  2. Energie Warum Japan auf Wasserstoff setzt

Raspberry Pi 4B im Test: Nummer 4 lebt!
Raspberry Pi 4B im Test
Nummer 4 lebt!

Das Raspberry Pi kann endlich zur Konkurrenz aufschließen, aber richtig glücklich werden wir mit dem neuen Modell des Bastelrechners trotz bemerkenswerter Merkmale nicht.
Ein Test von Alexander Merz

  1. Eben Upton Raspberry-Pi-Initiator spielt USB-C-Fehler herunter
  2. 52PI Ice Tower Turmkühler für Raspberry Pi 4B halbiert Temperatur
  3. Kickstarter Lyra ist ein Gameboy Advance mit integriertem Raspberry Pi

  1. Verfassungsschutz: Einbruch für den Staatstrojaner
    Verfassungsschutz
    Einbruch für den Staatstrojaner

    Der Verfassungsschutz soll künftig auch Computer und Smartphones von Verdächtigen durchsuchen dürfen. Um Staatstrojaner zu installieren, sollen Wohnungseinbrüche erlaubt sein.

  2. Be emobil: Berliner Ladesäulen auf Verbrauchsabrechnung umgestellt
    Be emobil
    Berliner Ladesäulen auf Verbrauchsabrechnung umgestellt

    Der Ladenetzbetreiber Allego hat die Abrechnung der öffentlichen Ladestationen in Berlin umgestellt. Statt eines Pauschalpreises für den Ladevorgang zahlen Elektroautomobilisten in Zukunft nach geladener Strommenge.

  3. Segway-Ninebot: E-Scooter sollen autonom zur Ladestation fahren
    Segway-Ninebot
    E-Scooter sollen autonom zur Ladestation fahren

    Das Aufladen von E-Scootern ist für die Verleihdienste aufwendig und kostspielig. Daher könnten künftig Geister-Scooter durch die Städte rollen. Beim Kauf "normaler" E-Scooter gibt es derweil Verzögerungen.


  1. 14:28

  2. 13:20

  3. 12:29

  4. 11:36

  5. 09:15

  6. 17:43

  7. 16:16

  8. 15:55