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…
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?