💡 portal for anonymous telemetry. Hear me out!
Many developers want to have telemetry so that they can learn about how their app is used and how they perform.
It can lead to better software, but it's also a privacy nightmare 😮💨
Currently, apps need to enable full network for it (or more) and users have 0 control over it. This is happening. Right now.
What if there was a way to remove all the negative aspects of telemetry so that we can consider it safe? 🛡️
1/2 🧵
Federico Mena Quintero reshared this.
Sonny
in reply to Sonny • • •With a telemetry portal for apps, we could
• 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
• anonymize
• aggregate
• make public
Worth thinking about, no?
2/2 🧵
Andy Holmes reshared this.
Gary "grim" Kramlich
in reply to Sonny • • •Xerz~! :blobcathearttrans:
in reply to Sonny • • •Sonny
in reply to Xerz~! :blobcathearttrans: • • •@xerz the network permission is not considered safe in Flatpak / Flathub
That's why we have leverage.
Maksym Hazevych
in reply to 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
Sonny
in reply to Maksym Hazevych • • •@mks_h @xerz
This wouldn't be possible if network was considered safe and had no penalty.
It's not silly, it's honest and forward-looking.
It gives the platform leverage and will let us innovate and do what no other platform does.
But I'm not interested in debating this again tbh :)
João Azevedo
in reply to Sonny • • •what is the penalty?
Users not installing it because it show a "potentially" unsafe warning?
@mks_h @xerz
dflxh v0.2 : the bio update
in reply to Sonny • • •Sonny
in reply to dflxh v0.2 : the bio update • • •Will Thompson
in reply to Sonny • • •Interesting idea!
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”.
Will Thompson
in reply to Will Thompson • • •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…
Will Thompson
in reply to Will Thompson • • •Philip Withnall
in reply to Will Thompson • • •Jordan Petridis
in reply to Philip Withnall • • •Sonny
in reply to Jordan Petridis • • •@alatiera @pwithnall @wjt
No expert but I was hoping the aggregation would make fingerprinting or unique identifiers useless.
Also, if there is a server, say administrated by Flathub, we can have terms and conditions at least.
Philip Withnall
in reply to Sonny • • •Sonny
in reply to Will Thompson • • •@wjt
That depends on how the system is designed, right?
From client API to whatever we want to enforce in the terms and conditions.
`about:telemetry` in Firefox is a good example of transparency.
Joel
in reply to Sonny • • •you could even provide users a telemetry id and key per app, so they could access the portal without signing up.
only requiring email sign up if they want an easy way to manage and collate the different apps using it.
Sonny
in reply to Joel • • •@j
By "portal" I meant this https://flatpak.github.io/xdg-desktop-portal/
It's basically standard Linux APIs for apps.
Maybe you understood web portal?
I don't think there should be a signup
XDG Desktop Portal
flatpak.github.ioJoel
in reply to Sonny • • •oh nice
i was thinking more the full spectrum of telemetry sources across apps, websites, devices, etc.
2ndontyfzz
in reply to Sonny • • •I'm unsure it'd provide much privacy improvement. Apps could still exfiltrate any identifiable information, there's no way the "trusted" server can understand and automatically remove those from logs. It would only hide the IP, which can already be done better by a VPN.
But in a similar idea, it'd be cool if Flatpak had a per-app domain whitelist firewall. For eg I'm okay with Blender reaching blender.org, but I don't want a 3rd party Blender addons reaching any other domain.
et konsept fra BAR
in reply to Sonny • • •Seirdy
in reply to Sonny • • •Content warning: Telemetry standards
Like any study: subjects need to opt-in per-study (per measurement per-app), have access to results, and be able to revoke data at any time. There should also be oversight to ensure that research subjects are treated ethically.
This applies to all human research, whether it’s behavioral monitoring (telemetry) or experimentation (A/B testing).
Seirdy
in reply to Seirdy • • •Content warning: Telemetry standards
Seirdy
in reply to Seirdy • • •Content warning: Telemetry standards
Pilum
in reply to Sonny • • •Sure. Absolutely. But the problem remains: how do we trust the server?
Imo the solution needs to involve not *having* to trust the server.
Thib
in reply to 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.
Sonny
in reply to Thib • • •@thibaultamartin
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.
Martin Owens :inkscape:
in reply to Sonny • • •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.
Sonny
in reply to Martin Owens :inkscape: • • •@doctormo thanks for the feedback!
Inkscape was an interesting case study when I was researching use cases for the network permission.
https://github.com/flathub/org.inkscape.Inkscape/blob/3e5cb8a35a113f82a369461fd81e763a47e2db6c/README.md?plain=1#L29
I wanted to ask about extensions. We have Flatpak extensions but they wouldn't be a good fit I believe.
I think we should also have a mechanism/portal to let apps fetch assets.
Perhaps by letting them download from the verified domain? In your case inkscape.org
org.inkscape.Inkscape/README.md at 3e5cb8a35a113f82a369461fd81e763a47e2db6c · flathub/org.inkscape.Inkscape
GitHubMartin Owens :inkscape:
in reply to Sonny • • •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.
GeopJr
in reply to Sonny • • •Sonny
in reply to GeopJr • • •@GeopJr
https://floss.social/@xerz@fedi.xerz.one/112248771936804985
Xerz~! :blobcathearttrans: (@xerz@fedi.xerz.one)
floss.socialGeopJr
in reply to Sonny • • •Sonny
in reply to GeopJr • • •@GeopJr ha got it
I don't know what *the* network portal would do yet and how it would interact with the security rating.
A telemetry portal certainly is *a* network portal.
This is one of the thought that came to mind while thinking about the problem space.
João Azevedo
in reply to Sonny • • •Honest question: can you define "that they can learn about how their app is used"?
I get that devs might want performance information and crash reports, and maybe know on what OS it is running. But I am confused about the: how the app is used part.
I mean, a music player plays audio files. A text editor edits text, a translation app translates text, etc.
fffff
in reply to Sonny • • •research!rsc: Transparent Telemetry
research.swtch.com