News Google Chrome: Patch schließt gefährliche Zero-Day-Lücke

[ComputerJunge]

Überladene Websiten bei denen der Button die Position nach dem Laden ändert.

Eine im Vergleich zur Vergangenheit deutlich einfachere Entwicklung von Unternehmensanwendungen. Kein Bedarf mehr für Client-Rollouts. Security kann besser implementiert werden, da die Clienten zunehmend einfach komplett "vernagelt" werden können. Ich darf bei Kunden schon lange nichts mehr am internen Software-Shop vorbei selbst installieren, im FF nicht mal die abbout:config öffnen.

Und das besonders unbeliebte Electron,

Ich mag VS Code. ^^

Beim öffentlichen Web sehe ich es ähnlich kritisch. Im Unternehmensumfeld wurde dadurch jedoch vieles erleichtert und vereinfacht.

 

[AlphaKaninchen]

...und keine Touchscreengesten auf meinem Laptop (Linux, vielleicht geht's unter Windows).

Du musst halt Wayland nutzen, da Firefox aber noch als default X.Org nutzt ist das etwas tricky

Bei Flatpak kann man einfach X.Org mit Flatseal deaktivieren, die dnf Version in Fedora nutzt ebenfalls Wayland und Touchgesten funktionieren einwandfrei.

 

[pseudopseudonym]

Ich bin heilfroh das GNOME jetzt eine “local first” Initiative für auf autarke Anwendungen anlaufen lässt. Git und IMAP sind die besten Beispiel, schnell, verlässlich, autark und Server dienen nur der Synchronisierung und nicht der Abhängigkeit.

git —everything-is-local

Und halt doch gleich auf dem Server und bei allen anderen. Wenn man Server als Server nutzt und nicht als Methode und Abhängigkeit zu erzeugen.

Die Frage ist immer, über welche Abhängigkeiten wir reden. Natürlich möchte ich mein Git lokal haben und auch mal offline arbeiten können. Google Meets z. B. würde mir lokal aber nichts bringen. Offline höre ich dann trotzdem nicht mein Gegenüber. Docs nutze ich so selten, dass mir das egal ist. Das soll einfach laufen, da wäre eine Installation unnötig.
Für unsere internen Anwendungen brauchst du ebenfalls Internet. Kurze Unterbrechnungen sind okay, das wird gesynct, aber mehr ist nicht drin. Unabhängig davon, ob's im Browser oder lokal läuft.

 

[flaphoschi]

Ich mag VS Code. ^^

Beim öffentlichen Web sehe ich es ähnlich kritisch. Im Unternehmensumfeld wurde dadurch jedoch vieles erleichtert und vereinfacht.

VSCode ist auch die einzige Anwendung für Electron die Leute wollen. Wobei die viele bei Plugins den Braten riechen, Microsoft hat da wohl eine Lizenzfalle gebaut.

Migrationsquote von VIM/Emacs dürfte nahe null sein. Der Durchbruch ist eigentlich LSP? Da hat Microsoft mal etwas für alle getan. VIM war vorher eine Macht, aber mit LSP und den heutigen APIs in den Compilern ist es einfach nur genial

PS: Was Unternehmen angeht. Es wird immer Schadensfälle geben, es ist eine Frage des wie oft. Nicht ob.
Sobald ActiceDiretory, SMB und Exchange eingesetzt werden knallt es nur besonders häufig und laut. Auch weil bei der Truppe immer jemand glaubt, dass man mit dem nächsten Schlangenöl die Absolution gekauft hat.

 

[ComputerJunge]

@flaphoschi
Ich sehe es dennoch nicht als Schlangenöl. Viele (frühere) Angriffsvektoren über den Clienten sind einfach nicht mehr möglich. Zudem fallen die ganzen Desktop-Rolloutpakete samt ihrer Kopplung ans IAM weg (es gibt ja noch welche für einige Systeme aus der "alten" Zeit). Das reduziert Risiken (auch in der Häufigkeit) und (Test)Aufwand.

Der Rest ist zwar ebenso interessant, ist aber Schwimm-gefährdet.

 

[andy_m4]

Ich mag VS Code. ^^

Man muss sagen, Microsoft macht da einen guten Job. Was die z.B. Performance-technisch aus electron rausholen ist überragend. Ist sicherlich eine der flüssigsten IDEs ist die ich kenne.

Die Ernüchterung kommt dann, wenn ich mal ne durch und durch native IDE öffne. Auf dem modernen Rechner merkt man es vielleicht nicht ganz so deutlich, aber wenn man mal ein Kleinrechner wie ein Raspberry Pi hat, dann zieht die native IDE Kreise ums VSCode.

Im Unternehmensumfeld wurde dadurch jedoch vieles erleichtert und vereinfacht.

Ja. Wobei es auch schon zuvor durchaus Technologien für so was gab. Ich erinnere nur mal an Java-Webstart.

Migrationsquote von VIM/Emacs dürfte nahe Null sein.

Böse Zungen würden sagen: Weil das kaum mehr einer benutzt. :-)

emacs hat ja damals wirklich Maßstäbe gesetzt in seiner Eigenschaft als durch und durch programmierbarer Editor. Darum hat er auch die Zeit überlebt, weil er extrem anpassbar ist. Trotzdem merkt man dem Projekt sein Alter an vielen Stellen an und man würde heute Dinge da anders machen.
Aus dem Grund gibts zwar noch Bestandsnutzer die auch nicht weg wollen, weil sie seit Jahrzehnten da ihren gewohnten Workflow haben. Aber neue Nutzer gewinnt man kaum noch.

So was wie VSCode ist quasi das Konzept von emacs in die Moderne geholt. Wobei, was die Programmierbarkeit angeht: So trivial wie emacs einem das macht, da kommt VSCode immer noch nicht hin.

 

