DuckDuckGo-browser krijgt synchronisatiefunctie die werkt zonder account

Zoekmachinebedrijf DuckDuckGo voegt een synchronisatiefunctie voor opgeslagen wachtwoorden en bookmarks toe aan zijn webbrowser. Gebruikers kunnen die data daarmee synchroniseren tussen meerdere apparaten, zonder een account aan te maken.

Volgens DuckDuckGo werkt de synchronisatiefunctie tussen 'de meeste' Windows-, Mac-, Android- en iPhone-apparaten. Mobiele gebruikers van de DuckDuckGo-browser kunnen een apparaat synchroniseren door een QR-code te scannen in het geval van een mobiel apparaat. Desktopgebruikers krijgen een unieke code om handmatig in te vullen.

De zoekmachinemaker, die zich vooral richt op privacy, claimt dat alle gesynchroniseerde data van gebruikers end-to-end wordt versleuteld en daarmee niet kan worden ingezien door het bedrijf. Gebruikers krijgen een pdf-bestand met recoverycodes waarmee ze hun gesynchroniseerde data kunnen terugkrijgen als de gekoppelde apparaten van gebruikers zijn verloren of beschadigd. De feature is volgens DuckDuckGo per direct beschikbaar.

Reacties (58)

[wica]

Zonder account? Je scanned toch een token, door de QR te scannen. Wat eigenlijk weer een account is.

[GenomDalar1983]

Niet gekoppeld aan een e-mailadres of persoonsgegevens. Gewoon een "blinde" token.

[wica]

Achter die "blinde" token, zit gewoon een account.
Als ik naar de werking kijk, is het eigenlijk niet meer dan een 2FA, zonder username/password.

[Kjoe_Ljan]

Natuurlijk wordt de data ergens opgeslagen. Als je dat een account vindt, prima, dan is dat een account.
Maar het feit dat dat account niet terug te leiden is naar een persoon (bijvoorbeeld via een single sign-on of e-mailadres) maakt dit net weer een stukje meer gericht op privacy.

[Zer0]

Maar het feit dat dat account niet terug te leiden is naar een persoon

Tot je de data gaat bekijken, en ziet dat het wachtwoord voor het account [e-mail] er in staat. en voor het tweakers account van kjoe_ljan.... van wie zou die data dan zijn?

[Nico de Vries]

"De zoekmachinemaker, die zich vooral richt op privacy, claimt dat alle gesynchroniseerde data van gebruikers end-to-end wordt versleuteld en daarmee niet kan worden ingezien door het bedrijf."

Ofwel dat zou niet moeten kunnen. Uiteindelijk speelt vertrouwen natuurlijk ook een rol maar de uitganspunten zijn goed hier. Wat ze wel kunnen zien is wat je IP adres is, maar dat kunnen zoekmachines en websites sowieso al.

[Reactie gewijzigd door Nico de Vries op 22 juli 2024 15:24]

[Zer0]

Maar zolang de data encrypted is maakt het ook niet zo veel uit of deze naar een persoon te herleiden is.....

[batjes]

Encrypted data is in de praktijk maar tijdelijk en veranderd weinig aan de inhoud van de data. Mocht DuckDuckGo hiervoor bijvoorbeeld Sha-512 gebruiken, iemand verzameld jouw encrypte data en morgen weet een 1337 hackerman guru Sha-512 te kraken.

Tadá, herleidbare data.

Er wordt ontiegelijk veel encrypted data opgeslagen dat over X jaren zonder al te veel moeite te kraken is en alsnog van belang kan zijn. Je zou nu maar een tiener zijn of in de begin 20 hangen en over b.v. een paar decennia ergens president willen worden.

Persoonlijk ben ik heel blij dat ik mijn jeugd op een beginnend internet rondbracht en niet vandaag de dag. Bijna alle persoonlijke gegevens uit die tijd is ondertussen gewoon compleet foetsie.

[DvanRaai89]

Encrypted data is [...] Mocht DuckDuckGo hiervoor bijvoorbeeld Sha-512 gebruiken, [...]

Yeah right...
SHA-512 is een hashing algoritme. Als je goed luistert hoor je het ook wel een beetje terug in de naam; Secure Hashing Algorithm. De outpits van deze funcries bevatten minder data (lees: er gaat letterlijk data verloren) en
meerde inputs leiden tot dezelfde output (duiventil principe).

Als is het wel zo dat er geen beter encryptie algoritme bestaat; dit garandeert dat níémand je bestanden leest. Het enige wat nog veiliger zo zijn is sudo rm -rf.

[Reactie gewijzigd door DvanRaai89 op 22 juli 2024 15:24]

[timonb]

Oei, ik hoop dat je geen tracking cookies toe staat. Immers Google en Meta weten precies waar jouw interesses liggen. Stel dat diezelfde 1337 hackerman guru met alu hoedje die twee bedrijven hackt…

Het idee dat iemand jouw encrypted gestolen bookmarks en dan huidige wachtwoorden gaat opslaan om over jaren tegen je te kunnen gebruiken, lijkt me onwaarschijnlijk.

Er zijn denk ik wel betere manier om die informatie te krijgen en wel nu.

[Nox]

En als je dan wat randomization er op los laat kan je opeens een geldig token te pakken krijgen? Het is te hopen dat dit soort dingen gigantisch lang zijn en de generatie van die tokens goed gerandomized is.

Zelf een zwik tokens aanmaken en predicten wat vorige en volgende tokens kunnen zijn... Als ie raak is ligt alles open. Geeft me geen goed gevoel.

[[Roland]]

Dit gaat over browser data. Bookmarks en plugins enzo. Niets belangrijks ervanuit gaand dat je voor je CC en passwords een betere oplossing gebruikt.

[Het.Draakje]

Volgens mij kan je toch wel enige leuke dingen afleiden uit iemands bookmarks. Zo onschuldig zijn ze niet.

Maar volgens het artikel is jouw aanname fout: synchronisatiefunctie voor opgeslagen wachtwoorden en bookmarks. (Eerste regel).

[dcm360]

Daarom dus met end-to-end-encryptie. Je vraagt de data weliswaar op met een unieke identifier, maar die data is versleuteld. De browser heeft lokaal wel de sleutel om de data leesbaar te maken, maar die wordt niet meegestuurd naar de server. In de QR-code om de gegevens te delen zitten dan zowel de identifier als de sleutel.

[The Zep Man]

Niet gekoppeld aan een e-mailadres of persoonsgegevens.

Een pseudoniem (zoals een unieke account identifier) is ook een persoonsgegeven, want het is direct of indirect herleidbaar naar een persoon.

[watercoolertje]

Naar een persoon misschien maar welke van de 8 miljard personen weet je daarmee juist niet.

Het is dus niet te herleiden naar een specifiek persoon (wat een email of ip in zekere zin wel kan).

[Reactie gewijzigd door watercoolertje op 22 juli 2024 15:24]

[The Zep Man]

Naar een persoon misschien maar welke van de 8 miljard personen weet je daarmee juist niet.

Dat is het mooie van indirect herleidbaar zijn. Het is nog steeds een persoonsgegeven.

Het is dus niet te herleiden naar een specifiek persoon (wat een email of ip in zekere zin wel kan).

Een indirect herleidbaar gegeven naar een persoon (=persoonsgegeven) is dat op zichzelf nooit. Combineer het echter met een IP-adres, met tijden waarop de dienst gebruikt wordt, met digital fingerprinting, ... Allemaal indirecte zaken, en het wordt voldoende herleidbaar. Dat maakt het een persoonsgegeven. Het gaat er niet om of die zaken gecombineerd worden. Het gaat erom dat als die zaken gecombineerd zouden worden of het iets zou zeggen over een specifiek persoon. Het antwoord daarop is ja.

