• Let the user enable or disable telemetry per app
• Be transparent about what is being sent
• batch, throttle and schedule transmissions
• deduplicate efforts to collect generic info
Combined with a trusted server to process and relay, we can
@sonny@xerz honesty I don't think neither users nor developers really care for what Flathub considers unsafe, and maybe in part because of such silliness as considering network access unsafe.
I like the idea, but honestly I only care for the ability to turn telemetry on/off, especially if I can make it off by default
KDE has a kuserfeedback library that combines anonymous data points sent at a fixed frequency (same approach that Endless OS's metrics system uses to get a distribution of values without having to identify individual devices), a way to prompt users to complete surveys, and a control panel to select the level of data to contribute (but not per-app).
A prototype might be a portal for the same data model – then you'd get all KDE apps in the new system “for free”.
@sonny And since the model is so similar (at least superficially) I could well imagine converging this with the Endless OS metrics system.
Anyone pursuing this in earnest should also look at other widely-used telemetry systems on the desktop – e.g. is OpenTelemetry used in desktop apps? Does Electron have a thing, whether built-in or widely used? – and figure out how those can be brought into the same fold.
Sadly I don't have the time/resources to work on this…
@sonny but "be transparent about what is sent" is not necessarily a consequence of having a portal. Each data point is a name/event-id and some blob of data - what can be shown to a human without knowledge of the app's particular data points? What stops the app from shoving a machine ID into that blob?
From Inkscape's perspective, I think we would be interested. Stats are very hard. But I'd also like it if it was multi-platform and windows and mac users could submit to the same system.
It would be useful to have the data and perms be a defined standard. Not just an empty json bucket.
Though I'd also like telemetry to include one extra field called "owch", text of no more than 200 chars that the user can populate with whatever their single most important demon is.
We also download assets from wikimedia, openclipart and github (for some science repos)
For installable code extensions, I'm not sure how solvable it is. We promote python over anything else and we expect certain workflows, so it should be possible to sandbox. But hard to download that code at a whim.
Though Inkscape.org for code would be fine. We still check extensions and sign them.
@sonny it sounds like a lot of effort, and I’m unsure about the benefits.
Given the tremendous task (not only in terms of build but also of run), user testing with mockups sounds like an install important step.
It would also be interesting to know how many apps are actively maintained and don't require network access. A biased indicator, but it can help get an order of magnitude of the number of apps concerned.
I'm told KDE has a telemetry API and server that could be reused, at least to play around with the idea.
I think we need more network related portals to cover other use cases currently requiring full network access so it would concern more and more apps in the future.
We can also encourage apps to adopt it regardless because they don't have to build it themselves.
Add comment