Help with KDE PIM and Google Privacy Policies needed

[Alexander Potashev]

пт, 6 мар. 2020 г. в 08:21, Nicolás Alvarez <nicolas.alvarez at gmail.com>:
>
> El vie., 6 de mar. de 2020 a la(s) 03:41, Martin Flöser
> (mgraesslin at kde.org) escribió:
> > Reading [0] I see "Your use of data obtained via the Restricted Scopes
> > must comply with these requirements:" ... "Only transfer the data to
> > others if necessary to provide or improve user-facing features that are
> > prominent in the requesting application's user interface"
> >
> > And reading the screenshot I think that's the problem. We state in our
> > privacy policy about 3rd party plugins and Akonadi. Especially Akonadi
> > is a "transfer of data to others" and that allows all applications to
> > access the data. If KWin accesses the data it would be in violation of
> > the additional requirements of the requested scope.
>
> If I add my Google account to KDE PIM, it will sync my email and
> calendar events with Akonadi. Third-party apps can then access my
> email and calendar events via Akonadi.

Hi,

Thanks for the constructive discussion!

I'm not an expert, and I only judged by the info from this email
thread and from the linked documents, but tend to agree with Martin.
We should clearly communicate the intent to the end user before
accessing their data.

For now there may be various cases where the user stays unaware about
how our software handles their data. Consider this scenario for
example:
 1. A user installs KMail and e.g. an E-mail notifier Plasma widget on
the same machine,
 2. The user runs KMail and grant access to their Gmail account,
expecting that it will only be used by KMail,
 3. The user enables the E-mail notifier widget. The widget will just
work without asking the user for permission to access their data from
Gmail account. This conflicts with Google’s API Services User Data
Policy.

In our https://community.kde.org/KDE_PIM/Privacy_Policy, the red flag
is clearly "It is possible for any locally running software to
interact with Akonadi and thus access, modify or delete any data
stored there."


Here are two approaches that in my opinion would (at least partially)
resolve the issue:

[Approach #1]. Have all Akonadi clients create and use their own
Google API app IDs/keys. Isolate cached data in Akonadi per app, so
that e.g. an E-mail notifier widget cannot reach through Akonadi API
to access the data downloaded specially for Kmail. It will need to ask
Akonadi IMAP resource to request the same emails again.
This implies huge data duplication in Akonadi in some cases, however
it can probably be deduplicated inside Akonadi to save storage space.

[Approach #2]. Apps still don't need to have their own API keys, just
like today. Add metadata to Akonadi resources about which apps are
"cleared" for data access by the end user. In this above mentioned
scenario:
  - When starting KMail, Akonadi IMAP resource will request Gmail API token,
  - Akonadi will ask the user again if it's OK to hand their Gmail
data over to Kmail,
  - When an Email notifier Plasma widget [1] is enabled, it requests
access to Gmail from Akonadi. Before this access can be granted,
Akonadi asks the user the same question - if it's OK to hand their
Gmail data over to Email notifier Plasma widget. If the user says
"yes", then it may be OK to reuse the same Gmail API key.

Although this second approach still seems to me like walking on thin
ice, I don't find it to be in a direct conflict with Google API
Services User Data Policy and its first part [2] specifically.


Not sure which of the approaches would be more desirable nor easiest
to implement since I'm not familiar with Akonadi internals. I would
suggest that KDEPIM developers first choose an approach, write a
design doc, make a new draft of KDEPIM Privacy Policy and submit for
additional review before putting effort in implementing any of these
changes that might be large-scale.

[1] *(or another software that wants to access the same Gmail account
through Akonadi, e.g. Akonadi Indexing Agent)
[2] https://developers.google.com/terms/api-services-user-data-policy#accurately_represent_your_identity_and_intent


Disclaimer: My personal views, thoughts, and opinions expressed in the
text above belong solely to me, and not necessarily my employer,
organization, committee or other group or individual.

-- 
Alexander Potashev