Waarom een nevenaccount in Chrome niet genoeg is: de isolatielimiet van Chrome-profielen

Kern van de zaak: Chrome-profielen scheiden de loginstatus uitstekend, maar een platform kijkt naar het apparaat, niet naar de loginstatus. Alle Profiles draaien op dezelfde browserengine en melden exact hetzelfde fingerprint; de proxyinstelling geldt voor de hele browser, dus het uitgaande IP-adres laat zich niet scheiden; en wie overal dezelfde Google-account laat synchroniseren, koppelt de profielen in de cloud alsnog aan elkaar. Voor eigen dagelijks gebruik is een Profile prima. Zodra een account als bedrijfsaccount lang meegroeit, verdient elk account een eigen fingerprint en een eigen uitgaand IP.

Via het profielpictogram rechtsboven in Chrome een nevenaccount aanmaken: voor veel mensen de eerste stap richting meerdere accounts. Op Profiel toevoegen klikken, een naam en kleurtje kiezen, klaar. De loginstatus blijft staan, na afsluiten en heropenen ben je nog steeds ingelogd, en er hoeft niets geïnstalleerd te worden.

Maar hoe meer nevenaccounts, hoe meer gedoe. Sommige platforms beginnen afwijkend gedrag te melden, accounts raken beperkt, terwijl de Profiles elkaar toch echt niet in de weg zitten. De oorzaak zit niet in slordig ingerichte profielen, maar in het feit dat er maar de helft gescheiden wordt. De lokale gegevens liggen netjes apart; de apparaat- en netwerksignalen die het platform ziet, zijn nooit gescheiden geweest.

Dit artikel pakt het laag voor laag aan: wat er wél gescheiden wordt en wat niet. Aan het eind volgt een beoordelingsmaatstaf: wanneer is een Profile toereikend en wanneer is een andere omgeving nodig.

Profile scheidt gegevens, geen apparaten

De isolatie van een Profile speelt zich af op het niveau van lokale gegevens. Google bedoelt de functie vooral om bladwijzers, geschiedenis, wachtwoorden en dergelijke gescheiden te bewaren. In de praktijk heeft elk Profile eigen cookies en sitegegevens, een eigen browsegeschiedenis, eigen extensies en een eigen wachtwoordkluis. Twee nevenaccounts in twee verschillende Profiles: de loginstatus overlapt nergens en beide accounts op hetzelfde platform kunnen tegelijk online zijn.

Deze laag is echt gescheiden, en dat doet het beter dan een incognitovenster: dat gooit bij het sluiten ook je loginstatus weg, terwijl Profile alles langdurig bewaart. De verschillen tussen beide worden het helderst naast de checklist uit het artikel over incognitomodus en accountkoppeling.

De beperking schuilt in dezelfde zin. Wat gescheiden wordt, is uitsluitend gebruikersdata op de harde schijf; het browserprogramma zelf, de videokaart, de netwerkkaart en het besturingssysteem blijven onveranderd. Alle Profiles draaien dezelfde Chrome, lezen dezelfde hardware en gebruiken dezelfde netwerklijn. Je kunt honderd datamappen aanmaken, de apparaatidentiteit blijft er één.

Alle Profiles op dezelfde machine melden hetzelfde fingerprint

Platforms herkennen apparaten via de browserfingerprint, en op dit niveau grijpt een Profile totaal niet in. De User-Agent komt uit het browserprogramma zelf, dus alle Profiles melden hetzelfde versienummer. De rendering van Canvas en WebGL wordt door de videokaart bepaald. Fontlijst, schermresolutie, aantal CPU-kernen en geheugenklasse: het zijn allemaal gegevens van dezelfde machine.

In de analyse van browser-fingerprintingtechnieken van FingerprintJS, een bureau dat gespecialiseerd is in fingerprintdetectie, vormen precies deze signalen de kern van de apparaatidentificatie. Een andere datamap verandert daaraan niets.

Wie het niet gelooft, controleert het zelf. De fingerprinttest van EFF draait direct in de browser: test elk Profile een keer en zet de resultaten naast elkaar. Die vergelijking is overtuigend: browser- en systeeminformatie, fonts, canvasrendering en hardwareparameters komen vrijwel punt voor punt overeen; het enige wat doorgaans verandert, zijn cookies en lokale opslag.

