Re: Clarifications regarding GNOME Online Accounts

[Debarshi Ray]

Hey Michael,

Sorry, I have been a bit behind with email.

On Mon, Feb 18, 2019 at 01:12:29AM +1100, Michael Gratton wrote:
> On Sun, 17 Feb, 2019 at 4:58 AM, Michael Terry  wrote:
> > Thank you for the clarification! As someone that had been confused 
> > about the intent and ended up relying on GOA in my third party app, 
> > it???s nice to see the intention spelled out so clearly.
> 
> Seconded!
> 
> Also, Debarshi, sorry for jumping down your thread in that other thread.

It's ok; no problem. I can totally understand why you might have felt
the way you did. Thank you for your efforts on Geary!

Cheers,
Rishi
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[makepost]

Every user has to indeed obtain their personal key, it's the only way to remain 
free software with reproducible builds while keeping the feature. Simplenote 
for one example is an open source app that can't get accepted in F-Droid 
because the data synchronization platform enforces the developer to keep their 
key private. GNOME will be better off taking the initiative in maximizing this 
issue coverage in publications targeted at desktop users, before updating the 
implementation. Maybe releasing a patch that visibly deprecates the current 
use, publishing tutorials on getting the keys, and emphasizing that the 
inconvenience is caused by a requirement from Google. If you're familiar with 
imageboard extension userscripts, getting own keys is what users have needed to 
do for years to prefetch YouTube metadata for example, and because of the 
origin of this requirement explained right next to the input field, users 
understand that the developer isn't the one to blame.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[Adrian Perez de Castro]

Hi,

On Mon, 18 Feb 2019 09:52:54 -0600, mcatanz...@gnome.org wrote:
> On Sun, Feb 17, 2019 at 7:20 AM, Sam Thursfield  
> wrote:
>
> [...]
>
> > 3. continue distributing a "GNOME key" with the source code, and hope 
> > that Google don't mind
> 
> I suggest we don't continue to willfully violate Google's terms of 
> service now that the issue has been brought to our attention. The only 
> reasonable option seems to be to shut down our Google integration. Not 
> just from g-o-a, but also the Safe Browsing support in Epiphany.

At least in the case of Safe Browsing, I think it would make more sense to
figure out what Firefox, Vivaldi, or even *Chromium* are doing, or at least
contact someone inside Google.

Also, looking at [1] I can see how there can be options which are not “throw
grenade, run away, burn feature”. One that immediately popped into my mind
would be to store the complete database and use the update API to keep it
up-to-date; then expose it as a service ran by GNOME (even with the same REST
API as Google does) [2]. Only the machine which fetches updates needs to have
the actual API key used to contact Google's service.

On the other hand, knowing that using the Safe Browsing service mandates
adding a cookie [3], one could make a case for either removing the support,
or at least not using Google's service 樂

Cheers,


-Adrián

---
[1] https://developers.google.com/safe-browsing/v4/
[2] Though something like this would need some clarification on what is the
license of the database
[3] https://ashkansoltani.org/2012/02/25/cookies-from-nowhere/


pgpr6qgi_TavQ.pgp
Description: PGP signature
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[Allan Day]

On Mon, 18 Feb 2019 at 15:53,  wrote:
...
> I suggest we don't continue to willfully violate Google's terms of
> service now that the issue has been brought to our attention. The only
> reasonable option seems to be to shut down our Google integration. Not
> just from g-o-a, but also the Safe Browsing support in Epiphany.

I don't think it's a good idea to speculate about terms of service
like this (nor is it a great idea to discuss legal issues on a public
mailing list!) There may well be grey areas involved, and it's
probably best to get legal advice.

Until we know more, let's not throw dramatic suggestions around. The
original post in this thread still stands.

Allan
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[Neil McGovern]

On Mon, 2019-02-18 at 09:52 -0600, mcatanz...@gnome.org wrote:
> On Sun, Feb 17, 2019 at 7:20 AM, Sam Thursfield  
> wrote:
> > 3. continue distributing a "GNOME key" with the source code, and
> > hope 
> > that Google don't mind
> 
> I suggest we don't continue to willfully violate Google's terms of 
> service now that the issue has been brought to our attention. The
> only 
> reasonable option seems to be to shut down our Google integration.
> Not 
> just from g-o-a, but also the Safe Browsing support in Epiphany.
> 

Hi Michael,

I think first, I'll reach out to Google folks to see if this can be
adjusted. I suspect it's an oversight - a lot of the issues that are
being brought up seem to infer that this is being thought of as a
webapp centric use, rather than how we do it natively.

