tcinotto
commented
3 years ago @tcinotto Upload prototype.
Closed tcinotto closed 3 years ago
tcinotto
commented
3 years ago @tcinotto Upload prototype.
tcinotto
commented
3 years ago Resolving a breach fx monitor.pptx This is a potential prototype (not meant to be prescriptive design) but some ideas.
tcinotto
commented
3 years ago I also think it might be really useful to do some research here. There hasn't been dedicated usability research but from Jennifer: "We had 3 people who resolved a breach in the recent Monitor study. It didn’t make the “cut” of highlights. But the short answer from what I recall is that they ACTUALLY did stuff to resolve the breach. They didn’t just click though, and I think that’s because of the necessary friction that Ryan Gaddis designed into the process. So, it seems from a glance, that the process is usable, and that people actually took action. One participant even went so far as to call the company to ask if they still had her data. Others changed passwords. There was a desire from one participant to delete an account more easily, because some of the breaches were with accounts they didn’t use/care about anymore. There has been no dedicated usability study about resolving breaches or that functionality, though, and I think it would make a lot of sense to put on your backlog! "
Understanding user's mental models and past experiences with resolving and not resolving a breach would be extremely valuable in determining how to reshape this experience.
malqinneh
commented
3 years ago @tcinotto if you have it handy; can you post a screenshot of "you have a data breach" (single) email? I already have "Firefox Monitor found your info in these breaches" trying to see what the difference might be between them.
tcinotto
commented
3 years ago here you go. my email address is hidden by the black box.
malqinneh
commented
3 years ago Thank you @tcinotto! Can you also post the Subject line of the email?
tcinotto
commented
3 years ago Yep here you go!
malqinneh
commented
3 years ago Breach stats using the scripts/breach-stats.js script
malqinneh
commented
3 years ago Mapping of Firefox Monitor notifications experience and resolving a breach:
@jwibowo the switch of info/details on user dashboard (based on number of breaches pending vs resolved) might be of interest
malqinneh
commented
3 years ago Discussed breach resolution recommendations with @lesleyjanenorton today and it came up that - contrary to Row 3, Column I - there are legal constraints stopping us from providing users with a CTA that goes directly to the breached site for changing a password.
Also, Lesley mentioned that "sometimes the site no longer exists, sometimes the site's security standards are so low that we'd be remiss to send them back there" as additional reasons for not offering a direct link to a breached site.
malqinneh
commented
3 years ago Reached out to Michael Feldman to clarify any legal constraints around providing users a CTA (in their breach notification email) to change their email address on the compromised service or website.
malqinneh
commented
3 years ago From Michael Feldman:
I don't have any legal concerns about linking users to websites that have had data breaches to change their passwords. There might be some security issues there, but my understanding is that changing the password that is definitely already breached outweighs the risk of visiting the site again.
@nshadowen314 as it turns out - there are no legal concerns with prompting users to change their password and offering a direct link to the compromised service or website. Are there any security implications that you're aware of?
nshadowen314
commented
3 years ago @malqinneh Good to know.
First, as Jenny mentioned in the slack thread, this might be technically difficult because there are is no standard for where websites locate their "change credential" page, and we would need to find that in order to send people to that location for every webpage/account.
Second, yes, there are security implications that arise from the flow of users learning of a breach and connecting to the page to change their credentials. The main attack vector is a known and potentially growing (due to AI techniques) threat called login spoofing in which an adversary inserts their own link to our flow and takes a user to a webpage that looks highly similar to the intended page. Then the adversary easily collects and steals the person's credentials because they have just directly entered them onto the adversary's page. Because Monitor is clearly a breach identifier, we may be more at risk to these types of attacks because an adversary would know that a user is highly motivated to act and change their credentials from the information they have received from us, and may be less likely to look for signs of fraud (this is called inattentional blindness).
There are ways to mitigate this risk, and it's not to say that we can't or shouldn't still try to link people to the page where they can change their credentials. However we could put some measures in place to address the risks such as linking only to sites that use best practice security protocols (HTTPS only), looking into how other orgs (like have-i-been-pwned) deal with this, and having some mechanism (or education for users) to check the validity of URL.
It would be helpful to know more detail about how the Monitor team has thought about this already, and the reasoning behind the decisions for the current user flow in regards to addressing a breach. Then, perhaps we can go from there!
malqinneh
commented
3 years ago Thanks @nshadowen314 -- after looping in with Nicole and confirming with Thomas (S&P lead) we will put this on hold until we hear back from Thomas and Wennie tomorrow (after their meeting). Will update this item with new information by Friday, September 25.
malqinneh
commented
3 years ago @tcinotto quick update; Thomas is on PTO and will be back Wednesday (Sep 30). Will loop in with him when he's back and update the issue then. Let me know if you have any questions in the meantime!
tcinotto
commented
3 years ago Great! I have a meeting scheduled tomorrow too with Thomas if we all want to chat through that in the meeting too.
On Tue, Sep 29, 2020 at 8:40 AM Mustafa Al-Qinneh notifications@github.com wrote:
@tcinotto https://github.com/tcinotto quick update; Thomas is on PTO and will be back Wednesday (Sep 30). Will loop in with him when he's back and update the issue then. Let me know if you have any questions in the meantime!
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozilla/blurts-server/issues/1932#issuecomment-700791720, or unsubscribe https://github.com/notifications/unsubscribe-auth/AKFMWH6XR565NK5ALLO3HTTSIH5X7ANCNFSM4RGECJEQ .
Decision(s)
XD
Proposed project plan
Goal
Subtasks
Timeline and priority (if applicable)
Related issues
Additional context
Original ask
I would like to explore improving the Firefox Monitor: Resolve Breach User Flow.
From qualitative user research we see that many users see Firefox Monitor as a set it and forget service until they receive alerts that they have been involved in a breach. When a user is involved in a breach we have a list of actions they can take (both immediate and more time consuming actions) to help try to remediate the breach. They are then prompted with a “resolved breach” action, which they can select if they’ve resolved a breach. We only see around 6% of breaches being resolved.
I am going to comb through some of our research to see if we have existing data points, but some more explorations could be helpful here. It would be interesting to do research to understand how user’s resolve a breach and their experiences/mindset.
This current flow is potentially problematic: Emails to users have a CTA: Resolve this breach but when a user visits a breach detail page like: https://monitor.firefox.com/breach-details/Zynga we do not mention anything about Resolving a breach, until the “Marking this breach as resolved.” We have a small short term fix here, but would like to ensure that we are making this a seamless and easily understood flow for our users, especially when they are feeling in a state of vulnerability after discovering they were in a breach. https://github.com/mozilla/blurts-server/issues/1915https://github.com/mozilla/blurts-server/issues/1915 Is this the best and simplest flow for users? Taking them from an email to firefox monitor then monitor to another website to resolve a breach? We present some actions that a user can take to resolve a breach, but these actions are a mix of immediate actions and many longer term hygiene actions. Then we ask a user to “resolve their breach” after doing the mix of actions. Some of these actions could take a lot of time to do and aren’t specific just to this breach (like getting a VPN). I’d like us to find ways to focus on what is immediately actionable in terms of steps when a user’s data has been exposed so this process feels manageable. Then find another way to surface and encourage users to take more long term data hygiene behaviors. Immediate steps a user could take: Change their password for this account. Risk: Some password flows are easy to find and link to, others have been more challenging. This might be very manual for us each time we add a breach and could slow down our time it takes to add a breach in. Read through the company’s breach statement to understand if the company is offering any remediations like free credit monitoring etc.. Most companies have a breach statement and many do offer some types of remediation, but it’s not fully a standard practice. This might also be challenging for breaches that are not in English unless we can leverage community member’s support or directly interact with these companies. Next steps: Change their password for any accounts that are using the same password to prevent credential stuffing attacks. We should encourage users not to ever use the same password across accounts. This should be a user’s immediate next step after changing their password for the breached account, but in reality we can see that this might take a lot of time and effort for someone. Also how might a user know all the accounts that use the same password? It is the correct thing to do but is it truly realistic that a user would go throw this step to have their breach resolved? Monitor their other accounts for any suspicious activity. Longer term steps: Use a password manager Set up 2FA on accounts that offer it Get a VPN General recommendations (pulled from monitor’s existing steps): Don’t use the same password across multiple accounts Avoid sharing your phone number Avoid using personal info in pins Avoid using addresses in passwords Be cautious about giving personal info
Notes: For data aggregators like: https://monitor.firefox.com/breach-details/Apollo there are no real steps you can take like changing your password at this point in time. We are also looking to add spam lists which are surfaced in HIBP’s database, but again there are no actions a user can take at that time. Monitor and Lockwise together can be very powerful to help protect a user and change their credentials, but as lockwise isn’t offered when non-firefox browser users visit Monitor this can be challenging.