Google draait Chromium-update met iframes die websites stukmaakt terug

Google heeft een update voor Chrome teruggedraaid nadat die websites stukmaakte. Het bedrijf probeert een bepaald soort iframes voor het versturen van notificaties uit te faseren uit de browser, maar ontwikkelaars klagen dat websites daardoor niet meer goed werken.

Het gaat om een voorstel waar al sinds maart vorig jaar aan wordt gewerkt door de ontwikkelaars van Chromium. Google wil ondersteuning voor cross origin-iframes in pop-ups verwijderen. Dat doet het bedrijf uit veiligheidsoverwegingen; Chrome laat iframes momenteel JavaScript-dialogen triggeren, in de vorm van pop-ups. In een cross origin-iframe, waarin wordt gelinkt naar een ander domein dan waar de pop-up op verschijnt, zien gebruikers een andere tekst dan wanneer die wel van het oorspronkelijke domein komt.

"De huidige gebruikerservaring is verwarrend en heeft in het verleden geleid tot spoofs", schreven de ontwikkelaars vorig jaar in een issuetracker. Door in pop-ups te kunnen linken naar andere domeinen is het dus mogelijk om gebruikers te spoofen of op andere manieren malware te verspreiden, omdat de gebruiker zulke pop-ups sneller accepteert.

Sindsdien heeft Google onder andere het inladen van JavaScript in cross-origin-iframes geblokkeerd. Uiteindelijk is het de bedoeling dat window.alert, window.prompt en window.confirm helemaal verdwijnen uit pop-ups in de browser. Dat gebeurde in Chrome-versie 92.0.4515.107 voor het eerst. Die versie kwam twee weken geleden uit. Sindsdien klagen veel ontwikkelaars dat dat verwijderen problemen oplevert met hun websites.

In een issuetracker klagen meerdere ontwikkelaars dat het bugs oplevert op hun sites. Onder andere het gebruik van thirdpartyservices in pop-ups werkt niet meer, en andere websites zeggen dat hun content niet meer kan worden ingeladen via een externe CDN.

Google heeft de beslissing daarom inmiddels teruggedraaid. Dat gebeurt in ieder geval tot 15 augustus, zodat ontwikkelaars langer de tijd hebben om hun software bij te werken. Ook Microsoft hoort de kritiek. Het bedrijf heeft in Edge 92.0.902.62 de functie teruggedraaid.

Reacties (50)

[Peter]

Google wil ondersteuning voor cross origin-iframes verwijderen.

Nee, Google wil ondersteuning voor het weergeven van modal dialogs door cross origin-iframes verwijderen. Ondersteuning voor cross origin-iframes zelf blijft. (Al willen we daar ook graag veranderingen in zien, met name via betere isolatie.)

Deze dialogs worden vaak gebruikt voor social engineering, gezien ze beantwoord moeten worden voordat verdere interactie met de rest van de pagina mogelijk is—anders dan bijvoorbeeld toegangsverzoeken, die met name vervelend zijn. Het probleem hierin met cross origin-iframes is dat het dialoog niet weergegeven wordt door de website weergegeven in de adresbalk.

Edit: typo, dank je justinkb

[Reactie gewijzigd door Peter op 23 juli 2024 18:59]

[lilmonkey]

gezien ze beantwoord moeten worden voordat verdere interactie met de rest van de pagina mogelijk is

Wat wel grappig is, is dat oldschool Opera (Presto), als ik het mij goed herinner, dit al grotendeels gemitigeerd had door die modal dialogs modeless te maken. Geen idee eigenlijk waarom dat bij de huidige browsers niet het geval is.

[RoelRoel]

Modeless kan niet bij bijv. prompt(), alert() en confirm() want de javascript kan pas verder als ie de input van de gebruiker heeft. Het werkt niet met een callback.

Het is bijvoorbeeld:

const name = prompt('Uw naam')

[Reactie gewijzigd door RoelRoel op 23 juli 2024 18:59]