Een postcode op zich hoeft geen persoonsgegeven te zijn. Bedenk een willekeurige postcode en schrijf hem op, en het is geen persoonsgegeven. De reden daarvoor is dat die gegeven in die context niet (direct of indirect) herleidbaar is tot een enkel persoon. Een unieke identifier van een account is dat wel, want je weet dat die bij een gebruiker hoort. Dat je mogelijk andere gegevens erbij moet combineren om de unieke identifier aan een specifiek persoon toe te wijzen is voor de AVG irrelevant. Het is een persoonsgegeven.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:24]

[watercoolertje]

Combineer het echter met een IP-adres, met tijden waarop de dienst gebruikt wordt, met digital fingerprinting

De vraag is dus of dat wel gebeurd, jij neemt blijkbaar blind aan van wel, terwijl ik er van uit ga van niet

[The Zep Man]

[...]
De vraag is dus of dat wel gebeurd [sic], jij neemt blijkbaar blind aan van wel, terwijl ik er van [sic] uit ga van niet

Lees nog eens. Het gaat er niet om dat het gebeurt. Het gaat erom dat het kan. Dat maakt het een persoonsgegeven.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:24]

[watercoolertje]

Lees nog eens. Het gaat er niet om dat het gebeurt. Het gaat erom dat het kan. Dat maakt het een persoonsgegeven.

Om het te kunnen moet die data er wel zijn, en zoals gestelt ga ik er van uit dat dat er niet is, dat zou namelijk nogal tegenstrijdig zijn met waar DDG voor staat...

Misschien kan @Arnoud Engelfriet hier wat over zeggen, lijkt mij in zijn straatje te liggen

Volgens zijn eigen blog (niet zijn post) is een gehashed wachtwoord ansich geen persoonsgegeven (enkel icm een username en/of andere gegevens die samen naar jou als persoon kunnen leiden). https://www.ictrecht.nl/b...woord-een-persoonsgegeven

Als DDG dus enkel dat gehashte wachtwoord heeft (dat kan tevens de 'identifier' voor die regel in de database zijn) en de versleutelde (wachtwoord)data dan kunnen ze prima zonder die persoon te kunnen identificeren die versleutelde data terugsturen en naar de app waar de niet gehashte versie van dat wachtwoord die data vervolgens voor je ontsleutelen...

[Reactie gewijzigd door watercoolertje op 22 juli 2024 15:24]

[Arnoud Engelfriet]

Ik weet niet welke blog je bedoelt? Een gehasht wachtwoord is zonder meer informatie niet aan een persoon te koppelen. Iedereen kan wel hunter2 gebruiken.

Dit token gaat voor mij verder. Met dat token herkent DDG jouw sessie, jouw wachtwoorden en bookmarks en dergelijke. Het is functioneel niet anders dan een cookie met een random ID waar men serverside van alles aan koppelt.

Het is een misverstand dat identificatie betekent dat je weet hoe iemand heet of hoe je die persoon kunt benaderen. Onder de AVG is voor identificatie genoeg dat je een identificator op iemand kunt plakken, en een token, cookie of willekeurig gekozen getal is daarvoor genoeg. Plat gezegd héét iemand gewoon "127.0.0.1/20240214-1617", en of daar nou een Tweakers username "watercoolertje" bij te vinden is, is niet relevant.

De herleiding moet in redelijkerwijs te doen zijn. Enkel theoretisch het kunnen herleiden is niet genoeg. Er zal vast íemand achter 127.0.0.1 zitten op dit moment, maar dat is te vaag om te zeggen dat je daar nu iemand mee geïdentificeerd hebt gaat mij te ver. Koppel je het aan zeg browsegedrag of een aanmeldpoging, dan wordt het voor mij een ander verhaal.

[watercoolertje]

Sorry heb de link toegevoegd, die miste inderdaad.

