It’s weird to me that people are willing to trust a saas provider with the safe handling of all of their sensitive passwords but then won’t trust them to safely handle measuring how many times you click a button in their app.
It’s really painful to handle as a developer. I need to use specific phrasing and be very explicit about “stacktraces get sent to me, because getting you to reproduce the issue, figure out how to use event log, send me the right parts would take days”. Yes it’s telemetry and no, I neither care about nor receive your data.
But the word telemetry is toxic now - as usual, ad companies are why we can’t have nice things.
That sounds like a good outcome for everyone - your users are hopefully grateful for the clarity? If a developer can’t come up with a concise and uncontroversial description without invoking the T-word, well, maybe they’re doing things that some users would rather they wouldn’t.
Telemetry is broad, but so are ‘stack traces’. If they are just call stack addresses, then that’s unlikely to leak very much personal data, but a lot of more advanced post-mortem stack traces capture arguments and these can contain a lot of personal information. Error reporting, which @insanitybit mentions, may include complete core dumps, which can contain a load of private data.
Collecting telemetry that is both privacy preserving for the users and useful for the developers is very hard.
Does having a “crash report” style dialog work better in terms of report outcomes? I mean the sort of thing where you don’t collect “telemetry” in the usual sense, but then if there’s a (caught) crash you pop up a dialog which allows the user to click a “Submit crash report” button, and is clear what is included in the report.
Personally, I’m much more inclined to use this sort of feature to submit actual feedback when something goes wrong, rather than allowing generic info on what I’m using in the application all the time.
“The app crashed then some weird window popped up so I closed it.” If you’re providing software to non-tech people, that kind of request is meaningless to them. When that dialog pops up, is there any reason a user of an app provided by their employer should not report a crash? I don’t believe there is.
is clear what is included in the report.
This applies to developers only. A generic user does not understand what a stacktrace is.
The fact that someone doesn’t want to do something, in this case share x information, is reason enough to respect that preference. The burden isn’t on users to justify why they don’t want to share information.
Beyond that I don’t think it’s illogical. We live in a world in which, best case scenario, our privacy is perpetually invaded against our will by the technology we rely on. If that means users don’t want to share any additional information to preserve what little privacy they have left that’s completely rational.
Not to mention that a lot of telemetry isn’t honest. It’s often not collected without user consent, or knowledge at all, which makes it shady. Often there’s no opt out. There is a fair amount of academic research on techniques to de-anonymize supposedly “anonymous” data sets telemetry collects, e.g. https://www.cs.utexas.edu/~shmat/shmat_oak08netflix.pdf
So “telemetry is good, opposing it is illogical” is incorrect and misses all of the nuance related to this topic. Really it’s an attitude that’s disrespectful to users.
There’s a related problem, which is that end users are not good at understanding the consequences of aggregation. If I show you all of the data collected about you by one application, it’s very hard for you to understand what someone can learn about you by correlating that against other data about you and against other data about users of that app. If you want to try to anonymise it then you need users to understand differential privacy (and, while I understand the concepts, I don’t want to actually do the maths every time I agree to a service).
The GDPR with a clear privacy policy can improve this. If you have consent to collect data for some explicit purpose then you cannot legally use it for any other purpose without additional consent. A telemetry service that showed me precisely what it collected and had a GDPR-backed guarantee that it would be used only for answering a specific set of questions about the program would be fine. You might also be able to make this dynamic. If you provided users with the set of questions that developers wanted to answer and let them opt into having their data used to compute the result, you might get some very helpful results.
The fact that someone doesn’t want to do something, in this case share x information, is reason enough to respect that preference.
No it isn’t.
The burden isn’t on users to justify why they don’t want to share information.
Yes it is. It’s everyone’s burden to justify their positions.
We live in a world in which, best case scenario, our privacy is perpetually invaded against our will by the technology we rely on.
That is obviously not the best case scenario. One can obviously write software that does not perpetually invade your privacy against your will. I suspect the vast majority of software written is in fact abiding by that.
Not to mention
All of these are implementation failures. Not all telemetry is good, not all telemetry is bad. Some may be bad, most might be, in fact.
Users are welcome to opt out of whatever they want by not participating and I always believe they should have that option, but I’m not going to pretend that their decision is magically rational.
Really it’s an attitude that’s disrespectful to users.
It’s disrespectful to everyone, actually. Developers, end users, etc, are really terribly informed about technology and make pretty illogical decisions all the time. I don’t see why that’s taboo to point out that people are irrational.
Title on the blog post is the opaque marketing speech “We’re changing how we discover and prioritize improvements”, hence the editorialized submission title.
They’ve taken VC funding, which means the MBAs have their foot in the door. Once the founders leave, a bean counter gets in charge and then they can abuse their user’s trust to monetize their user and telemetry data. It’s Doctorow’s Enshittification cycle.
I can’t say the same about 1Password which has semi-opensource client, and closed source server. I’m more concerned about 1Password being the next Lastpass.
I hope it’s obvious to everyone at this point that any time a corporation is comparatively better than others at respecting the people who rely on its stuff, this is purely a temporary state of affairs.
Free software projects are never as polished or featureful as corporate ones, but it’s quite rare for them to suddenly grow surveillance tooling. To me, this is worth it. Everyone can make their own decisions of course…
Beyond the angle being addressed in sibling comments, I think another interesting angle here is: what does telemetry collection say about your product management? I may be cherry picking, but I constantly see telemetry being used as an argument for further product deterioration (ahem, *Firefox*) If nothing else, it correlates with scope creep and hyper-growth ambitions. Which, BTW, normally comes with huge funding rounds like Agilebits’.
As a product developer, I think telemetry is valuable, and I’d love to be able to understand aggregate usage statistics of things like command line tools, and installed products. As a user who cares about my privacy, however, I hate this.
But, I think the reason I hate this is because I’m so used to companies saying one thing and doing another, or reneging on the initial agreement in hard to keep track of privacy policies, etc, etc, etc.
I’m starting to think that what we really want is a non-profit, privacy focused foundation of sorts that runs a privacy preserving telemetry proxy that companies can utilize. Most of the time, the data that’s being gathered is as 1Password is saying–and I don’t really see a reason to stop that. The problem is always – “well, what else will they do when I’m not looking?”
The same is true of the recent “golang wants to collect telemetry.” The problem isn’t, really, the telemetry itself. The problem is that the data being collected goes to Google.
Stuff I, as a developer, used telemetry for in IntelliJ Rust:
Crash reports. They are sort-of-different from the telemetry, but also are the same.
Figuring out what to focus on. Eg, if a lot of people use IntelliJ Rust with PyCharm, it makes sense to spend some time integrating into PyCharm-specific project view.
Figuring out when to drop support for old platforms. If only 5% of users are on a particularly old IJ, plug-in can stop supporting it.
Getting personal moral boost from seeing the number of installs going up
Justifying continuing investment into the project by the company
I didn’t use fine-grained telemetry for specific features, as, at that time, barely anything was working at all.
It doesn’t really say they do that. Ending the experience feels different than finding hugs. It could mean both though but without a precise description of how data will be used all bets are off.
For what makes sense and what people want interacting with your users, etc. tends to give more insights info the whys. With telemetry one ends up having to guess
You could just count downloads. You could also describe better what your telemetry is on. I think people would be fine if you specified something like well report your version when you log in through our extension.
And for general stats about how much sense continued investment makes sense wouldn’t downloads and paying users be enough?
I really want to emphasize here that you could just make a l list of what and why you tell it. You likely have that internally anyways. Why not publish it unless it’s something you don’t want your users to know? Sure it might be a bit of effort but it could almost be seen as marketing/gaining trust.
Automatic error reporting is also telemetry, and for non-developer focused tools, it is immensely useful to be able to record what errors people encounter without their interaction.
The first thing that comes to mind is to check which features they could drop without aggravating too many users. Also, you could prio the backlog by feature group as well as to see which new features get attention and which don’t.
From what I’ve seen in my professional life (as a product manager, thus making decisions about features), this is telemetry goal but, unless done at a Facebook scale where you truly experiment with a very large user base of “identical” users, it’s bullshit.
— Following the data, we could remove A.
— Wait, if you remove A, it breaks B.
— We could also remove C.
— No, C is the pet feature from the CEO.
— So let’s remove D.
— Ok.
— …
(phone rings)
— It’s our biggest customer. He’s angry we removed D. The CEO is using the feature once a year but it’s important to him.
— Sigh.…
— So let’s remove E
— Hey, no way, I did E, I like it. I’m simply blocking the telemetry.
I’ve never seen telemetry data being useful. You need to use it in conjunction with user survey and interviews. Oh, guess what? Once you take the time to do proper user interviews, telemetry are mostly useless.
And the cost associated with telemetry is very high: you need to maintain the telemetry infrastructure. You augment the risk surface (remember when OSX was bugging because it was trying to phone home?). You need to keep this data reliably to avoid any privacy breach. You need to sort this data, to analyze it. The cost is important.
Which means that when a product add telemetry, there are only two options: either they are doing that “because everybody does it” or they have some way to recoup for the high cost. Which is rarely a good thing for the end user.
Fortunately, in 1password case, I switched to bitwarden years ago and bitwarden is cheaper, simpler, opensource multiplatform and works even better for me.
Collecting user data, including anonymous data collection, is insaney valuable and it will keep getting more valuable in the future. Even if they don’t know as of now what they’ll be able to do with it, they certainly can harvest it as an “investment” of some sorts.
I would expect there to be ~no blowback, because people posting on message boards (myself most certainly among them) make up a vanishing small percentage of the market of folks who pay for 1Password.
This is a real problem with these web based and autoupdating products. Companies can just do things to you. They can reach into your computer and change the terms of the deal you already made with them. We’re in this state where they can just decide that they want something new from you and the best you can do is get upset and beg them not to. And because (1) you need security updates and (2) versions are monotonic, you can’t opt out of it unless they allow you to. You don’t really own your computer anymore, you rent it from a bunch of product managers with dollar signs in their eyes.
I am a fan of pass, but I’m not a fan of the fact that I have to copy my private key everywhere to use it. I’d prefer something with the simplicity of pass, but with, say, KDF + AES-256, as in KeePass… that still had the ecosystem that pass has…. that I also feel comfortable with leaving the files on someone else’s servers for syncing purposes…
It’s weird to me that people are willing to trust a saas provider with the safe handling of all of their sensitive passwords but then won’t trust them to safely handle measuring how many times you click a button in their app.
Telemetry has become a curse word. The opposition is totally illogical.
It’s really painful to handle as a developer. I need to use specific phrasing and be very explicit about “stacktraces get sent to me, because getting you to reproduce the issue, figure out how to use event log, send me the right parts would take days”. Yes it’s telemetry and no, I neither care about nor receive your data.
But the word telemetry is toxic now - as usual, ad companies are why we can’t have nice things.
That sounds like a good outcome for everyone - your users are hopefully grateful for the clarity? If a developer can’t come up with a concise and uncontroversial description without invoking the T-word, well, maybe they’re doing things that some users would rather they wouldn’t.
It’s not great. It basically says: whatever word is chosen by adtech for a dark pattern will be killed for general use.
What if they start talking about “comment” next? Would you “post a message replying to another message” that it’s a good outcome for clarity?
This may sound like a slippery slope, but we’ve already lost telemetry and cookie, and are close with user experience and personalisation.
Not really. If you say “now collects error reporting” users still lose their minds.
Telemetry is broad, but so are ‘stack traces’. If they are just call stack addresses, then that’s unlikely to leak very much personal data, but a lot of more advanced post-mortem stack traces capture arguments and these can contain a lot of personal information. Error reporting, which @insanitybit mentions, may include complete core dumps, which can contain a load of private data.
Collecting telemetry that is both privacy preserving for the users and useful for the developers is very hard.
Does having a “crash report” style dialog work better in terms of report outcomes? I mean the sort of thing where you don’t collect “telemetry” in the usual sense, but then if there’s a (caught) crash you pop up a dialog which allows the user to click a “Submit crash report” button, and is clear what is included in the report.
Personally, I’m much more inclined to use this sort of feature to submit actual feedback when something goes wrong, rather than allowing generic info on what I’m using in the application all the time.
“The app crashed then some weird window popped up so I closed it.” If you’re providing software to non-tech people, that kind of request is meaningless to them. When that dialog pops up, is there any reason a user of an app provided by their employer should not report a crash? I don’t believe there is.
This applies to developers only. A generic user does not understand what a stacktrace is.
The fact that someone doesn’t want to do something, in this case share x information, is reason enough to respect that preference. The burden isn’t on users to justify why they don’t want to share information.
Beyond that I don’t think it’s illogical. We live in a world in which, best case scenario, our privacy is perpetually invaded against our will by the technology we rely on. If that means users don’t want to share any additional information to preserve what little privacy they have left that’s completely rational.
Not to mention that a lot of telemetry isn’t honest. It’s often not collected without user consent, or knowledge at all, which makes it shady. Often there’s no opt out. There is a fair amount of academic research on techniques to de-anonymize supposedly “anonymous” data sets telemetry collects, e.g. https://www.cs.utexas.edu/~shmat/shmat_oak08netflix.pdf
So “telemetry is good, opposing it is illogical” is incorrect and misses all of the nuance related to this topic. Really it’s an attitude that’s disrespectful to users.
There’s a related problem, which is that end users are not good at understanding the consequences of aggregation. If I show you all of the data collected about you by one application, it’s very hard for you to understand what someone can learn about you by correlating that against other data about you and against other data about users of that app. If you want to try to anonymise it then you need users to understand differential privacy (and, while I understand the concepts, I don’t want to actually do the maths every time I agree to a service).
The GDPR with a clear privacy policy can improve this. If you have consent to collect data for some explicit purpose then you cannot legally use it for any other purpose without additional consent. A telemetry service that showed me precisely what it collected and had a GDPR-backed guarantee that it would be used only for answering a specific set of questions about the program would be fine. You might also be able to make this dynamic. If you provided users with the set of questions that developers wanted to answer and let them opt into having their data used to compute the result, you might get some very helpful results.
No it isn’t.
Yes it is. It’s everyone’s burden to justify their positions.
That is obviously not the best case scenario. One can obviously write software that does not perpetually invade your privacy against your will. I suspect the vast majority of software written is in fact abiding by that.
All of these are implementation failures. Not all telemetry is good, not all telemetry is bad. Some may be bad, most might be, in fact.
Users are welcome to opt out of whatever they want by not participating and I always believe they should have that option, but I’m not going to pretend that their decision is magically rational.
It’s disrespectful to everyone, actually. Developers, end users, etc, are really terribly informed about technology and make pretty illogical decisions all the time. I don’t see why that’s taboo to point out that people are irrational.
Title on the blog post is the opaque marketing speech “We’re changing how we discover and prioritize improvements”, hence the editorialized submission title.
I’m fine with this; I’ve been a 1Password user for years, and I guess I just don’t panic reflexively at the use of the word “telemetry”
They’ve taken VC funding, which means the MBAs have their foot in the door. Once the founders leave, a bean counter gets in charge and then they can abuse their user’s trust to monetize their user and telemetry data. It’s Doctorow’s Enshittification cycle.
Assuming 1Password uses privacy-preserving techniques like the Stanford team’s Prio used by Mozilla, I would be ok with this. https://hacks.mozilla.org/2018/10/testing-privacy-preserving-telemetry-with-prio/
Correct!
Next question.
You can’t have the data you want. The end.
Even if they did, they can still quietly change the implementation later. The cat is out of the bag.
Come to Bitwarden. It’s nice over here. Really starting to feel like one of those rare “wow companies can be this good?” situations.
Come join. Pay them. Give them a reason not to pull this shit on us all 👍
+1 for Bitwarden. I migrated three years ago and have never regretted it.
People been saying that about lastpass)) I think 1Password is still a good company.
Lastpass was closed source. Bitwarden is open source on both the client and server side, and was audited by Cure53. There is also a community-maintained alternative lightweight server implementation for people who want to self-host on a raspberry-pi or cheap VPS.
I can’t say the same about 1Password which has semi-opensource client, and closed source server. I’m more concerned about 1Password being the next Lastpass.
Can confirm, the Rust VaultWarden server implementation is super light-weight and enables some nice premium features (group vaults, TOTP) for free!
They recently added support for argon2id too, addressing my one real complaint.
you realize 1password is a paid product right?
sigh
At least they’re being open about it and proise to provide an opt-out option. It could’ve been beter but it also could’ve been worse.
I hope it’s obvious to everyone at this point that any time a corporation is comparatively better than others at respecting the people who rely on its stuff, this is purely a temporary state of affairs.
Free software projects are never as polished or featureful as corporate ones, but it’s quite rare for them to suddenly grow surveillance tooling. To me, this is worth it. Everyone can make their own decisions of course…
Honestly, I’ve found the opposite to be true. I think it is fair to say they’re rarely as easy for novices to learn, however.
“Easy to learn” is a big “polish” item.
Well that explains why HP calculators are hard to learn; they got the polish backwards.
Beyond the angle being addressed in sibling comments, I think another interesting angle here is: what does telemetry collection say about your product management? I may be cherry picking, but I constantly see telemetry being used as an argument for further product deterioration (ahem,
*Firefox*) If nothing else, it correlates with scope creep and hyper-growth ambitions. Which, BTW, normally comes with huge funding rounds like Agilebits’.As a product developer, I think telemetry is valuable, and I’d love to be able to understand aggregate usage statistics of things like command line tools, and installed products. As a user who cares about my privacy, however, I hate this.
But, I think the reason I hate this is because I’m so used to companies saying one thing and doing another, or reneging on the initial agreement in hard to keep track of privacy policies, etc, etc, etc.
I’m starting to think that what we really want is a non-profit, privacy focused foundation of sorts that runs a privacy preserving telemetry proxy that companies can utilize. Most of the time, the data that’s being gathered is as 1Password is saying–and I don’t really see a reason to stop that. The problem is always – “well, what else will they do when I’m not looking?”
The same is true of the recent “golang wants to collect telemetry.” The problem isn’t, really, the telemetry itself. The problem is that the data being collected goes to Google.
I wonder what they hope to achieve with that. I always do when someone adds telemetry. So far I haven’t seen a convincing answer.
Stuff I, as a developer, used telemetry for in IntelliJ Rust:
I didn’t use fine-grained telemetry for specific features, as, at that time, barely anything was working at all.
It doesn’t really say they do that. Ending the experience feels different than finding hugs. It could mean both though but without a precise description of how data will be used all bets are off.
For what makes sense and what people want interacting with your users, etc. tends to give more insights info the whys. With telemetry one ends up having to guess
You could just count downloads. You could also describe better what your telemetry is on. I think people would be fine if you specified something like well report your version when you log in through our extension.
And for general stats about how much sense continued investment makes sense wouldn’t downloads and paying users be enough?
I really want to emphasize here that you could just make a l list of what and why you tell it. You likely have that internally anyways. Why not publish it unless it’s something you don’t want your users to know? Sure it might be a bit of effort but it could almost be seen as marketing/gaining trust.
Automatic error reporting is also telemetry, and for non-developer focused tools, it is immensely useful to be able to record what errors people encounter without their interaction.
Fair point, though I wouldn’t really consider crash/error reports telemetry. And judging by 1Password’s wording, this isn’t about that anyway.
The first thing that comes to mind is to check which features they could drop without aggravating too many users. Also, you could prio the backlog by feature group as well as to see which new features get attention and which don’t.
From what I’ve seen in my professional life (as a product manager, thus making decisions about features), this is telemetry goal but, unless done at a Facebook scale where you truly experiment with a very large user base of “identical” users, it’s bullshit.
— Following the data, we could remove A.
— Wait, if you remove A, it breaks B.
— We could also remove C.
— No, C is the pet feature from the CEO.
— So let’s remove D.
— Ok.
— …
(phone rings)
— It’s our biggest customer. He’s angry we removed D. The CEO is using the feature once a year but it’s important to him.
— Sigh.…
— So let’s remove E
— Hey, no way, I did E, I like it. I’m simply blocking the telemetry.
I’ve never seen telemetry data being useful. You need to use it in conjunction with user survey and interviews. Oh, guess what? Once you take the time to do proper user interviews, telemetry are mostly useless.
And the cost associated with telemetry is very high: you need to maintain the telemetry infrastructure. You augment the risk surface (remember when OSX was bugging because it was trying to phone home?). You need to keep this data reliably to avoid any privacy breach. You need to sort this data, to analyze it. The cost is important.
Which means that when a product add telemetry, there are only two options: either they are doing that “because everybody does it” or they have some way to recoup for the high cost. Which is rarely a good thing for the end user.
Fortunately, in 1password case, I switched to bitwarden years ago and bitwarden is cheaper, simpler, opensource multiplatform and works even better for me.
Thank you for this insightful comment.
Out of curiosity: What kind of development team size, product/code size and customer base size are we talking about here?
Without aggravating the users who leave telemetry enabled, you mean.
I would simply not remove features.
While admirable, that is not ultimately a sustainable policy depending on market factors.
Collecting user data, including anonymous data collection, is insaney valuable and it will keep getting more valuable in the future. Even if they don’t know as of now what they’ll be able to do with it, they certainly can harvest it as an “investment” of some sorts.
Cool. Good. I expect their product will have fewer bugs and a better UX because of this.
I don’t know what they expect to happen here aside from massive blowback and customer loss.
Perhaps. I doubt the large majority of customers will care. Telemetry-phobia is pretty niche in the mainstream.
I would expect there to be ~no blowback, because people posting on message boards (myself most certainly among them) make up a vanishing small percentage of the market of folks who pay for 1Password.
I’m happy that I am using Keepass2Android with cloud provider sync.
Sounds great, I hope they use error reporting and other metrics to catch some of the tiny rough edges around the product.
Thanks, I hate it.
“And, of course, once this functionality rolls out to customers, you’ll be able to control whether or not telemetry is active on your account.”
Now I just have to remember to turn it off.
This is a real problem with these web based and autoupdating products. Companies can just do things to you. They can reach into your computer and change the terms of the deal you already made with them. We’re in this state where they can just decide that they want something new from you and the best you can do is get upset and beg them not to. And because (1) you need security updates and (2) versions are monotonic, you can’t opt out of it unless they allow you to. You don’t really own your computer anymore, you rent it from a bunch of product managers with dollar signs in their eyes.
https://www.passwordstore.org/
I am a fan of pass, but I’m not a fan of the fact that I have to copy my private key everywhere to use it. I’d prefer something with the simplicity of pass, but with, say, KDF + AES-256, as in KeePass… that still had the ecosystem that pass has…. that I also feel comfortable with leaving the files on someone else’s servers for syncing purposes…
[Comment removed by moderator pushcx: Snark doesn't help.]