Announcement

Collapse
No announcement yet.

Qt 5.13 Might Add QTelemetry For Opt-In Anonymous Data Collection

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Qt 5.13 Might Add QTelemetry For Opt-In Anonymous Data Collection

    Phoronix: Qt 5.13 Might Add QTelemetry For Opt-In Anonymous Data Collection

    The next release of the Qt5 tool-kit might introduce a potentially controversial module to facilitate anonymous data collection of Qt applications...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Since most users produce very poor bug reports, telemetry is undoubtedly a great tool for developers.

    The problem starts when someone read "telemetry" and the "cha-ching" goes on their head, and start to abuse the system.

    Comment


    • #3
      Originally posted by M@GOid View Post
      Since most users produce very poor bug reports, telemetry is undoubtedly a great tool for developers.

      The problem starts when someone read "telemetry" and the "cha-ching" goes on their head, and start to abuse the system.
      Agreed, telemetry is the only way to know for sure what sensible defaults look like. But it doesn't work with opt-in because you're still not getting the whole picture. And if do it opt-out, that doesn't work with privacy. So there.

      Comment


      • #4
        Most call centers or corporations who run desktops have some sort of telemetry hook engaged. While it could be used for opt-in junk at the consumer level, it would have more value for telemetry tool vendors like Aternity or Splunk.

        Comment


        • #5
          Hmm... such a shitty world to live in!
          Instead of fixing real problems, everyone competes on stealing user data, with carefully chosen words like telemetry instead of spyware and saying that is for greater good.
          It's like never ending nightmare which will give the government unlimited power with all these software collecting huge amounts of data.
          I'll wait for more people wake up before it's too late.
          In any case, does Qt finished adding and improving support for Wayland and Vulkan before starting to put this crap in ?

          Comment


          • #6
            Originally posted by bug77 View Post

            Agreed, telemetry is the only way to know for sure what sensible defaults look like. But it doesn't work with opt-in because you're still not getting the whole picture. And if do it opt-out, that doesn't work with privacy. So there.
            Maybe there is a middle ground. If the program watch itself with a internal log, but only offers to send it home in the case of a crash, maybe people find this acceptable.

            Comment


            • #7
              Originally posted by Danny3 View Post
              Hmm... such a shitty world to live in!
              Instead of fixing real problems, everyone competes on stealing user data, with carefully chosen words like telemetry instead of spyware and saying that is for greater good.
              It's like never ending nightmare which will give the government unlimited power with all these software collecting huge amounts of data.
              I'll wait for more people wake up before it's too late.
              In any case, does Qt finished adding and improving support for Wayland and Vulkan before starting to put this crap in ?
              Telemetry can be used for the good.

              A graphics driver update that was recently distributed is causing slowness with webex users and the issue was picked up by an AI instance crunching the telemetry logs.

              Its not all nefarious and evil at work.

              Comment


              • #8
                Originally posted by M@GOid View Post

                Maybe there is a middle ground. If the program watch itself with a internal log, but only offers to send it home in the case of a crash, maybe people find this acceptable.
                Many programs have built-in crash reporting. But that won't tell you when 90% of your users are hiding some UI element when you thought the sensible thing to do was to show it by default. They won't tell you which codec your users use the most so you'll know where to concentrate your efforts either.
                I have a thing for UIs, I've thought about this for quite some time. And I still couldn't find that "middle ground".

                Comment


                • #9
                  I've always thought that privacy is important and we need to protect it, but without it becoming paranoid!

                  Comment


                  • #10
                    In my work, privacy is so important nothing can be allowed to auto-connect and send out data. That said, there is one use of this module I consider acceptable: as something a user facing a bug can turn on, then load a safe "dummy" file to invoke the bug. Example: a QT app I use a lot is the video editor Kdenlive. I also built it from source and report issues. I could not have telemetry active while handling sensitive raw video files, given that in some cases the final cut requires careful review prior to publication. However, after a series of crashes I could create a dummy project, load known safe video files into it, termporarily turn telemetry on, and invoke the bug. I would then need to be able to connect that resulting data dump to the bug report.

                    Ideally I would be able to use the telemetry module debug data to a file (by redirecting output) so I can examine the file, redact anything sensitive (like motherboard information usable to write a malicious custom BIOS), and attach it manually to the bug report. I can do this now with GDB for some problems but GDB is only really useful for all-out crashes. Something like garbled video rendering would be silent in GDB.

                    Those with non-sensitive systems (not encrypted, not handling sensitive files) might find this usable as the core of an automated bug reporting system BUT in my judgement every report should have a "send bug report?" dialog box. Remember that you have to allow not only for the intended recipient of the telemetry but also for anyone watching the source or the destination IP address. For instance, suppose I had pushed a special build of Kdenlive to someone editing video on my behalf, and they were having problems so telemetry was used to send data back to me. If they do not understand it must be used only with safe files, a 3ed party (e.g. the cops as I do protest video) watching my IP address or that of the sender might get dangerous metadata.

                    A consumer might face other risks. For instance, some telcos try to restrict tethering to phones on their plans, but are technically unable to block tethering on "bring you own phone" plans because they don't control the Android builds and are thus connecting phones with tethering enabled. Snarfing copies of any unencrypted telemetry from apps would allow them to compare all app data to a list of apps available for phones, and flag accounts sending data for an app not available on any phone for termination or rate hikes.

                    Comment

                    Working...
                    X