Onderzoekers waarschuwen voor tracking via favicons in cache browsers

Onderzoekers van de Universiteit van Chicago waarschuwen voor een methode om gebruikers op het internet te volgen met behulp van favicons. Dat zijn icoontjes die domeinen meegeven om ze makkelijk identificeerbaar maken in de interface.

De onderzoekers claimen dat een malafide domein een specifieke combinatie van favicons opslaat op de machine van een gebruiker en ze zo volgt. De favicons worden in meerdere populaire browsers opgeslagen in een cache die niet geleegd wordt of buitenspel gezet wordt in private browsing. Daardoor kan een domein een specifieke gebruiker volgen, zelfs als zij cookies blokkeren, privé browsen en andere fingerprinting-technieken dwarsbomen. Browsers melden de aanwezigheid van een relevante favicon in de cache aan de website die ze bezoeken, om zo bandbreedte te besparen.

Een malafide website zet een bepaalde combinatie van favicons op het systeem van een doelwit, waaraan ze dan te herkennen zijn bij een herhaald bezoek. Hoe groter de hoeveelheid bezoekers een website heeft, hoe meer verschillende favicons en redirects langs subdomeinen met favicons er nodig zijn. Zelfs met een website die bijna 4,3 miljard unieke browsers moet volgen, zijn 32 redirects echter genoeg. Dat kan volgens een rekenvoorbeeld van de onderzoekers in twee seconden gedaan zijn.

De onderzoekers hebben de makers van de getroffen browsers op de hoogte gesteld. Dat zijn Chrome, Safari en Edge. Google zegt al aan een fix te werken, Apple zegt naar de bevindingen van het onderzoek te kijken en Microsoft was niet op tijd bereikbaar, aldus Ars Technica. De Brave Browser was ook vatbaar, maar de makers van die browser hebben de kwetsbaarheid opgelost. Firefox hoort eigenlijk ook in het rijtje getroffen browsers, maar door een bug werkt de exploit bij die browser niet. Als workaround zouden gebruikers favicons kunnen uitschakelen, hoewel men er wel zeker van moet zijn dat ze ook daadwerkelijk niet opgeslagen worden en niet alleen niet getoond worden in de interface.

Reacties (104)

Altijd al vermoed, eerlijk gezegd. Daarom schakel ik uit voorzorg het cache'en van favicons ook standaard uit. Geen idee hoe je dit onder andere browsers doet, maar onder Firefox doe je het zo:

Ga in "about:config" op zoek naar de sleutel "browser.chrome.site_icons". Zet de waarde op "False". Sluit daarna Firefox af. Verwijder daarna in de profielmap van Firefox vervolgens de bestanden "storage.sqlite" en "favicons.sqlite", mochten er al favicons zichtbaar zijn in je bladwijzers. Bij het opnieuw opstarten van de browser maakt Firefox de beide containers "storage.sqlite" en "favicons.sqlite" opnieuw aan, die dan helemaal schoon zijn.

Easy does it..

Dit was ook al bekend. Daarom kun je deze feature uitschakelen in Bitwarden.

Vraag me af hoe groot een database met alle favicons ter wereld zou zijn. GeoIP valt bijvoorbeeld best mee qua grootte.

Is dat Disable Website Icons?

Yup, en @CykoByte dat bedoelde ik inderdaad

[Reactie gewijzigd door Jerie op 20 februari 2021 16:26]

Bedankt

Staat in artikel : 32-bit * 4,3 miljard ~ 13,2 GB

Als je wilt uitrekenen hoeveel favicons je nodig hebt om 4,3 mljd unieke browser te tracken, klopt je antwoord niet. Elke favicon is een bit in je 32-bits identifier, dus 32 favicons is genoeg.

Waarschijnlijk bedoelt @Jerie trouwens gewoon een globale database van alle favicons die op het moment door sites in gebruik zijn.

Ah bring document nu gelezen.
Zet geen unieke naam voor favicon maar roept 32 pagina's aan met elk wel of niet een fav icoon.

En het wel/niet aanwezig zijn bepaald de bit waarde.

Dit trucje kan met elk element dat behouden blijft tussen bezoeken in. Voorheen werd dat met images in cache, toen local storage etc. gedaan.

