Some challenges for GNOME online accounts
GOA is meant to provide a single sign on system integrating GNOME applications with web-based services. Any application that, for example, wants to access files stored in Google Drive would ordinarily have to ask the user for credentials and log into Drive separately, which gets tiresome for users running a lot of applications. By routing this access through GOA, the GNOME developers hope to simplify the process of using those services. GOA includes a number of different "integration points" for different types of services, including files, email, calendars, contacts, and more.
The "documents" point was used by the Documents application,
which is meant to help users manage their documents. It has suffered,
though, from a lack of both users and developers and lacks basic features;
Michael Catanzaro described it as
"basically just 'bad evince'
". That certainly restricts its
prospects for success; as Ray put it:
"it doesn't stand any chance of adoption unless it
can open files like /usr/bin/evince
". Documents has duly been removed
from the core set of GNOME applications. Since it was the only core
application using the "documents" integration point, that point is now
being removed.
The initial concerns that were raised had to do with the prospects of stranding any other application that might have been using the GOA documents integration point, though no such applications have been named. Bastien Nocera asked:
These concerns are amplified by discussions within the Fedora project about dropping the Evolution email client and deleting the corresponding email integration point from GOA. That seems likely to break other email clients, including Geary, which is just now gaining GOA support. The GNOME project itself is not currently considering removing email support (though Catanzaro did say that it makes no sense in the absence of a core GNOME email application), but even if that removal is confined to Fedora, that would have a significant impact. It would make it much harder for developers to be able to count on the existence of GOA support for their particular application.
Given such concerns, one might wonder why the GNOME developers are considering removing support from GOA. There are a couple of significant forces at play here, one of which being that keeping GOA support working requires constant effort, and few developers are stepping up to do that work. Indeed, as Ray explained, almost nobody is working on it, and that is driving the desire to reduce its scope:
This is why, from my point of view, it's better to have a simpler, more straightforward GOA, because then we can invest whatever little resources we have to keep our SDKs alive.
This problem is compounded, Ray said, by the fact that a lot of
application developers are uninterested in "betting the farm
"
on GOA in the first place. Many key applications have continued to carry
their own web-service integration features.
As it happens, it seems that developers for many of those projects may have
been right in not feeling
entirely welcome to use GOA at all. Early in the discussion,
Allan Day described the question of whether
applications that are not considered to be a part of the GNOME core should
be using GOA at all as "a rather big gray area
". By the time
he posted some "clarifications" on the subject on
February 11, the line taken was rather harder:
There are a couple of reasons behind the desire to restrict access to GOA, but the strongest of those would appear to be that the GNOME project must obtain API keys from service providers to provide its integration features. Those keys come with a long and rapidly changing set of requirements about how they can be used; a failure to follow the rules can cause the keys to be revoked, breaking all users. This happened in 2016, when an evolution-data-server bug caused usage limits to be exceeded. If GNOME is to avoid problems like that in the future, it needs to keep a handle on how its keys are used.
This has led developers to say that non-GNOME-core applications should be shipped with their own API keys. That, of course, breaks the single-sign-on functionality that was the motivation behind the whole thing. One other minor problem with all of this, as Catanzaro pointed out, is that GNOME is open-source software, so its API keys are not exactly secret. He asked:
Nobody had any sort of convincing answer to that question.
Finally, GOA has one other problem that needs to be worked out: in a world where the project is encouraging application developers to ship their wares in the Flatpak format, should those applications have access to GOA? After all, one of the key features in Flatpak is its ability to sandbox applications; giving those applications access to the keys to web-service accounts would rather defeat the purpose. Solving that issue, it seems, is going to require some significant rethinking of how GOA works.
Days's clarifications concluded by saying "We realise that this does
not provide complete clarity around GNOME Online Accounts
". The
project is promising to work on a number of issues, including an actual
definition of what constitutes a "GNOME application", a design for a GOA
that handles sandboxed applications properly, and a new design for GOA in
general. One can imagine that this is not a discussion that will reach a
conclusion anytime soon.
Posted Feb 14, 2019 19:38 UTC (Thu)
by colo (guest, #45564)
[Link] (9 responses)
o) Tight integration with third-party, completely proprietary network services beyond anyone's own control and without any kind of evasive mobility in case of a change or discontinuation, that therefore may break at any time (which _could_ in theory be navigated around by a project depending on such a service, but what is at odds with accepted distribution lifecycles) is a bad idea that will eventually, yet unavoidably, end in pain and disappointed, frustrated users.
o) Having "untrusted" application bundles delivered in some app-store-esque kind of way execute in a magically unbreakable sandbox that prevents all harm is never. gonna. happen.
Once that finally sinks in, maybe the efforts can be re-focussed again to deliver programs, tools and features that are of use and value to the actual, already existing audience for free, libre desktop applications.
Posted Feb 14, 2019 21:43 UTC (Thu)
by dvdeug (guest, #10998)
[Link] (4 responses)
Taking applications and verifying them in some sort of way that you can trust them and prevent all harm is never. gonna. happen. Perfect is never. gonna. happen. Now let's talk about how we're going to provide a variety of programs in a way that minimizes the potential harm from those programs.
The actual, already existing audience for free, libre desktop applications is shrinking. I used Gnumeric in the past, but now I use Google Sheets for my minimal spreadsheeting needs. It's accessible where I need it to be. I go to Wolfram Alpha for many types of calculations I might have opened up bc for or wrote some code. Evolve or die.
Posted Feb 18, 2019 14:06 UTC (Mon)
by nim-nim (subscriber, #34454)
[Link] (3 responses)
And now computing is becoming network-centric. And proprietary cloud services only care about their own desktop frontends. Tough luck. It is easier for Microsoft, to pivot into being a Linux cloud provider, than for free software Desktop projects to admit their windows 95 target is DOA, that Android would not exist without the Google cloud, and that they need to work on what happen on the other side of the network link.
Posted Feb 18, 2019 23:12 UTC (Mon)
by dvdeug (guest, #10998)
[Link] (2 responses)
For one big example of the problem, compare GitHub to GitLab. I'm going to assume they're at feature parity, but I haven't really looked at GitLab. Because setting up my own GitLab on my own computers wouldn't make it available outside my apartment, and setting it up on a cloud service would take a bunch of time, for little value, and I'd lose all the connections GitHub gives me, the ease of access and notice from other people. There are other GitHub-like websites, but GitHub is good enough feature-wise and all the others lack those connections. Since it is a server I don't run or control, the money has got to be coming from somewhere, be it ads (like Google) or proprietary extra-cost add-ons (like GitHub).
I'm pretty sure that the *nix network-centric heritage was not simply going to lead to Android gold; the ideas and models are quite different. Could GNOME and KDE have done better? Surely; but I'm not seeing where they could have amazingly side-stepped Google. Servers aren't free, and that's the hard part of this.
Posted Feb 19, 2019 6:12 UTC (Tue)
by nim-nim (subscriber, #34454)
[Link] (1 responses)
Owncloud built a useful server-to-end-user solution and got funding.
What do they have in common? They all address the kind of non-unixy end user GNOME would like to attract. They all focus on helping users getting things done instead of pretty app demonstrators that are useless in the real life and where half the functionality is disabled for no reason anyone can understand. (who uses GNOME Web in real life?)
GNOME could have chosen to support any one of them, or take the FreedomBox and run with it, or do its own server-side thing, instead it chose things like GOA that would never give it any ability independent from what proprietary cloud owner were ready to concede at any given time.
Posted Mar 9, 2019 11:54 UTC (Sat)
by zarrro (guest, #54749)
[Link]
Posted Feb 14, 2019 22:14 UTC (Thu)
by jccleaver (guest, #127418)
[Link] (3 responses)
There is a traditional audience for open source software and tooling. For computer users.
There is also an audience (a much bigger one) for turnkey solutions. For computer consumers.
Unlike, say 15 or 20 years ago, the mode/median needs of the population of computing hardware users is not interested in -- nor do they have a plausible route to -- programming and utilization of computers in a meaningful way for the open source community. 25 years ago, even closed systems had paths to scripting and user-control of the system: HyperCard springs to mind on the Mac, and AppleScript (a language derivative) and other macro systems provided an onramp to programmer/administrator-level control of a complex piece of hardware and software.
As consumer use of computing systems took off, from the workplace and prosumer environment and game-player or family system to the current era of *mass* smartphone consumption of internet-based walled gardens, the attempt by desktop environments to duplicate the mobile OS environment has doomed itself to failure in pursuit of an audience that doesn't exist.
Mass consumers who want to pick apps from a curated gallery are not interested in the complexities of local administration.
GNOME should avoid impossible features such as these within its core design and allow for simplifications for embedded situations to sit on top of it. Anything else really doesn't seem a tenable position in the long run.
Posted Feb 15, 2019 2:12 UTC (Fri)
by drag (guest, #31333)
[Link]
There are more programmers and developers and all that stuff then there ever was before. They are doing more sophisticated, more interesting, and more useful stuff on a larger scale then ever before. And it's not all high level stuff. There is more going on in digital electronics then ever before and it's much more accessible and being used by individuals and small businesses then ever before. We have more options, more tools, more document, easier access to in-depth information, larger community, more diverse community. Cheaper, better, faster.
It's just that the desktop doesn't have anywhere close to the same level of utility that it did 10-15 years ago. The world has moved on to bigger and better things. If you were in any business and you told everybody you think that it would be a great idea to write a new desktop app in C or C++ they would probably want to see some serious justification for that decision before they would take you seriously. It's kinda lunatic approach to doing things nowadays unless you are writing some 3D game or something like CAD software.
As far as tablets and smart phones.. People are using computers for things other then 'computing'. Widespread proliferation of these devices just reflects that. After all the point of software is not software. The point of computers is not computers. It's that you can do useful things with these things to improve your life and make the world a better place. Having a interface that is convenient to have around when you need them is a improvement. The problem with them is that they become walled gardens and the corporations that control them attempt to use copyright and other IP laws to seize control of user's data and devices to control and monitor them. It's beyond critical that open source and secure alternatives exist for those people who seek them out.
Even in tablets and smartphones open source software is utterly dominate, although layered over with proprietary garbage. Android AOSP is a FLOSS operating system that isn't really alien or that different from a regular Linux distribution anymore and is increasingly compatible with any and all sofware people would care to run on any traditional Linux OS. The number of phones out there a year or older that is capable of running more vanilla Google-free Android is enormous. I am sure that it can be numbered in the millions world-wide. The opportunity is huge.
As far as flatpack goes.. There isn't anything mysterious about their contents. Not any more mysterious then what you have in a install CD or a Deb mirror. If you want to know what is going on all you have to do is look. The first thing I do when I look to use containers for anything is find out the docker file for them and see what is actually going into them. It's actually pretty easy to understand what is going on in most containers if you want.
Which reflects more on the fact that open source software is so completely and utterly dominate at this point that it's not even funny. You may poo-poo containers, but it's containers that are a large part of making this possible. It simply would never work if everybody had to depend on RPMs or Debian releases for their software... it's simply a ineffective approach for many things. (not everything).
I think the biggest problem we are going to see going forward with many important open source software projects is that after 20 or 30 years of continuous development they have reached such a high degree of sophistication that anybody possessing less then 10 years of working with these sorts of projects is not going to be able to make a meaningful contribution. It's a barrier of entry problem.
Posted Feb 15, 2019 17:42 UTC (Fri)
by daniels (subscriber, #16193)
[Link] (1 responses)
System administrators and programmers who can effectively use open-source software (that is: understand the source, should the need to do so arise) are not interested in flatpak application distributions. As a system administrator and programmer who can effectively use open-source software, including understanding the source and/or just writing it in the first place - I am interested in Flatpak application distribution, and have had a huge benefit from Docker-like container systems as well. As have many, many, others who developed those technologies in the first place, develop with those technologies, and also consume the results. If you don't like them, fine, but there's no reason to be condescending about it.
Posted Feb 15, 2019 18:22 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Not true. These are overtly general remarks and easily disproven by even a few personal experiences. Even within a small sample of 6 sysadmins in my team, the vast majority of them are quite interested in Flatpaks. One runs several for random games. Two of them are experimenting with using Flatpak + Fedora Silverblue and so on. If you step back and look at container style app deployments, such interests would extend to a lot more people.
Posted Feb 15, 2019 8:28 UTC (Fri)
by zdzichu (subscriber, #17118)
[Link] (3 responses)
> It has suffered, though, from a lack of both users and developers
That's somewhat different, but quite valid point – why does GNOME spend resources on applications neither users nor developers want?
– Maps
They are kind of apps that you run once, say "ok pretty", but never run for the second time. When I need a map, I'd rather go to maps.google.com and get the best experience, instead of running the Maps app. I see no point in Weather app at all. GNOME Clocks is borderline usable when you have coworkers in different timezones, but https://www.timeanddate.com/worldclock/meeting.html is again more usable and accessible.
GNOME Documents started with a good premise, but turned out to be limited, read-only view of docs.google.com. Where's the value in that?
Posted Feb 15, 2019 10:15 UTC (Fri)
by hadess (subscriber, #24252)
[Link]
GNOME is a volunteer project, it doesn't have a GNOME management pulling people from a project and force them to work on another. People work on what they want.
> They are kind of apps that you run once, say "ok pretty", but never run for the second time.
Filing issues against them for what features you think are missing would be useful.
> GNOME Documents started with a good premise, but turned out to be limited, read-only view of docs.google.com. Where's the value in that?
Google Docs could be edited in GNOME Documents.
Posted Feb 15, 2019 19:37 UTC (Fri)
by mcatanzaro (subscriber, #93033)
[Link]
Honestly that's a broad trend across all of GNOME. We have some high-quality applications, but for the most part quality is lacking compared to that of the desktop itself.
Posted Mar 8, 2019 18:38 UTC (Fri)
by andyc (subscriber, #1130)
[Link]
> They are kind of apps that you run once, say "ok pretty", but never run for the
I do use Weather occasionally., however I quite often fire up Maps to just lookup some place.
> GNOME Clocks is borderline usable
I do find this very useful (and have used similar tools in the past) and have a number of timezones set up in it.
Of course there are reasons why I'd rather use the apps than some website.
Posted Feb 15, 2019 15:01 UTC (Fri)
by Flameeyes (guest, #51238)
[Link] (1 responses)
That doesn't sound like a particularly positive feature to me, even without Flatpak: why would my email client use the same permission as a document browse? What if I want two different apps to have access to a cloud storage but for different folders, that never should be mixed together?
Posted Feb 16, 2019 20:00 UTC (Sat)
by smcv (subscriber, #53363)
[Link]
That's why GOA isn't intended to be used in apps outside GNOME itself (although that wasn't always communicated very well in the past, and there's no technical mechanism to stop unsandboxed third-party apps from using it).
Posted Feb 17, 2019 19:08 UTC (Sun)
by flussence (guest, #85566)
[Link]
“I guess you have to decide if you are a GNOME desktop, an Ubuntu desktop, a OneDrive desktop, a Yahoo desktop, or a Google desktop unfortunately.”
Posted Mar 2, 2019 8:19 UTC (Sat)
by ThinkRob (guest, #64513)
[Link]
True...
...but isn't that pretty much true of any app/OS/software?
Like yeah, your closed-source whatever may not be quite as easy as OSS -- but if there's sufficient motivation someone *will* extract keys/secrets/tokens from your software and use them for unintended and/or nefarious things.
I remember how within days of the iPhone (the original one) having it's first couple FW updates released the jailbreak people had extracted out the Yahoo APIs and were (ab)using them for all sorts of stuff. (Ex: that funky UDP-based push e-mail was kinda neat on non-iPhone devices.)
I guess the main saving grace for GNOME is this: what would extracting a key get you? The ability to do a distributed brute force on some login system? You can already usually do that just pretending to be a browser or any one of a zillion other apps and launching from some PaaS/VM host with a ton of IPs. GNOME doesn't have any special privileges that would make that sort of attack easier.
I'm genuinely curious as to why the key disclosure is a problem -- aside, of course, from the risk of griefers trying to get GNOME banned just for the hell of it.
Some challenges for GNOME online accounts
Some challenges for GNOME online accounts
Some challenges for GNOME online accounts
Some challenges for GNOME online accounts
Some challenges for GNOME online accounts
Matrix build a useful connected solution and got funding and a FOSDEM keynote.
Collabora is webifying Libreoffice and is getting funding.
Some challenges for GNOME online accounts
I find the Gnome approach of mounting OC, instead of syncing a local directory, works much better for my usage.
Some challenges for GNOME online accounts
System administrators and programmers who can effectively use open-source software (that is: understand the source, should the need to do so arise) are not interested in flatpak application distributions.
(I'll leave my thoughts on Devs who point-and-click mystery containers and assume someone upstream knows what they're doing unsaid.)
Some challenges for GNOME online accounts
Some challenges for GNOME online accounts
(I'll leave my thoughts on Devs who point-and-click mystery containers and assume someone upstream knows what they're doing unsaid.)Some challenges for GNOME online accounts
Unneeded applications
And the selection of GNOME applications is lacking in reason. Recently I saw that GNOME ships with small apps lacking a use case:
– Weather
Unneeded applications
Unneeded applications
Unneeded applications
> – Weather
> second time.
Single-sign-on vs siloed access
Single-sign-on vs siloed access
Some challenges for GNOME online accounts
Some challenges for GNOME online accounts