4 ms·
> IMHO if you want to collect any information, it should never be anything but opt-in, a conscious decision. Serious (general) question: How do you do that giv
by mananaysiempre 4y ago
> IMHO if you want to collect any information, it should never be anything but opt-in, a conscious decision.
Serious (general) question: How do you do that given a non-technical user population? Debian’s opt-in popcon kind of manages to get a little bit of data from a fairly technical one, but nowhere near enough to estimate a low usage frequency, and it’s the only opt-in program I’m aware of that gets anything usable at all. Given that I’m unwilling to implement an opt-out system, I don’t really see a workable approach here at all.
- JohnFen 4y agoWhat I hear you saying here is that people don't do what you want if you give them the choice, so you lean towards not giving them the choice rather than respecting their wishes. Is my interpretation correct?
- mananaysiempre 4y ago>> I’m unwilling to implement an opt-out system > [Y]ou lean towards not giving them the choice rather than respecting their wishes. > Is my interpretation correct? I don’t think it is, no :) Rather, I’m not sure how to sell, to put it crassly, users on a choice when properly investigating or even being confronted with that choice would delay them seeing the dancing bunnies[1], but that would also, if I have any say about it, improve the bunnies in the future. Does that mean there’s a shade of “I know better” in my problem statement? Of course it does, if I didn’t know better than the average user I’d have no business designing such choices. I don’t think there’s anything wrong about that, better than the average at an activity few practice is not a terribly high bar. Not giving the users a choice or manipulating them into making the one I think is right would absolutely be wrong, though. Basically, how do I make the user think, how do I give them the appropriate data to do so, and how do I deal with the obvious contradiction of that goal with principles of good design[2]? The potential benefits to the software and (thereby) the users are too much to give up without even asking those questions. (See nearby comment for extended discussion.) [1] https://blog.codinghorror.com/the-dancing-bunnies-problem/ https://blog.codinghorror.com/the-dancing-bunnies-problem/ [2] https://sensible.com/dont-make-me-think/ https://sensible.com/dont-make-me-think/
- JohnFen 4y agoThank you for the thoughtful response. We disagree on much, but I respect your opinion nonetheless. > Not giving the users a choice or manipulating them into making the one I think is right would absolutely be wrong, though. I'll pull out just this point, though, to perhaps illustrate how different our worldviews are. I consider opt-out to be a manipulative approach.
- mananaysiempre 4y ago> I consider opt-out to be a manipulative approach. So do I, which is why I wrote I’m unwilling to implement it :) The original (and, to be clear, purely theoretical) point was, opt-out is too manipulative while opt-in is likely useless. Ah shoot. Did you take that to mean that I’m unwilling to implement an off switch at all? That wasn’t it, sorry for the confusion.
- JohnFen 4y agoPerhaps we aren't so far apart after all. The struggle is real. As a developer, more data is obviously desirable and can make development much easier. I just can't think of a way to do telemetry that, if I were a user, I would accept. And I don't want to produce software that I wouldn't personally use. I just don't know how to have my cake and eat it too.
- philosopher1234 4y agoAs a developer your entire purpose is to make decisions for users. "Where should this service live, how should security work, how should I increment their billed service usage, when should I shut down their vm..." I don't think the issue here is making decisions for users and not giving them a choice. 99.999% of software does not have a flag to change it. The issue seems to be more about the precise nature of this specific feature.
- JohnFen 4y ago
- musicale 4y ago> people don't do what you want if you give them the choice, so you lean towards not giving them the choice rather than respecting their wishes This nicely summarizes a very popular approach to telemetry – and to a variety of user-hostile behaviors. Web sites (for example) seem to have mastered the "fight against user preferences" approach, trying to play video when autoplay is blocked, using javascript modals since pop-up windows are blocked, fighting ad blockers, ignoring "do not track", etc.. If users are given any choice, usually it's a difficult opt-out process, which is more effective precisely because it makes it harder for users to make the choice that you don't want them to make, even if it isn't their actual preference. For an extreme example, see Facebook's (anti) privacy settings. Commonly used dark patterns further amplify user manipulation.
- rom-antics 4y agoAsk for consent during setup or on first run. Syncthing does this and they get plenty of usable data. It's even public: https://data.syncthing.net/ https://data.syncthing.net/
- autoexec 4y agoHow many people are installing and using open source software but couldn't understand a pop-up explaining what data is collected and asking if they'd like to submit it? Is the non-technical nature of the user the problem or is it just that when you have an opt-in option most people make the choice to opt-out? That's the thing about respecting users by giving them choice, they get to say no. If they mostly say no, and you don't get enough data, that's the will of your users and therefore not really a problem.
- mananaysiempre 4y ago> How many people are installing and using open source software but couldn't understand a pop-up explaining what data is collected and asking if they'd like to submit it? I’ve taught probability theory using randomized response[1] as an exercise problem, and while people can understand it given time and motivation, it’s not immediately obvious. So I’m not exactly hopeful that a prospective Audacity, Blender, or even Free Pascal user (to take an arbitrary set of examples) would get what I mean if I say “I’m collecting no more than 10 bits of information about you using RAPPOR”[2], and I’m not willing to engage in comforting bullshit such as “all collected data is anonymous”, as I’ve been all too close to situations where the difference between the two might be one between freedom and prison. > Is the non-technical nature of the user the problem or is it just that when you have an opt-in option most people make the choice to opt-out? Both, because confirmation dialogs, especially privacy-related ones, have been thoroughly poisoned in users’ minds. But confirmation of obscure actions, however beneficial their consequences, is problematic in general—if I go on the street and ask people if they’d like caffeine in their tea or ascorbic acid in their apples, I expect (but have not checked) that the majority will say no, nevermind that both are normally there and intrinsic to the experience. (The possibility of meaningful consent from a non-specialist is the subject of much discussion and few good answers in med school, or so I’ve heard.) Whether the ultimate answer is to grant or deny permission, I’m not sure I can present the question in a way that will actually have it made on the basis of merit and not on “scary permission dialog, better say no” or “yes, yes, just let me through to my dancing bunnies[3]” or “yes, if I say no the installer will just tell me to GTFO”. (In that respect the “Send crash report to vendor” button is unexpectedly good, because you’re not actually interposing yourself between the user and any prospective bunnies. But personally I don’t like to spend time and effort in order to send “feedback” into an unmarked hole where I’ve no idea if anybody will ever look at it. From that point of view, it is background data collection that’s unexpectedly good.) And even if, for the purposes of this question, it would be best if people took the time to learn the necessary maths, computing, and operational security to make an informed choice, in reality I’m not sure that’s the best thing they can spend their life on. So it may be the answer is that you simply can’t do telemetry well for the social reason that users won’t ever end up making an informed choice, or that the well has been poisoned so thoroughly that the rational choice is to reject everything. It’s just that I know that it’s basically possible in a technical sense, so I don’t want to give up that easily. [1] https://en.wikipedia.org/wiki/Randomized_response https://en.wikipedia.org/wiki/Randomized_response [2] https://blog.cryptographyengineering.com/2016/06/15/what-is-differential-privacy/ https://blog.cryptographyengineering.com/2016/06/15/what-is-... [3] https://blog.codinghorror.com/the-dancing-bunnies-problem/ https://blog.codinghorror.com/the-dancing-bunnies-problem/
- cowl 4y agoFirst, we are talking about Development tools, so not non-technical population. Second, if Opt-in is considered difficult for the population, what does it say about the opt-out? Opt-out is always, no exception, more difficult than opt-in.
- mananaysiempre 4y agoSeems like you also[1] didn’t read the above the way I intended. I meant that I find explicit opt-out (as opposed to explicit opt-in) manipulative so I don’t want to implement it, not that I oppose having the ability to opt out at all. The difficulty, though, lies not (entirely) with the default position of the toggle, the difficulty lies with making the user think about the question which is not relevant to their immediate task and which in any case they may not have the theoretical tools or time to evaluate properly. The default position of the toggle (if “off”, as I believe it should be) matters only because an opt-in process means you either confront the user with irrelevant questions on first launch or get essentially no data. (I called this out as a a “general” question because I meant for it to apply not only to the Go toolchain, but to general-use software like Firefox or niche but non-programmer-oriented software like Audacity.) The systemwide daemon proposed elsethread[2] would solve this nicely as well, but I have to admit that I’ve dismissed it from my thought process more than once before, because I didn’t think we were going to get one with any reasonable usage on any platform. Now that I’ve seen it put in writing, maybe it does deserve to be considered. [1] https://news.ycombinator.com/item?id=34716342 https://news.ycombinator.com/item?id=34716342 [2] https://news.ycombinator.com/item?id=34709836 https://news.ycombinator.com/item?id=34709836