[Reactie gewijzigd door djwice op 20 februari 2021 18:36]

Werkt deze exploit ook als javascript is uitgeschakeld?

Browsers controleren by default altijd naar een favicon op een domein. Dat zie ik vanuit de serverlogs standaard als een favicon niet op het domein staat (een 404). Dus ja theoretisch is het mogelijk; maar goed een browser per domein een favicon apart op laten slaan kost gewoon blocks aan data. Die dingen zijn amper 2KB groot en je krijgt zo enorm veel overhead als je extreem veel sites bezoekt.

Ja je kunt dit namelijk server-side afvangen en dan een speciale combinatie van opvolgende redirects terugsturen. Staat beschreven op SO: https://stackoverflow.com...sit-to-a-website/16933618

Overigens is dit al uit 2013.

Het zou wel handig zijn om voor de meest gebruikte sites zelf een icoontje op te geven, dat maakt de herkenbaarheid toch wat makkelijker als je veel tabs open hebt.

[Reactie gewijzigd door sampoo op 20 februari 2021 19:12]

In Google Chrome kon je een aantal versies geleden nog de zichtbaarheid uitschakelen van favicons d.m.v. een flag. Helaas hebben ze die mogelijkheid ongedaan gemaakt. Gelukkig kun je "chrome.dll" patchen en behoren favicons weer tot het verleden, waar ze horen.

Hoe herken je dan fatsoenlijk een website als je meerdere tabs open hebt, waarbij de titel van de website in elke browser ook al wordt afgepakt. Ik moet er niet aan denken dat de visuele herkenning van websites dmv de favicon niet zou bestaan.

Thanks, direct aangepast!

Dank voor de uitleg. Ik heb het vanmiddag uitgezet, maar nu weer aan gedaan. Ik vind die icoontjes toch wel handig (bijv als ik een tabblad pin, dan zie je niets behalve het icoontje, als je meerdere doet kan je ze niet meer onderscheiden). Wat enorm irritant dat ze die kunnen gebruiken om je te tracken. Zal er nog maar even over nadenken.

Misschien handig om even te melden waar je dit hebt gevonden.

In de map %appdata%\Mozilla\Firefox\Profiles\<profielnaam>

Onder Help in het hamburgermenu, klik op Troubleshooting Information, about:support opent, scroll naar Profile directory en klik dan op Open directory, file opent en dan instructies volgen die Qalo beschrijft.

Dit is zo'n klassieke 'nvm i fixed it' comment ;)! Je zou even een link/beschrijving kunnen plaatsen voor de volgende lezer die het niet kan vinden

Het blijkt dat deze onderzoekers nogal onetisch te werk zijn gegaan.

https://twitter.com/antumbral/status/1352569510692179969

Ze hebben een bug report naar Mozilla gestuurd en als deze 'bug' gefixt zou zijn zou daarmee deze attack vector ook mogelijk zijn geworden op Mozilla. Ze hebben niks gezegd over dat de reden was om een aanval te kunnen testen, het lijkt erop dat de enige reden om die bug te reporten was zodat ze een 'sterker' paper zouden hebben.

Het lijkt er ook niet op dat ze ooit van plan waren Firefox te informeren over het waarom. Bewust proberen exploits toegevoegd te krijgen aan software lijkt me niet hoe een beveiligingsonderzoeker zich zou moeten gedragen...

De tweet is niet meer beschikbaar, dus ik link even de bron: https://bugzilla.mozilla.org/show_bug.cgi?id=1618257

De reactie van de onderzoeker hierop:

quote: https://bugzilla.mozilla.org/show_bug.cgi?id=1618257#c10

To provide additional details and context about our disclosure process: Our bug report was submitted to Firefox in February 2020 while we were still trying to understand how different browsers fetch/process/store favicons. Once we had devised the technique detailed in the paper and run experiments to see which browsers were susceptible, we informed all vulnerable browsers (June 2020). Our disclosure process took place before we submitted our paper and many months before publicizing our findings (February 2021), to allow browsers ample time to address this issue and prevent any users from actually being tracked in practice. Not notifying Firefox at that time was our oversight because we were focused on notifying the vulnerable browsers. In hindsight, we agree that we should have proactively notified Firefox. We hope that the continued conversations we had with other vendors to get the bug fixed shows that we had the best interests of web users at heart, and that neglecting to circle back with Mozilla once we found the security bug was an oversight rather than due to malice on our part.

