Signal repareert bug waardoor gebruikers afbeeldingen van anderen kregen te zien

Signal heeft een bug gerepareerd in de Android-app waarmee sommige gebruikers afbeeldingen te zien kregen die bedoeld waren voor andere contacten van de verzender. Er stond al sinds december 2020 een ticket open voor de bug, maar die kwam volgens de makers weinig voor.

Signal zegt dat het de bug in de meest recente versie heeft opgelost. Dat is versie 5.17 van de Android-app. Het issue werd begin december voor het eerst gerapporteerd door een gebruiker. Die beschreef op de GitHub-pagina dat hij soms afbeeldingen te zien kreeg die mogelijk naar andere gebruikers in de contactenlijst van de eerste gebruiker zijn gestuurd, al blijkt uit het issue niet of de afbeeldingen echt daarvan afkomstig zijn. Later bleken er meer gebruikers te zijn die dat probleem hadden. Dat gebeurde alleen maar op Android-toestellen. Bij sommige gebruikers leek het probleem sporadisch voor te komen, bij anderen juist consistent.

Signal bug

Inmiddels zou het probleem zijn opgelost. Veel details over wat er precies mis ging zijn er nog niet, al zijn de twee commits met het issue wel in te zien. Daarin is te zien hoe sommige velden in de SQLite-database geen gebruik maakten van de autoincrement-functie. Dat is in de nieuwe versies wel toegevoegd.

Volgens de ontwikkelaar was de bug gelinkt aan een andere bug. Het probleem zou alleen ontstaan als gebruikers conversation trimming aan hadden staan. Dat is een feature waarbij oude berichten in een gesprek automatisch worden verwijderd. In dat geval kon een database-id van een gebruiker worden hergebruikt bij andere gebruikers. "Het was heel moeilijk de bug te achterhalen", zeggen de ontwikkelaars. "Zodra we meer informatie verzamelden werd dit onze topprioriteit."

Voor zover bekend kwam de bug alleen voor bij Android-gebruikers. De ontwikkelaars zeggen dat dat 'maar weinig voorkwam', al merken sommige gebruikers op Hacker News op dat Signal dat moeilijk kan zeggen zonder goede telemetrie.

Update: in het stuk is verduidelijkt dat het gaat om afbeeldingen die afkomstig zijn van lokale gebruikers en niet van willekeurige Signal-gebruikers.

Door Tijs Hofmans

Nieuwscoördinator

26-07-2021 • 17:27

83

Submitter: x86dev

Reacties (83)

Sorteer op:

Weergave:

@dutch_mentor @DJMaze @jaenster @marcieking RE: Jullie verontwaardiging over mogelijk veiligheidsprobleem van Signal

De commits betreffen de Android App. Zit deze bug dus ook alleen maar in de client? Daarmee is het naar mijn inschatting alleen maar een 'hussel' of 'verwarring' met andere foto's die je - zelf - reeds hebt ontvangen of verzonden. (als het dus om hergebruik van bericht-IDs van je lokale berichten database gaat)

Of zijn dit foto's die van de Signal Server getrokken worden en daadwerkelijk van andere gebruikers komen? In dat geval is dit een enorm nieuwsbericht dat de veiligheid van Signal als dienst helemaal afbreekt.

In het artikel is het niet zo duidelijk, kan de auteur dit even checken en bevestigen? Ik ben ook benieuwd! Als het alleen je eigen foto's betreft, denk ik dat de kop van dit artikel niet helemaal juist is.

[Reactie gewijzigd door Helium-3 op 22 juli 2024 21:05]

