Live data from Hacker News

Console Do Not Track – Proposal for a standard environment variable

consoledonottrack.com

341–350 of 352 posts

Re: Console Do Not Track – Proposal for a standard environment variable

#341

Earlier quoted context omitted.

> now as a founder who is building a tool to collect telemetry in the most respectful manner possible. Thank you for taking being respectful to users seriously. I'd be very interested in learning how your consent flows look, and what other aspects of your product are driven by the goal to "collect telemetry in the most respectful manner possible". I couldn't see much on it on the landing page, so if you have a moment…

Happy to show you some code. You cannot set up Bugout telemetry in your codebase without first defining your consent flow. We have a library of consent mechanisms that you can chain together like lego blocks to build these flows. For example, our Python consent library is here: https://github.com/bugout-dev/humbug/blob/main/python/humbug... Consent is calculated at the time that each reports are sent back. This means…

Hey, thanks for replying!

I like the design for your consent pipeline, and the code itself is very readable.

I have some further questions:

1. You say:

> You cannot set up Bugout telemetry in your codebase without first defining your consent flow

How is it enforced? Is it just an API limitation that I could work around by defining my consent block as below?

  def much_consent_so_informed() -> ConsentMechanism:
    def mechanism() -> bool:
      return True
    return mechanism
That is, are you relying entirely on trust and/or contractual obligations, or do you have some means of enforcing that the user of your SDK isn't cheating?

> Consent is calculated at the time that each reports are sent back. This means that your users can grant and revoke their consent on a per-report basis, which is the only respectful way to do things.

Correct. I like how you think about this. I assume the SDK user will be ultimately responsible for prompting the end-user for consent; I wonder if you have any "best practices" documents for the software authors, so that they don't have to reinvent respectful consent flow UX from scratch?

> We are also building programs which will deidentify reports on the client side, before any data is even sent back to our servers.

I don't see any code in that Kaggle notebook you linked (I'm not very familiar with Kaggle, I might be clicking wrong). Should I assume your approach is based on training a black-box ML model? Or do you use some heuristics to identify what data to cut?

Re: Console Do Not Track – Proposal for a standard environment variable

#342
I think that this approach kind of dissolves the power of the word "consent"

> plainly and unambiguously expresses LACK OF CONSENT by a user

in GDPR terms, consent can never be assumed. In order to be valid, the consent has to be a result of a conscious, explicit action from the user. Things that are opt-out cannot use "consent" as a legitimizing premise

Re: Console Do Not Track – Proposal for a standard environment variable

#343

Earlier quoted context omitted.

> making network requests that aren't necessary to carry out the expected functionality I think regularly updating the package formulae for homebrew is actually necessary to carry out the functionality most users expect from homebrew.

Homebrew doesn't show ads either. They weren't just talking about Homebrew.

Right, but they specifically listed "automatic update phone-home" as something to be supressed too. As well as some other things that aren't ads; the proposal is about "telemetry" not just ads.

And the proponent of the standard got in an argument with homebrew about supporting the env variable. (Although not necessarily for suppressing automatic updates? Which might be a violation of the standard, to suggest you support it, but only support it incompletely?)

Perhaps the proposed standard needs some more consultation and fine-tuning (as is common with standards for a reason) before trying to strong-arm projects into adopting it.

Re: Console Do Not Track – Proposal for a standard environment variable

#344

Earlier quoted context omitted.

Homebrew doesn't show ads either. They weren't just talking about Homebrew.

Right, but they specifically listed "automatic update phone-home" as something to be supressed too. As well as some other things that aren't ads; the proposal is about "telemetry" not just ads. And the proponent of the standard got in an argument with homebrew about supporting the env variable. (Although not necessarily for suppressing automatic updates? Which might be a violation of the standard, to suggest you supp…

The person you replied to didn't say that. And updating a package manager manually works fine. I consider forced updates and tracking different problems though.

Re: Console Do Not Track – Proposal for a standard environment variable

#345

Earlier quoted context omitted.

Right, but they specifically listed "automatic update phone-home" as something to be supressed too. As well as some other things that aren't ads; the proposal is about "telemetry" not just ads. And the proponent of the standard got in an argument with homebrew about supporting the env variable. (Although not necessarily for suppressing automatic updates? Which might be a violation of the standard, to suggest you supp…

The person you replied to didn't say that. And updating a package manager manually works fine. I consider forced updates and tracking different problems though.

The OP says that. That is the proposal in the OP that I thought we were discussing here, is why I was discussing it. The proposal in the OP for `DO_NOT_TRACK` does consider them part of the same problem all to be controlled by a `DO_NOT_TRACK` setting.

It may be that both you and I think that's not a great idea, or at least needs more fine-tuning as a proposed standard.

> This is a proposal for a single, standard environment variable that plainly and unambiguously expresses LACK OF CONSENT by a user of that software to any of the following:

> ad tracking

> usage reporting, anonymous or not

> automatic update phone-home

> crash reporting

> non-essential-to-functionality requests of any kind to the creator of the software or other tracking services

https://consoledonottrack.com/

Re: Console Do Not Track – Proposal for a standard environment variable

#346

Earlier quoted context omitted.

The person you replied to didn't say that. And updating a package manager manually works fine. I consider forced updates and tracking different problems though.