[lilmonkey]

Ahja, daar heb je gelijk in. Nog even gecheckt en het ging inderdaad om andere dialogs als HTTP Basic Auth enzo.

[himlims_]

veel betaalplatforms maken daar ook gebruik van

[Peter]

Inderdaad, en dat is precies het probleem waardoor deze verandering teruggedraaid is.

[NEO256]

Klinkt voor mij onnodig, De betaal platformen die ik ken gaan met een token door naar de betaal pagina site en gaat vervolgens met die token weer terug.

Dan is cross platform spul (iframes, calls zoals xhr of http etc) vanaf dezelfde pagina niet langer nodig.
Wat het als het goed is allemaal stukken veiliger maakt.

[Peter]

Je hebt helemaal gelijk: behalve voor websites die écht afhankelijk zijn van synchrone code (de primaire meerwaarde die deze functies bieden) zijn er alternatieven beschikbaar die op alle vlakken beter zijn. Veiliger, vriendelijker voor de gebruiker, en in de huisstijl van de website.

Dat neemt echter niet weg dat er websites blijven bestaan die gebruik maken van de functies. De "confirm()" functie wordt gebruikt door cross origin-iframes in 0.003% van de pageviews. Stel dat de gemiddelde gebruiker 25 pagina's per dag bezoekt, dan heb je het direct al over 1,5 miljoen dialogen. Stel dat slechts 5% daarvan voorkomt op pagina's voor mobile banking: je hebt het over 75 duizend mensen die niet bij hun geld kunnen. In de realiteit zijn deze getallen velen malen hoger.

[bigbadbull]

probleem is dat je cross nooit meer kan verbieden en het gaat enkel erger worden.
cross & thridparty cookies lopen hierin een stuk gelijk.
Vooral de de bedrijfswereld wordt dit vervelend. Want die hebben eigen AD en willen users toelaten om via SSO aan te loggen op hosted SAP, Dynamics, HR stoftware en wat weet ik allemaal.
Aldie toepassingen worden natuurlijk aangeboden vanop het corporate intranet en omdat dit geen korte checks zijn maar lange sessie controles, zit je gevangen met dergelijke toestanden.

[Peter]

Het wilde westen van ongecontroleerde cross-origin interactie is het probleem—en dat staat naast de belangrijke use cases zoals SSO die absoluut moeten blijven werken. Op het moment dat aanbieder en afnemer bij elkaar bekend zijn, wat het geval is bij AD/SSO (zelfs in geval van OAuth), dan kan je hele andere oplossingen gaan overwegen, zoals first-party sets.

[TheVivaldi]

