If I create a OSS app with analytics to detect & log crashes with feature use, is it a bad practice? I think analytics is really helpful in finding which features are worth developing & which bugs needs to be solved first.

  • Jimbabwe@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    All depends on what you collect, how it’s stored, how transparent you are about it, and how easy it is to opt out of. It can definitely be done well.

  • jonne@infosec.pub
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    6 months ago

    Generally people make a huge issue out of something like that (some will even call it spyware, etc).

    I think the best approach is to ask the actual community of users what they’re ok with before you start. You probably want to make sure it’s opt-in as opposed to opt-out, and be very clear about what information you do and don’t collect, and make sure it’s stored securely.

    • Max-P@lemmy.max-p.me
      link
      fedilink
      arrow-up
      0
      ·
      6 months ago

      It’s not even always necessarily about trust, but risk management as well. I’ve definitely coded a crash handler that exposed my database credentials in it. There’s also the network aspect of it: your ISP/job/coffee shop can see the DNS request and TLS server name from the telemetry ping. That can be used to track you, or maybe you trigger some firewall alarm at work because of the ping.

      We’ve kind of just started accepting that most apps will phone home and that there’s constantly some chatter on the network from all those apps. But if you actually start looking at what all your devices and apps are doing in the background with say, a PiHole, it’s pretty shocking.

      I’m not that paranoid and would certainly accept some level of telemetry if asked nicely. “Hey I’m a small dev, I appreciate receiving detailed crash reports to make the app better”. And as a developer, users might be willing to offer way more than what would be reasonable to do in the background. I might even agree to submit a screenshot on crash, but if and only if I’ve been asked before and told what it’s used for, and I get the option to disagree if I’m going to be handling private information and don’t want to risk my data be part of a stack trace.

  • thejevans@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    I will not use software that has analytics that I have to opt out of if there is an alternative that has analytics off by default with the ability to opt-in.

    The psychology surrounding opt-out vs opt-in is very well understood, and choosing to include analytics with an opt-out structure is taking advantage of people to make development potentially easier. Not cool.

  • /home/pineapplelover@lemm.ee
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    For foss apps, I mostly allow analytics to track to help the dev out more. Complete 180 for any big tech since whenever they ask for it, they sell that information to the highest bidder.

  • rufus@discuss.tchncs.de
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    6 months ago

    Many people who deliberately choose open source, are also into privacy. I’m not sure what people like. But you’ll definitely face some rejection by people like me. I like to file bugreports myself. I get my apps from F-Droid and they usually strip those telemetry libraries from the source. But for people who use Obtanium, it’ll work. I think there is a good share of users who are fine with crashreports. Maybe the majority. You could make the app ask for confirmation before sending the report. Or offer two variants of the app, one normal and one without. Or let people like F-Droid offer the latter.

    If it’s more than crash reports, I think it should be opt-in rather than opt-out.

  • dont_lemmee_down@lemm.ee
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    I think if you use your own Matomo instance I’m way more ok with it, than if you include google.

    If your app could also be used by people from the EU, you have to be GDPR complaiant as IP adresses are considered personal information. The question if crash reports are necessary (in the sense of GDPR Art. 6) hasn’t been decided yet AFAIK.

  • ResoluteCatnap@lemmy.ml
    link
    fedilink
    English
    arrow-up
    0
    ·
    6 months ago

    Do not collect more data than you need. If you need IP for some reason then that needs to be relevant. Is your app geographically based, for instance? And does the location or IP impact how the app works?

    Beyond that, if you’re collecting personal or sensitive data it should be opt-in from a privacy focused perspective.

  • kbal@fedia.io
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    It is opt-out

    Yeah, you are doing it wrong. As I am guessing you already know, even if you haven’t fully admitted it to yourself yet. All telemetry should be opt-in.

  • SheeEttin@programming.dev
    link
    fedilink
    English
    arrow-up
    0
    ·
    6 months ago

    This doesn’t really have anything to do with open source software. It’s more of a privacy topic. You can harvest as much data as you want and still be GPL.

  • digdilem@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    It takes years to build a good reputation in OSS, and only one dumb thing (like opt-out of personal data) to ruin it.

    (Yes, IPs may be considered personal data in that they can be used to identify individuals, and so subject to the GDPR and, potentially, the very high fines associated with that. Unless you’re evil, don’t collect any personal or identifying data unless you absolutely have to, and very triple sure the user knows what you’re sending and why)

  • tbk@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    6 months ago

    I would view it as basically a research ethics question, as in you owe the participants of your study to be made fully aware about what you are collecting and why. Giving them the ability to remove their analytics seems obvious as well.