Er hoeft in dit geval niet meer te zijn dan een gehasht wachtwoord (of token) en een brok encrypted data.

Op basis van dat gehashte wachtwoord kan je de brok encrypted data dan opvragen en lokaal met het daadwerkelijke wachtwoord die data decrypten tot wat nuttigs.

Ik ben wel benieuwd hoe dat herleidbaar zou kunnen zijn aan een natuurlijk persoon.

[Reactie gewijzigd door watercoolertje op 22 juli 2024 15:24]

[Arnoud Engelfriet]

"0xdeadbeef is data van user 1337” is een persoonsgegeven. Dit gegeven betreft immers de persoon die we 1337 noemen. We weten dat dit een persoon is want de dienst is ontworpen voor mensen, niet machines. We weten niet hoe 1337 zijn or haar paspoortnaam luidt, maar dat is niet vereist. We hebben geen idee welke informatie er in de string 0xdeadbeef zit maar dat maakt niet uit.

[watercoolertje]

Dank je voor je input!

@The Zep Man lees je nog mee? Had je toch gelijk

[jwal]

Hoe gebruik je het internet dan als je geen indirect herleidbare gegevens wilt achterlaten?
Als daar een manier voor is dan hoor ik het graag, want volgens mij laat je constant sporen achter.

[The Zep Man]

Hoe gebruik je het internet dan als je geen indirect herleidbare gegevens wilt achterlaten?

Niet.

Als daar een manier voor is dan hoor ik het graag, want volgens mij laat je constant sporen achter.

Je laat constant sporen achter. Het ligt aan de diensten waarvan je gebruik maakt of die daar iets mee doen of niet. De meeste data die iemand "lekt" wordt niets mee gedaan. Zet je naam als header in een HTTP-verzoek richting de server van tweakers.net, en het is vrijwel zeker dat daar niets mee gedaan wordt. Dat komt omdat het voor T.net niet interessant is om te registreren, en omdat dankzij TLS iemand op de lijn niet kan zien dat je dat meestuurt.

Anoniem internetten bestaat niet. Pseudoniem wel. Wat je wel kan doen zijn beschermende maatregelen nemen om het onwaarschijnlijk of duur te maken om jou te identificeren gebaseerd op indirect herleidbare persoonsgegevens. Één ervan is niet je naam in een HTTP-header zetten, want dat maakt de koppeling van pseudoniem naar identiteit wel heel makkelijk.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:24]

[batjes]

en het is vrijwel zeker dat daar niets mee gedaan wordt. Dat komt omdat het voor T.net niet interessant is om te registreren, en omdat dankzij TLS iemand op de lijn niet kan zien dat je dat meestuurt.

Apache en Nginx hebben nog altijd access logs waar die headers naast een IP adres by default in gelogged worden.

Voeg daar een centraal logging systeem aan toe (welk bedrijf met een SoC heeft zoiets niet) en je verwerkt persoonsgegevens.

Geen idee hoe Tweakers het in detail doet, dus een aanname, maar ook Tweakers houdt (zeer waarschijnlijk) access logs bij.

[svennd]

Hoe wil je direct of indirect herleiden naar een persoon dan ? De database is encrypted, dus dan moet je het van meta-data gaan halen (zoals download ip, indien daar logs van bestaan).

[The Zep Man]

Hoe wil je direct of indirect herleiden naar een persoon dan ? De database is encrypted, dus dan moet je het van meta-data gaan halen (zoals download ip, indien daar logs van bestaan).

Ik heb het over een unieke identifier. Die zal buiten de versleutelde gegevens bestaan, omdat die opvraagbaar moet zijn voor de betreffende dienst om een inkomende sessie daaraan te koppelen, om zo te weten welke data moet worden aangeboden.

[rc_enzo]

Een account zou zijn dat je inlogt op een dienst die ze aanbieden, waar alle gegevens encrypted worden opgeslagen.

