Mozilla scheidt cache van sites vanaf volgende stabiele versie Firefox

Firefox gaat vanaf de volgende stabiele versie van de browser een einde maken aan het delen van de cache voor sites en een scheiding aanbrengen. Door die 'cache partitioning' moet de browser een manier van tracking die gebruikmaakt van informatie uit de cache tegengaan.

De functie komt in Firefox 85 en die verschijnt 26 januari, zegt Mozilla. Sites kunnen dan niet langer gebruik maken van onder meer de gedeelde http-cache, afbeeldingencache, faviconcache en meer, schrijft ZDNet. Ook kunnen sites niet langer gebruik maken van de gedeelde cache voor fonts.

Door de stap is het niet langer mogelijk om Firefox-gebruikers te tracken door middel van de inhoud van de gedeelde cache, zo redeneert Mozilla. Momenteel werkt de Privacy Community-groep van het W3C ook aan een 'storage partitioning'-standaard. Het is mogelijk dat sites trager laden door de stap, omdat het downloaden van resources langer kan duren dan ze uit de cache halen.

Mozilla is niet de eerste die deze stap neemt. Google haalde de gedeelde http-cache al uit Chrome in oktober. Mozilla scheidt nog veel meer delen van de cache. Andere browsers, ook die op basis van Chromium, hebben deze stap nog niet aangekondigd of doorgevoerd.

Caches die Firefox gaat scheiden vanaf versie 85
HTTP cache	HTTP authentication	Intermediate CA cache
Image cache	Alt-Svc	TLS client certificates
Favicon cache	Speculative connections	TLS session identifiers
Connection pooling	Font cache	Prefetch
StyleSheet cache	HSTS	Preconnect
DNS	OCSP	CORS-preflight cache

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (62)

Mozilla is niet de eerste die deze stap neemt. Google haalde de gedeelde http-cache al uit Chrome in oktober. Mozilla scheidt nog veel meer delen van de cache. Andere browsers, ook die op basis van Chromium, hebben deze stap nog niet aangekondigd of doorgevoerd.

Ik had toch serieuze bedenkingen bij dit stuk, zeker omdat ik weet dat Apple toch een voortrekkersrol heeft als het op privacy aankomt. En wat blijkt bij het lezen van jullie eigen bron:

But while Mozilla will be deploying the broadest user data "partitioning system" to date, the Firefox creator isn't the first.
Edwards said the first browser maker to do so was Apple, in 2013, when it began partitioning the HTTP cache, and then followed through by partitioning even more user data storage systems years later, as part of its Tracking Prevention feature.

Jullie stuk klopt dus niet en insinueert zelfs dat andere browsers als Safari niets doen, terwijl het tegendeel waar is. Waarschijnlijk zijn er zelfs nog andere browsers op Webkit gebaseerd die dit ook al jaren hebben.

Niet helemaal eens dat Apple de voortrekkersrol heeft wat betreft privacy.
Apple is best goed bezig, maar het is Mozilla die Apple vaak aanmoedigt.
Het is wel zo dat Apple soms verder gaat dan wat Mozilla aandraagt, zie bijvoorbeeld:
https://foundation.mozill...for-apples-idfa-decision/
Maar zie zelf Mozilla als een voortrekker wat betreft bescherming van de gebruiker.

Het klopt dat Apple dit in Safari al eerder deed en ook Chrome heeft al gedeeltelijke partitionering van de cache. Ik ben het met je eens dat het vreemd is dat dat laatste wel in dit artikel wordt vermeld.

De partitionering die Mozilla nu in Firefox gaat doorvoeren gaat echter verder dan in Safari of Chrome momenteel het geval is.

[Reactie gewijzigd door rbr320 op 21 december 2020 13:42]

Ik had precies dezelfde gedachte over het ontbreken van Safari. Ik ben het zelf gaan opzoeken en kwam toen op dezelfde informatie die jij hier ook vermeldt. Safari is geen kleine speler als je mobiel/tablet gebruik meetelt.

Doet me denken aan Decentraleyes. Een add-on die een lokale cache maakt van veelgebruikte web resources, zodat je niet elke keer met Google en zo contact moet opnemen voor fonts en jquery.

https://decentraleyes.org/

Vindt de lokale cache eigenlijk slimmer. Dan werken sites nog steeds zoals de ontwikkelaars bedoelen, maar zit je niet met de performance of privacy nadelen.

[Reactie gewijzigd door Eonfge op 21 december 2020 10:22]

Alleen doet deze stap van Mozilla daar niets aan af en is Decentraleyes dus nog steeds nodig.