Volgens de developer (https://github.com/signal...47#issuecomment-886239978) was dit inderdaad puur een verwarring/hergebruik van database ids, waardoor er dus een foto verscheen die je lokaal al eerder had ontvangen van een andere gebruiker. Dit kon alleen gebeuren als je automatische het verwijderen van oude berichten had aanstaan.

Het artikel kan inderdaad een stuk duidelijker, want het gaat hier dus niet om het onbedoeld ontvangen van een foto van een willekeurige andere Signal gebruiker, maar om een aan jou geaddreseerde foto die je al eerder hebt ontvangen.

edit: @TijsZonderH Bij nader inzien, door het hergebruik van ids kon het ook voorkomen dat je bij het sturen van 1 beeld (ook bij image preview van een link) onbedoeld 1 of meerdere beelden uit je eigen database meestuurde, wat het issue aanzienlijk pijnlijker maakt.

[Reactie gewijzigd door epTa op 22 juli 2024 21:05]

AuteurTijsZonderH Nieuwscoördinator @epTa26 juli 2021 18:22
waardoor er dus een foto verscheen die je lokaal al eerder had ontvangen van een andere gebruiker
Ik haal niet uit die commit dat dit alleen gaat om foto's die je echt zelf al eerder had ontvangen. Dat zie ik ook niet in andere issues terug.
Het is toch echt wat er in de commits voor de fix staat. Er was een fout gemaakt in de aanroep naar de lokale sqlite database, waar het mis liep met auto increment ids.
Dat suggereert absoluut dat het gaat om de verkeerde foto's tonen uit de lijst met bestaande foto's.

Edit: link naar de comment met referenties naar de commits(https://github.com/signal...47#issuecomment-886250177)

[Reactie gewijzigd door incapable op 22 juli 2024 21:05]

Volgens mij klopt dat niet, want ik lees op jouw doorgestuurde pagina het volgende:

@Helium-3
"Standard conversation between two users (let's call them party A and party B). Party A shares a gif (from built in gif search). Party B receives the gif, but also some other images, which appear to be from another user (party A has searched their phone and does not remember the images in question). Best case the images are from another contact of B and messages got crossed, worst case they are from an unknown party, who's data has now been leaked. Luckily in this case they were not sensitive."

Volgens mij heeft @TijsZonderH wel gelijk. Het lijkt mij in deze situatie ook verstandig om van het worst-case scenario uit te gaan, wat overigens bevestigd lijkt te worden op basis van de bovenstaande quote, naar mijn interpretatie.

[Reactie gewijzigd door jetspiking op 22 juli 2024 21:05]

Volgens deze comment https://github.com/signal...47#issuecomment-886239978 en de wijzigingen die hier naar gerefereerd worden https://github.com/signal...47#issuecomment-886250177 (ja ik in de code gekeken) gaat het om wat er lokaal in de telefoon opgeslagen staat, het gaat hier ook om een bug in de app.

De quote waar je naar refereert is overigens van de report, niet de oplossing en geeft slechts een denkrichting aan. De mensen die dit nu opgelost hebben, hebben zeker rekening gehouden met het worst case scenario en al uitgevonden dat dit niet het geval is, of het geval kan zijn.

@TijsZonderH zit er concreet, verifieerbaar naast.
AuteurTijsZonderH Nieuwscoördinator @incapable26 juli 2021 19:25
Dat suggereert
Suggereert het dat of wéét je dat? Ik weet niet genoeg van Signals codebase om definitief te concluderen dat het echt alleen lokaal is. Er is namelijk geen enkele andere comment (inclusief van de devs zelf) die dat stelt.
Wéét jij dat het om foto's van anderen gaat, of suggereer je dat? :+

Kwaliteit hoor, dit. En als dan blijkt dat het allemaal meevalt dan horen we niks meer.
AuteurTijsZonderH Nieuwscoördinator @uNoTopia26 juli 2021 19:49
Ik probeer hier een discussie aan te gaan maar door nu al 100 keer "kwaliteit dit hoor" naar me toe geslingerd te krijgen heb ik daar weinig zin meer in.
Wéét jij dat het om foto's van anderen gaat, of suggereer je dat? :+
Nee. Maar: de issues suggereren dat, en de devs ontkennen het niet.
En als dan blijkt dat het allemaal meevalt dan horen we niks meer.
Zure, cynische aanname die niet klopt. Ik zit hier nu al de hele avond uit te zoeken hoe dit zit en waar mogelijk pas ik de tekst aan, zoals we altijd op Tweakers doen als blijkt dat iets niet klopt. Als het nieuws interessant genoeg is voor een follow-up-nieuwsbericht plaats ik dat. Net zoals we altijd op Tweakers doen als blijkt dat dat nodig is.
Op basis van suggereren stel je zelf de titel op:
"Signal repareert bug waardoor gebruikers afbeeldingen van anderen kregen te zien"

De devs bevestigen dit niet op de wijze die je suggereert.

Je kunt ook kiezen voor een titel als
"Signal repareert bug waardoor gebruikers mogelijk afbeeldingen van anderen kregen te zien"

Als je zelf aangeeft de tekst aanpast als het nieuwsbericht niet klopt, dan is het raar dat je dit stuk niet aanpast:
Signal heeft een bug gerepareerd in de Android-app waarmee sommige gebruikers afbeeldingen te zien kregen die voor andere gebruikers bedoeld waren.
Dit is namelijk geen feit, maar speculatie. Je kunt prima op basis van wat gebruikers van Tweakers aangeven de tekst aanpassen dat het wellicht om afbeeldingen van anderen gaat, of afbeeldingen van jezelf, ontvangen van een andere gebruiker. Dit is niet bevestigd door een dev, ook niet in de commit.

Wellicht helpt het als je de feedback ter harte neemt in plaats van in je eigen standpunt te volharden.

Het staat op dit moment simpelweg niet vast wat het exacte probleem is. Dus pas het nieuwsbericht daar dan goed op aan. Dat zou netjes en passend zijn. Nu staat er 1x 'hoogstwaarschijnlijk' in het artikel, ergens middenin. Het gros van de lezers heeft door de titel en de intro allang tot zich genomen dat je als Signal gebruiker foto's van willekeurige andere Signal gebruikers te zien krijgt.

[Reactie gewijzigd door KoffieAnanas op 22 juli 2024 21:05]

AuteurTijsZonderH Nieuwscoördinator @KoffieAnanas26 juli 2021 20:08
Wellicht helpt het als je de feedback ter harte neemt in plaats van in je eigen standpunt te volharden.
Wellicht doe ik dat ook wel gewoon en ben ik hier naar aan het kijken, tussen m'n nieuwsdienst door, maar ga je uit van je eigen standpunt dat ik dat niet doe.
tijs, fix je artikel nou gewoon. Of lees de daadwerkelijke code en zie dat alle weizigingen zitten in de lokale DB. En fix dan alsnog je artikel
Ik heb de pagina 3 sec geleden gefreshed en de titel is echt:
Signal repareert bug waardoor gebruikers afbeeldingen van anderen kregen te zien

Nogal misleidend niet?

Titel zou (als voorbeeld) moeten zijn :Signal repareert bug waardoor gebruikers afbeeldingen uit andere (hetzij hun eigen) chats te zien krijgen

edit: ook staat er nu dit: Signal heeft een bug gerepareerd in de Android-app waarmee sommige gebruikers afbeeldingen te zien kregen die bedoeld waren voor andere contacten van de verzender. Er stond al sinds december 2020 een ticket open voor de bug, maar die kwam volgens de makers weinig voor.

Maar ook dat is incorrect, want dat suggereerd dat ik naar persoon A een afbeelding stuur, maar persoon B de afbeelding ontvangt, wat niet het geval is. Wat er gebeurd is dat bij het showen van de afbeelding (dus het renderen) de lokale DB een fout maakt, en de verkeerde ophaalt. @TijsZonderH

[Reactie gewijzigd door dec0de op 22 juli 2024 21:05]

Laat je niet gek maken ;) Ben het met de tweakers eens dat de titel iets minder aannames kan bevatten maar de manier waarop dit wordt gebracht keur ik af.
Het is gefixt, in de Android Client. Dus er was niks mis met de server.
Nee. Maar: de issues suggereren dat, en de devs ontkennen het niet.
Heel mooi dat het voor jou ok is om een artikel te schrijven omdat de issues suggereren dat, en omdat de tegenpartij het niet ontkent.

Je zegt dat feitelijke informatie die suggereert dat het lokaal is niet klopt, omdat ik dit niet
wéét je dat
weet. Maar vind jouw ongefundeerde informatie wel ok omdat het issue suggereert dat het server side is.

Je hebt totaal niet naar de oplossing gekeken, je negeert ronduit wat iedereen jou verteld, omdat de developers jou dit niet persoonlijk zijn komen vertellen, je reageert ronduit arrogant wanneer ik jou de juist informatie geef, en je gebruikt vervolgens datzelfde argument zonder substantie om je eigen artikel te verantwoorden.

Vind je het serieus gek dat mensen zo fel zijn tegen je? Ik kan echt niet anders dan uiterst teleurgesteld zijn in hoe je hier mee om gegaan bent.

Edit voor jouw credit:
Artikel is aangepast inmiddels met de correcte informatie, dank daarvoor, maar bovenstaande blijft me onveranderd storen.

[Reactie gewijzigd door incapable op 22 juli 2024 21:05]

Nee dat weet ik niet, ik heb het niet bedacht en het is niet mijn code. Maar als het een lokale database is (dit is een feit, het gaat om sqlite in de app, dus lokaal.) gaat het niet om serverside data.

[Reactie gewijzigd door incapable op 22 juli 2024 21:05]

SQLite is de lokale database, al zou er een bug in zitten waardoor de client afbeeldingen van iemand anders probeert op te halen zou de server dit niet toestaan. (En uit de commit kan je wel opmaken dat dit client sided is, niet server sided)
Signal heeft toch end-to-end encryptie? Lijkt me sterk dat ik de foto's van iemand anders kan zien die ik nooit eerder ontvangen heb tenzij ze hetzelfde keypair gebruiken.

Of mis ik iets?
Klopt, als het wél zo was geweest dat het inderdaad van andere gebruikers afkwam, had Signal dit never nooit (intended) zelf naar buiten gebracht. Dat was het einde van Signal geweest.
Maar je haalt er ook niet uit dat het "afbeeldingen van anderen" zijn.
Hou de titel dan neutraal met "verkeerde afbeeldingen".
Dat verhelderd een hoop! Nu kunnen we weer door met een stuk minder sensatie, maar een goed gevoel houden over Signal's veiligheid ;)
Volgens artikel op bleepingcomputer was het toch een stuk serieuzer en kon het voorkomen dat meerdere willekeurige afbeeldingen (van telefoon verzender) werden meegestuurd bij het versturen van een afbeelding. Verklaart ook waarom E2E encryptie niet werkt.
Aha, wat een bizarre bug? Dus je stuurt een foto naar je vriend/vriendin/other en de App besluit voor de lol wat extra random foto’s mee te sturen.

Nu, een bug, dat kan, sh*t happens. Maar waarom heeft het dan van december 2020 tot nu 8 maanden later moeten duren voordat er een oplossing gevonden werd? En als Signal op de hoogte was, waarom hebben ze dat niet preventief gecommuniceerd naar Android gebruikers?

Ik vind de aangehaalde reactie ook wel gepast in deze;
"This is crazy. This bug should be the number 1 priority for Signal right now and yet all they do is ask for logs and make enhancements that aren't anywhere near as important as fixing this. This is a bug that should kill Signal, honestly," complained pseudonymous security and privacy advocate InfiniteLight
Niet alleen is het “stilhouden” een laakbare strategie voor een open organisatie die pronkt met transparantie en veiligheid. Maar het toont ook een ernstig gebrek in de modus operandi van Signal. Namelijk, geen logs—>geen data—>geen bugfixes. Of nouja, laat.
“Verklaart ook waarom E2E encryptie niet werkt.”

E2E-encryptie werkt juist prima? Niets in dit artikel noch de bug wijzen op het tegendeel.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 21:05]