Met de QR code voor end-to-end encryption krijg je enkel een soort unieke handshake (die weliswaar over hun servers zal moeten lopen voor communicatie), maar in feite zou alles weg moeten zijn als je op zowel je telefoon als PC de browser uninstalled.

[GoldenBE]

Ik vraag me eigenlijk ook wel af hoe dit achterliggend werkt.

Ik neem aan dat de data (wachtwoorden, bookmarks, etc) encrypted wordt opgeslagen op hun servers. Maar ze moeten dus kunnen achterhalen welke encrypted data bij wie hoort. En anderzijds wil je de encryption key niet bij de data opslaan, deze moet dus in de QR-code (of de code die je handmatig moet ingeven op dekstop) zitten.
Maar ook de identifier (welke data is van mij) moet dus in deze code zitten. Dus ik gok dat die QR codes zowel een "identifier" (soort username) als een encryption key (soort wachtwoord) bevatten.

Dus het lijkt op een account maar het verschil is dat Duckduckgo je waarschijnlijk niet kan helpen met je wachtwoord te resetten (tenzij je de recovery keys hebt) en het niet met een e-mailadres verbonden is. Dus ik gok dat het verschil hem daarin zit?

[downtime]

Je hebt geen identifier en wachtwoord nodig zolang je maar kunt garanderen dat elk “wachtwoord” uniek is. Dan identificeer je iemand aan de hand van het wachtwoord alleen. Via een lookup in je database bepaal je dan bij welk account dat wachtwoord hoort.

[GoldenBE]

Dat is idd. een optie die ik over het hoofd zag: je kan bv. het wachtwoord hashen en de hash vervolgens opslaan in de database als "identifier". Op die manier kan je het wachtwoord als identifier gebruiken zonder dat je het wachtwoord bij de data zet.

Moet je er wel wat meer van kennen dan mij om dat hele idee nog goed (veilig) te maken

[DeTeraarist]

Bij een beetje account verwacht ik toch minstens een vorm van authenticatie. Nu krijg je alleen een brokje authorizatie.

[Cergorach]

Daar zat ik ook aan te denken, want iedereen kan een code genereren en invoeren, niets van MFA bij.

Echter is het 149 tekens die kennelijk cijfer, kleine letter en grote letter kunnen zijn, je heb dus 62 opties per positie en 149 posities.

[Qwerty-273]