[ComputerJunge]

dann zieht die native IDE Kreise ums VSCode.

Natürlich. Für diesen Anwendungsfall ist VS Code wie auch die anderen "fetten" IDEs halt aber einfach nicht gemacht (und auch nie gemacht gewesen). Im Gegensatz zu TogetherJ ist das alles jedoch auch leichte Kost. ^^

Ich erinnere nur mal an Java-Webstart.

Ja, das war eine gute Idee, um Deploymentverfahren zu dezentralisieren.

Trotzdem konnte damit bei "fetten" Clients durch ein morgendliches Update zu Arbeitsbeginn die gesamte Infrastruktur lahmgelegt werden. Das lag aber hauptsächlich an "optimistischer" Kapazitätsplanung (vulgo: schlechter Kalkulation). Spaßig war das Erlebnis einer allgemeinen Arbeitsblockade in jedem Fall. Mein Damen und Herren: "Nichts geht mehr." ^^

 

[andy_m4]

Für diesen Anwendungsfall ist VS Code wie auch die anderen "fetten" IDEs halt aber einfach nicht gemacht (und auch nie gemacht gewesen).

Naja. Das hat jetzt nicht unbedingt was mit dem Anwendungsfall zu tun. Wenn Du ne electron-App hast, sind da halt so viele Layer dazwischen, das das natürlich Zeit kostet. Geht ja auch gar nicht anders. In der Praxis ist das normalerweise kein Problem, weil selbst die electron-App schnell genug ist. Und Microsoft hat eben auch viel dafür getan, das es trotzdem flott geht.

Trotzdem konnte damit bei "fetten" Clients durch ein morgendliches Update zu Arbeitsbeginn die gesamte Infrastruktur lahmgelegt werden.

Ja. Aber auch das ist nicht etwas, was jetzt erst durch Webtechniken anders geworden ist.
Thin Clients konnte man auch schon früher haben. Da waren sogar Thin Clients eher die Regel, weil Computer teuer waren und man einen (oder wenige) Zentralrechner hatte, an dem viele Terminals angeschlossen waren.
Und selbst später konnte man X11-Netzwerktransparenz oder Lösungen a-la Citrix dünne/dumme Clients realisieren.

Worauf ich hinaus wollte: Dein Posting klang so, als ginge das erst jetzt wo man Apps in Browsern ausführen kann. Dem hab ich widersprochen.

Spaßig war das Erlebnis einer allgemeinen Arbeitsblockade

Das hast Du aber immer noch. Beobachte ich regelmäßig hier in der örtlichen Arztpraxis. Seit dem die auf Thin Clients umgestellt wird, bekommt man häufiger gesagt: "Das geht jetzt gerade nicht. Die IT klemmt. Wir versuchen es gleich noch mal und hoffen das es dann geht"

Das lag aber hauptsächlich an "optimistischer" Kapazitätsplanung (vulgo: schlechter Kalkulation).

Was sehr schön zeigt: Technologie alleine hilft einem noch nicht, wenn man die schlecht einsetzt.

 

[ComputerJunge]

as hat jetzt nicht unbedingt was mit dem Anwendungsfall zu tun.

Ich finde durchaus. Es gibt doch Szenarien, wo das 24cm-Kochmesser nicht die erste Wahl ist. ^^
Was nutzt du auf einem Raspberry? Sublime? Da habe ich keine Ahnung.

Thin Clients konnte man auch schon früher haben.

Das war aber gaaanz früher. Mein Ex-Chef hatte in den 70ern seine Diplomarbeit noch zeilenbasiert und stundenweise im Terminal geschrieben - sagte er mal zumindest.
Aber da geht die Reise wohl wieder hin - auch wenn die Clients wohl in der Breite nicht mehr so "thin" werden.

 

[andy_m4]

Ich finde durchaus.

Vielleicht hab ich nur nicht verstanden, was Du meinst. Wie bereits gesagt: Umso weniger Layer man hat, umso schneller wird eine Software sein.
Nichts anderes hab ich ausgesagt. Daher weiß ich nicht, was Du mit Deinem Kochmesservergleich willst.

 

[ComputerJunge]

Warum gleich so unterschwellig aggressiv?

Ich meinte genau das Gleiche. Weil ich den von Dir erläuterten Zusammenhang ja kenne, würde ich in bestimmten Anwendungsszenarien VS Code (das "Kochmesser") nicht erwägen.

 

[andy_m4]

Ich meinte genau das Gleiche.

Dann frag ich mich aber, was Dein Messervergleich soll.
Ja hab ja verstanden, das Du für spezifische Jobs ein passendes Tool wählen willst. Aber was hat das mit generellen Performancefragen zu tun?
Und ja. Das ein einfacher Editor schneller ist als eine "aufgeblasene" IDE, das ist logisch. Das war aber gar nicht mein Punkt.
Von daher weiß ich jetzt nicht wirklich, was Du von mir willst.

Ich hoffe, das war jetzt nicht zu aggressiv formuliert für Dich. ;-)

 

[ComputerJunge]

Aber was hat das mit generellen Performancefragen zu tun?

Nicks. Ich bin offensichtlich zu früh und ohne Ausfahrt in Richtung der speziellen abgebogen - und kenne mich der Falschfahrerei schuldig. ^^

Ich hoffe, das war jetzt nicht zu aggressiv formuliert für Dich. ;-)

Passt.

 

[Blutschlumpf]

Ich bekomme nur Chrome 120.0.6099.115 über den PlayStore.

Inzwischen bekomme ich auch die .144

 

[FrAGgi]

Solange schnell reagiert wird, ist das alles für mich ok.
Primär bin ich beim Firefox. Der Chrome ist aber für Testzwecke und einige berufliche Anwendungen mit installiert.