Att hitta vänner i en meddelandeapp och att hålla adressboken privat är inte samma problem. Appen måste avgöra vilka identifierare som tillhör användare av tjänsten, men matchningsmetoden avgör vilken information tjänsten får tillgång till. Att hasha ett telefonnummer garanterar inte i sig att numret inte kan identifieras.
Varför kan ett hashat nummer identifieras?
En hashfunktion omvandlar indata till ett värde med fast längd. Utrymmet av telefonnummer är dock begränsat och strukturerat. En angripare kan generera sannolika nummer, beräkna deras hashvärden och leta efter matchningar. Det är inte att ”dekryptera hashen”, utan att prova indata som går att gissa.
Signal förklarar just denna begränsning hos identifierare med låg variation i sin beskrivning av problemet med privat kontaktupptäckt. Samma text presenterar en design baserad på en betrodd exekveringsmiljö. Detta historiska exempel bör inte generaliseras till alla meddelandetjänster utan att man granskar versionen och nyare dokumentation.
Påståendet ”servern ser bara hashvärden” är alltså inget fullständigt svar på integritetsfrågan. Det måste framgå vem som kan beräkna matchningarna, vilka förfrågningar som loggas och hur länge uppgifterna sparas.
Vad tillåter kontaktbehörigheten?
Behörighet att läsa kontakter ger appen tillgång till adressbokens uppgifter; den avgör inte i sig om appen laddar upp dem. Namn, nummer, e-post och kontaktanteckningar kan vara känsliga, särskilt när de innehåller information om personer som inte ens använder tjänsten.
Androids dokumentation för Contacts Provider skiljer mellan bred läsning av adressboken och att välja en kontakt via systemets gränssnitt. Åtkomstens omfattning beror på implementationen och operativsystemets version.
| Metod för att hitta kontakter | Möjlig fördel | Vad som behöver granskas |
|---|---|---|
| Dela användarnamn eller inbjudningslänk | Behöver kanske inte läsa hela adressboken | Identifierarens sökbarhet och andras möjlighet att hitta kontot |
| Välja några kontakter | Appen får tillgång till färre uppgifter | Får appen enbart de valda posterna? |
| Ladda upp en lista med nummer eller hashvärden | Enklare matchning mot registrerade användare | Möjligheten att gissa nummer, loggning av förfrågningar och lagring av listan |
| Särskilt protokoll för privat kontaktupptäckt | Kan minska exponeringen inom en viss hotmodell | Tillitsantaganden, begränsningar och belägg för oberoende granskning |
Vad bevisar inte meddelandekryptering om adressboken?
End-to-end-kryptering kan dölja samtalets innehåll för servern, men säger i sig inget om kontaktbehörighet, användarsökningar eller registrering av relationer. Även utan adressboken kan routningsinformation avslöja en del av kommunikationsrelationerna.
På sin säkerhetssida beskriver Livara lagring och behandling av driftsinformation som gruppmedlemskap, tid och routning. Dokumentet ger inte grund för slutsatsen att adressboken hashas med en viss metod, att inga historiska uppgifter sparas eller att relationsgrafen är helt dold. Sådana påståenden kräver en separat förklaring av kontaktupptäckten.
Ställ dessa fem frågor innan du ger behörigheten
- Kan jag chatta med hjälp av användarnamn eller en direkt inbjudan utan kontaktbehörighet?
- Exakt vilka fält lämnar enheten: bara numret, eller även namn och andra detaljer?
- Hur används och raderas uppgifter om personer som inte är registrerade?
- Stoppar återkallad behörighet bara framtida åtkomst, eller finns det också ett sätt att radera redan skickade data?
- Stämmer den tekniska beskrivningen och policyn för datalagring med appens aktuella version?
Granska appens behörighet i systeminställningarna och begränsa onödig åtkomst om du inte behöver hitta vänner automatiskt. Alternativens namn varierar mellan telefoner. Likställ inte återkallad behörighet med att tidigare uppladdade uppgifter raderas.
Kontaktintegritet mäts genom dataminimering och tydlighet om uppgifternas väg, inte bara genom att ordet ”hash” står bredvid ett telefonnummer.