Neil
-- 
Neil McGovern
Executive Director, The GNOME Foundation

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[mcatanzaro]

On Sun, Feb 17, 2019 at 7:20 AM, Sam Thursfield  
wrote:
1. require every user of the software to contact Google and obtain 
their own client ID, which they provide at runtime to any desktop 
software that needs to interact with Google APIs at


Ha ha.

2. require distributors and people who build their own software to 
contact Google and obtain a client ID, which they provide at build 
time


We could require that our distributors provide their own API keys, but 
they're still going to be embedded in the public (open source) build 
definitions (RPM, deb, whatever) so that fails.


3. continue distributing a "GNOME key" with the source code, and hope 
that Google don't mind


I suggest we don't continue to willfully violate Google's terms of 
service now that the issue has been brought to our attention. The only 
reasonable option seems to be to shut down our Google integration. Not 
just from g-o-a, but also the Safe Browsing support in Epiphany.


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[Bastien Nocera]

> On 17 Feb 2019, at 04:04, mcatanz...@gnome.org wrote:
> 
>> On Sat, Feb 16, 2019 at 2:57 PM, Nathan Graule via desktop-devel-list 
>>  wrote:
>> A solution would be for distribution package maintainers to use the
>> binary tarball as a base instead of sources - this way the build can be
>> done with secrets (ie. using GitLab CI and environment variable
>> secrets) and sent to distributions for packaging. This certainly puts
>> GNOME in a unique position in the landscape, though it allows for GNOME
>> to control the build process in such a way that build secrets become
>> possible.
>> Though if this is the way it goes, be sure to be prepared for all the
>> "GNOME forbids people to build their software stack" headlines,
>> followed by a "actually the reason is that they needed to handle
>> secrets in their builds in order to support client keys for the various
>> integrations in the software" in the third paragraph.
> 
> Well yeah... but distros will never allow that.

It’s also against the GPL (and the LGPL, depending on where the secrets gets 
stored)

> 
> Michael
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[Bastien Nocera]

> On 17 Feb 2019, at 18:18, Alexandre Franke  wrote:
> 
> Hi,
> 
>> On Mon, Feb 11, 2019 at 4:46 PM Allan Day  wrote:
>> The “documents” source type is primarily used by GNOME Documents to
>> access Google Drive. […]
>> GNOME Documents is able to use the “files” source type as an
>> alternative to the documents type, and can be converted so that it can
>> continue to access Google Drive
>> 
>> The “documents” source type is also used by GNOME Documents to access
>> Microsoft OneDrive, and there is no replacement planned for this.
> 
> The "documents" source type is also used by GNOME Documents to access
> NextCloud, isn’t it? What is the future of that?

The same as for the Google accounts, as written in the gnome-documents issue in 
the original mail:
https://gitlab.gnome.org/GNOME/gnome-documents/issues/34

> 
> -- 
> Alexandre Franke
> GNOME Hacker
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[Alexandre Franke]

Hi,

On Mon, Feb 11, 2019 at 4:46 PM Allan Day  wrote:
> The “documents” source type is primarily used by GNOME Documents to
> access Google Drive. […]
> GNOME Documents is able to use the “files” source type as an
> alternative to the documents type, and can be converted so that it can
> continue to access Google Drive
>
> The “documents” source type is also used by GNOME Documents to access
> Microsoft OneDrive, and there is no replacement planned for this.

The "documents" source type is also used by GNOME Documents to access
NextCloud, isn’t it? What is the future of that?

-- 
Alexandre Franke
GNOME Hacker
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[Michael Gratton]

On Sun, 17 Feb, 2019 at 4:58 AM, Michael Terry  wrote:
Thank you for the clarification! As someone that had been confused 
about the intent and ended up relying on GOA in my third party app, 
it’s nice to see the intention spelled out so clearly.


Seconded!

Also, Debarshi, sorry for jumping down your thread in that other thread.

//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[Sam Thursfield via desktop-devel-list]

On Sat, Feb 16, 2019 at 7:58 PM  wrote:

> On Sat, Feb 16, 2019 at 11:58 AM, Michael Terry 
> wrote:
> > “Developer credentials (such as passwords, keys, and client IDs)
> > are intended to be used by you and identify your API Client. You will
> > keep your credentials confidential and make reasonable efforts to
> > prevent and discourage other API Clients from using your credentials.
> > Developer credentials may not be embedded in open source projects.”
>
> It's not clear to me how g-o-a can continue to exist, then. Also,
> Epiphany's Safe Browsing support. (How do Firefox and Chromium make
> this work?)
>