Voor het lokaal cachen van generieke resources waarvoor verschillende websites naar een en dezelfde grote hoster verwijzen, toch? Bijvoorbeeld als example.com het script jQuery inlaadt via https://ajax.googleapis.c...query/3.2.1/jquery.min.js .

Voor de duidelijkheid, Decentraleyes cachet alleen bepaalde javascript libraries.
https://en.wikipedia.org/wiki/Decentraleyes

Decentraleyes is bundled with 14 Javascript libraries; AngularJS, Backbone.js, Dojo, Ember.js, Ext Core, jQuery, jQuery UI, Modernizr, MooTools, Prototype, Scriptaculous, SWFObject, Underscore.js, and Web Font Loader. It can locally redirect connections to the Google Hosted Libraries, Microsoft Ajax CDN, CDNJS (Cloudflare), jQuery CDN (MaxCDN), jsDelivr (MaxCDN), Yandex CDN, Baidu CDN, Sina Public Resources, and UpYun Libraries networks. With these bundled resources in the software package, they are served to the user locally from their machine, as opposed to from a server. The blocking of connections to these CDNs is claimed (by Softpedia) to result in faster loading times for the end user.

In het artikel wordt gezegd dat sites mogelijk trager laden door de cache partitioning, hoewel dat eigenlijk ook maar eenmalig is om de eigen cache te vullen, maar eigenlijk verhelpt Decentraleyes dit probleem een klein beetje doordat de libraries alsnog niet via internet wordt ingeladen, maar vanuit de lokale cache van Decentraleyes.

Denk je dat er echt iets zal veranderen dan?

Als jij naar Google gaat en ze plukken de laatste jquery van: https://code.jquery.com/jquery-3.5.1.slim.min.js
Dan zal dit bestand toch echt niet worden opgeslagen worden in de cache van google.com maar in de cache van jquery.com. En je zult dus als gebruiker dit maar een keer ophalen en niet als je vervolgens naar yahoo.com gaat die dit zelfde bestand wil gebruiken weer het bestand ophalen en het dan opslaan in yahoo.com zodat je het zelfde bestand nu meerdere malen in je cache hebt staan.

Zo'n lokale proxy want dat is wat die tool bied zal echt niets anders doen dan gewoon de meest gebruikte bestanden zo als jquery ophalen en vervolgens alle requests afvangen en als ze op de lijst met cached files staan ze van de lokale disk serveren in plaats van ze van internet plukken (natuurlijk wel eens in de zo veel tijd even kijken of er een nieuwere versie van het bestand bestaat online maar dat gebeurt maar eens per uur of per dag)
Niet echt spectaculair en met een fatsoenlijke verbinding likt het me ook niet heel erg nuttig. Het idee dat je dan populaire CDN's kunt ontwijken omdat je daar niet zo vaak bestanden ophaalt is leuk maar redelijk nutteloos omdat de bestanden die gecached worden onmogelijk meer dan een paar procent van wat er op zo'n CDN staat kunnen beslaan. Voor privacy redenen is het dus redelijk zinloos, en met een fatsoenlijke verbinding is de snelheidswinst ook vrij wel te verwaarlozen.
Als deze tool wel enkele honderden GB's aan data zou binnen halen en deze constant up to date zou houden dan heb je een flinke verbinding nodig om constant vele GB's per dag te updaten in je cache terwijl je de overgrote meerderheid van deze bestanden nooit zult bekijken.

Al me al zie ik het nut van deze tool niet zo in.
Het Mozilla verhaal dan weer wel omdat het je systeem net weer even veiliger maakt.

Ik gebruik nu sinds 3j terug Firefox (na een hele tussenperiode Chrome te hebben gebruikt) en ik ben erg tevreden over de stappen die zij hier zetten.
Hun privacy opties en de mogelijkheden tot personaliseren zitten goed in elkaar en maken deze browser echt gericht op gebruikers ipv bedrijven en advertentie- en userdata-verkopers. Mooie visie van Mozilla!

Ik zou graag zien dat ze dit doen voor ALLE data. Dus ook cookies, local storage (nou ja dat zal al wel het geval zijn), cross-origin referral data, enzovoort.

Dat kan toch met het container systeem?

Ik gebruik de Firefox Containers samen met de add-on Temporary Containers. Die zorgt ervoor dat domeinen automatisch in een nieuwe, tijdelijke container geopend worden. Sluit je de tab, dan wordt alles weer weggegooid na X seconden. Je kan ook 'named' containers aanmaken en aangeven dat een domein altijd in container X geopend moet worden, zodat je niet telkens opnieuw moet inloggen e.d.

