So it looks like they will be collecting PII (user_ipaddress) and they will also link these events to an account (account_uuid) and you just have to trust their "de-identification pipeline".
Will be interesting to see if they roll this out in the EU (especially with the "Share analytics" box being checked by default).
The EU's GDPR only requires explicit consent for data collection for the purposes of the processing of data that is personally identifiable and there are exemptions such as for operational reasons. For example if you make an HTTPS request to my server then of course I have your IP address. It's what I do with that personally identifiable information that determines whether it requires explicit consent or not. For example if I only use it for the purposes of ensuring operational security and destroy access logs after some limited time, then explicit consent isn't required.
Data collection for aggregate analysis that discards personally identifiable information in a non-recoverable way similarly does not require explicit consent.
Sounds to me like what they say they're doing is compliant, does not require explicit consent under the GDPR anyway, and therefore whether or not the checkbox defaults to checked or not is moot from the point of view of the GDPR.
I understand some people might not want to trust them, their processes or their competence regardless, but that's a matter that's outside the scope of the GDPR. The GDPR is about what they are doing and for what purposes, not whether you trust them.
I for one am glad they're doing this. There's a lot of UX stuff I wish they'd improve (random lockouts and desyncs, autofill not showing up in Android, no dedupe, no automatic discovery of app logins from saved web logins, etc.)
The basic feature set already works great. I hope having more usage data will let them keep tweaking the product for users.
Or they might just sell it all to data brokers. Who knows these days, lol.
> There's a lot of UX stuff I wish they'd improve (random lockouts and desyncs, autofill not showing up in Android, no dedupe, no automatic discovery of app logins from saved web logins, etc.)
How does usage data fix this?
Have you considered just sending them feature requests and bug reports?
Depending on the granularity, all those actions (if not intents) could be tracked.
I've never really had feature requests acted on by a company before. Small one person software shops, yes, but companies? Never. I don't think their feature pipelines actually care what customers want.
If you don't think they care what their customers want (and I agree), then you better go back to the original question of whether this is a "good thing" or not. Why are they actually collecting the data, if they don't care what you want?
They probably want to sell it, primarily, or to help different internal teams decide what to focus resources on.
But if some product owner in their org uses it to make even one improvement, it's worth it to me. I really don't mind them collecting usage data (heck, they don't even have to anonymize it for me) as long as my passwords remain encrypted.
Edit: I mean, I trust this company with my entire online existence, including major financial and government functions. It's closed source and I take their word (and reputation) for it. Surely I can trust them to monitor which buttons I push...
Based on some anecdotal observations, I think 1Password 7 was better than version 8. I don't think missing telemetry is their problem. Lots of UI changes don't sit right with me, but they're only minor annoyances.
I respectfully suggest they pull some devs off inventing new telemetry techniques and put some work into the backlog instead, particularly this embarrassing date display issue that's causing actual problems for a solid group of their users:
https://1password.community/discussion/131071/incorrect-date...
Why are you worried about their analytics platform if your happily using their product today, which requires the use of 1Password cloud?
1Password don’t need to an analytics platform to steal your passwords. They could just straight up modify their client to send back your decrypted passwords to them. Analytics doesn’t make a jot of difference to the difficulty of doing that.
I'm unhappily using their product today, having still refused to update to v8. I still have local vaults.
The point is, that they are wanting to intentionally collect data about me now. It's quite easy to see how that could be data that I don't want collected.
Your question is like asking why it bothers me that all my neighbors have Ring doorbells now recording my walks, when they could just look out their window and spy on my anyway. It's a step along the slippery slope that makes the likelihood of privacy invasion much higher as time goes on. Ignore the CIA if you want, but I'm pretty sure they'll have an easier time collecting data they might want now that it exists. But leaving that to the side, collecting data accidentally is a known problem that keeps cropping up.
> I'm unhappily using their product today, having still refused to update to v8. I still have local vaults.
Then this change doesn’t impact you. There’s no indication 1Password have any interest in back-porting analytics to older versions of 1Password.
> Your question is like asking why it bothers me that all my neighbors have Ring doorbells now recording my walks…
No, my question is quite simple. Either you trust the entire 1Password client or you don’t. Telemetry might change a persons stance on that trust, but holding up the boogy man CIA as reason for not liking telemetry is ridiculous. If the CIA could and wanted to force 1Password to hand over your encrypted data, then not having telemetry isn’t going to slow them down.
If your argument is you don’t like telemetry, full stop. Then make that argument. Throwing in FUD about shady CIA activities does more to undermine your argument than strengthen it.
Feels like you're making a big deal out of nothing by picking apart their language.
They're saying they've designed the system, so it's separated from access to your vault. This is their way of trying to reassure users they have considered user privacy.
Obviously, they could be secretly collecting things this entire time. But also, why would they need the telemetry system to view your vault? If they wanted to view that, they could do that "secretly"
They could have always injected code to migrate your passwords to a new system when you unlock your account, no matter how secure the settings are.
Wealthsimple actually did something like that when they purchased SimpleTax. Logging into your account after the acquisition resulted in them in decrypting and migrating data (I think it was opt-out by default, it's been a few years).
Any system running inside your password manager's process can in theory be used to extract your data. Ideally the surface area stays small.
I really don’t like BW. I use multiple vaults to split out specific categories of things. I have a vault per contract for example. I don’t want them all in a single vault.
Technically nothing is preventing you from maintaining your own reverse-engineered 1Password backend. You're even legally allowed to do so under US law. You just don't want to invest the time and effort. And neither does 1Password for the price you pay. Maybe it would be nice for them to offer a pricing tier where they make it easy for your to BYOB, but it doesn't seem to be a priority of theirs anymore and you can always switch to one of those open source apps that stores things locally if that's really a deal breaker.
The complaint is that there were already perfectly good 1Pw "backends" that didn't need any reverse engineering at all: wifi sync, and dropbox. But they took them away. The complaint is: why the fuck did they do that?
Because not enough of their user base cared for it to be cost effective to maintain it. Would it have been nice for them to offer a pricing tier where you could pay to have offline backends? Sure. But whatever the case they decided that didn't make sense. So your options now are to talk with your legs or get over it.
I’ve used 1Password for over a decade, and I’ve worked in that part of the industry professionally (secrets management specifically). I was an early adopter of 1Password.com and was involved in private beta tests (that are long since concluded).
Over that time I observed that they were very aggressively repositioning the cloud offering as the only one, or as one that was the most secure for every use case. New users eventually only saw the standalone options as a small link.
I was in various public and beta test groups for 1Password 6-8, and 7 felt like the sweet spot, but somewhere around 7.4, they started rapidly changing onboarding screens and release note screens to feature only 1Password.com.
Only after doing that did they start discussing how many “new users were signing up for the cloud, and skipping standalone.”
I felt that was disingenuous because I saw them constructing that very outcome. I even discussed it with them, but actually saying that aloud seemed to be like taking a leak on the third rail. I’m not arguing with your logic, but as someone who was close to it at the time, this outcome was very carefully constructed over a non-trivial period of time.
All that said, my big gripe is that when you try to talk to them about backups, they refuse to talk about anything but sync. They still don’t have actual account-wide backups. They have CSV and 1PUX exports that only capture vaults currently present on the exporting client.
What privacy are you giving up by storing an encrypted blob on their servers (other than any info required by law for them to accept digital payments from you)?
A month ago: 1Password rolling out “privacy-preserving” telemetry system (1password.com) 74 points by LopRabbit 34 days ago | 70 comments | https://news.ycombinator.com/item?id=36427299
FTFA: “We recently shared that we’ll soon be rolling out a privacy-preserving telemetry system that will help us improve 1Password by leveraging aggregated, de-identified usage data. Here we’ll share technical details about how this system works and the steps we’ve taken to protect customer privacy while engaging with the resulting data.”
> But why collect these data points in the first place?
This heading is followed by several paragraphs that don't explain at all why they're collecting several of these data points.
If the IP address is dropped in the de-identification pipeline, why is it stored in the "raw events"? If you don't need an exact timestamp, why are you storing it? Why does the app send all of this identifying data to be stored for 21 days instead of "de-identifying" it beforehand?
That's what also annoyed me a bit so I just contacted them via the link in the bottom of the blog post:
"Hey there,
I just read the "under the hood" blog post about telemetry and have some questions.
First of all, the section "But why collect these data points in the first place?" does not really answer the question. There is no explanation given about why e.g. IP-addresses are collected when, as by your schematics, they are never really used and completely anyway. So why store them in the first place, even if only for 21 days?
Another question I have is, why the de-identification of some items takes place in your AWS environment instead of on device. For example, when talking about the IP-address, it is not used later on anyway. And the timestamp could easily be truncated by the batcher on device, couldn't it?
Thanks for your thoughtful questions and for your patience as we connected with our engineers over the weekend.
*Why are IP addresses collected?*
Currently, IP addresses are an unavoidable part of the telemetry data process because the event transmission occurs over the TCP/IP protocol. The library we use as the web server automatically parses IP addresses from that transmission, but we've implemented a step to entirely remove that field from the data before it's processed for analytics. We currently don't require or desire IP information for telemetry; we’re early in our telemetry journey and will consider improving our handling of IP addresses as a future enhancement.
*Why do we de-identify server-side rather than on the device?*
De-identifying server-side allows us to enrich the raw event data with additional metadata elements that aren't stored on your device. These elements are non-identifying pieces of information like the type of account and whether or not the trial period is active. The entire server-side enrichment pipeline is hosted entirely within 1Password's own infrastructure.
*Could the timestamp be truncated by the batcher on the device?*
The timestamp being truncated on the device is possible – our primary concern here is the loss of visibility into latency in our pipeline. This can have a significant impact on data quality and understanding the health of our pipeline.
Our goal as we roll this out is to provide transparency on how we prioritize customer privacy while building a better 1Password. We hope this helps answer some of your questions and we’re here to help if you have anything else you’d like to know.
I was originally OK with some collection just to help their product team but seeing IP address, device ID, and account IDs makes this a massive nope for me. And I won’t change my mind on that even if they defensively drop them after seeing peoples feedback. I’ve paid for this app for nearly a decade and have been an adamant fan and user of their software. Why break my trust over something so stupid? I was expecting an apple-level privacy protection effort here. With so many paid users, there’s just no need to collect so many personal details to verify the legitimacy of data.
1pass - take a hint from apples privacy preserving photo scanning snafu last year - if you’re upsetting loyal users, take a step back, and rethink the system.
45 comments
[ 2.9 ms ] story [ 90.4 ms ] threadWill be interesting to see if they roll this out in the EU (especially with the "Share analytics" box being checked by default).
Data collection for aggregate analysis that discards personally identifiable information in a non-recoverable way similarly does not require explicit consent.
Sounds to me like what they say they're doing is compliant, does not require explicit consent under the GDPR anyway, and therefore whether or not the checkbox defaults to checked or not is moot from the point of view of the GDPR.
I understand some people might not want to trust them, their processes or their competence regardless, but that's a matter that's outside the scope of the GDPR. The GDPR is about what they are doing and for what purposes, not whether you trust them.
The basic feature set already works great. I hope having more usage data will let them keep tweaking the product for users.
Or they might just sell it all to data brokers. Who knows these days, lol.
How does usage data fix this?
Have you considered just sending them feature requests and bug reports?
I've never really had feature requests acted on by a company before. Small one person software shops, yes, but companies? Never. I don't think their feature pipelines actually care what customers want.
But if some product owner in their org uses it to make even one improvement, it's worth it to me. I really don't mind them collecting usage data (heck, they don't even have to anonymize it for me) as long as my passwords remain encrypted.
Edit: I mean, I trust this company with my entire online existence, including major financial and government functions. It's closed source and I take their word (and reputation) for it. Surely I can trust them to monitor which buttons I push...
I respectfully suggest they pull some devs off inventing new telemetry techniques and put some work into the backlog instead, particularly this embarrassing date display issue that's causing actual problems for a solid group of their users: https://1password.community/discussion/131071/incorrect-date...
"Our telemetry system cannot, by design, have insight into the end-to-end encrypted data you store in 1Password."
It can't by design... but can it by accident? And will they secretly change the design at the request of the CIA?
1Password don’t need to an analytics platform to steal your passwords. They could just straight up modify their client to send back your decrypted passwords to them. Analytics doesn’t make a jot of difference to the difficulty of doing that.
The point is, that they are wanting to intentionally collect data about me now. It's quite easy to see how that could be data that I don't want collected.
Your question is like asking why it bothers me that all my neighbors have Ring doorbells now recording my walks, when they could just look out their window and spy on my anyway. It's a step along the slippery slope that makes the likelihood of privacy invasion much higher as time goes on. Ignore the CIA if you want, but I'm pretty sure they'll have an easier time collecting data they might want now that it exists. But leaving that to the side, collecting data accidentally is a known problem that keeps cropping up.
Then this change doesn’t impact you. There’s no indication 1Password have any interest in back-porting analytics to older versions of 1Password.
> Your question is like asking why it bothers me that all my neighbors have Ring doorbells now recording my walks…
No, my question is quite simple. Either you trust the entire 1Password client or you don’t. Telemetry might change a persons stance on that trust, but holding up the boogy man CIA as reason for not liking telemetry is ridiculous. If the CIA could and wanted to force 1Password to hand over your encrypted data, then not having telemetry isn’t going to slow them down.
If your argument is you don’t like telemetry, full stop. Then make that argument. Throwing in FUD about shady CIA activities does more to undermine your argument than strengthen it.
They're saying they've designed the system, so it's separated from access to your vault. This is their way of trying to reassure users they have considered user privacy.
Obviously, they could be secretly collecting things this entire time. But also, why would they need the telemetry system to view your vault? If they wanted to view that, they could do that "secretly"
Wealthsimple actually did something like that when they purchased SimpleTax. Logging into your account after the acquisition resulted in them in decrypting and migrating data (I think it was opt-out by default, it's been a few years).
Any system running inside your password manager's process can in theory be used to extract your data. Ideally the surface area stays small.
I really like Bitwarden (after moving from Lastpass) but haven’t tried 1Password. Am I missing out?
https://www.passwordstore.org/
Over that time I observed that they were very aggressively repositioning the cloud offering as the only one, or as one that was the most secure for every use case. New users eventually only saw the standalone options as a small link.
I was in various public and beta test groups for 1Password 6-8, and 7 felt like the sweet spot, but somewhere around 7.4, they started rapidly changing onboarding screens and release note screens to feature only 1Password.com.
Only after doing that did they start discussing how many “new users were signing up for the cloud, and skipping standalone.”
I felt that was disingenuous because I saw them constructing that very outcome. I even discussed it with them, but actually saying that aloud seemed to be like taking a leak on the third rail. I’m not arguing with your logic, but as someone who was close to it at the time, this outcome was very carefully constructed over a non-trivial period of time.
All that said, my big gripe is that when you try to talk to them about backups, they refuse to talk about anything but sync. They still don’t have actual account-wide backups. They have CSV and 1PUX exports that only capture vaults currently present on the exporting client.
This heading is followed by several paragraphs that don't explain at all why they're collecting several of these data points.
If the IP address is dropped in the de-identification pipeline, why is it stored in the "raw events"? If you don't need an exact timestamp, why are you storing it? Why does the app send all of this identifying data to be stored for 21 days instead of "de-identifying" it beforehand?
"Hey there, I just read the "under the hood" blog post about telemetry and have some questions.
First of all, the section "But why collect these data points in the first place?" does not really answer the question. There is no explanation given about why e.g. IP-addresses are collected when, as by your schematics, they are never really used and completely anyway. So why store them in the first place, even if only for 21 days?
Another question I have is, why the de-identification of some items takes place in your AWS environment instead of on device. For example, when talking about the IP-address, it is not used later on anyway. And the timestamp could easily be truncated by the batcher on device, couldn't it?
Looking forward to hearing from you!"
Thanks for your thoughtful questions and for your patience as we connected with our engineers over the weekend.
*Why are IP addresses collected?*
Currently, IP addresses are an unavoidable part of the telemetry data process because the event transmission occurs over the TCP/IP protocol. The library we use as the web server automatically parses IP addresses from that transmission, but we've implemented a step to entirely remove that field from the data before it's processed for analytics. We currently don't require or desire IP information for telemetry; we’re early in our telemetry journey and will consider improving our handling of IP addresses as a future enhancement.
*Why do we de-identify server-side rather than on the device?*
De-identifying server-side allows us to enrich the raw event data with additional metadata elements that aren't stored on your device. These elements are non-identifying pieces of information like the type of account and whether or not the trial period is active. The entire server-side enrichment pipeline is hosted entirely within 1Password's own infrastructure.
*Could the timestamp be truncated by the batcher on the device?*
The timestamp being truncated on the device is possible – our primary concern here is the loss of visibility into latency in our pipeline. This can have a significant impact on data quality and understanding the health of our pipeline.
Our goal as we roll this out is to provide transparency on how we prioritize customer privacy while building a better 1Password. We hope this helps answer some of your questions and we’re here to help if you have anything else you’d like to know.
1pass - take a hint from apples privacy preserving photo scanning snafu last year - if you’re upsetting loyal users, take a step back, and rethink the system.