I don't think any software can meet Google's requirements, if the binaries
are distributed to end users. If you can run the program on your computer,
you can use a debugger to extract the "secret" key. This model only makes
sense for webapps and other programs which users don't run on their own
computer.

There are several options:

1. require every user of the software to contact Google and obtain their
own client ID, which they provide at runtime to any desktop software that
needs to interact with Google APIs at
2. require distributors and people who build their own software to contact
Google and obtain a client ID, which they provide at build time
3. continue distributing a "GNOME key" with the source code, and hope that
Google don't mind

(1) puts a burden on end-users, who have to visit
https://console.cloud.google.com/ and navigate a non trivial process to
obtain a key (or not use Google services).  (2) puts the burden on
distributors.  Are there other options?

Sam
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[mcatanzaro]

On Sat, Feb 16, 2019 at 2:57 PM, Nathan Graule via desktop-devel-list 
 wrote:

A solution would be for distribution package maintainers to use the
binary tarball as a base instead of sources - this way the build can 
be

done with secrets (ie. using GitLab CI and environment variable
secrets) and sent to distributions for packaging. This certainly puts
GNOME in a unique position in the landscape, though it allows for 
GNOME

to control the build process in such a way that build secrets become
possible.

Though if this is the way it goes, be sure to be prepared for all the
"GNOME forbids people to build their software stack" headlines,
followed by a "actually the reason is that they needed to handle
secrets in their builds in order to support client keys for the 
various

integrations in the software" in the third paragraph.


Well yeah... but distros will never allow that.

Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[Nathan Graule via desktop-devel-list]

A solution would be for distribution package maintainers to use the
binary tarball as a base instead of sources - this way the build can be
done with secrets (ie. using GitLab CI and environment variable
secrets) and sent to distributions for packaging. This certainly puts
GNOME in a unique position in the landscape, though it allows for GNOME
to control the build process in such a way that build secrets become
possible.

Though if this is the way it goes, be sure to be prepared for all the
"GNOME forbids people to build their software stack" headlines,
followed by a "actually the reason is that they needed to handle
secrets in their builds in order to support client keys for the various
integrations in the software" in the third paragraph.

Le samedi 16 février 2019 à 13:06 -0600, mcatanz...@gnome.org a écrit :
> On Sat, Feb 16, 2019 at 12:57 PM, mcatanz...@gnome.org wrote:
> > It's not clear to me how g-o-a can continue to exist, then. Also, 
> > Epiphany's Safe Browsing support. (How do Firefox and Chromium
> > make 
> > this work?)
> 
> Turns out it's a new restriction that took effect on January 16,
> 2019. 
> So probably we've only been in violation for one month now. (You can 
> see the previous version of the terms of use are from 2011 and do
> not 
> include that requirement.)
> 
> Anyway, we can't have secrets in the build, so we don't have a lot
> of 
> options. Maybe not any options. At least, I don't see any.
> 
> Michael
> 
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[mcatanzaro]

On Sat, Feb 16, 2019 at 12:57 PM, mcatanz...@gnome.org wrote:
It's not clear to me how g-o-a can continue to exist, then. Also, 
Epiphany's Safe Browsing support. (How do Firefox and Chromium make 
this work?)


Turns out it's a new restriction that took effect on January 16, 2019. 
So probably we've only been in violation for one month now. (You can 
see the previous version of the terms of use are from 2011 and do not 
include that requirement.)


Anyway, we can't have secrets in the build, so we don't have a lot of 
options. Maybe not any options. At least, I don't see any.


Michael

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[mcatanzaro]

On Sat, Feb 16, 2019 at 11:58 AM, Michael Terry  
wrote:
“Developer credentials (such as passwords, keys, and client IDs) 
are intended to be used by you and identify your API Client. You will 
keep your credentials confidential and make reasonable efforts to 
prevent and discourage other API Clients from using your credentials. 
Developer credentials may not be embedded in open source projects.”


It's not clear to me how g-o-a can continue to exist, then. Also, 
Epiphany's Safe Browsing support. (How do Firefox and Chromium make 
this work?)


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Clarifications regarding GNOME Online Accounts

[Michael Terry]

Thank you for the clarification! As someone that had been confused about the 
intent and ended up relying on GOA in my third party app, it’s nice to see the 
intention spelled out so clearly.

I just wanted to mention an interesting challenge in having open source apps 
handle this themselves. Let’s take Google as an example. According to their 
developer terms of service [1]:

“Developer credentials (such as passwords, keys, and client IDs) are intended 
to be used by you and identify your API Client. You will keep your credentials 
confidential and make reasonable efforts to prevent and discourage other API 
Clients from using your credentials. Developer credentials may not be embedded 
in open source projects.”

