Firefox gaat links beveiligen door rel="noopener"-attribuut toe te voegen

Mozilla gaat links in Firefox beter beveiligen. Firefox 79 voegt automatisch het rel="noopener"-attribuut toe aan alle links die in een ander tabblad openen. Daarmee voorkomt de browser dat webpagina's gemanipuleerd kunnen worden.

In Firefox 79 worden links die via target="_blank" op een webpagina worden geplaatst automatisch ook voorzien van het attribuut rel="noopener". Dat attribuut kan door websitebeheerders worden toegevoegd aan links als extra beschermingsmaatregel, maar het is geen standaardfunctie in Firefox en veel andere browsers.

Met target="_blank" worden links in een nieuw tabblad geopend. Die functie heeft echter de eigenschap dat de gelinkte pagina kan bepalen wat er in het originele tabblad gebeurt. Daardoor kan een webpagina waarvandaan gelinkt wordt worden bijgewerkt door de nieuwe pagina, bijvoorbeeld door er een phishingpagina van te maken of er een nieuwe pagina van te maken met advertenties erop. Er zijn verschillende webdemo's beschikbaar die dat probleem illustreren.

Websitebeheerders kunnen dat mitigeren door het rel="noopener"-attribuut aan links toe te voegen. Het rel-attribuut specificeert de relatie tussen de originele en de nieuwe webpagina, en kan er dus voor zorgen dat de nieuwe pagina de oude niet mag veranderen.

Lang niet iedere websitebeheerder voegt noopener toe aan target="_blank"-links. Ghacks schrijft dat Mozilla dat attribuut standaard gaat toevoegen aan dergelijke links vanaf Firefox 79. Die komt eind juli definitief uit.

De functie zat al sinds 2018 in de Firefox Nightly-bèta's. Het is niet duidelijk waarom de feature nog niet eerder definitief is doorgevoerd. Safari voegt het attribuut al wel toe, en Google wil dat in de toekomst ook doen in Chrome.

Reacties (56)

[MrMonkE]

Is dit niet het probleem dat ze moeten verhelpen? "Met target="_blank" worden links in een nieuw tabblad geopend. Die functie heeft echter de eigenschap dat de gelinkte pagina kan bepalen wat er in het originele tabblad gebeurt. "

De gelinkte pagina zou niets moeten kunnen tenzij het dezelfde host is.

[RobertMe]

Het gaat hierbij om de window.opener "verwijzing" in JavaScript waarmee het window van de originele tab opgevraagd kan worden en dus ook gemanipuleerd. Origineel zal lijkt mij deze API ook meer bedoelt zijn in relatie met window.open(), waarmee een popup geopend kan worden. En in het geval van popups kwam het nog met enige regelmaat voor dat je in de popup "iets" doet en vervolgens de originele pagina wordt bijgewerkt. Denk daarbij bv aan een ouderwetse WYSISYG editor waarbij je bv een afbeelding wilt invoegen. Vaak opende dan een popup (window) waarin je de afbeelding deed uploaden, waarna op de originele pagina de juiste inhoud in de editor werd geplaatst. Dit verliep dan dus via deze window.opener. En toentertijd zal er vast ook een goede reden zijn geweest om dit ook via links met target="_blank" te ondersteunen.

Tegenwoordig kan soortgelijke functionaliteit echter ook via cross window messaging, met de window.postMessage API. Waarbij niet de volledige controle over het window wordt afgestaan (en dus niet bv een redirect van de originele pagina kan worden gedaan), maar er alleen berichtjes heen en weer gestuurd kunnen worden, en waarbij er ook controle plaatsvind over welk domein deze berichten mag sturen. Echter is ook in dat geval nog steeds een referentie nodig naar het window waarnaar je het message wilt sturen, dus ook daarvoor is, zoals ook in die documentatie staat, window.opener nodig.

[Reactie gewijzigd door RobertMe op 24 juli 2024 21:32]

[TijsZonderH]

