Most apps are opt-out though, the checkboxes are already checked and a message shown. I agree that it would be easier to just enter an option on the command line instead of typing the environment variable option.
IMO, this is the key problem. I have no issue with optional telemetry, but there should be a bright line here: all telemetry should be opt-in. If necessary, by law. It should not become standard practice for applications to send data without explicit consent.
- If you have to opt in, most people won't bother as it's not of direct benefit to them (even though overall it's beneficial to the community the more people who do opt in).
- If you have to opt out, people will complain even where the option's made explicitly clear (i.e. where it's not an attempt at being devious / a deliberate dark pattern).
Admittedly then people complain that they have to make a choice / can't just install-and-go... :/.
Can any dev out there give me a good use-case aside from forcing someone to check something, and should nullable booleans mostly make sense on front-end as opposed to back-end code? How does a GUI define something is nullable, if a user has not selected it but it's unselected by default.. I find it all a bit confusing...
Radio buttons come closer, but most UI widget libraries provide no way to select none of a radio group once one has been selected. So you can have a radio button each for true and false, and default to no value (i.e. neither selected), but the user can't change her mind and go back to no value.
Sometimes that's okay, as when no value is invalid or meaningless in the context of the form. When it's not, the best solution I have is a select box with three options; three radio buttons in a group would work too from a semantic perspective, but necessitate a probably confusing label on the no-valued one, where a blank option in a select box is much likelier to make intuitive sense to the user, especially if it's the default.
For required fields, either works. With the select box, making the no-valued option default requires the user to interact with the field, and the same holds for a radio button pair that has no button selected by default. In either case, if the field's value is null rather than false, you know no selection was made and can complain accordingly.
Windows developers might disagree, since Windows 95 checkboxes have had three states (on/off/mixed, or checked/unchecked/filled out), and the third state is used in a lot of places by Windows (though usually to mean that some subitems are on and some are off).
Another example is an ORM system. A data entity could be initialized from an existing database record, or it could be blank. Each property of the data entity could be initialized or not, depending on the SQL query that was used to initialize it. For fields that are non-nullable in the database, you can compare two entities for the same record to determine if fields have been updated or just weren't initialized. That lets you perform database updates only when necessary, and prevents accidentally deleting information.
One of my clients has a database flag field that I needed to use to determine whether or not to show something on their website. Should be a simple boolean field, I thought. Nope; their field can contain one of half a dozen character codes, none of which are Y or N. So you're right; I created an enum to represent the allowed codes and map them to meaningful names, and then I had to create a second boolean property to contain the business logic that decides whether or not to do the display based on the various codes.
That being said, I challenge other developers on my team to make sure they have a very good reason for using a nullable boolean. Sloppily using nullable booleans when not needed causes queries and data understanding to be a mess (i.e. what does IsActive == null mean?!), as well as the possibility of introducing subtle bugs.
Also, I don't think "nullable boolean" as used by the parent actually should refer to the CLI/GUI, but rather that the setting of whether you've opted in or out would be null by default before the first run, and then the CLI/GUI would force a choice resulting in a non-null true or false for whether to opt-in to telemetry. That doesn't require "nullable" checkboxes, but rather a nullable boolean data field in the .NET Core settings. If you need to represent a "I'm purposefully not making a choice" null boolean value in a UI, use a radio group with 3 options.
Eg, if there is a form with optional values, do not store them in a sparse row, instead consider using Entity Value Attribute to store each value as a row (even though its kind of blegh in general, you wont ever store nulls for things you just dont know "yet".)
Personally, I would prefer developers have this option to improve their products. I am willing to put lots of caveats there: the telemetry gathering should be clearly indicated, it should be transparent, we should have access to the data, and obviously, it should be anonymized as much as possible. I think Microsoft ticks all those boxes in their approach. I also acknowledge that they hadn't done so at the start of the issue, but the situation quickly got muddled up with the opt-in vs opt-out back-and-forth, rather than how well they had implemented their opt-out approach.
If I'm clicking back and forth in a window, why should you assume it has something to do with your software? Yeah it's the most likely culprit in your opinion. But in my opinion I simply accidentally clicked somewhere, brought your window to focus, and went back to what I was doing elsewhere. Or clicked a button and clicked around to figure out how to undo it. I've seen tons of people with ADD-style clicking and typing while they're actually doing something completely irrelevant. It's literally just noise. Why do you need to try to interpret it?
Using telemetry to see how users use software is pointless.
I'm certainly not convinced that for consumer grade applications opt out telemetry is a good thing, for lots of reasons. But none of them are "it isn't useful".
Personally, I find that I have knee-jerk reaction to this. My feeling is that if something can be wrong or be abused, it will. That's why I feel that the best thing would be for opt-in telemetry to be simply put outside of consideration.
This kind of data collection is something that we've given to ourselves as an industry in the past few years, but we've developed software for decades without it. IMO, developers definitely have no inherent right to extract data from user systems, especially with Open Source products, where the license effectively says that there are no strings, and no obligations. If we want this, I think that we should have to make the case for it.
Don't be so quick to call for laws.
I do agree however, we do not need more laws about that, we just need the people to start using software that respects its users and can be audited by anyone - free software.
if ycombinator.com logs information on that request, is that okay? if not where does the "fault" lie? With the site that linked to a 3rd party (my website in this example)? With the site that is gathering telemetry without opt-in consent (ycombinator.com in this example)?
If it's the former (my fault for including a 3rd party request), what happens when user-submitted content includes a link to a 3rd party? What about if a user-submitted content includes a link but doesn't make a request and your browser decides to prefetch the contents of that link?
True, which is why many people (including me) use something like umatrix with every 3rd party request disabled unless whitelisted. This should be the default to be honest.
> if ycombinator.com logs information on that request, is that okay?
You are willingly letting your traffic be logged by the original site that you connected to. Does it matter if another party (usually trusted by the first party) gets the logs as well?
> and your browser decides to prefetch the contents of that link?
Change browser or configure it properly. Who even thought that prefetching is a good idea?
Anyway, the one at fault at this specific case is your browser (and maybe you, considering how you selected to use that browser or didn't bother configuring it).
Logging things from a device that are not related to your server is telemetry.
Don’t be so quick to apologize for spying on users. Telemetry is not necessary, we did fine without it for decades.
What about when it's run through VS or some other tool that hides much of the text? How does it know that I've read this information when it could be buried in several thousand lines of output from itself and other tools like make or msbuild?
Being explicit about opt-out is even less acceptable for command line tools than it is GUI based ones.
It should take one misconfiguration for your hold server to not call home.
Slightly subtle inversion there.
VS uses MSBuild rather than the dotnet cli (its also what the dotnet cli calls)
https://github.com/dotnet/cli/issues/3093#issuecomment-32632...
https://github.com/dotnet/cli/blob/22cd85daf6ca63a48e35fc7e2...
https://github.com/dotnet/cli/blob/22cd85daf6ca63a48e35fc7e2...