Contacts Plugin

[Aleix Pol]

On Sun, Jan 21, 2018 at 6:51 PM, Thomas Posch
<mail.kde.org at online.posch.name> wrote:
> 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?

It's simpler because everything supports vCard.
KAddressBook, Evolution, Outlook, GMail, the N9 mail client that
doesn't exist anymore,...

Aleix