4 ms·
Telemetry to inform product decisions is fine, in fact I think it's necessary to have confidence that software is performing in the wild (e.g. crash reporting),
by danpalmer 4y ago
Telemetry to inform product decisions is fine, in fact I think it's necessary to have confidence that software is performing in the wild (e.g. crash reporting), or that customers know how to use it.
What is not ok is opt-out telemetry for personalisation for advertising, or over-reaching personal data collection, in 1Password's case data from your vault.
There is however a grey area in the middle – data about the performance of product upsells. This is a tricky one, because arguably if I do upgrade (say, to 1Password Family/Teams), I've probably done so because it made sense for me, and I'm probably happier with the product... but I might not have done so without that information on how I or others use the product that helped optimise that flow. When done well I don't have a problem with this, but I hope 1Password are careful about the culture of upsells that this data could create.
- TechBro8615 4y agoThe worry about telemetry in a product like this is how it's implemented. It's more code that could have bugs in it. What assurances do we have that it will execute safely in a way that it can't possibly access the password database, even in the event of (for example) compromise of the CI pipeline that builds the telemetry SDK? > No customer vault data can be seen or collected. We’re only interested in how people use the app itself, what features and screens they interact with – not what they store in their vaults, what sites they autofill on, or anything like that. This seems contradictory to me. How can the code see what screen is open without interacting with the app? This implies there is some kind of sandboxing layer. How can the 1Password software engineers possibly be confident enough in this sandboxing to assert that "no customer data can be seen?" That may be their intent, but bugs happen, especially in code that runs at a layer above the app to analyze how users interact with it. I will be opting out. Hopefully the opt-out mechanism doesn't have a bug in it either. And when there is inevitably a bug in the telemetry, I hope 1Password is okay with admitting that their opt-out system created two classes of users: those who did nothing, and thus remained vulnerable to bugs in the telemetry layer, and those who opted out of it.
- 1123581321 4y agoThey do separate the UI application from the kernel that manages access to the data. I guess the biggest risk would be that you click reveal, which has the kernel expose a password to the UI, and then the UI phones home with its entire raw contents.
- julian37 4y agoSurely the UI code is what responds to clicking "reveal" and therefore, if compromised, could fetch the secret even without a click?
- 1123581321 4y agoGood point. I don’t know what 1Password could do to prevent the telemetry from issuing control commands to the rest of the app outside of trying to prevent malicious code from being checked in and deployed.
- Animats 4y ago> The worry about telemetry in a product like this is how it's implemented. Exactly. They are enlarging the attack surface of a security device. For their own benefit. One buffer overflow and there's a backdoor. That this is happening means their marketing people have more power than their security people. This is a very bad thing for a security company. Start migrating away from 1Password. Now.
- wootland 4y ago> What is not ok is opt-out telemetry for personalisation for advertising Opt-out telemetry is also not ok for product decisions. It's a dark pattern that shows no respect for user privacy.
- abigail95 4y agoWhat's the difference between telemetry from the client side, and aggregate logs of server api endpoints? Assume no PII, what's the difference? What do you mean by dark pattern?
- wootland 4y agoI would say server side logging is one of the many downsides to SaaS based products and makes a great argument for running things locally. Any additional tracking of users exacerbates the problem.
- abigail95 4y agoFor a password manager I'm in full agreement, but the gap between running something like SAP Cloud vs On-Premises is very costly. There are tradeoffs where it's worth it.
- yamtaddle 4y agoServer logs can't watch your every move, even when you're not intentionally creating network requests. "Telemetry" is spyware, full stop.
- danpalmer 4y agoWhy? If everything works as it is supposed to then the only result is a better product. It may not work correctly, and there's some risk there, but it's pretty low risk. A poor implementation may cause UX regressions, but the company have incentive to not do that.
- wootland 4y ago
- whoopdedo 4y agoDo any developers collect usage statistics by sampling rather than a persistent data stream? I think it would possibly reassure privacy-conscious users that anonymized & aggregated telemetry really is what it claims to be if the phoning home only happens at random intervals. Otherwise that detailed record of usage is too tempting a target for the surveillance capitalists.
- JohnFen 4y agoThat wouldn't reassure me at all. Just because an application is phoning home at random intervals in no way means that the data wasn't being continuously collected. What would reassure me is if the data were all in human-readable form and given to me to transmit myself.
- jader201 4y ago> What is not ok is opt-out telemetry for … data from your vault. If I’m reading correctly, they’re pretty clear and intentional about not collecting data from your vault (regardless of opt-in or opt-out). It’s simply usage patterns of the UI. Do you see anything that suggests otherwise?
- JohnFen 4y ago> or that customers know how to use it. Telemetry that is detailed enough to reveal how I use a product is too invasive for my tastes.