Contacts Plugin

[Thomas Posch]

On Sunday, 21 January 2018 15:22:43 CET Aleix Pol wrote:
> On Sat, Jan 20, 2018 at 11:09 PM, Simon Redman <simon at ergotech.com> wrote:
> > Thank you all for the feedback! My thoughts inline:
> > 
> > On 01/16/2018 01:24 PM, Andy Holmes wrote:
> >> Probably the most flexible is to keep them cached, in vCard or even
> >> flat JSON since that's how it's received, in a directory with
> >> permissions restricted to the local user. It's not unlikely each phone
> >> might have different contacts (eg, work phone, personal phone) so
> >> should have their own file/directory and leaving the data in an easily
> >> parsable format means applications could write contact providers as
> >> needed.
> > 
> > I don't mean to start an argument, but I don't understand what this adds
> > vs. an on-demand dbus interface which exports contact data in some
> > useful format (like vCard)
I don't think vCards would make it easier. Unless you use fuse or inotify 
hackery it would be quite hard to sync changes from the desktop to a remote 
device.
> > KDE Connect's dbus registration already supports multiple devices --
> > Just figure out the device ID you want and call the contacts/ping/etc.
> > plugin under that device
> > 
> > I am new to working with dbus, so I may misunderstand this point, but
> > since KDE Connect registers to the session dbus (at least on my
> > computer), method calls are restricted to processes running under the
> > user's account
You are not mistaken.
> > 
> > Saving files does have the advantage that contacts would be available
> > when the phone is disconnected, but if we want that we should avoid
> > writing our own address book application and instead integrate with one
> > that already exists, like KAddressBook
I second that.
> > 
> >> On Tue, Jan 16, 2018 at 12:12 PM, Aleix Pol <aleixpol at kde.org> wrote:
> >>> On Tue, Jan 16, 2018 at 8:56 PM, Nicolas Fella <nicolas.fella at gmx.de> 
wrote:
> >>>> On Dienstag, 16. Januar 2018 01:43:07 CET Aleix Pol wrote:
> >>>>> On Sat, Jan 6, 2018 at 3:03 AM, Simon Redman <simon at ergotech.com> 
wrote:
> >>>>>> I have just put up a contacts plugin for review
> >>>>>> 
> >>>>>> In its current form, it is extremely primitive. Probably too basic to
> >>>>>> be
> >>>>>> usable. The KDE-side has a DBus slot which takes no arguments but
> >>>>>> sends
> >>>>>> a request to the Android side for its entire contacts book. The
> >>>>>> contacts
> >>>>>> book comes back, and is then sent back on DBus as a massive list of
> >>>>>> strings, one name, followed by one number.
> >>>>>> 
> >>>>>> I know that there are projects/people other than me interested in
> >>>>>> this
> >>>>>> functionality, so I am looking for input from those people for what
> >>>>>> they
> >>>>>> would like to see in terms of a better DBus API
> >>>>>> 
> >>>>>> Also code-review feedback, because I don't have much real-world
> >>>>>> experience :(
> >>>>> 
> >>>>> Hi Simon,
> >>>>> It's definitely interesting, something we have discussed in the past
> >>>>> even.
> >>>>> How do you expect to present these contacts?
> >>>>> 
> >>>>> Aleix
> >>>> 
> >>>> Hi,
> >>>> 
> >>>> thanks for your work on this!
> >>>> 
> >>>> Before implementing things we should think about the use-cases we want
> >>>> to
> >>>> serve. I was thinking about a import from device function in
> >>>> KAddressbook.
> >>>> Another often demanded feature is writing SMS from the desktop.
> > 
> > I specifically want to support SMS from the desktop. In particular, the
> > telepathy plugin.
> > 
> > Since telepathy is not a KDE-dependent protocol, I would like to make
> > that plugin also not be KDE-dependent. In other words, if someone is
> > using Empathy and KDE Connect on Gnome, I wouldn't want them to have to
> > install KAddressBook in order to use kdeconnect-telepathy
> > 
> >>>> We also should
> >>>> care about privacy here (it got selected as one of our primary goals).
> >>> 
> >>> +1
> > 
> > (Sorry if the +1 was supposed to refer to the whole paragraph and I have
> > now split it, Aleix)
> > Where can I read those primary goals? I'm still new to this project and
> > KDE, so I should read those before continuing!
https://dot.kde.org/2017/11/30/kdes-goals-2018-and-beyond
> > 
> >>>> Obviously the user has to consent by giving the contacts permission,
> >>>> but she/ he might want to restrict access to certain applications, so
> >>>> we might need to restrict who can read from the DBus interface.
> >>> 
> >>> There's no much of a security model around dbus, so it's probably not
> >>> doable.> 
> > Is an acceptable answer to this problem to leave the plugin disabled by
> > default until we come up with a better answer? In the worst case, nobody
> > uses the plugin and the situation is the same as today, but we have a
> > framework to move forward.
> > 
> > I am not a security expert, so I can't think of a way to secure the dbus
> > interface. One thought would be to have some popup on the phone saying
> > such-and-such an app wants to access the contacts interface, but I don't
> > know how to authenticate that an app reading the dbus interface is the
> > app it says it is.
kwallet solved that: Restricted access for executables. Encrypted 
communication.
This can be added once a protocol is established.
> > 
> >>> Another way to implement it would be to keep a synchronized set of
> >>> vcards on the system.
> > 
> > Is this the same thing as Andy suggests? If so, see above
> > 
> >>> Aleix
> 
> To simplify:
> You don't need much of a dbus API, just a directory where the vcards
> go for every plugin within the device config.
How does this simplify syncing to a remote device? How is this more secure 
than dbus? How does this simplify writing a bidirectional adaptor for e.g. 
KAddressBook?

Or is this meant to only ever work from phone to desktop? I for one would 
really like this to work from desktop to phone or laptop too.

Are there more severe security implications than running carddav/ldap? What is 
the threat model?
> 
> Aleix

Thomas