Het grappige is dat dit natuurlijk al lang bestaat (slechts 1 code waarmee je toegang hebt). Juist de kracht hiervan is de grote entropie waardoor het zo goed als onmogelijk is om een dezelfde code een tweede keer te genereren. Vergelijk het met de private key van een crypto wallet. Dat is ook slechts 1 code waarmee je toegang hebt tot de financiën (op basis van de private key, kan je het bijbehorende public adres berekenen - beetje ala https://keys.lol/bitcoin/random ). Verdere uitleg op https://medium.com/coinmo...-private-key-b0f134883077

[Reactie gewijzigd door Qwerty-273 op 22 juli 2024 15:24]

[batjes]

Authenticators doen het met alleen 6 cijfers en dat werkt prima. Die token om te koppelen zal net zo'n tijdelijke token zijn en aan de achterkant zal er een (GU)ID aan hangen.

[pepsiblik]

Alleen wel een erg random "account" waar verder geen data aan hangt die direct of indirect gaat leiden tot identificatie van een persoon. Dat is met de accounts in bijvoorbeeld Edge en Chrome wel het geval. Daar gebruik je email.

[SMGGM]

Een klein nadeel: Wat als ze gehackt worden en al je data komt op straat terecht. Hoe gaan ze al hun gebruikers informeren als ze geen contact info hebben om die gebruikers te informeren? Wachten op een volgende login van de gebruiker?

Het lijkt op het eerste zicht een ideologisch concept, maar dit lijkt me een duidelijk geval waar een account aanmaken niet is wat de gebruiker zou verhinderen om het te gebruiken.
Als ik al mijn login gegevens ga synchroniseren met zo'n dienst is het feit dat ze mijn email adres hebben het minst van mijn zorgen.

[iRob87]

Het voelt wat ontastbaar op deze manier. Alsof je je wachtwoorden in een zwart gat plaatst.
Hoe kom je nog bij je wachtwoorden als je geen QR code meer hebt?

[watercoolertje]

Hoe kom je nog bij je wachtwoorden als je geen QR code meer hebt?

Staat toch in het artikel beschreven?

Gebruikers krijgen een pdf-bestand met recoverycodes waarmee ze hun gesynchroniseerde data kunnen terugkrijgen als de gekoppelde apparaten van gebruikers zijn verloren of beschadigd.

[Reactie gewijzigd door watercoolertje op 22 juli 2024 15:24]

[wica]

3 jaar later, 2 computers en 1 telefoon verder. Waar heb ik ook al weer die PDF

Denk dat je die recoverycodes, het beste in je eigen password manager kan opslaan.

[The Zep Man]

Denk dat je die recoverycodes, het beste in je eigen password manager kan opslaan.

Maar waar bewaar je daar de recovery codes van?

[Darkstriker]

Recovery codes bestaan voor fatsoenlijke password managers niet. Je wachtwoord laat je achter in een kluis bij een bank.

[Christoxz]

Een `recovery code` is dan toch gelijk aan een wachtwoord?
Iets wat ook gewoon de kluis in kan gaan?

[Darkstriker]

Als een recovery code niet meer is dan een gewoon wachtwoord, wat is dan de meerwaarde boven gewoon je normaal wachtwoord op een veilige plek opslaan? Beide geven dezelfde toegang tot je wachtwoorden.

[CAPSLOCK2000]

Een `recovery code` is dan toch gelijk aan een wachtwoord?
Iets wat ook gewoon de kluis in kan gaan?

Zolang het maar een andere kluis is. Je wil de recovery codes apart bewaren van je normale wachtwoorden zodat ze niet door één fout samen verloren kunnen gaan.

[ToolBee]

Inderdaad, gewoon op een USBstick in de brandkluis.

[wica]

In lastpass natuurlijk

[CAPSLOCK2000]

Maar waar bewaar je daar de recovery codes van?

Buiten de deur, bij vrienden en kennissen die je kunnen identificeren zonder een code nodig te hebben. Liefst zowel in digitale vorm (op usb-key) als uitgeprint in een lettertype dat goed werkt voor OCR.

Als je het nog beter wil (bv omdat het zakelijk is) kun je ergens een kluis huren bij een organisatie die je (in geval van nood) toegang geeft op grond van je paspoort.

[Christoxz]

Denk dat je die recoverycodes, het beste in je eigen password manager kan opslaan.

Lijkt mij dat je geen password manager hoef te gebruiken van DDG als je al een password manager gebruikt..

[Yinchie]

Beste manier uitprinten en ergens bewaren waar het veilig is.
Ik bewaar persoonlijk het in me paswoord manager + print het uit.

[RoRoo]

Ik denk dat het zelfs slimmer is om je wachtwoorden in de password manager te zetten.

het is maar een idee

[iRob87]

Je vangt mij letterlijk op mijn woord. Wat ik bedoel natuurlijk is wanneer je geen QR code en geen recovery codes meer hebt.

[[Roland]]

Dan ben je het kwijt. Is dat heel erg voor je bookmarks, plugins e.d.?

[iRob87]

Kan, hoeft niet. En je wachtwoorden?

[P-e-t-j-e]

Opslaan in een willekeurige password manager met slechte beveiliging. Kun je een paar jaar later op een of andere darkweb gewoon je wachtwoord terugkopen in een grote dataset

[iqcgubon]

Heel fijne zoekmachine maar hun browser vind ik maar wat karig. Daar gebruik ik tegenwoordig Librewolf.