Wel moet ik er bij zeggen dat sommige zaken een stuk lastiger werken, je offert een stuk usability en gebruiksvriendelijkheid op. Het vergt dus ook een aanpassing van de gebruiker.

Container systeem, wel van gehoord maar eerlijk gezegd nog nooit naar gekeken. Maar het klinkt als iets wat je zelf moet doen?
Ik wil daar liever niet over hoeven nadenken. Als ik twee verschillende websites bezoek die toevallig dezelfde 3rd party resource includen die een cookie zet, wil ik dat die cookies gescheiden blijven.

Een named container klinkt al als iets meer in de goede richting, maar dat vergt dan wel weer handwerk.

Het zelf doen is ook wel handig eigenlijk. Zo kan je verschillende sessies van elkaar scheiden. Bijvoorbeeld 2x tegelijk in Office 365 inloggen, normaal kan dat absoluut niet.

Ook kan je dan kiezen om troep van facebook in dezelfde container te houden zoals Instagram, whatsapp en facebook zelf.

Zo lijkt het voor die site of je helemaal open werkt maar dingen die je niet wil laten zien kunnen ze niet zien. Helaas is het wel niet helemaal waterdicht meer. Bijvoorbeeld Google ziet ook in een andere container dat ik ingelogd ben! Ik hoop dat dat snel gefixt wordt. Edit: Ik had het mis, dank @Cerberus_tm

[Reactie gewijzigd door GekkePrutser op 22 december 2020 07:20]

Hmm weet je dat zeker? Ik heb dat nooit gemerkt?

Oeps.

Je hebt gelijk. Ik checkte het net even, en wat er gebeurt is dat hij automatisch switched naar de Google container omdat het om een Google site gaat. Doh... Dat heb ik zelf zo ingesteld . Ik zag het laatst toevallig en had geen tijd om er echt in te duiken.

Nouja blij dat ik het mis had en er dus niks lekt!

[Reactie gewijzigd door GekkePrutser op 22 december 2020 07:20]

Haha gelukkig!

Er zijn bijvoorbeeld twee addons voor van Mozilla zelf:
https://addons.mozilla.or...addon/facebook-container/
https://addons.mozilla.or...multi-account-containers/
Lees wel even de handleiding om issues te voorkomen.

Valt wel mee, ik heb een 5 tal websites in een eigen container draaien
Overige sites draaien niet in een container, maar die data wordt na sluiten van de tab automatisch verwijderd

Volgens mij doet Firefox First-Party Isolation dit.

Wellicht zou iemand mij kunnen uitleggen hoe facebook "boos" is op Apple, en roept dat zij het vrije internet laten verdwijnen terwijl we eigenlijk allemaal het tracken uit willen schakelen? Ik weet niet precies hoe "on-topic" dit is. Maar Firefox doet er alles aan om tracking uit te schakelen. Apple probeert tracking te voorkomen (oke, ze geven een optie waarmee ze zelf weer meer geld kunnen verdienen, besides the point). De meeste mensen hier zullen een addblocker/pihole hebben om reclame mee te voorkomen.

Het EFF, een organisatie die voor privacy op internet vecht, heeft wel een mening:

https://www.eff.org/deepl...y-against-users-and-small

De eerste alinea (en titel) draaien er niet omheen.

This is a laughable attempt from Facebook to distract you from its poor track record of anticompetitive behavior and privacy issues as it tries to derail pro-privacy changes from Apple that are bad for Facebook’s business

Als er 1 bedrijf is dat echt geen ene moer om privacy of het mkb geeft, dan is het wel Facebook. Dit is 100% dat ze niet willen dat gewone mensen doorkrijgen wat een datavampieren ze zijn.

[Reactie gewijzigd door Keypunchie op 21 december 2020 11:21]

Het is vrij off-topic hier, maar Facebook is boos op Apple omdat ze nu minder makkelijk data kunnen vergaren. Er is geen andere reden. Facebook doet het af als een anti-consumenten stap van Apple, maar als we heel eerlijk zijn is het vrij absurd om te claimen dat Apple die je waarschuwt voor hoeveel data Facebook verzameld anti-consument te noemen.

Dit gaat om grote bedrijven die hun winst willen veiligstellen.
Apple kan via deze manier meer winst maken op hun eigen ad platform of via de app store, facebook ziet mogelijks hun winst aangetast doordat ze nu minder gericht kunnen werken.

Dit doet dan ook volledig het gebruik van CDNs teniet? Of worden die wel geshared gedeeld?

Het gedeeld gebruiken van dezelfde resources? Ja. Al de rest? Nee.

Hoewel het noemenswaardig is dat Google Fonts tegenwoordig aanraad om fonts zelf te hosten.

