Re: Clarifications regarding GNOME Online Accounts
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
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
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
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: API stability for Meson configuration options
On Sun, Feb 17, 2019 at 8:55 AM, Sam Thursfield via desktop-devel-list wrote: Do we have a policy for if/when we can do breaking changes to Meson configuration API? If this was a change to the C API, we'd delay it until the next major release (in this case Tracker 3.0). If gnome-build-meta or gnome-continuous use those options, then they need to be updated at the time you make the change. If you touch gnome-build-meta, be sure to release a new tarball before the next scheduled tarball deadline. (And ask Garnacho about tarball problems specific to tracker.) In this particular case, it looks like gnome-build-meta is fine but gnome-continuous will need to be updated to not use the -Ddocs= option. I'd consider avoiding such changes after the .90 release, but there's no strict policy, other than keep GNOME building. Thanks, 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
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: What is the status of developer.gnome.org and help.gnome.org?
On Fri, 2019-02-15 at 20:19 +, Emmanuele Bassi via desktop-devel- list wrote: > Given the state of library-web’s maintenance and resources, I’m > actually > trying to figure out a way to use Gitlab’s CI to build the > documentation > and put it somewhere else; I still have to investigate how to achieve > this > on the GNOME infrastructure. I'd like to switch help.gnome.org to use Pintail. I have a very rough work in progress of such a setup here: https://gitlab.gnome.org/shaunm/help.gnome.org It builds straight from git branches. Tarballs are irrelevant. There's also a group of people wanting to do something else for the developer site. I went to some of their meetings, but haven't had time to keep up. I don't know their status. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What is the status of developer.gnome.org and help.gnome.org?
On Fri, 2019-02-15 at 20:19 +, Emmanuele Bassi via desktop-devel- list wrote: > the switch to Meson for various libraries broke the expectations of > library-web Hi, not only Meson, but also CMake (and eventually anything what doesn't include developer documentation in the release tarballs anymore), as stated here: https://bugzilla.gnome.org/show_bug.cgi?id=785522 which leads to https://gitlab.gnome.org/Infrastructure/Websites/issues/224 I'm mentioning it here just to not fill duplicates of it. Bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