Maar daar maakt Google toch ook gebruik van? One Tap bijv. is modal, maar bijv. ook die meldingen van Google dat je de app kunt gebruiken in plaats van de website (bijv. bij Google Foto's).

[RoelRoel]

Het gaat over javascript confirm() , alert() en window.prompt(). Deze functies zorgen voor native bevestigings- of invoerdialogs die de uitvoering van de pagina tijdelijk blokkeren. Externe ingeladen reclames dmv een iframe kunnen hier misbruik van maken om gebruikers om de tuin te leiden. Het probleem is dat bijv. websites met javascript-cursussen ook zulke iframes gebruiken en dan niet meer werken.

[justinkb]

derde persoon enkelvoud van willen is wil, niet wilt

[WoutervOorschot]

Maar wat kun je er mee spoofen dan? Alleen een ja/nee knop als dialog toch?

Dat dat soms vervelend of storend is gebeurt wel vaker, snap niet precies waarom ze zulke basisfunctionaliteit persé willen verwijderen.

[P1nGu1n]

Google heeft de beslissing daarom inmiddels teruggedraaid. Dat gebeurt in ieder geval tot 15 augustus, zodat ontwikkelaars langer de tijd hebben om hun software bij te werken.

Dit is, naar aanleiding van de feedback is de issue tracker, uitgesteld naar januari 2022:

quote: https://bugs.chromium.org...ues/detail?id=1065085#c72

Thanks everyone for the feedback. We have decided to postpone this deprecation until at least January 2022 to give us time to do more outreach and propose alternatives to sites that rely on this behavior, and to give website owners more time to explore alternatives.

We will provide an update once we have a set milestone/date to re-enable the deprecation.

(cc @TijsZonderH)

[dwizzy]

Vroeger was Microsoft Internet Explorer vrij dominant in het bepalen hoe HTML er uit moest zien wilde je in de meerderheid van browsers werken, maar nu is het een stuk ernstiger omdat de Chrome+afgeleide browsers samen dominanter zijn dan MSIE ooit was.

De keuzes die Google wil maken zijn vaak best te verdedigen, maar worden niet in de gemeenschap gemaakt. En soms gewoon rechtstreeks op hun verdienmodel lijken te zijn gestoeld.
Google was nog redelijk enthousiast lid van de stanedaardisatie-organisatie W3c om via internationale standaarden te bepalen hoe het web er uit zag. Volgens mij zijn ze daar een beetje mee gebroken met Blink.
Blink werd hun eigen engine (geforkt van Safari's WebKit), ironisch genoeg omdat Google onder andere af wilde van niet-W3c-conforme tags als <blink>, en browser-specifieke css-dingetjes. Maar de laatste jaren zie je dat Google steeds vaker dingen wil uitfaseren die nog redelijk in gebruik zijn op het web, zonder gebruikers de keus te geven.

[CJ_Latitude]

Lijkt anders alsof hier een vrij lange, openbare discussie over is geweest:
https://groups.google.com...TOXiBj3D6A/m/JtkdpDd1BAAJ

[dwizzy]

Google heeft een redelijk open houding in discussie voeren, dingen bekendmaken, broncodes publiceren. Maar de besluiten worden alsnog genomen door Google, niet door een onafhankelijke standaardisatieorganisatie waarbij de toetreding zonder discriminatie kan gebeuren. En de gepubliceerde werken (broncodes) worden niet altijd onder een volledig open licentie uitgegeven.

[mocem]

Google gaat waarschijnlijk hetzelfde doen met BoringSSL. Ze willen gewoon dat iedereen naar hun pijpen danst.

[n00bs]

Ik blijf lekker bij Firefox, mag hopen dat toch deze user base gaat groeien.

[CyberMania]

Firefox krimpt alleen maar. Is het nog steeds zo dat FF meer geheugen en meer accu zuipt dan andere browsers? Dat was voor mij een belangrijke reden het niet te gebruiken op laptops.

[Reactie gewijzigd door CyberMania op 23 juli 2024 18:59]

[Heidistein]

Nee, al een paar jaar niet meer.

[PatrickH89]

Volgens mij is momenteel Chrome de grootste geheugenslurper en dat al tijdenlang.

[Vexxon]

Je loopt een paar jaar achter, dat klopt echt allang niet meer.
Zeker voor privacy moet je bij FF zijn

[Frame164]

Het is in ieder geval qua performance de mindere van alle browsers. Het voelt allemaal wat log aan.

[jimshatt]

Firefox is bij mij niet trager dan Chrome of Edge ondanks (of misschien wel dankzij) een hele set extensies.

[Meiklokje]

Veel bronnen ? ik draai firefox in een vm met 4gb ram en 12 tabs open, 3 liggen hier te streamen als test en niks hangt hier. 3 keer youtube open gegooid de rest internet sites. Wat voor een computer heb jij dan. Dat vliegt hier op een XFCE Linux distro. Terminal code vliegt hier als een trein. Als ik chrome op die linux vm installeer is dat een pak minder soepel.

[Nomisma]

Ja nog erg veel. Enkele GBs aan geheugen op MacOS met zo'n 10-15 tabs open.

[McBacon]

Weird, ik heb vrijwel altijd 200+ tabs open en zelfs dan zit ie maar op een paar GB. Misschien ff al je plugins uitzetten of in safe mode draaien. ;]

[Nomisma]

Heb je ook de andere processen meegeteld? Bij mij heten die FirefoxCP Web Content.

Nu zit FF bij mij op 1.11GB. Dat is dus zonder die FirefoxCP Web Content.

[McBacon]

Ja die tel ik ook altijd mee. ;] Meeste zijn maar een paar 10 MB als ik het me goed herinner. Alleen als ik op een site zit die veel aan lazy loading (of gewoon überhaupt dynamische rendering) doet loopt het verbruik redelijk op. Maar zelfs dan komt dat ene proces moeilijk boven 1 GB.