Google Fonts geeft de mogelijkheid om fonts te downloaden. Ze raden het niet aan toch? Kan dit in ieder geval niet terugvinden. Ben een aantal jaar geleden overgestapt van self hosted naar hosting bij Google vanwege font-weight / Cleartype issues (windows vs osx). Zou ze graag weer zelf hosten.

Een beetje moderne developer zal zijn fonts dan ook gewoon als depency linken (npm/bower) en mee bundelen met de website/applicatie.

Voor deze groep zal er feitelijk niks veranderen

Ik hoop eigenlijk van wel. Dat het CDNs teniet doet bedoel ik.
98% van wat van een CDN komt bespaart in de praktijk eigenlijk geen significante hoeveelheid downloadtijd. Dan lijkt veiligheid/privacy me waardevoller dan dat een website 0.1sec sneller laadt.

Hoofdfunctie van een CDN is snel veel media kunnen laden. Bij de meeste grotere sites worden CDNs ingezet om jou van afbeeldingen, video of audio content te voorzien. Daar verandert niks aan. Ze hebben een essentiële rol in het hedendaagse internet.

Dat er verder ook andere mogelijkheden waren zoals tracking, bijvoorbeeld door een 1x1 pixels plaatje te laden in een email of op een site, was voor adverteerders en hun partners een handige bijkomstigheid.

Waarom zou dit het gebruik van CDN's teniet doen? Een CDN, Content Delivery Netwerk, zijn niets meer dan servers die content van sites hosten, dat kan van alles zijn, tekst, scripts, plaatjes, video's, downloads, documenten, noem maar op. Om een site in je browser te krijgen zal nog steeds alle benodige data gedownload moeten worden.
Als door cache partitioning websites hun cache niet meer kunnen delen kan het juist inhouden dat CDN's het ietsjes drukker krijgen, omdat elke site zijn eigen cache moet aanleggen. Als site A en B beide bestand X van een CDN gebruiken houdt het in dat site A en B beide bestand X een keer moeten downloaden in plaats van dat ze het bestand delen nadat de eerste site het gedownload heeft en in een gedeelde cache heeft geplaatst.

Omdat de requests naar de CDN nu per hoofddomain gecached gaa worden.
Dus tweakers.net krijgt een cache van de resources uit het CDN, en hardware.info daarnaast nog een.
Eigenlijk dus net zo alsof het bestandje vanaf de main website afkomstig was die request originate.
Daarmee heeft het voor veel zaker geen zin meer om een cdn te gebruiken. Hierbij was altijd de gedachte dat je browser wellicht jquery al ergens eerder had gezien, en dus gecached, waardoor de website die hem daarna nodig had hem uit de cache kon trekken.

Die overlap was trouwens al intens klein, en dus waardeloos, maar vanwege het copy/paste gedrag van veel developers was het toch de meest voorkomende manier om third-party recources te laden.
Alle security (remote code in je domain), performance (extra dns requests), en privacy (call naar third party servers) werden voor lief genomen.

In tegendeel, het maakt CDNs belangrijker dan ooit.

Vroeger was het als volgt:
Website 1 heeft een script import https://ajax.googleapis.c...query/3.2.1/jquery.min.js
Website 2 heeft ook een script import van https://ajax.googleapis.c...query/3.2.1/jquery.min.js

Als je de 2de website bezoekte zei Firefox: oh, ik heb die file al, geen nood om opnieuw te downloaden. Resultaat: site 2 laadt sneller.

Dit werkt nu niet meer.

CDNs worden belangrijker als we kijken naar de website en om zo de data dichterbij de klant te krijgen, aangezien iedere website zijn eigen versie nu moet downloaden, zelfs als komt die uit een gedeelde CDN.

Dat dingen al gecached zijn en dus niet gedownload hoeven worden is maar 1 functie van een CDN. Een CDN zorgt ervoor dat content wereldwijd snel beschikbaar kan zijn en niet dat een Australische gebruiker alles vanaf een server in Frankrijk (bijv.) moet downloaden. Dat laaste heeft deze stap natuurlijk geen invloed op.

Een CDN was voornamelijk interessant bij het oude HTTP/1 protocol.

HTTP/2 bracht multiplexing en lagere latency, daardoor is het efficiënter veel (kleine) bestanden van het dezelfde domein aan te bieden dan van verschillende domeinen.

Nu worden CDN ook wel gezien als trackers, daarom wordt ook de cache gescheiden.

Het zou wat dat betreft handiger zijn geweest als de cache per domein zou werken en niet per website. Dan zou je alle downloads van cdn.xxx.xxx nog steeds binnen dezelfde cache opslaan.