Ze zeggen dat ze domweg vergeten waren om Mozilla te informeren. Ik heb niet echt aanwijzingen gezien dat we hierbij van de slechtst mogelijke bedoelingen zouden moeten uitgaan. Twitter doet dat uiteraard wel, altijd boos boos zonder dingen uit te zoeken.

[Reactie gewijzigd door Cerberus_tm op 21 februari 2021 03:37]

That’s what twitter is for matey .

Dat gezegd hebbende is dat natuurlijk wel gewoon een bug die voor 99,9% van de websites wel gewoon extra laadtijden kan geven.

Tja, denk je dat de browser wacht met laden voordat het favicon is opgehaald? Ik zou denken van niet?

Nou. Technisch gezien wel. Aangezien HTML van boven naar beneden afgehandeld wordt en je <head> tags in principe als eerste worden gepakt ben je met 32 requests wel de sjaak. Ja een browser gebruikt vaak meerdere requests in parallel, maar als je dus 32 redirects krijgt is de kans groot dat die connection pool snel volloopt. Meestal is het namelijk een kleine 10 wat tegelijk verstuurd wordt. De rest wordt gequeued, waarbij een redirect vaak prioriteit krijgt omdat dit vaak nog het resolven van een eerder request behelst.

Aangezien een favicon eigenlijk altijd in de <head> bestaat is de kans dus echt wel groot dat dit impact heeft.

Het punt van een cache is juist dat je dingen die eigenlijk niet veranderen binnen korte tijd gewoon bijhoud en zonder tussenliggend request gewoon kan tonen.

Bij dit soort kleine dingen is het issue dan ook niet bandbreedte maar latency. Stel dat je op een gemiddelde verbinding zo’n 50ms vertraging hebt op de hele route roundtrip. Dan heb je met 32 requests dus al 1600ms vertraging minimaal op de transmissie. Vertraging voor het verwerken van de redirect en het opzetten van de verbinding daargelaten.

Moet je voor de gein eens met devtools kijken hoelang het duurt om tweakers te laden en dan de network timeline eens bekijken.

Wat ik bedoel is, stel dat om de een of andere reden het laden van een favicon heel lang duurt (probleem op de server) bij een normale pagina, die deze truuk helemaal niet gebruikt. Zou Firefox dan wachten met het weergeven van de pagina totdat het favicon geladen is? Dat lijkt me toch niet? Dus dan lijkt het me niet dat deze bug zal zorgen voor extra laadtijden bij de meeste websites.

Nee het zal niet wachten totdat de boel wel geladen kan worden (een http.cat/404 is bijvoorbeeld ook altijd nog een optie), maar het neemt wel een slot in beslag van de requestpool waardoor iets anders bijvoorbeeld langer moet wachten op een fetch.


Daarnaast kan het ook andere ongewenste effecten hebben. Ik weet dat Safari vroeger een keer een bug had met de leeslijst waardoor de favicon een kleine 20-50K per uur werd opgevraagd omdat cache resolving niet goed ging. Vond tweakers niet zo grappig aangezien je dan dus je reverse proxy heel snel dicht trekt door openstaande connecties die simpelweg niks nuttigs doen.

Serverside kost dit ook gewoon resources. Stel dat tweakers 1000 requests per seconde kan afhandelen en doordat cache niet goed gebruikt wordt haalt iedere gebruiker bij iedere pageload weer een favicon op, dan kun je dus gewoon minder gebruikers serveren per seconde doordat je connectionpool gewoon vol raakt met nutteloze troep requests.

Okee, ja, het is wat inefficiënt, maar normaliter zal het toch geen effect hebben op de laadtijd voor de gemiddelde gebruiker dus.