Ben nu niet thuis maar als je het echt wilt weten kan ik vanavond wel ff kijken.

[Nomisma]

Als je dat leuk vindt, waarom niet.

Hier is dan mijn geheugengebruik. Dit betreft een M1 MBP met 8GB werkgeheugen. Er zal ook ongetwijfeld per besturingssysteem wel wat verschil zitten tussen hoeveel geheugen Firefox inneemt.

[McBacon]

Ik heb een MBP mid 2012 met 16 GB, ik gebruik zowel Chrome als Firefox omdat ik 1) bepaalde sites alleen in Chrome (kan) open(en) en dat is veel makkelijker met Cmd+Tab 2) ik redelijk vaak dingen wil controleren vs. Firefox.

Chrome
* 45 tabs
* 585.6 + 253.0 + 137.9 + 130.7 + 125.0 + 115.3 + 88.2 + 80.8 + 79.9 + 73.2 + 67.5 + 67.1 + 66.1 + 62.5 + 57.8 + 57.2 + 51.5 + 51.4 + 50.3 + 49.7 + 47.3 + 46.2 + 45.9 + 41.9 + 33.9 + 31.8 + 29.5 + 26.2 + 25.8 + 25.6 + 25.4 + 23.3 + 18.0 + 17.8 + 15.8 + 12.8 + 11.3 = 2729.2 MB

Firefox
* 406 tabs
* (1.81 * 1000) + 523.2 + 509.8 + 383.1 + 377.0 + 359.6 + 347.4 + 310.6 + 308.6 + 307.3 + 89.3 + 8.3 = 5334.2 MB
- Volgens mij rekent macOS met 1 GB = 1000 MB i.p.v. 1024, dus vandaar de * 1000 hierboven. Die 1.81 is dus het Firefox-proces zelf, de rest is Web Content en de allerlaatste 2 zijn Privileged Content en RDD Process.

Beide browserts hebben eenzelfde set plugins: uBlock, FoxyProxy, referrer control, ColorZilla, cookie managers, user agent control. Dan vind ik Firefox behoorlijk zuinig.

[Reactie gewijzigd door McBacon op 23 juli 2024 18:59]

[dwizzy]

ik zoek de connectie met BoringSSL.
Google zegt uitdrukkelijk dat het niet voor publiek gebruik is... ook al zijn er partijen als Cloudflare die BoringSSL nu ook gebruiken (maar die hebben de middelen om dat toe te passen).
Zeg je dat BoringSSL iets verandert aan het TLS-protocol, waardoor de standaarden op het internet veranderen?

[Remzi1993]

Dit staat letterlijk op de projectpagina: https://boringssl.googlesource.com/boringssl/

BoringSSL is a fork of OpenSSL that is designed to meet Google's needs.

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Google is vrij open wat de intentie is van projecten en of ze het adviseren om het te gebruiken of niet. Ik snap dat deze comment off-topic is, echter ik wilde wat nuance bij @mocem aanbrengen aangezien mensen vaak zwart-wit denken en daarmee de maatschappij verder polariseeert.

[ApexAlpha]

Het verschil is wel dat Chromium open source is, en door meerdere browsers kan worden gebruikt.

Zo gebruikt ook MS Chromium onderwater en, ondanks dat Chrome enorm dominant is heeft Google niet dezelfde positie als MS destijds met IE.

