Telemetry Function
Comments
-
From ccw on July 31:
I'm not seeing any way to close the prompt without making a choice.
The following comes from a seven year 1Password user and family organizer. I do not follow new 1Password features - I just want a secure and functional password manager. A few days ago I happened to want to get a password while checking out at a grocery store. I got a prompt, I could not skip in iOS, to confirm, or not, participation in the sharing of usage data. Final bolded question was: "Would you like to participate?" Then in a separate box my family account name and email with a toggle that was defaulted "on". There was zero explanation of the toggle. In the desktop screenshot further above in this discussion the toggle it at least says: "Share analytics". Here I am just wanting to buy some groceries and my password manager is forcing a decision on me.
Maybe consider that not all customers have time to digest the information and make a decision - they just want a password. Not only is the default opt-in an affront, the inability to 'skip', such as the situation I was in...sucks. I'm glad I toggled off, which answers no to the question about participating. After using 1Password's service for seven years I'm looking to move myself and my family to another service. Thank you.
0 -
@Ben, thank you for the thorough reply and sorry for my delayed reply.
I want to start this response by acknowledging, and commending, you and the 1Password team as a whole for your transparency and engagement on this. I didn't do that in my previous post, and that was a miss on my part.
It's truly noticed and appreciated (at least by me :))!
Before getting into quote-replying, I want to call out my experience with the confirmation dialog for enabling/disabling telemetry collection, as it popped up for me today.
I was on a phone call and needed to get my credit card information for that phone call. I bring up 1Password with that goal in mind, only to be presented with the dialog. I needed to:
1. Context switch to that dialog and what the heck it's asking about.
2. Try to make sure I don't miss anything on the phone.
3. Disable the toggle.
4. Don't forget about the phone call.
5. Double-check I didn't miss something to disable. Yes, your dialog is good about having one toggle, but the unfortunate state of the world is that most of these dialogs have multiple switches, some hidden. This meant making sure the dialog didn't scroll or wasn't otherwise obscuring something I needed to disable.
6. Don't forget about the phone call.
7. Click the confirm button twice (I appreciate the extra confirmation and am not saying you should change that part).
8. Fully context switch back to the phone call and search for my credit card info.That experience sucked. In that moment, 1Password was not serving me, the user, it was serving 1Password the company and business.
Sure, that's a one-time experience in 1Password, but you don't exist in a vacuum. Your dialog came after rejecting cookies on a dozen or more websites that day in a similar (albeit worse) dialog.
Even worse, this is exactly how people wind up agreeing to data collection without understanding what they're agreeing to. I had to do all of that rapid context switching and I'm a technical user, actively reading your blog, reading this thread, and engaging with you. There will be many, many users who face this same situation and just mash the "go" button until they can do what they need to do because they have no prior information and can't afford to digest it in the middle of a task.
(Which reminds me, I need to go check my family member's apps to ensure they didn't inadvertently agree to it.)
An improved, user-focused experience: put a soft prompt at the top of the window, similar to your update prompts. Data collection is disabled until that prompt is acted upon by the user, which brings up the current dialog allowing the user to make their choice. This way the dialog is only presented when it's convenient for the user.
The threat model is inherently different, and thus the required tooling is different. Usage data is less sensitive than the data customers store in 1Password. Usage data cannot be tied to an individual outside of our systems, even in its raw form, and our de-identification pipeline strives to decrease the likelihood of a user being identifiable even within our systems. The data is treated with best practices for the threat model.
I guess I place a higher value on that data, in no small part because of how pervasive data collection is across the industry. It's a constant battle at every turn to not provide unpaid data to everyone, and it's been wearing on me for years at this point. Now I have one more thing to pay attention to in this regard (changes in policy happen; bugs happen; disabling is theoretically a one-time event, but as long as the capability exists it will be in the back of my mind).
That's a large part of why I (and I suspect others) are reacting so strongly: 1Password was a safe haven, and it's falling away from that to be yet another source of data collection in our lives. Obviously the fact you aren't selling that data puts you far above those businesses who are, but it's still a step on the path.
Our position hasn't changed with regard to the data customers store within 1Password. This continues to be end-to-end encrypted, and we have no access to any of it. As for why usage data has become a motivating factor, frankly we've found that the data we already have/receive isn't always sufficient to make informed decisions.
Your example is a good one, and I hope the upsides outweigh the downsides for everyone.
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. The entire server-side enrichment pipeline is hosted entirely within 1Password's own infrastructure.
I struggle to see what data strictly needs to be added in server-side. Perhaps there are things I'm missing? Two examples were given in the blog post:
"This enriched metadata is defined and based on specific event types, and can include information such as the account type and if the trial period is active."
The client is well aware of both of those pieces of information based on functionality in the app. The client should be able to tag events with that information. This has the added benefit of ensuring the tags are accurate for the user's client-side experience, which may not match the server state for any number of reasons (e.g. being offline).
My goal isn't to backseat engineer, but to push back on the idea that a giant store of identifiable information is an inevitability. By doing this your implementation is far closer to many others in the industry than your communications seem to acknowledge.
0 -
That experience sucked. In that moment, 1Password was not serving me, the user, it was serving 1Password the company and business.
You have a very important point here. Although I'm in favor of the telemetry in general as I posted previously, I do see the point, and I guess I would have the same bad experience here, in a similar situation.
I remember I had such situations in the past with other apps and websites, and with every one of these, I just wanted to get that popup away as quickly as possible, without reading it, no matter what it said, because I had a different urgent task to do and in mind. And afterwards, I never remember these popups, so whatever it did choose, stayed forever.
This configuration thing is no obligatory decision the user has to do in exactly that moment. It can be postponed, and as long as it is postponed, telemetry can stay off without damage.
If I am reminded in some non stress situation, for example after I finished some task, this would be the proper way. A notification popping up asynchronously, or an email, asking me to revise my config. An interesting thing is also what Samsung does for their Android apps: if something new is added, a red dot appears in all menus leading to that new configuration item. It's a non-intrusive notice to notify the user that here is something new that might be of interest to the user.
1 -
The experience was as unpleasant as it could be:
- A dialog that could not be postponed, while I urgently needed to look up a password
- Telemetry was on by default (so opt-out, as I feared)
Luckily I was already aware this was coming (and bad) so I quickly disabled telemetry. The chance of me ever turning it on is now even lower than before (thanks to this bad experience).
1 -
Reading the comments above, I fear that many user will simply opt in on data collection.
I wonder, when the dialog will hit me.
So far, there is nothing. I've been checking all my settings over and over again, to make sure, I did not miss anything.
And as suggested above: once this gets rolled out to us, I gotta check on my family members to make sure, they have opted out as well.1 -
I am curious about this statement which appears on the 1Password telemetry opt-out screen: “We won’t sell your data to a third party if you decide to opt-in.”
While I have no legal expertise, it seems to me that the statement does not prohibit AgileBits from sharing data with a third party (e.g., to support a joint marketing campaign with another company, or for a barter/trade arrangement in which no cash is exchanged and thus no “sale” occurs).
Can AgileBits please clarify its intent, hopefully confirming that it does not intend to either share or sell “your data to a third party if you decide to opt-in”? (Thank you.)
0 -
So I wonder why DNS-lookups to "telemetry.1passwordservices.com" don't stop after opting out... I mean, it is the most blocked DNS-request in my office..... 5173 requests in seven days. Happens at least on Windows-clients....
0 -
@Pleonasm The team has looking into the DNS lookups and were unable to replicate the issues. Just me trying to think outside the box here, is it possible there are many folks who have not decided on a selection for the feature? If they turn it off the lookups should stop.
Privacy-Preserving Usage Data: Under the Hood
We are committed to collecting only the minimum data necessary and not sharing this raw data outside of our infrastructure.
0 -
@ag_tommy, thank you for your helpful responses to the questions of (1) sharing telemetry data with third parties, and (2) DNS-lookups to "telemetry.1passwordservices.com".
As a matter of curiosity, can you please share the approximate percent of consumers who have elected to participate in the telemetry process?
0 -
As a matter of curiosity, can you please share the approximate percent of consumers who have elected to participate in the telemetry process?
Apologies, but we're not in a position to share this publicly. If the team decides to share that sort of information in the future then it will be published in an article on our blog: 1Password Blog
-Dave
0 -
I am a long time customer of yours, I have recommended you to many people. You used to be the best tool.
When I read the news that you got another round of funding, I was afraid that this would be the end and you would start acting like the other companies.
And I was right. Today I got a prompt on my phone for telemetry with consent checked by default. GDPR aside (such an action is against the regulation. The fact that offices don't do anything about it is another matter), it's not ethical. You are putting your needs ahead of the customers who pay you, thanks to whom you exist!
My annual subscription is about to expire, and thanks to your actions, I know I will not renew for another year.
PS The fact that you use Google captcha on this forum confirms that things are going badly with you. Google has a lot on its conscience, there are other solutions.
As a person who avoids Google, I feel excluded from this forum. I had to bend my rules just to be able to write one comment...0