Het centrale probleem bij de andere browsers is, als ik het goed heb begrepen, dat plaatjes normaliter per domein gecached worden, opdat een ander domein er nooit achter kan komen dat het plaatje in de cache zit bij een ander domein; maar bij de getroffen browsers worden favicons van alle domeinen in één grote cache gestopt, waardoor een favicon op het ene domein opgehaald kan worden uit de cache, terwijl een ander domein dat favicon in de cache had laten stoppen. Dus een lek in domeinisolatie.

Maar bij Firefox werkt het cachen van favicons überhaupt niet; volgens mensen in de bug op Mozilla was dit met opzet zo geprogrammeerd, inderdaad om domeinisolatie te waarborgen. Blijkbaar was het cachen van favicons geheel stoppen makkelijker dan het wel toelaten maar per domein isoleren.

Nou ja en nee. Ligt aan de browser. Firefox heeft in principe een pool van 17 connecties beschikbaar, maar Chrome heeft er voor hoofdtab slechts 6. In firefox loop je dus veel minder snel tegen blocking aan.
https://blog.bluetriangle...g-web-performance-villain

Het probleem met blocking is dat het vaak een ondergeschoven kindje is, maar dat het wel een significante impact kan hebben. Het ophalen van een favicon duurt meestal relatief lang door netwerk en http overhead ten opzichte van daadwerkelijk nuttige data. Als dit dus als een van de eerste dingen gebeurt dan is dat zonde als dit ook gewoon gecached had kunnen zijn.

Dat mozilla denkt dat het beter is om geen caching te hebben dan niet helemaal de juiste subdomein isolatie is hun keuze, maar ook gelijk een die ik niet begrijp. Het zijn dit soort kleine dingen die allemaal bij elkaar opgeteld zorgen voor een waardeloze browser experience (niet dat ze die hebben, maar hypothetisch gezien). Een favicon zou over subdomeinen gecached mogen worden, zolang dat op top level gespecificeerd staat. Een favicon van een subdomein mag je niet cachen voor gebruik op het hoofddomein.

Sws zou dit client side natuurlijk volledig transparant moeten zijn. Cache of niet zou voor de opvragende code niet relevant moeten zijn. Net als dat dit met allerlei ander files het geval is.

Ik ben het met je eens dat Mozilla gewoon het favicon zou moeten cachen. Het is een beetje inefficiënt en verspillend.

Maar ik ben het wel met Mozilla eens dat niet cachen beter is dan domeinisolatie verbreken. Ik denk dat dit meer een tijdelijke work-around was. Hopelijk gaan ze het nog aanpakken.

Verder zie ik niet echt hoe het extra moeten laden van een klein plaatje in elke nieuwe tab nou zou moeten zorgen voor significant langzamer laden van de pagina voor de gebruiker. Als al die connecties vol zitten, zal er vast nog wel meer zijn dan de boel kan vertragen; dan maakt zo'n extra faviconnetje toch niet zo heel veel meer uit?

[Reactie gewijzigd door Cerberus_tm op 21 februari 2021 21:49]