[xenn99]

Gaat het nou om een chromium update of om een chrome update?
die 2 dingen zijn namelijk niet hetzelfde maar ze worden door elkaar gebruikt in dit artikel.

[Countess]

Chromium lijkt het. MS heeft in hun chromium based Edge browser deze verandering ook teruggedraaid is het lezen aan het einde van dit artikel.

[Xieoxer]

Google is de baas over het internet en is machtig genoeg om zulke aanpassingen door te voeren. Hun motor wordt gebruikt door bijna alle bekende browsers. Deze browsers moeten handmatig de change terug bouwen in hun code, maar dat zorgt alleen maar voor meer onderhoud op langer termijn.

Alleen Firefox en Apple gebruiken hun eigen motor voor het renderen van webpagina's. Google pusht eindgebruikers die een "andere" browser om over te stappen naar Chrome, door express Google diensten minder goed te laten werken op deze browsers ondanks dat de browser de zelfde technologie ondersteund. Google Meets werkt minder goed op Firefox dan op Chrome, ondanks dat gewoon gebruikt maakt van gestandaardiseerde technologie WebRTC.

[Reactie gewijzigd door Xieoxer op 23 juli 2024 18:59]

[Pizzaballs]

Chrome update die websites stukmaakt? “Stukmaakt” in de titel en in de tekst zonder quotes? Stukmaakt moet toch echt niet of beter anders weergeeft zijn… stukmaakt wat een onzin..

[TheVivaldi]

Websites zijn niet te gebruiken, maar in andere browsers werken ze wel zoals vanouds. Dus inderdaad zijn ze stuk.
Als ik op het motorblok van jouw auto een onderdeel weghaal en de garage moet hem repareren voordat je weer de weg op kan, dan zeg ik toch ook niet tegen jou “je motor loopt gewoon anders”? Dan is je auto gewoon stuk, klaar.

[Reactie gewijzigd door TheVivaldi op 23 juli 2024 18:59]

[Frame164]

Nee, de weergave is niet goed. De site zelf wordt niet veranderd. De webdevelopers hoeft niet zijn code te repareren en opnieuw te deployen. Op andere systemen werkt het immers nog gewoon.

Het voorbeeld met de auto klopt dan ook niet. Dat voorbeeld zou opgaan als iets of iemand de webserver applicatie kapot maakt waardoor die gerepareerd moet worden.

[MrMonkE]

Chrome is stuk.

[Nimja]

Het klopt wel. Een update van Chromium die nog niet in de standaarden zit (dus niet verwacht kan worden door websites), breekt websites die de standaarden volgen.

Dus ja, Chromium update maakt websites stuk.

[McBacon]

Zeker klopt het wel. Een random Chrom* user die op een site zit die door deze change niet meer werkt zoals het hoort: "kutsite, doei". Jij denkt dat iedereen het altijd ff in een andere browser probeert? Het bedrijf achter de site loopt vervolgens *iets* mis, dus waarom zou je het niét stukmaken mogen noemen?

[HollowGamer]

De nieuwe release zou ook de problemen moeten fixen met Linux-systemen die systemd-resolved gebruiken.

[prolitehds]

Google geeft mij Cyberdyne Systems gevoel. Echt niet gezond hun invloed. En nu lijken ze ook nog eens Microsoft te willen volgen met IE debacle. Waterfox is de enige goeie browser.

[prolitehds]

Veiliger? Internet is in de laatste 7 jaar hard achteruit gegaan. Kunt bijna stellen dat we nu zonder beter af zouden zijn. Het werkte eerst in ons voordeel nu wordt het vooral tegen ons gebruikt

[aikebah]

Veiliger ja.. voor deze (nu helaas teruggedraaide) change dan. Dat er daarnaast een major function creep voor webbrowsers is die deze kleine winst vrij makkelijk teniet kan doen met een paar browserbugs is dan wel weer jammer.