AuteurTijsZonderH Nieuwscoördinator @Helium-326 juli 2021 18:25
In het artikel is het niet zo duidelijk, kan de auteur dit even checken en bevestigen? Ik ben ook benieuwd! Als het alleen je eigen foto's betreft, denk ik dat de kop van dit artikel niet helemaal juist is.
Omdat het niet duidelijk is. In de originele bug report stelt de ontvanger dat er twee mogelijkheden zijn: óf hij heeft de afbeeldingen eerder ontvangen van iemand anders, óf ze zijn echt van een willekeurige gebruiker. Maar uitsluitsel daarover is er (voor zover ik zie, correct me if I'm wrong) niet, ook niet van de devs die in de issue tracker reageren. Andere gebruikers die het issue aankaarten geven daar ook geen uitsluitsel over. En in de commits staat alleen wat er veranderd is, maar daar wordt geen extra informatie bij gegeven.

[Reactie gewijzigd door TijsZonderH op 22 juli 2024 21:05]

[...]


Omdat het niet duidelijk is. In de originele bug report stelt de ontvanger dat er twee mogelijkheden zijn: óf hij heeft de afbeeldingen eerder ontvangen van iemand anders, óf ze zijn echt van een willekeurige gebruiker. Maar uitsluitsel daarover is er (voor zover ik zie, correct me if I'm wrong) niet, ook niet van de devs die in de issue tracker reageren. Andere gebruikers die het issue aankaarten geven daar ook geen uitsluitsel over. En in de commits staat alleen wat er veranderd is, maar daar wordt geen extra informatie bij gegeven.
Die commits zijn alleen niet duidelijk als je écht niks van softwareontwikkeling weet. Je hoeft niet eens diep te begrijpen waar ze over gaan, zodra je ziet dat het om een client-fix gaat snap je al dat er geen beveiligingslek is gedicht waarbij je echt data van andere gebruikers kan zien.

En ik reageer zo fel omdat dit echt een waardeloos stuk journalistiek is dat Signal in een slecht daglicht zet voor iedereen die niet 2x kijkt.

Wat er door de oorspronkelijke rapporteur werd beschreven en wat je noemt, namelijk “ Die beschreef op de GitHub-pagina dat hij soms afbeeldingen te zien kreeg die hoogstwaarschijnlijk van andere gebruikers afkomstig leken.” dat is in ieder geval niet in de hand. Wél kon er vanuit die buggy client data naar de verkeerde personen op je eigen app lekken.

[Reactie gewijzigd door Argantonis op 22 juli 2024 21:05]

Het is heel duidelijk thijs.

Het is een fout in de *lokale database* waar ze een Id *hergebruiken* wat niet meer bestaat en daarmee het verkeerde id uit de *lokale database* halen.

Als je de commit leest zie je dat het ook niet de networking code aanpast
En op basis waarvan is dan de keuze gemaakt het artikel op dit moment te publiceren? Eigenlijk zegt dit artikel nu niet meer dan dat er een potentieel serieuze bug is opgelost waarvan het hoe en wat niet duidelijk is. Er blijven (terecht) ontzettend correcte en kritische vragen open staan, helemaal mee eens. Maar komt er dan ook een vervolg op het artikel op het moment dat het allemaal wel mee blijkt te vallen?
AuteurTijsZonderH Nieuwscoördinator @McRegt26 juli 2021 19:23
En op basis waarvan is dan de keuze gemaakt het artikel op dit moment te publiceren?
Het nieuws dat Signal een bug heeft gefixt.
Maar komt er dan ook een vervolg op het artikel op het moment dat het allemaal wel mee blijkt te vallen?
Als ze meer informatie geven wel ja.
... Het nieuws dat Signal een bug heeft gefixt.
Hoe kan dat feit op zichzelf nieuws zijn? Alle softwarebedrijven zijn constant bezig met bugs fixen. Ik zou het pas nieuws vinden als er een bedrijf is die dat niet doet. ;)
Als ik de oorspronkelijke post over dit probleem doorscrol, lijkt het toch echt alsof de extra afbeeldingen uit random andere gesprekken komen, die niets met deelnemers van de chat te maken hebben. De OP zegt namelijk: "party A has searched their phone and does not remember the images in question" in zijn bug report en voegt later zelf in een comment toe "No, the images did not arrive in another conversation the B has."

Dan kan ik ergens iets verkeerd begrijpen, natuurlijk, maar als A en B de afbeeldingen allebei niet uit hun Signal-gesprekken herkennen, moeten ze van een onbekende partij C komen, toch?
Vanuit je observatie klopt je conclusie helemaal, maar ik heb zelf genoeg ervaring met troubleshooten van bugs, klantenservice en customer experiences dat ik maar al te vaak heb mee gemaakt dat mensen zich dingen pertinent verkeerd herinneren. :+

De reactie van @epTa legt mooi uit hoe het lijkt te zitten volgens de ontwikkelaars!

[Reactie gewijzigd door Helium-3 op 22 juli 2024 21:05]

Hm, people do suck, dat is wel zo, idd :+

Ik weet niet genoeg van hoe Signal onder de motorkap werkt, geef ik ook grif toe. Het was mij niet helemaal duidelijk waar die database stond, of dat een lokale of serverside database is, ook in post van die dev niet. Ik weet ook niet of Signal überhaubt serverside databases gebruikt. Daar ging ik vanuit, omdat bij berichtentoepassingen meuk meestal ergens tijdelijk woont tot er verbinding met ontvanger is. Maar als de concensus is dat het lokaal was, is het vooral suf en verwarrend foutje, maar niet extreem problematisch natuurlijk. :)
Danku voor deze toevoeging <3
Zet je de auteur er dan ook even bij? Had wel fijn geweest als dat ook in dit artikel stond... Kan ook bewust zijn natuurlijk. Page views en interacties zijn king tegenwoordig. ;)
Zoals ik het begrijp uit het GitHub Issue, ziet de ontvanger beelden die hij van een andere partij ontvangen had. Er komen dus geen foto's bij de verkeerde mensen terecht, maar ze worden aan de ontvangende kant in een verkeerde chat getoond.
Er is dus niet per se iets mis met de encryptie, maar de App maakt lokaal een fout met ID's van foto's als de trimming functie aan staat en er ID's hergebruikt worden voor foto's.
Typisch weer een krom vertaald nieuwsbericht dat door de redactie niet begrepen of onderzocht is. En dan pissig worden wanneer mensen aangeven dat de code open source is en je corrigeren. Tenslotte de clickbait titel lekker laten staan.

