Hacker News Reader

Comment by danpalmer | Hacker News Reader

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.

View on HN

The 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.

They 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.

Surely the UI code is what responds to clicking "reveal" and therefore, if compromised, could fetch the secret even without a click?

Good 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.

> 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.

> 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.

What'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?

I 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.

For 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.

Server logs can't watch your every move, even when you're not intentionally creating network requests. "Telemetry" is spyware, full stop.

Why? 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.

> Why?

Because I value my privacy, period.

> If everything works as it is supposed to then the only result is a better product.

After 20+ years in the industry, I've never once seen this to be the case. I can't think of a single product that used telemetry that I'd consider to be of high quality. It has always been a sign that there's no captian on the ship though.

> It may not work correctly, and there's some risk there, but it's pretty low risk.

I'm unwilling to take on any risk to prop up a poorly run product team.

I wrote more about the consent aspect here: https://news.ycombinator.com/item?id=35706897

tl;dr If we roll this out to customers, we'll be asking for consent, and won't be collecting telemetry data unless we have it.

-Ben, 1Password

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

> 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.

Do 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.

That 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.

Reply on news.ycombinator.com