So in order for an open source project to access Google APIs, it would want 
build secrets. An interesting argument for flatpaks and snaps, where you could 
have those (as long as you don’t use a public builder).



Unfortunately, distros do not typically support build secrets. I’m not sure 
what to do in those cases. (And if a distro did support them, would they use 
their own API keys or act as a trusted handler for maintainers’ keys?)

GOA currently just embeds the API secret anyway, presumably because the 
realistic alternative is just not supporting Google. For my part, I’m not sure 
what to do. Short term, I’ll probably just keep coasting on GOA’s loose 
approach.

[1] https://developers.google.com/terms/___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Clarifications regarding GNOME Online Accounts

[Allan Day]

Hi all,

Recently there has been quite a lot of debate on this mailing list
about GNOME Online Accounts. Debarshi (the Online Accounts maintainer)
and I wanted to clear up any confusion that might have resulted from
that discussion, and clarify exactly what the situation is with Online
Accounts today, as well as what is being planned for the future.

Right now, there is only one change planned for Online Accounts. This
is the removal of the “documents” source type, which is being planned
for GNOME 3.34 (due for release in September 2019). As far as we are
aware, the only application that will be affected by this change is
GNOME Documents.

The “documents” source type is primarily used by GNOME Documents to
access Google Drive. It is one of two methods through which Google
Drive can be accessed. The other is the “files” source type, which is
the more widely used of the two, and which is going to continue to be
supported.

GNOME Documents is able to use the “files” source type as an
alternative to the documents type, and can be converted so that it can
continue to access Google Drive [1].

The “documents” source type is also used by GNOME Documents to access
Microsoft OneDrive, and there is no replacement planned for this.
However, the existing OneDrive support isn’t in fantastic shape (it
uses of an old API and has only received very minimal maintenance), so
we only see this as a minor regression..

There are no plans to retire any of the other source types.

That’s the main substance of what has been proposed recently: there is
one proposed change for GNOME 3.34, which we think will only affect a
single application.

The other aspect of GNOME Online Accounts that has been discussed is
which applications it can be used by. Strictly speaking, GNOME Online
Accounts has only ever been intended for use by GNOME applications.
The reason for this is simple: any app using GNOME Online Accounts
uses GNOME’s API keys to access online services. In order to ensure
that those keys continue to work, we have to conform to service
providers’ terms and conditions, and that means restricting access to
only our own software.

If this is news to you, then we are genuinely sorry. Effort was put
into communicating the role of GNOME Online Accounts (it’s documented
on the wiki [2], and there has been a blog post [3], and we’ve tried
to have conversations with developers about it when necessary), but
this clearly wasn’t enough, and we should have done a better job.
We’re going to add details to the API docs so the guidelines are
better advertised in the future [4].

We also want to emphasise that there are no plans to enforce the
existing policy around which apps can use GNOME Online Accounts. As
far as we are concerned, GNOME Online Accounts will continue to
function as it has done since it was first introduced.

If your application already uses GNOME Online Accounts, it can
continue to do so. If you are currently in the process of adding
Online Accounts support to an application, or are interested in adding
it, then you can continue to work on it, although we would encourage
you to get in touch with Debarshi, if you haven’t already.

We realise that this does not provide complete clarity around GNOME
Online Accounts, and this is something that we will work towards
during the next development cycle (3.33.x). Having discussed this,
we’ve identified three things that will be needed:

 - A clear framework for defining “GNOME software”. This isn’t
something we can provide ourselves, but we understand that the GNOME
Foundation is working on it.
 - A technical design for managing access to online accounts,
particularly for sandboxed applications.
 - An updated design for the Online Accounts service, which will
follow on from an evaluation of potential architectures [5].

If anyone wants to participate in these lines of enquiry, you’d be very welcome.

Once we have a proposal we’ll present it for feedback and discussion.
If new arrangements do come into effect, there will be plenty of
advance notice, and we’ll do our best to provide migration paths
should they be necessary.

We hope that this helps to clarify where we are today, and we hope
that it goes some way to addressing concerns that people might have.
We’re happy to answer any questions, either here or privately.

Many thanks,

Allan
-- 
[1] https://gitlab.gnome.org/GNOME/gnome-documents/issues/34
[2] https://wiki.gnome.org/Projects/GnomeOnlineAccounts/Goals/
[3] https://debarshiray.wordpress.com/2012/10/06/goa-why-it-is-the-way-it-is/
[4] https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/44
[5] https://wiki.gnome.org/Design/OS/OnlineAccounts/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list