Waarom zou het? CDNs gebruiken vaak gewoon 1 domein (cdn.xyz)

Welke server je pakt word dan bepaald via DNS (op basis van GeoIP, al is dit al lang niet meer de standaard) of afhankelijk van je route naar een CDN IP.

[Reactie gewijzigd door smiba op 21 december 2020 10:35]

Partitionering vindt plaats op het hoofddomein van het venster. Dus een resource laden van een ander domein komt in de cache van het hoofddomein terecht.

Ah! Dan is dat inderdaad een fors probleem!

Excuus, overheen gelezen

Naja, fors probleem... Dit is gewoon een afweging tussen performance en privacy. Er gaat niks stuk, alleen iets trager. En het kost natuurlijk iets meer bandwidth.

Misschien zullen hier en daar sites over het randje van hun capaciteit geduwd worden, maar ik verwacht eigenlijk van niet.

Ik neem aan dat dit voor gebruikers instelbaar gaat worden, dus dat iedereen z'n eigen afweging kan maken. Dan kunnen gebruikers op trage of heel strikt metered connecties terug naar de huidige situatie.

Als website eigenaar/hoster gebruik je een CDN ook om het verkeer naar je site te beperken. Als je met een beperkt dataplan zit, dan gaat je verbruik omhoog en zul je mogelijk meer moeten betalen voor je hosting.

Ik ben heel erg benieuwd naar het antwoord op bovenstaande vraag.

Dit doet idd de CDN teniet.
Zie https://www.zdnet.com/art...google-fonts-performance/

Dat is wel heel kort door de bocht. Een CDN levert meestal alle media content, afbeeldingen, video, audio. Ze zijn essentieel voor veel online diensten. Dat blijft zo.

Een CDN zou niet essentieel moeten zijn aangezien het enkel moet zorgen voor grotere snelheid, niet om een site/dienst überhaupt werkend te hebben.

laat maar, hieronder wordt het veel beter beargumenteerd

[Reactie gewijzigd door belal op 21 december 2020 12:14]

Er wordt in Firefox behoorlijk getrackt, ook als ik aangeef dat ik dat niet wil. Als ik op de site van winkel A zit te kijken en ga vervolgens naar een site waar van die irritante reclames tussen zitten, dan gebeurt het veel te vaak dat ik dan prompt winkel A tegen kom, en dat is geen toeval!

Dat aangeven is alleen maar een verzoek "To not Track" naar de adverteerders die zich er doodleuk niks van aan trekken.

Dat aangeven is alleen maar een verzoek "To not Track" naar de adverteerders die zich er doodleuk niks van aan trekken.

Dat is niet een verzoek maar een order.

Onder de AVG/GDPR kunnen betrokkenen bij gebruik van een elektronische dienst er voor kiezen om hun recht van bezwaar geautomatiseerd uit te laten voeren middels een daarvoor bestemde technische standaard. De Do-Not-Track header is nu juist de standaard die daar expliciet voor bedoeld is.

Adverteerders die deze header negeren, negeren het recht van bezwaar en zouden eigenlijk eens flink hard aangepakt moeten worden.

Dat die adverteerders aangepakt moeten worden ben ik met je eens.

Klinkt als een goede zet. Ik weet verder niet het fijne van browser-cache, maar is het aannemelijk dat die nu wel significant meer schijfruimte in gaat nemen?

Je hebt kans dat bepaalde bestanden van een populaire CDN dubbel op je systeem staan. Echter is die kans niet zo heel groot omdat websites een tal van verschillende versies gebruiken. Die 100 files die je dan misschien extra op moet slaan zijn denk ik niet echt significant te noemen.

Een paar gedachten...
Google heeft deze instelling in Chrome al doorgevoerd. Mijn twisted-mind zegt meteen: Dus google heeft al een alternatief voor 'tracking via de cache'. En ja, dat heeft ze, bijvoorbeeld de dns-servers. Nu wordt alles iedere keer opnieuw opgehaald en dus mogelijk ook de dns vaker geraadpleegd.

Voor de gebruikers: Er zijn (veel) meer cache missers dus moet er meer worden opgehaald. Of de cache wordt (veel) groter. Het zal wel ergens in het midden uit komen.

Je moet niet vergeten dat Google best wel wat baat heeft bij het tegen gaan van tracking en dergelijke. Het maakt het vooral moeilijker voor hun concurrenten, Google krijgt die data zelf toch wel. Al is het maar via Google Analytics.

Geldt dit dan ook voor gedeelde cdn? Of dat niet?
Ik me namelijk niet voorstellen dat je anders gedeelde cache uberhaupt zou willen.