The OP says that. That is the proposal in the OP that I thought we were discussing here, is why I was discussing it. The proposal in the OP for `DO_NOT_TRACK` does consider them part of the same problem all to be controlled by a `DO_NOT_TRACK` setting. It may be that both you and I think that's not a great idea, or at least needs more fine-tuning as a proposed standard. > This is a proposal for a single, standard env…

I thought we were discussing the comment you quoted and replied to. It has a different but similar suggestion. And Homebrew automatic updates aren't needed anyway.

I don't think fine tuning would help. People who think they're entitled to collect user data without consent don't want to make it easy to opt out.

Re: Console Do Not Track – Proposal for a standard environment variable

#347

Sure. But I have a question: why ? Why should we opt out of the telemetry? To me, this idea seems to not just be admitting defeat, it's ensuring defeat right from the start. Telemetry should always be opt-in. Yes, that means vendors will get much less data. It's on them to deal with it. On a related note, I wonder how long it takes until one of the vendors of popular CLI tools or desktop apps get fined for GDPR viola…

Right on point. Also its at the mercy of the application and even then one there must be a trusty third party who can certify that an application follows the spec. This is not practical.

The reliable and practical way is to have a ad blocker at the kernel level similar to browser ad blockers.

Re: Console Do Not Track – Proposal for a standard environment variable

#348

Earlier quoted context omitted.

Happy to show you some code. You cannot set up Bugout telemetry in your codebase without first defining your consent flow. We have a library of consent mechanisms that you can chain together like lego blocks to build these flows. For example, our Python consent library is here: https://github.com/bugout-dev/humbug/blob/main/python/humbug... Consent is calculated at the time that each reports are sent back. This means…

Hey, thanks for replying! I like the design for your consent pipeline, and the code itself is very readable. I have some further questions: 1. You say: > You cannot set up Bugout telemetry in your codebase without first defining your consent flow How is it enforced? Is it just an API limitation that I could work around by defining my consent block as below? def much_consent_so_informed() -> ConsentMechanism: def mech…

Thanks for looking at the code, and for your feedback!

Here is a recipe for adding error reporting (reporting of all uncaught exceptions) in a Python project. The highlighted line shows that, when you instantiate a reporter, you have to pass a consent mechanism: https://github.com/bugout-dev/humbug/blob/main/python/recipe...

We allow you to create a consent mechanism that always returns true: > consent = HumbugConsent(True)

But even with that mechanism, we ultimately respect BUGGER_OFF=true: https://github.com/bugout-dev/humbug/blob/main/python/humbug...

Of course, someone can always create their own subclass of HumbugConsent which overrides that check. We don't have a good way to prevent this, nor would we want to restrict anyone's freedom to modify code.

re: Kaggle and stack trace deidentification

We started by crawling public GitHub issues for Python stack traces and built up a decent sized dataset of these: https://www.kaggle.com/simiotic/python-tracebacks

Our emphasis is on building simple programs that we can reasonably expect to run on any reasonable client without using an exorbitant amount of CPU or memory. For this reason, we aren't using black box ML models. Rather, we analyzed the data and came up with some simple regex based rules on how to deidentify stack traces for our v1 implementation.

We are in the process of doing this for more languages and building this into a proper deidentification library that can be imported into any runtime - Python + Javascript + Go + etc.

Apologies for the link not working. It seems I had to publish a version of the notebook. This link should work now: https://www.kaggle.com/simiotic/python-tracebacks-redactor

Actually, we started this work on a livestream if you're interested in watching: https://youtu.be/TFKe614Ml1M

Again, really appreciate your engagement and feedback. Thank you!

Re: Console Do Not Track – Proposal for a standard environment variable

#349

Sure. But I have a question: why ? Why should we opt out of the telemetry? To me, this idea seems to not just be admitting defeat, it's ensuring defeat right from the start. Telemetry should always be opt-in. Yes, that means vendors will get much less data. It's on them to deal with it. On a related note, I wonder how long it takes until one of the vendors of popular CLI tools or desktop apps get fined for GDPR viola…

I am installing Windows to a new machine right now. And here's the "Privacy Settings" setup step;

Title: "Diagnostic Data"

Explanation: "Send all Basic diagnostic data, along with info about the websites you browse and how you use apps and features, plus additional info about device health, device activity, and enhanced error reporting."

And this is ON by default.

"websites I browse"... ...Diagnostic Data?

Re: Console Do Not Track – Proposal for a standard environment variable

#350

Earlier quoted context omitted.

The OP says that. That is the proposal in the OP that I thought we were discussing here, is why I was discussing it. The proposal in the OP for `DO_NOT_TRACK` does consider them part of the same problem all to be controlled by a `DO_NOT_TRACK` setting. It may be that both you and I think that's not a great idea, or at least needs more fine-tuning as a proposed standard. > This is a proposal for a single, standard env…

I thought we were discussing the comment you quoted and replied to. It has a different but similar suggestion. And Homebrew automatic updates aren't needed anyway. I don't think fine tuning would help. People who think they're entitled to collect user data without consent don't want to make it easy to opt out.

You literally just said you considered them very different problems? But now you say you think they should both be handled per the OP with a single flag, and you're opposed to both of them on the same grounds -- doesn't sound like you do consider them very different problems?

This seems like one of those internet debates where what we're talking about keeps changing in pursuit of "winning" rather than enlightening.

Post reply on HN