Een nieuw dieptepunt, gefeliciteerd.
Mooi dat het gefixed is. Echter vraag ik me iets af...

De bug is momenteel dus vrij discutabel begrijp ik? (qua intepretatie)

Optie 1: Hij stuurt de afbeelding naar dezelfde persoon in een andere chat.
(Dit kan alleen een groepsapp zijn want je kunt niet 2 rechtstreekse chats hebben met dezelfde persoon, tenzij in een groepschat. Dus evengoed een zeer slechte zaak.)

Optie 2: Hij stuurt wel degelijk naar andere personen als de bug getriggerd word.

Ongeacht welke van de twee, beide zijn dan toch vrij ernstig? Of begrijp ik het nu verkeerd?


Thanks @jorikc en @comecme voor de uitleg! Nu snap ik hem... (Dus een storm in een glas water als je het mij vraagt..)

[Reactie gewijzigd door EGCnightstalker op 22 juli 2024 21:05]

Optie 3: hij toont een afbeelding uit jouw chat met persoon A in de chat met persoon B.

Welke optie het is weet ik niet, maar dit is dus een derde optie.
Eh... dit doet wel vermoeden dat het niet end to end encrypted is. Hoe kan het immers anders bij iemand anders aankomen en zichtbaar zijn? Mis ik iets?
Dit betekent wel effectief dat bestanden en afbeeldingen op Signal niet beveiligd zijn. Voor een app die zo'n punt maakt van hoe absoluut veilig ze wel niet zijn is dit wel een beetje amateuristisch vrees ik... Niet het feit dat deze bug ontstond, dat kan altijd gebeuren, maar de slechte ontwerpkeuzes die er toe leidden dat dit uberhaupt kon gebeuren.
Het gaat over afbeeldingen uit je lokale Signal database. Afbeeldingen die je in een ander gesprek ontvangen of verstuurd hebt.

