GNOME Bugzilla – Bug 629538
Folks should auto-link Personas with corresponding fields
Last modified: 2018-08-04 08:24:35 UTC
There are a lot of secondary fields on Personas that can suggest they are the same person (in which case, we'd like to auto-link them into the same Individual). For example, an XMPP UID "foo@example.org" might also be an email address. If we have a Persona with a UID "foo@example.org", which is identified as an email address, we probably want to link these two Personas together. Similarly, an IM-based Persona may have extended contact info that suggests another email address entirely. However, we'll need to carefully check the trust level of the backend(s) involved, since we must not allow contacts to maliciously cause auto-linking of themselves with another person's Personas, since that could allow them to spoof the other person's identity. This depends upon bug #629537, so users can correct any flaws in this algorithm while awaiting bug fixes. (Not that we'd have any errors in our algorithm.)
Now that my Google+ contacts appear in my roster (which is cool) I get loads of duplication (XMPP, Facebook, Google+...). We should rely try to improve auto linking to reduce this contacts explosion.
I agree. We should have made this a higher priority. Bumping now.
See also bug #670040
Didn't make folks 0.3.4 release, punting to Future milestone for now.
Travis, Guillaume, Is this still needed? or is the suggestion in gnome-contacts (as 670040 was closed) enough?
I think suggested links (using folks’ PotentialMatch API) are a better, safer way to approach this than implicitly linking on properties other than linkable ones. I would suggest WONTFIX, but Travis might have other ideas.
(In reply to comment #6) > I think suggested links (using folks’ PotentialMatch API) are a better, safer > way to approach this than implicitly linking on properties other than linkable > ones. I would suggest WONTFIX, but Travis might have other ideas. I'm on the fence with this. It's "safer" to leave this up to a UI which uses the potential matches to do most inferred links just a few clicks. But I quote "safer" because I think any malicious spoof-directed linking would go unnoticed (especially amongst potential hundreds). And if we think that's a valid premise, why not just do it and let the user correct after-the-fact? Maybe we should come up with sets of fake contacts (including "malicious" contacts) and see if we can reasonably route around such spoofing somehow. Or at least make it less likely that we'll auto-link in those cases.
(In reply to comment #7) > But I quote "safer" because I think any malicious spoof-directed linking would > go unnoticed (especially amongst potential hundreds). And if we think that's a > valid premise, why not just do it and let the user correct after-the-fact? I think a key difference is that if this level of auto-linking were done, a malicious contact could spoof someone at any time, then change their details back to look innocent as soon as they’re finished (plausible deniability). By contrast, requiring the user to explicitly link suggested contacts is a one-time operation which more permanently links the contacts together. A malicious contact can’t then deny having spoofed the user, and if they change their details back to look innocent, the user should hopefully notice the conflict between the malicious contact’s innocent persona properties and the properties of the persona they were impersonating. > Maybe we should come up with sets of fake contacts (including "malicious" > contacts) and see if we can reasonably route around such spoofing somehow. Or > at least make it less likely that we'll auto-link in those cases. I think that could easily get into an arms race where the spoofers and folks keep tweaking things to work around each others’ heuristics, with the end result being that auto-linking is effectively useless. But that’s just my opinion. If you can demonstrate that auto-linking can work usefully and safely with some example persona sets, please do. :-)
(In reply to comment #8) > (In reply to comment #7) > > But I quote "safer" because I think any malicious spoof-directed linking would > > go unnoticed (especially amongst potential hundreds). And if we think that's a > > valid premise, why not just do it and let the user correct after-the-fact? > > I think a key difference is that if this level of auto-linking were done, a > malicious contact could spoof someone at any time, then change their details > back to look innocent as soon as they’re finished (plausible deniability). By > contrast, requiring the user to explicitly link suggested contacts is a > one-time operation which more permanently links the contacts together. A > malicious contact can’t then deny having spoofed the user, and if they change > their details back to look innocent, the user should hopefully notice the > conflict between the malicious contact’s innocent persona properties and the > properties of the persona they were impersonating. Well met. > > Maybe we should come up with sets of fake contacts (including "malicious" > > contacts) and see if we can reasonably route around such spoofing somehow. Or > > at least make it less likely that we'll auto-link in those cases. > > I think that could easily get into an arms race where the spoofers and folks > keep tweaking things to work around each others’ heuristics, with the end > result being that auto-linking is effectively useless. But that’s just my > opinion. If you can demonstrate that auto-linking can work usefully and safely > with some example persona sets, please do. :-) It seems like such an intuitively-useful feature, and I've heard that it worked pretty well on WebOS. Then again, there may just not have been a big enough installed base for these attacks to happen and/or be noticed. I'll see if I can come up with some evidence-based reasoning.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/folks/issues/6.