пт, 6 мар. 2020 г. в 08:21, Nicolás Alvarez <[email protected]>: > > El vie., 6 de mar. de 2020 a la(s) 03:41, Martin Flöser > ([email protected]) 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