Deze bug bevindt zich dus buiten de end-to-end encrypted communicatie. Je krijgt ook geen afbeeldingen van iemand anders te zien (zoals verkeerdelijk in de titel van Tweakers staat), maar afbeeldingen uit het verkeerde gesprek.
Dat is waar ik eerst vanuit ging, maar dit artikel (en de bug) gaf mij dus het idee dat het dat niet was. Blijkt nu inderdaad wel het geval te zijn. Dank voor de verduidelijking.
Kan toch perfect.... het is niet zo dat je geen bericht naar een vreemde kan sturen met Signal. Als de bug al in een vroeg stadium aan bod komt en zich vergist van bestemming bijvoorbeeld.

EDIT: gelukkig is er nu verduidelijking dat het niet zo'n type bug was, maar in theorie kan het dus.

[Reactie gewijzigd door Jim80 op 22 juli 2024 21:05]

Hoeveel van die afbeeldingen waren naaktfoto's?
Want je kan wel zeggen "weinig", maar 1 naakt foto naar de verkeerde is er 1 te veel.

Jammer dat het oplossen dan zo lang duurde.

[edit]
Dit verklaart dat het gelukkig niet zo erg is:
Sorcix in 'nieuws: Signal repareert bug waardoor gebruikers afbeeldingen van ...
Helium-3 in 'nieuws: Signal repareert bug waardoor gebruikers afbeeldingen va...

[Reactie gewijzigd door DJMaze op 22 juli 2024 21:05]

"al merken sommige gebruikers op Hacker News op dat Signal dat moeilijk kan zeggen zonder goede telemetrie."

Als ze al weinig kunnen zeggen over de kwaniteit, denk jij dat ze precieze informatie hebben over de inhoud wat nog belachlijker is aangezien je voor de hoeveelheid nog de meta zou hebben, maar om naaktfoto's te identificeren moeten ze dus daardwerkelijk de foto zelf kunnen zien.

Als ze daar een antwoord op hadden zou t hele privacy aspect van Signal teniet gedaan worden.

Dus ik kan je vertellen dat Signal precies 0 naaktfotos geteld heeft in dit lek
Signal heeft ze niet geteld, maar het is niet uit te sluiten dat het gebeurd is, en dat is het punt van DJMaze, denk ik.

1) Er kwamen afbeeldingen terecht bij mensen die niet bedoelde ontvanger waren. Dit heeft Signal zelf ook erkend.
2) Sommige mensen sturen naaktfoto's.
3) Er is dus een reële kans dat sommige afbeeldingen die verkeerd bezorgd werden naaktfoto's waren.

Dat is gewoon basale logica, vrees ik, en toch beetje gênant voor zo'n berichtendienst... Dan kan je beredeneren dat het belachelijk is, maar Signal heeft zelf toegegeven dat het gebeurd is en dat doen ze ook niet voor de lol, lijkt me :+
Ja maar dat is dus niet zo, want dit lek is een lokaal lek waar afbeelding uit chat A bij chat B geshowed wordt, niet van gebruiker a bij gebruiker B
Maar toch heeft Signal en als het goed is 0 geteld. @WORPspeed zegt niets raars.
Niet enkel naaktfoto's zijn vervelend in verkeerde handen.
Een gelekte foto van inloggegevens kan ook erg vervelende gevolgen hebben...
Niemand zegt dat er naaktfoto's waren. Niet het bericht sappiger proberen te maken dan het is.
Niemand zegt dat die er waren, maar niemand zegt ook dat die er niet waren. Gezien er best wat naaktfoto's worden verstuurd via berichtenapps (en zeker deze, waar je je nog net wat veiliger acht), vind ik het een terechte vraag.