Voor de risicoanalyse van een platform zijn tien Profiles één identiteit. Deze set identieke signalen is ruim voldoende om ze als één huis te klasseren. Cookie-isolatie zorgt er alleen voor dat accounts lokaal niet overlappen; de grondslag waarop koppeling wordt beoordeeld, lag nog nooit lokaal. Wie wil nagaan welke koppelingssignalen zijn nevenaccountcollectie nog heeft, doorloopt omgevingen, proxy's en loginhistorie laag voor laag volgens de gids voor zelfcontrole van het risico op accountkoppeling.

Het uitgaande IP-adres is browserbreed, niet per Profile

Op het netwerkniveau is het gat het meest zichtbaar. Chrome kent geen proxy-instelling per Profile; de proxyconfiguratie volgt het besturingssysteem. Eén lijn wijzigen betekent: alle Profiles tegelijk wijzigen. Twee nevenaccounts die via een andere uitgang willen, hebben binnen het profielsysteem geen serieuze ingang. Oplossingen die met extensies of externe tools in elkaar worden gezet, halen qua stabiliteit en consistentie geen langdurige bedrijfsvoering. Ook het lokale adres dat WebRTC lekt, is identiek, want realtime communicatie wordt door dezelfde browserkern afgehandeld.

Zo ziet de typische nevenaccountcollectie er dus uit. Een tiental Profiles, elk met zijn eigen account, sprankelende loginstatus, en als uitgang hetzelfde IP-adres. In de logboeken aan platformzijde zijn deze accounts om de beurt actief op één en dezelfde lijn. Gecombineerd met de identieke fingerprints uit de vorige sectie is de bewijsketen voor koppeling vrijwel compleet. Hoe goed de gegevensisolatie ook is, de netwerkidentiteit laat zich niet bijspijkeren. Dit is de meest concrete grens tussen een Profile en een omgeving in een anti-detect browser.

Google-account synchroniseren: een vaak over het hoofd gezien koppelingsingang

Bij het aanmaken van een Profile stuurt Chrome je richting een Google-account voor synchronisatie. Bladwijzers, wachtwoorden, extensies en instellingen gaan de cloud van het account in en zijn op een ander apparaat terug te halen. Voor privégebruikers is dat ideaal. Voor nevenaccounts geldt iets anders. Zitten er meerdere Profiles op hetzelfde Google-account, dan komt alles in de cloud op één plek samen. De verbinding tussen accounts loopt dan niet meer alleen lokaal, maar ook via de platformkant. Zolang synchronisatie aan staat, blijft het signaal staan. Hoe netjes de isolatie op het apparaat ook is, de cloudkant houd je er niet mee tegen.

De oplossing is niet ingewikkeld. Bij het aanmaken van het Profile van een nevenaccount kies je voor doorgaan zonder inloggen, of je geeft elk nevenaccount een eigen Google-account, elk met zijn eigen synchronisatie. Met synchronisatie uit blijven de gegevens tussen de Profiles gewoon gescheiden en merk je in het dagelijkse gebruik niets.

Wanneer is een Profile toereikend, en wanneer wisselen van omgeving?

Beoordeel naar het gewicht van het account, niet de tool.

In deze situaties kun je gewoon bij een Profile blijven:

• Je eigen dagelijkse accounts, bijvoorbeeld een werkmail en een privémail; verwisselen is pas het probleem.
• Backends van laag-risicoplatforms, zonder commerciële banden tussen de accounts en zonder apparaatgerichte risicocontrole door het platform.
• Tijdelijke projectdubbels die je na afloop weggooit en niet langdurig onderhoudt.

Komt een van de onderstaande signalen voor, dan verhuizen de accounts naar een aparte omgeving:

• Het account draagt echt bedrijf: bij een winkel, advertentieaccount of socialmediamatrix wordt een probleem doorgegeven aan de rest.
• Het platform controleert apparatuur expliciet; meerdere accounts op één apparaat is op zichzelf al een risico.
• Het aantal accounts loopt in de tientallen, het wisselen van vensters is niet meer bij te houden en het werk moet over het team worden verdeeld.