Dat lijkt me niet een probleem waar Mozilla alleen iets aan kan doen. Ik kan me ook voorstellen dat het voordelen heeft, al kan ik zo niet bedenken welke... Is er een webdev hier die daar meer verstand van heeft?

[5pë©ïàál_Tèkén]

Stel - we nemen deze link waarmee ik op de comment van @TijsZonderH kan reageren. Ik klik met m'n muiswiel op die link en voila - in het nieuwe venster kan ik een comment typen (wat ik letterlijk nu aan het doen ben).
Nadat ik op 'plaats reactie' heb geklikt kan het zo zijn dat dit tabblad naar het vorige tabblad doorgeeft 'Yo, @5pë©ïàál_Tèkén is klaar met z'n reactie, doe maar een soft-refresh (of zoiets) zodat de reactie uit dit tabblad daar ook staat'.
Ook bij het sluiten van dit nieuwe tabblad kan dit tabblad doorgeven (met z'n laatste adem) 'Yo, ik word afgesloten en @5pë©ïàál_Tèkén gaat weer verder scrollen in het tabblad waar ik vandaan kom. Refresh even zodat Kuus de laatste stand van zaken heeft want uw content is al XXX minuten oud'.

Voordeel is dat dit ingebouwd kan worden als men, om wat voor reden dan ook, geen javascript wil draaien (noscript).

[Reactie gewijzigd door 5pë©ïàál_Tèkén op 24 juli 2024 21:32]

[Tunaflish]

Dan heb je nog steeds dat het nieuwe tabblad het oude tabblad kan beheersen. Als je inderdaad zou willen dat een nieuw tabblad het oorspronlijke tabblad laat verversen, waarom dan niet een stel events heen en weer sturen. In plaats van het nieuwe tabblad dat het oude vertelt wat die vindt dat er moet gebeuren ('Yo, er is een reactie verstuurd, doe nu wat ik) krijg je dan dat het nieuwe tabblad het oude tabblad informeert over wat daar gebeurd is: 'Yo, er is een reactie verstuurd, doe met die informatie wat jij wil'. Daarmee leg je de verantwoordelijkheid bij het oude tabblad. Die kan zelf bepalen of er uberhaupt geluisterd wordt naar dat event, en wat die vindt dat er dan moet gebeuren.

Binnen je eigen applicatie is het misschien prima dat verschillende tabs elkaar aansturen, maar het is een heel ander verhaal wanneer een externe site de jouwe gaat vertellen wat die moet doen.

[RobertMe]

Dat is dus iets wat window.postMessage realiseert. Het nieuwe tabblad kan dan via postMessage een berichtje (wat jij dus event noemt) sturen naar een ander window, die daarnaar kan luisteren via het message event. Alleen heb je ook in dat geval nog een verwijzing nodig naar het window waarnaar je het message wilt sturen, en dat is dus alsnog window.opener. Waarbij deze API ook meteen "beveiliging" bevat waarbij op basis van domein gecontroleerd wordt of je het message wel of niet ontvangt (IIRC, maar kan me vergissen en kan ook zijn dat de ontvanger het zelf moet controleren).

Wat jij dus omschrijft kan tegenwoordig wel. Maar ding is dus dat de referentie naar window.opener nog nodig is, en juist dat nog steeds een aantal beveiligingslekken bloot legt. In die zin dat bepaalde APIs binnen window.opener al zijn afgeschermd (zoals window.opener.document, waardoor de HTML niet meer gemanipuleerd kan worden), maar andere APIs dus niet en dat nog steeds misbruikt kan worden. Zoals dus window.opener.location, waardoor niet de HTML uitgelezen noch aangepast kan worden, maar wel een complete malafide website in de plaats geladen kan worden.

[5pë©ïàál_Tèkén]

_{+3 van mij}

[Tunaflish]

Ik zit niet zo heel diep meer in de browser API's, ik geloof direct dat dit soort manieren al te implementeren zijn. Mijn reactie was meer bedoeld als 'Als je wil dat een nieuw tabblad een oud tabblad kan aansturen, zorg er dan gewoon voor dat het nieuwe tabblad het oude op de hoogte brengt van wat er is gebeurd, en laat de oude daar zelf over bepalen wat er moet gebeuren'. Dat in tegenstelling tot het nieuwe tabblad direct toegang geven tot de oude.

Persoonlijk ben ik van mening dat een tabblad alleen zichzelf zou moeten kennen, en niets weten van eventuele andere tabbladen, laat staan dat die ook nog eens code van elkaar kunnen ontvangen. In die zin vind ik de noopener best interessant, kende het tot dit nieuwbericht nog niet. Binnenkort eens induiken.

[5pë©ïàál_Tèkén]

Ik doe even de aanname dat je de events via javascript wil doen. Zoals ik zei tegen @Cerberus_tm - Stel dat je om wat voor reden dan ook geen javascript wil draaien (NoScript), dan kan je dit toch nog implementeren.

Jep, er zijn andere manieren waarop het kan. Afhankelijk van conventies, voorkeuren, richtlijnen, paranoia bij developers/product owners worden er keuzes gemaakt. Deze tool geeft het dev team een keuze. Dan is het aan Firefox om peilen 'goh, we hebben deze nieuwe tool in de toolbox gedaan, eens kijken wat de community er mee doet.'
Zorgt het voor veel security issues omdat men het verkeerd implementeerd? ==> betere documentatie. Helpt dat ook niet? Dan overwegen om de tool terug te trekken omdat het (helaas) niet goed uit de verf komt.

[Tunaflish]

Mja, javascript, browser API's, postduiven, de manier zelf is mij om het even. Wat ik probeerde over te brengen was dat het IMO beter zou zijn wanneer een tabblad een ander kan vertellen wat er gebeurd is, in plaats van het andere tabblad te vertellen wat die moet gaan doen. Dat is hoe ik dit artikel en je voorbeeld las, en wanneer je die verantwoordelijkheid verschuift heb je toch al een flink deel van de risico's aangepakt denk ik.

Ik vind het een prima zet van Firefox hoor, begrijp me niet verkeerd. Wat ik net al in een andere reactie zei, ik kende heel die functie niet. Ik zie ook zeker in wanneer het concept van communicatie tussen tabbladen nuttig ingezet kan worden, zoals in het voorbeeld wat je gaf. Wat mij betreft is de implementatie zoals ik die nu begrijp gewoon niet de juiste, maar is het prima te redden door de boel om te draaien.

[unilythe]

"Dan heb je nog steeds dat het nieuwe tabblad het oude tabblad kan beheersen"

Wat...? Er werd gevraagd een voorbeeld te geven waar het nuttig kan zijn om het oude tabblad te kunnen beheersen. Dan doet hij dit, en zeg jij "Ja maar dan kan je nog steeds het oude tabblad beheersen!"

[Tunaflish]

Ja, ik ga in op het specifieke voorbeeld omdat ik erken dat het een situatie kan zijn waar je dat als dev zou willen kunnen, maar dat ik niet denk dat de browser het op zo'n manier toe zou moeten staan. Als je al wil dat die tabbladen van elkaar weten, laat ze elkaar dan informatie geven in plaats van opdrachten.

Lees het anders als een 'Zou het niet beter zijn als...'. Leek mij wel vrij duidelijk.

[Cerberus_tm]

OK maar deze functionaliteit kun je toch ook met Javascript via berichten (.postMessage e.d.) verschaffen?

[RobertMe]

Dat klopt. Maar bij postMessage moet je wel aangeven met welk window je wilt communiceren, oftewel: heb je alsnog window.opener nodig om aan te geven waar het message heen moet. En bij gebruik van noopener is window.opener helemaal niet meer beschikbaar (is null), i.t.t. tot andere security maatregelen waarbij bv window.opener.document nu al niet (meer) beschikbaar/bruikbaar zijn). Het gebruik van noopener kan potentieel dus wat "issues" geven die niet zomaar opgelost kunnen worden, juist omdat de moderne APIs (zoals dus postMessage) nog steeds een verwijzing nodig hebben op basis van de oude APIs (window.opener voor de verwijzing naar welk window/tab gepost moet worden).

[Cerberus_tm]

A, okee, dat is dan inderdaad niet zo handig dan. Maar als je echt per se de oude functionaliteit nodig hebt, kun je dat immers altijd nog doen via een Javascript-knop in plaats van een gewone link; en als een aanvaller Javascript op je pagina kan uitvoeren, ben je toch al de pineut. Dus dan zou dit wel echt kunnen helpen.

[5pë©ïàál_Tèkén]

'Natuurlijk' kan het op andere manieren. Echter, het geeft de developer(s) de keuze om iets op deze manier te inplementeren. Stel dat je om wat voor reden dan ook geen javascript wil draaien (NoScript), dan kan je dit toch nog implementeren.

[Cerberus_tm]

Ja, elke beperking van functionaliteit heeft haar nadelen.

Als je geen Javascript wilt draaien kan de nieuwe pagina misschien het beste gewoon in hetzelfde tab openen?

[5pë©ïàál_Tèkén]

Gaarne rekening te houden met gebruikers die per ongeluk/expres alles in verschillende vensters openen .

[Cerberus_tm]

Dat kan dan inderdaad niet. Maar bij een site waarbij het echt absoluut nodig is dat er communicatie is tussen twee tabs/vensters, moet het dan maar zo.

[5pë©ïàál_Tèkén]

Het is in 99% van de tijd niet de bedoeling dat een site zo wordt gebruikt/misbruikt. Maar dingen afvangen zoals geen js mogen/willen, per ongeluk openen in een nieuw venster etc etc is denk ik het halve werk van een web dev. Functionaliteit inbouwen lukt vaak wel - het idiot-proof maken en zorgen dat de boel blijft werken in de ja-maar-wat-als-scenario's houdt het werk interessant

[Cerberus_tm]

Inderdaad, vooral bij dingen die bij het schrijven niet bij je op waren gekomen, of die überhaupt niet te voorzien waren.

[skunkopaat]

Maar moet dit cliënt side gebeuren? Er kan in dit geval toch bijvoorbeeld een seintje gegeven worden aan de server en die zorgt dat de comment er komt te staan. Of denk ik nu te simpel?

[5pë©ïàál_Tèkén]

Het lijkt mij handig om dit client side te doen omdat het refresh-gebeuren afhangt van wat er aan de client side gebeurd (submitten van de comment). Als je dit server side doet dan zou je bij elke gesubmitte comment server side een check moeten doen van goh staan er nog andere windows open bij die user in de sessie, zo ja --> refreshen. Bij veel comments kan dat behoorlijk wat load geven.
Als de client side een gilletje geeft scheelt dat weer wat server load.

[kozue]

Ik bouw zelf webapplicaties en kan me werkelijk geen enkele legitieme reden verzinnen waarom het nieuwe tabblad iets in het oude zou moeten kunnen wijzigen. De hele reden om iets expliciet in een andere tab te openen is immers omdat je de oude pagina wilt houden om daar weer makkelijk naar terug te keren. Zoals bv bij het openen van een externe site die je niet onder controle hebt. De enige uses waar ik deze functie ooit heb gezien is met vervelende popunder (reclame) sites, en dat vind ik geen legitieme reden.

Laten ze gewoon de mogelijkheid van het nieuwe tabblad om de opener te manipuleren er helemaal uit slopen, dan heb je ook geen vreemde rel attributen nodig. Dit is de eerste keer dat ik van rel=noopener gehoord heb, en ik zie nog steeds geen reden om dat zelf te gebruiken.

[RobertMe]

Dit is de eerste keer dat ik van rel=noopener gehoord heb, en ik zie nog steeds geen reden om dat zelf te gebruiken.

Als je geen reden ziet om het te gebruiken, dan heeft het ook geen reden dat het mogelijk is, en zouden ze het bestaande gedrag volgens diezelfde beredenering dus ook niet hoeven aan te passen Het zou juist moeten zijn "laat ze dit gedrag verwijderen uit de browser, en ik ga nu per direct overal rel="noopener" toepassen".

Het oude gedrag is een flink beveiligingsrisico. Als een webapplicatie ook maar op enigerwijze user generated content heeft (en die kans is nogal groot) en daarin kan de gebruiker zelf (beperkte) HTML plaatsen om bv ergens naar toe te linken dan kan een gebruiker dus ook een link naar een malafide website plaatsen, waarna iemand anders die link opent, en de malafide website bv de pagina in die tab kan vervangen / redirecten naar een phisingsite die exact op de webapplicatie lijkt. De gebruiker sluit vervolgens de tab, ziet de login pagina van de webapplicatie, logt in, en de aanvaller heeft meteen de login gegevens van die gebruiker. Immers let je als gebruiker wellicht wel op welke website je gewoon opent (URL intypt, selecteert uit adresbalk, ...) waardoor je op de juiste site uit komt, maar als je via een link binnen de "bekende" website op een andere website uit komt verwacht je niet dat bij terugkomst de "bekende" site is vervangen door een malafide / phisingsite. Dat is juist waar het grote probleem in zit en rel="noopener" oplost (immers kan de pagina die in de nieuwe tab wordt geopend dan niet meer een redirect doen in van de originele pagina/tab).

[ArmEagle]

Dit is de eerste keer dat ik van rel=noopener gehoord heb, en ik zie nog steeds geen reden om dat zelf te gebruiken.

Misschien is het bij wat jij ontwikkelt niet zo'n punt. Maar het artikel geeft volgens mij duidelijk genoeg aan waarom dit van belang is.

Op mijn werk voegen we al een aantal jaar standaard aan target=_blank rel=noopener toe. Gewoon omdat dat veiliger is.

[Kenhas]

Ik heb een paar webapplicaties waarbij er communicatie is tussen twee vensters. Het originele venster is een kaart met straten en het andere venster is een "streetview" - variant.

Klik je in het ene venster op een locatie, dan verandert de locatie in het andere venster en omgekeerd.

Nu is het me niet onmiddellijk duidelijk of dit gevolgen gaat hebben voor deze applicaties want deze werken met postmessage. Maar het is een voorbeeldje waarbij het ene venster invloed moet hebben op het ander

[Reactie gewijzigd door Kenhas op 24 juli 2024 21:32]

[denniszon]

Ik heb zelf laatst wat gemaakt voor een radiostation. De radio opent in de popup maar op de website zelf heb je ook nog een kleinere player. Zodra het in de popup speelt dan passen de controls zich aan op de player van de website. Je kan daar dan ook de radio terwijl je aan het browser bent op de website, in de popup dus pauzeren / starten. Dit is puur iets voor gemak en niet per se nodig. Maar terwijl je bezig bent met nieuws lezen op de website hoef je niet de popup erbij te pakken om hem even te pauzeren.

Waarom is de player in een popup? Dat komt omdat er nu video reclame makkelijk kan laten zien zonder dat je op de website ruimte verliest en je ook een uitgebreide lijst kan hebben van alle stations.

Er zit nu een kleine bug in de player van de website om de radio te stoppen in de popup, maar een voorbeeld kan je vinden op: https://kink.nl/

[Vinnie2k]

Ha, leuk om je hier tegen te komen. Heb zelf al eens een paar bugs doorgegeven van de site en de app.

Er waren wel een paar rare dingen met die site hier. Maar ga ervan uit dat dat nu niet meer speelt.

Grappig! Leuk station ook trouwens!

[denniszon]

Leuk om je weer is te spreken! Ja idd, hele andere muziek dan andere stations maar niet minder leuk daardoor.

Ah was jij degene die dingen doorstuurde .

[Vinnie2k]

Samen met GP, zeker! Hihi

[djwice]

Dit komt nog uit hele oude HTML specs, did een erfenis zo maar te zeggen.

(context) In die tijd was er nog geen https/ssl en bestond Google en Facebook nog niet. En opmaak werd nog met inline met aparte attributen voor bijvoorbeeld font, kleur en achtergrondkleur gedaan.

Het was fijn om te weten waar de bezoek vandaan kwam voor je referenties en er werd veel van frames gebruik gemaakt tussen diverse websites - ook binnen dezelfde universoteit bijvoorbeeld.

Het menu zat vaak in een apart frame zodat die altijd in beeld kon blijven. Deze functie hielp bijvoorbeeld er voor dat je het menu kon laten veranderen aan de hand van je content.

Voor meten van je bezoekers had je vaak een script met een teller (counter) van een 3e partij zoals Nedstat en HitBox (later overgenomen door Adobe). Deze boden dan een publieke pagina met tellers van bezochte pagina's en waar die bezoekers dan vandaan kwamen, welke browser en os gebruikt werd.

Tegenwoordig hebben we TLS en zijn die statistieken concurentie gevoelig en geld en waard. Het blokkeren van de verkeer gegevens is iets technisch; attributen toevoegen aan hyperlink tags en http-headers bij elk request.
Door waar we vandaan komen gebruikt een marketeer vaak scripts die gehost worden buiten de eigen website en de afstemming daarover met de HTML ontwikkelaar is er vaak niet, de afstemming met de server beheerder ook niet.
Gevolg is dat de server beheerder de http-headers wijd open zet om geen conflicten te krijgen met marketing.
En leren de meeste front enders met name hoe ze hun code in een eigen namespace kunnen zetten zodat hun code ondanks alles blijft werken.

Afschermen van click statistieken worden dus niet gedaan omdat de opdracht gevers vaak alleen kijken of alle marketing tools blijven werken en hoe de site smoelt.

De techniek om dit netjes te regelen bestaat al weer meer dan 8 jaar. Maar worden zelden goed toegepast. Zelfs security tools faciliteren de bestaande manier van werken niet goed.

side note
Ik heb daarom een proxy ontwikkeld dit wél faciliteert zonder dat de organisatie intern anders moet gaan communiceren. Hij wordt op dit moment onderworpen aan diverse certificeringen (PCI-DSS, HIPAA etc.) en penetratie tests en uiteraard praktijk tests met een bedrijf met enkele miljoen klanten.

[Reactie gewijzigd door djwice op 24 juli 2024 21:32]

[Puffino]

Zelfs dan nog kun je je afvragen of die geopende pagina iets mag op de opener.

[Annihlator]

Ik vraag me af of iemand goede voorbeelden kent waar een tabblad/venster directe toegang behoort te hebben tot de andere; waarom zou je dat bijv. niet middels page-layout/floats/hovers afscheiden zodat het functionele deel/de pagina één geheel is ipv meerdere losse vensters/tabbladen? Of interpreteer ik wat hier genoemd wordt dan compleet verkeerd?

Als daar niet echt goede voorbeelden voor zijn, vraag ik me af of de functie in het algeheel niet eerder een zwaktepunt beveiligingstechnisch is dan een extra mogelijkheid.

[Anoniem: 951889]

Vroeger toen beeldschermen 1024x768 waren en tabbladen nog niet bestonden was het handig voor webapplicaties met veel data in meerdere contexten, zoals chats of tool windows of wysiwyg editors die dan een nieuwe window openen om een file in te editen.

Nu heb je genoeg pixels en html5 stuff om een complete applicatie in een enkele browser tab te doen, je hebt nu hele windowing systems die binnen een webpagina werken.

Dus ja zover ik weet kan die hele functie er net zo goed uit.

[Annihlator]

Ahja, best kans dat het dan zegmaar een legacy-support remnant is

[5pë©ïàál_Tèkén]

Zie m'n plempsel hier

[NielsFL]

Omdat je het dan echt helemaal onmogelijk maakt. En dat is niet de bedoeling.

Feitelijk wijzigt men slechts de default van rel=opener naar rel=noopener en zul je straks expliciet rel=opener moeten gebruiken wanneer je deze relatie toch in stand wil houden.

[SavageBrother]

Poh dit had ik even nodig op de vrijdagmiddag.

[wifikabelhuren]

Dit is een veelgebruikt trucje bij de meeste kortingsites.

[hdullink]

Dit doet me sterk denken aan een breaking update van de Internet Explorer wat ongeveer 10 tot 15 jaar geleden plaats vond.
De target="_blank" werd veel gebruikt voor dialoog vensters in de vorm van een pop-up. Bij sluiten van het dialoog venster (na drukken op OK of Opslaan) wilde dit venster gegevens doorgeven aan het hoofdvenster. Dat lukte niet meer.
Zo werd in één update complete bedrijfsadministratiesystemen onbruikbaar.

[NLxDoDge]

Ik snap dat het 10 à 15 jaar geleden een probleem was. Maar als je nu nog zo omgaat met technologie en het zo hebt geprogrammeerd, zou ik me afvragen of het bedrijf dan zelf wel goed bezig is.

[rl3]

Voor het evenwicht vind ik het belangrijk dat midden en rechts ook dezelfde beveiliging krijgen, maar het is een goed begin.

[CyberMania]

Waarom zo laat? Apple biedt dit standaard al sinds 2019 op Safari. Had juist van Firefox (of andere opensource browsers) verwacht hiermee de eerste te zijn.

[Reactie gewijzigd door CyberMania op 24 juli 2024 21:32]

[ReVision.]

Firefox op mijn Apple apparaten doet dat anders helemaal niet.

[fretnn]

Op Mac of op een mobile device?

[Donstil]

Maar heeft dit dus wel, dat was zijn punt.

[tom.cx]

Wannee je andere browsers gebruikt op je iOS / iPadOS apparaat is het op de achtergrond gewoon Safari. Zit alleen een eigen GUI overheen. Dus een meerwaarde heeft het niet.

[atthias]

firefix sync of tabbladen doorsturen als je ook firefox op PC hebt is de enige meerwaarde die ik kan bedenken inderdaad

[lenwar]

Correctie. Je gebruikt dezelfde render engine als Safari. Een internetverkenner is meer dan alleen een render engine. Zoals hieronder al wordt aangegeven kan je bijvoorbeeld je favorieten/geschiedenis/tabbladen synchroon houden. Dat kan een meerwaarde zijn, afhankelijk van je gebruik.

[Jazco2nd]

Dat is inmiddels verouderd. Er is een update uitgekomen die dat aanpakt, en 1 of ander native onderdeel van MacOS gebruikt waardoor de accu van mijn MacBook nu flink gespaard wordt.
Bovendien zat ik al zovaak aan de lader dat het voor mij voor werk althans de ideale browser was, al voor de update.

[Reactie gewijzigd door Jazco2nd op 24 juli 2024 21:32]

[MN-Power]

Vergelijk je Firefox nu met piracy of zo? Die ontwikkelaars worden ook gewoon betaald. En die van Apple worden sowieso betaald, of je Safari nou gebruikt of niet. Dus als dat het argument is zou je juist Firefox (ernaast) moeten gebruiken. Overigens is het zelfs op mijn mobiel mijn standaard browser. Vooral omdat ik veel meer invloed heb op o.a. third party cookies. Chrome heb ik er zelfs af gegooid sinds Edge Chromium beschikbaar is.

[Loggedinasroot]

En als je Safari gebruikt krijgen de programmeurs tenminste betaald voor hun werk. Wel zo eerlijk.

Wat bedoel je hier precies mee?