Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add metrics for user's use of password managers #232

Closed
gene1wood opened this issue Sep 19, 2018 · 12 comments
Closed

Add metrics for user's use of password managers #232

gene1wood opened this issue Sep 19, 2018 · 12 comments
Assignees

Comments

@gene1wood
Copy link
Contributor

gene1wood commented Sep 19, 2018

In order to gather metrics on our users' use of password managers, I'd like to add a small test when they interact with the password field for LDAP login. I'd also like to emit the results of this test to Google Analytics.

Please add the following functionality to NLX. I've tested this with Lastpass and it correctly differentiates a human from Lastpass.

Add Google Analytics

Add in Google Analytics using a Do Not Track respecting wrapper.

The GA code looks like this.

Our GA tracking code for NLX is UA-84301250-4. If you don't have access to our Mozilla Google Analytics let me know and I can probably help get you access.

The Mozilla recommended way to wrap this to respect DNT is described here by Schalk Neethling (Shalk had me use archive.org while he figures out why his blog is down).

I don't know if you want to use his dnt-helper script or just incorporate the logic into NLX.

One thing I see missing from these examples is what to do so that the ga method which is called later doesn't cause an error as if DNT is set to yes, the ga method won't be defined.

Record the password entry timing

In my code I'm using jQuery to create an event triggered function on keypress in the password field. If we don't use jQuery I'm assuming it's trivial to do this without it.

Record the epoch time when the user first types a key in the field and when they last type a key. This is to accommodate password managers that actually type keys.

Some password managers don't even trigger keypresses which makes it all the easier

Check the timing and emit the metric

When the user submits their LDAP password, check the timing of the keypresses you've recorded and emit events to GA

I'm proposing an eventCategory of ldap-login-form and eventActions of machine-typed-password and human-typed-password. Feel free to suggest better ideas.

@hidde
Copy link
Contributor

hidde commented Oct 1, 2018

Thanks @gene1wood. I'll try and implement this GA event in the current sprint.

NLX has a fireGAEvent() helper function which we can use for this; it only runs if Google Analytics was initialised (which is only the case when user does not have Do Not Track enabled… sorry for the double negation).

cc @hmitsch

@hidde hidde self-assigned this Oct 1, 2018
@hidde
Copy link
Contributor

hidde commented Oct 10, 2018

Our current eventCategorys are:

  • Screen change (e.g. Continued as LDAP)
  • Auto-login (e.g. Already auto-logged in, aborting)
  • Hiding (e.g. Hiding Firefox Accounts, as it is unsupported)
  • Security (e.g. NLX was loaded inside an iframe)
  • Autorisation (e.g. Authorising with GitHub)

For this particular use case, I would suggest this:

eventCategory eventAction
Password entry Manual
Password entry Machine

@hmitsch
Copy link

hmitsch commented Oct 11, 2018

These GA category and actions look great!

hidde added a commit to hidde/auth0-custom-lock that referenced this issue Oct 22, 2018
To satisfy mozilla-iam#232

Signed-off-by: Hidde de Vries <[email protected]>
@hidde
Copy link
Contributor

hidde commented Oct 23, 2018

@gene1wood's heuristic is now implemented and visible in staging. This can be tested, because our Google Analytics functionality will:

  • in staging: log to the Dev Tools console
  • in production: send an event to Google Analytics

(ie whatever you see appear in Dev Tools in staging, will be logged in GA for users that have DNT disabled).

@rleitan this is now ready for test. I found it recognises LastPass input as 'machine', but 1Password as 'human'. Looking forward to hearing what your tests show.

@gene1wood
Copy link
Contributor Author

Interesting. I'm curious how 1Password fills the password in to produce the timing that maps to Human. I'll see if I can find someone with 1Password today and debug it.

@hmitsch
Copy link

hmitsch commented Oct 23, 2018

@gene1wood I am a 1Password user. If you want, we can look at this during my (late) evening hours.

@hidde
Copy link
Contributor

hidde commented Oct 23, 2018

I've just readded the code that logs key presses and start/end to the Console in the browser Dev Tools, for easier debugging.

@hmitsch
Copy link

hmitsch commented Oct 23, 2018

I can confirm. My 1Password is also recognized as human. 😢

image

@rleitan
Copy link

rleitan commented Oct 25, 2018

Metrics for user's use of password managers testing on Mac (Safari) is blocked because of bug #239

@gene1wood
Copy link
Contributor Author

gene1wood commented Nov 1, 2018

This is what console output is for a lastpass filled login

Lastpass

Lastpass

1Password

1Password

@hidde As someone who understands the flow a bit better, do these vastly different console outputs between lastpass and 1password reveal anything to you?

Why does event.which return 0? Why does console.table output for 1password but not lastpass?

@gene1wood
Copy link
Contributor Author

gene1wood commented Nov 5, 2018

I've resolved the issue with 1Password and the new code is live in dev.

I've created a PR from development to master, #245

@gene1wood
Copy link
Contributor Author

gene1wood commented Nov 12, 2018

This is now live in production as of 1:56pm PDT

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants