Help with KDE PIM and Google Privacy Policies needed
Ingo Klöcker
kloecker at kde.org
Sun Mar 22 20:23:46 GMT 2020
On Sonntag, 22. März 2020 15:28:55 CET Alexander Potashev wrote:
> 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.
Quite frankly, that's exactly what I expect from an integrated desktop. I have
the impression that Google’s API Services User Data Policy makes assumptions
that are true on Android, but that fail completely on any desktop computer
where any application can access the data of any other application running in
the same user account.
> 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."
Simply drop "interact with Akonadi and thus" from this policy and you get the
reality on desktop computer systems. Akonadi isn't needed. The data files can
be accessed, modified and deleted by any application without the help of
Akonadi.
BTW, the same is true for Thunderbird's data. And for Google Chrome's data.
And the data for any other application running in user space. (Probably unless
SELinux or AppArmor is enforced in user space.) The same is also true on
Windows and macOS. IOW, I don't see a problem that can be solved technically
(without reinventing data handling on desktop systems). It's purely a policy
issue. So, let's simply delete the above "red flag" from our policy. Why
mention something which is obvious for any application storing data locally on
a desktop computer.
> 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.
The whole point of Akonadi is to have a central hub for all PIM data to avoid
unnecessary duplication.
Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20200322/f59db781/attachment.sig>
More information about the kde-community
mailing list