[Reactie gewijzigd door TheVivaldi op 22 juli 2024 21:05]

Hij heeft gewoon een punt. Want volgens de AVG moet daar dan een melding van gemaakt worden, omdat een naaktfoto persoonlijke informatie is welke dus is gelekt. Ze kunnen het wel wegwuiven als zijnde dat het amper werd misbruikt, maar het zal.
Niemand zegt ook van niet.
Daarom is het een relevant vraagstuk.

Voor sappige verhalen kan je bij geenstijl terecht.
Een vervelende bug, zeker als de foto die gestuurd werd privacygevoelige informatie bevatte. Het heeft wel lang geduurd voordat ze het opgelost hadden, ik vind het vrij ernstig dat een foto bij de verkeerde persoon kan belanden.
En als de beschrijving klopt ook vrij makkelijk te misbruiken. Je kan continu een leeg(of willekeurig) plaatje posten in een gesprek(desnoods met jezelf op een ander nummer/telefoon) met conversation trimming aan en afwachten wat er nu weer terug komt. Een soort van virtuele grabbelton.
Een plaatje dat je toch al op je telefoon had staan dus.
Dat was vóór de toegevoegde update niet in dit artikel zelf duidelijk. Zoals in wel meer reacties te lezen is. ;)
Als een afbeelding end-to-end encrypted is en ik als gebruiker een afbeelding ontvang die ik niet hoor te hebben, dan kan ik die toch niet ontsleutelen?
Foto's krijgen een oplopend ID over alle conversaties heen. Als je autotrimming op had staan, werden ID's herbruikt, waardoor nieuwe foto's in oude conversaties konden opduiken.
Dit was een client side bug, je kreeg helemaal geen foto's te zien die je zelf nooit eerder ontvangen had.
Mag ik klagen over code?

Ten eerste, autoincrement heeft wat op- en aanmerkingen binnen SQLite; als je het toepast op een veld dat niet ook een primary key is, kan / gaat het IDs hergebruiken: https://www.sqlite.org/autoinc.html

Ten tweede, ieuw, ze concatenaten SQL queries bij elkaar ipv gewoon een .sql bestand te gebruiken (waar editors e.d. meer mee kunnen).

Ten derde, ik zie dat ze een migratie toegevoegd hebben; SQLite is lastig want, zoals ook op de sqlite website beschreven staat ondersteunt het maar een deel van de ALTER TABLE sql - voor het aanpassen van een bestaande tabel moeten ze een nieuwe tabel maken, data kopieren en de temp tabel renamen. Gezien de hoveelheid rijen e.d. lijkt me dat behoorlijk kwetsbaar als de ontwikkelaar + de reviewer niet opletten. Ik zie in de twee gelinkte commits ook geen wijzigingen die erop wijzen dat dit proces getest wordt.

Op dit item kan niet meer gereageerd worden.