Hoewel deze methode al heel oud is (is al uitgebreid gedocumenteerd in 2013 inclusief implementatie op stack overflow: https://stackoverflow.com...sit-to-a-website/16933618 en dat was naar aanleiding van een vraag die weggemodereerd is), is dit in de EU volgens mij nog steeds niet toegestaan zonder consent.

Men is kompleet doorgeslagen met cookiewalls en dingen als “legitimate interest” vinkjes. Had net nog een website waar ik 5 minuten bezig ben geweest om alle vinkjes uit te zetten (kuch dailymail).

De mensen die dit soort hoepels verzinnen verdienen wat mij betreft dan ook celstraf. Je wordt gewoon verkocht bij opbod.

In dit geval kost het ook nog eens resources van de client. 32 HTTP calls voor een stom icoontje is natuurlijk bizar en op instabiele lijnen kan dit behoorlijk wat tijd kosten. Je verpest dus de UX doordat je mensen per se wil tracken zonder consent. Dit is niet waar het web voor is bedoelt.

Super toevallig dat deze reactie is weggemodereerd

Sorry wat bedoel je precies? De originele vraag op StackOverflow?

Dat zijn icoontjes die domeinen meegeven om ze makkelijk identificeerbaar maken in interface.

Een favicon staat toch op de hosting server van de website? Of kan een favicon ook via een domeinnaam verspreid worden?

De browser cached een favicon. Ik heb me hier nog niet in verdiept, maar ik vermoed dat de website dan gewoon kijkt of een browser de favicon wel of niet op komt halen. Als de filename, bytesize enzo identiek zijn als wat de browser al in de cache heeft zitten, gaat het niet de favicon opnieuw downloaden en trekt het deze weer uit de cache.

Geef elk IP bv zijn eigen setje favicons. Combineer dat dan weer met X aantal favicons via redirects naar verschillende domeinen die wel of niet gecached zijn en tadá, fingerprint.

[Reactie gewijzigd door batjes op 20 februari 2021 13:17]

Dit is volgens mij precies wat er gebeurt. De malafide website checkt of een bezoeker het eerste favicon wel of niet komt ophalen, doet een redirect naar ULR 2 en kijkt daar weer of het favicon wordt opgehaald, doet een redirect naar URL 3, enzovoort, tot en met URL 32. Zo ontvangt de website via de 32 URL’s 32 keer een binaire waarde (wel of niet favicon ophalen). In totaal levert dat 2³² = 4,3 miljard mogelijkheden op. Als iedere terugkerende bezoeker een andere set favicons in zijn cache heeft staan door zijn vorige bezoek, zijn ze stuk voor stuk uniek herkenbaar.

Vreemd dat de verschillende browsers daarop in gaan. Voor de pagina zelf staat bijv. Chrome nauwelijks nog redirects toe; wordt je doorverwezen, dan moet je daar stuk voor stuk handmatig mee akkoord gaan.

Hoogstens naar externe domeinen waarbij je met een kluitje het riet ingestuurd wordt. Op vrijwel iedere request naar een non https link krijg je meestal namelijk eerst een 302 terug naar de SSL variant (HTTPS).

Het internet functioneerd niet zonder redirects.

Dus ze kunnen achterhalen wat je op dat moment in cache hebt. Maar als je dan tussendoor een andere site bezoekt met een tot dan toe nog niet gedownload favicon? Dan veranderd toch ook je favicon reeks?

Ik vraag me af hoe hij wordt gecacht, kan je de favicon inderdaad manipuleren voordat je hem serveert naar de browser zodat elk favicon unique en dus trackbaar is.

Je hoeft het icoontje zelf niet te manipuleren, je moet alleen weten welke icoontjes de bezoeker op zijn systeem heeft staan.
Het icoontje van Tweakers kan als een onderdeel zijn van een unieke vingerprint.
jij als gebruiker ziet het verschil niet maar je kunt schijnbaar niet bewust na kijken welke icoontjes van welke websites op jou systeem staan en de onbekende daarna wissen.
1x per 2 á 3 maanden gooi ik mijn volledige cache leeg/weg maar juist dit gedeelte kan ik dus niet terug halen en wissen dus daar zit een behoorlijke fout.

Als je geen unieke favicons gebruikt, werkt dat maar 1 keer. Na het tweede bezoek is dan elke favicon gecached.

Maar unieke favicons genereren is niet zo moeilijk met een url rewrite en php gd library bv.

Er zijn per website maar 32 favicons nodig op verschillende subdomeinen die iemand wel of niet in cache heeft.

[Reactie gewijzigd door RoelRoel op 21 februari 2021 09:24]

Wat ze volgens mij doen is zelf subdomeinen opzetten met eigen favicons. Die subdomeinen doen verder helemaal niks, het feit of de favicon wel of niet gecached is wordt gewoon gebruikt als 'bit'. Het favicon is er wel of niet, dus een 0 of een 1. Daarom staat er dat je met 32 redirects zo'n kleine 4,3 miljard unieke browsers kunt volgen. Een kleine 4,3 miljard, dat is 2 tot de macht 32, oftewel het aantal unieke combinaties wat je met 32 bits uit kunt drukken.

Als de filename, bytesize enzo identiek zijn als wat de browser al in de cache heeft zitten, gaat het niet de favicon opnieuw downloaden en trekt het deze weer uit de cache.

Maar die dingen zijn toch allemaal 16x16 pixels en heten allemaal favicon.ico als het goed is.
Dan wordt het - zonder manipulatie - best een uitdaging om de juiste favicon.ico te vinden in de cache lijkt me.

Je begrijpt dat de cache van je browser geen rekening houdt met een bestandsnaam, enkel met de volledige URL, die hij mee bewaart. Wat de filename is (op je PC in je cache) is daarbij niet relevant.

Als die volledige URL toch al in je cache zit, waarom dan ingewikkeld gaan zitten doen met een favicon voor tracking...

Dit is een taalkwestie: de domeinnaam heeft er niet letterlijk mee te maken, maar het favicon dient als identificatie voor een website/domein. Natuurlijk wordt het pictogram verspreid door een hosting server zoals alle website assets. In de volkmond kun je spreken van "het domein geeft dat mee", min of meer, ook al klopt het strikt technisch niet helemaal.

On topic: hopelijk kunnen browser-bouwers hier iets op verzinnen. In het ergste geval door favicons helemaal niet meer te cachen; het zijn niet bepaald de zwaarste of grootste assets. Of door de favicon-cache bij de "gewone" cache te trekken o.i.d. zodat dezelfde gebruiker niet meer privé en niet-privé gevolgd kan worden.

[Reactie gewijzigd door geert1 op 20 februari 2021 13:17]

Als je een randomizer erin zet dat 50% van de tijd favicons gecached worden, dan maak je dit al onbruikbaar lijkt me?

Ik heb niet naar het onderzoek gekeken maar ik vermoed dat het te maken heeft dat een browser vanuit zichzelf een favicon opvraagt. Als ontwikkelaar vond ik dat sowieso al vervelend. Soms bouw ik vrij snel een API endpoint met een wildcard om even te testen/debuggen. Vervolgens als ik met mijn browser er naar toe ga, dan kreeg ik opeens twee requests binnen. Blijkt dus het originele request te zijn, bijvoorbeeld; /test maar dan ook nog automagisch /favicon.ico

Inderdaad gek dat dat nog steeds gebeurt. Als je in je HTML geen icon opgeeft moet de browser niet zelf gaan vissen vind ik.

Inderdaad gek dat dat nog steeds gebeurt. Als je in je HTML geen icon opgeeft moet de browser niet zelf gaan vissen vind ik.

Je browser moet überhaupt niet zelf gaan vissen, eigenlijk. Soortgelijke zaken zoals content-type sniffing zijn in het verleden ook allemaal stop gezet omdat ze in meer of mindere mate problematisch bleken te zijn. Maar het favicon gebeuren heeft dat - tot op heden in elk geval - overleefd.

Het is gewoon een hele basic feature van een webserver. Dat bestandje moet in de HTML root staan en dan werkt het. Zit er ook al eeuwen in. Best slim gevonden deze 'exploit'.

Firefox hoort eigenlijk ook in het rijtje getroffen browsers, maar door een bug werkt de exploit bij die browser niet.

Grappig hoe een bug tegelijkertijd als fix kan dienen.

Echt correct is het eigenlijk niet. Dit is alleen van toepassing op Linux aangezien er daar blijkbaar een probleem is bij het ophalen van favicons uit de cache. Dus op Windows of Mac is deze manier van tracking dus even goed mogelijk op Firefox.

Als ik het goed begrijp werkt dit enkel binnen 1 en hetzelfde domein. Ik zie het probleem dan niet zo goed, die info is toch gewoon te vinden in de browser logs, tenzij een gebruiker echt heel erg hard zijn best doet om dat te vermijden. Maar zo interessant is deze "tracking" dan toch helemaal niet?

Favicon tracking is alleen nuttig voor de website die de gebruiker bezoekt, en waarbij de gebruiker private browser mode gebruikt, of zijn/haar cookies heeft gecleared. Als dat niet het geval is, dan had de website de gebruiker gewoon kunnen tracken met simpele cookies. Dus de inzet mogelijkheden van deze tracking methode zijn inderdaad vrij beperkt, maar kunnen wel voor bepaalde websites (zoals websites als Facebook) wel interessant genoeg zijn om te implementeren.

Dus de fix is gewoon dat een browser in private mode gewoon altijd 1x voor alle domeinen de favicon ook ophaald?

Ik volg de vraag niet helemaal, maar de fix moet liggen bij de browsermakers. Zij moeten zorgen dat private mode altijd start met een lege favicon cache, en ze moeten zorgen dat de gebruiker de mogelijkheid heeft om in de browser eenvoudig de favicon cache te clearen, bijv. automatisch indien de normale cache op verzoek van de gebruiker ook gecleared wordt. Zolang dat niet het geval is, moet je zelf als de favicon cache clearen door bepaalde files te verwijderen, of je moet favicon helemaal uitschakelen indien mogelijk.

Dat zeg ik toch precies?

Best een gedbed zonder eind..., dat tracking verhaal. Valt weinig aan te doen.Goed teken dat Brave deze tracking methode zo snel heeft opgelost. Ik moet zeggen dat Ublock origin en Ghostery echt vrijwel niets meer te doen hebben sinds ik Brave gebruik . Fijn ook dat alle extensies die ik in Chrome had gewoon in Brave werken. Bookmarks zijn makkelijk importeerbaar.

@JackDashwood : Zoals ze in het artikel zeggen worden favicons ook gecashed om bandbreedte te besparen

[Reactie gewijzigd door Tierelier op 20 februari 2021 13:08]

Ik gebruik sinds een maandje ook brave. Ik gebruikte daarvoor firefox, maar ik kreeg zoveel problemen met die browser (memory leaks, vast lopen, pc laten vastlopen door de memory leaks XD). Brave is wel echt een snelle browser. En ook vele malen betere privacy beveiliging dan andere browsers. Wel nog steeds gebaseerd op chromium. Dus ik weet niet of google ook nog dingen meekrijgt.

Brave doet vooral heel stoer over vanalles maar is ook niet perfect (mompelt iets over .onion naar DNS sturen...). Wat jij waarschijnlijk ervaart is gewoon het gebruik van een schone browser, zonder plug-ins etc. Firefox is lang zo slecht nog niet namelijk.

Ik gebruik op brave dezelfde plugins op het moment. 1Pass en ghostery. Heb het vaakste gehad met firefox dat een webpagina niet reageert en zodra ik de pagina sluit, begint de RAM vol te lopen. Ik weet niet waar dat aan ligt. Mijn pc is aardig krachtig, maar zelfs dan zou de RAM niet moeten vollopen door een doorgeslagen webpagina

Vind de ingebouwde Brave shield anders echt heel handig sinds ik nu paar maande Brave gebruik. Maar goed ik kom van Chrome af en niet FF

[Reactie gewijzigd door NLatuny op 21 februari 2021 00:42]

Firefox hoort eigenlijk ook in het rijtje getroffen browsers, maar door een bug werkt de exploit bij die browser niet.

Hier moest ik wel even om lachen!

De favicons worden in meerdere populaire browsers opgeslagen in een cache die niet geleegd wordt of buitenspel gezet wordt in private browsing.

WTF?

Een favicon is toch net zo goed data uit het boze internet? Hoezo zou die favicons blind te vertrouwen zijn?

Dit tracking mechanisme rust op de verkeerde implementaties van nagenoeg alle browser censors.

Dat is het gevolg van de volgorde waarin het gebouwd wordt.

Zou men in 1e instantie van privacy/niet tracking uitgaan dan zou men alles van het boze internet wantrouwen.
Alleen in de praktijk vertrouwde men in 1e instantie alles van het internet en is men dat nu aan het terugdraaien, waardoor je dus alles moet nalopen en controleren en je dus dingen kan missen.

Dit is een gevolg van developers die niet duidelijk willen zijn welke gegevens ze als een risico zien en welke niet. Het is anders bijna onmogelijk om te achterhalen waarom ze hier niets aan gedaan hebben of het kennelijk zelfs acceptabel vonden.
Al denk ik dat veel ontwikkelaars daar eigenlijk geen behoefte aan hebben omdat het ze tijd kost en ze er zelf nauwelijks last van hebben.

Tis ook van de zotte dat een favicon word gecached. Alleen google al openen kost kilo's aan data (1.5MB minimum).