Op het punt van omgeving wisselen verschuift het denkbeeld van 'nog een paar vensters openen' naar 'elk nevenaccount een complete identiteit'. MostMate is een anti-detect browser die browsergegevens, fingerprintparameters en de netwerkuitgang per herbruikbare omgeving verpakt, met voor elk nevenaccount een eigen set.

Het aanmaakformulier van een omgeving bestaat uit drie delen: basisinformatie, fingerprintinstellingen en geavanceerde instellingen, met rechts een fingerprintpreview die de actuele waarden live toont. Parameters die in een Profile onaantastbaar zijn, zoals Canvas, WebGL, de fontlijst en WebRTC, hebben hier elk eigen instellingsniveaus.

Ook proxy's lopen per omgeving. Proxy's worden centraal bijgehouden in een aparte proxylijst, en in het omgevingsformulier kies je uit drie opties: geen proxy, eigen proxy of een proxy uit de lijst. Van SOCKS5 tot SSH zijn vier typen beschikbaar. Voor taal, tijdzone en geografische locatie bestaat een modus op basis van het IP-adres: zodra de proxy vastligt, lijnen die items automatisch uit op de uitgangsregio. In elke rij van de omgevingslijst staan proxy, uitgaand IP-adres, gekoppeld account en groep; van elk nevenaccount is in één oogopslag te zien welke lijn het loopt.

Hoe de modules er in de interface uitzien en welke velden ze hebben, laat de pagina Wat is MostMate in hele reeksen screenshots zien. De werking van de isolatie over cookies, lokale opslag, sessies, cache, fingerprintomgeving en proxyconfiguratie wordt in het artikel over omgevingsisolatie systematischer uiteengezet. Wie de eerste omgevingen aanmaakt, doorloopt de volgorde van naamgeving en proxy tot parametercontrole aan de hand van de checklist voor nieuwe omgevingen.

Veelgestelde vragen

Hebben verschillende Chrome Profiles echt exact hetzelfde fingerprint?

De signalen op apparaat- en browserniveau komen inderdaad overeen. Profiles op dezelfde machine delen het browserprogramma en de hardware; Canvas, WebGL, fonts, schermparameters en User-Agent zijn identiek, en alleen lokale gegevens als cookies en geschiedenis staan er los van elkaar naast. Laat twee Profiles door een testsite meten en je ziet in één oogopslag hoe klein het verschil is.

Kun je niet beter handmatig de systeemproxy per Profile wisselen?

Nee. De systeemproxy is globaal; tijdens het wisselen veranderen alle Profiles mee. Moeten twee accounts tegelijk online zijn, dan blijf je instellingen heen en weer zetten, en één fout maakt dat de uitgang niet meer aansluit bij de historische lijnen van het account. Dat elk account een vaste uitgang nodig heeft, is precies wat proxy's op omgevingsniveau oplossen.

Is een nevenaccount veilig als je niet met een Google-account inlogt?

Het schrapt alleen het synchronisatiesignaal. Fingerprint en uitgaand IP-adres worden nog steeds gedeeld en het platform groepeert de accounts op dezelfde machine nog steeds netjes bij elkaar. Niet inloggen met Google is de moeite waard, maar het lost één laag op, niet alle.

Incognitovenster of Profile: wat is geschikter voor nevenaccounts?

Beiden veranderen niets aan de apparaatidentiteit. Een incognitovenster bewaart niet eens de loginstatus en is geschikt voor eenmalig kort gebruik; Profile houdt de loginstatus vast en is geschikt om een account lang te parkeren. Voor het platform zijn het twee manieren om hetzelfde apparaat te openen; het verschil zit in het bewaren van de sessie, niet in het koppelingsrisico.

Tot slot

Chrome-profielen scheiden de lokale gegevens prima; het platform beoordeelt koppeling op apparaat en netwerk, en die twee zitten op totaal verschillende niveaus. Of een Profile toereikend is, hangt af van het gewicht van het account. Voor eigen dagelijks gebruik kun je oneindig doorgaan, een bedrijfsaccount verdient een fatsoenlijke omgeving die het ten minste een eigen fingerprint en een eigen uitgang geeft. Wie zover is, kan MostMate downloaden, met de gratis versie twee omgevingen aanmaken en de vergelijking hierboven zelf draaien: de uitkomst zegt meer dan welke uitleg dan ook.