Sign-up form best practices
HTML-код
- Опубликовано: 16 сен 2024
- Help your users sign up, sign in, and manage their account details with a minimum of fuss.
Resources:
Sign-up form best practices → goo.gle/39ct4Q9
Speaker: Sam Dutton
Subscribe to Google Chrome Developers here → goo.gle/Chrome...
Watch all Chrome Developer Summit sessions here → goo.gle/cds20-...
#chromedevsummit #chrome #formbestpractice
event: Chrome Dev Summit 2020; re_ty: Publish; product: Chrome - General; fullname: Sam Dutton;
This was great to listen to. Easily digestable and informative.
Thank you!
Federated logins and password managers are totally adapted when you want to reduce friction, but are not exactly E2E encryption friendly, nor Intelligence Agencies safe. Great summary by the way. Special Kudos for the "Do not ask users to change password", OWASP mention, unicode regexp.
Thank you!
Thanks Denis!
The real elephant in the room is the Identity Providers who does the behavior tracking of my user base.
I never really realized that this could be an issue. I haven't been able to find a good source to read more on this. Do you have anything I could read?
@@marcframe7449 Just think of basic http request. How much info you can collect? Time, device, ip, location, regularity, etc, etc. On top of that how much users use this auth method. Why does this service exists? And for free. Just out of a good will? I don't think any of those providers will tell you what they do with this data behind the scenes.
@@Oswee ya I completely agree, the whole mantra "if you aren't paying, you're the product" is definitely true. I was just wondering if you knew of an indepth explanation of this.
federated login is unfortunately wayyy too convenient, so I don't see this going away. I think that password managers are like half the way there, but the average user will still prefer a one click solution over the 3-5 clicks it takes for a password manager to create an account.
Now that I think of it, I probably shouldn't even be using Chrome's built in password manager.
I'd like to see these companies commit to not tracking the use of the federated identities, perhaps this will be something pushed by Apple with their identity provider.
@@marcframe7449 ... i have no any metrics... but... it could be interesting just to measure the new subscription rate increase when 3rd party provider is enabled vs when it is not. Stickiness. Churn... etc. I personally don't think that just this one option will increase user base/loyalty vs in-house auth. Or the difference will be insignificant. Thou... i need to make deeper research.
Also... it all strongly depends on the app type.
I mostly work in enterprise app space.
If some day i will enable Google API... i will instantly loose all my customers. :) Can you imagine some bank enabling Google Oauth??? Or warehouse management system, etc. Or government Tax Office? I can't.
For the low value products like endless ToDo lists, calendars, cat picture galleries, blogs and other time waster apps/pages it's probably OK to enable 3rd party Oauth as the whole business model is based on the advertisements.
Apparently Facebook use this to monitor businesses who may be competitors and use it to either copy their products or buy them.
I'd like to hear your comments on "security questions". It seems like every bank requires them.
As always, very nice summary and right on point with the priorities.
Thanks Mirko!
Always great and clear lessons with good examples. Thank you Sam!
Thank you Sjors!
Very helpful. I literally watched his previous video on form best practices a few days ago
Thanks - hope they're useful.
Im not sure about OAuth logins. Many people I know save their passwords either in browser or password managers. So there is really no need to use FB or Google. Also creating accounts is super easy these days, it's a one time thing and I get to save different, strong password across websites.
Please tell this to my bank. All accounts I've had in multiple banks want me to set a new password every week, and don't support pasting or autofill!!! They even log me out every time I close the app. I need to handle family accounts and it's so frustrating.
For a bank this is reasonable. For a blog page it's too much. They are trying to prevent other people on a shared device from accessing your account.
@@Manivelarino Exactly what TPM is built for, isn't it? Almost all Password Managers are definitely complemented with a second factor verification, either with TPM, FIDO, or a Pin at the least. But what they have accomplished isn't usable security. If they still would like to claim otherwise, why do they use OTPs and simple button confirmation for transactions? Even that is critically a shared-device issue, isn't it?
@@VarunGupta3009 Yea enforcing those measures only on untrusted devices and allowing the user to use a password manager definitely seems like the way to go. Making things too hard to use doesn't make them safe.
@@Manivelarino Exactly. I hope they realise this soon.
Great tips. Thank you
Thank you so much for this gold mine pack of information!
Thank you - much appreciated!
Unfortunately, autocomplete="email" does not work every time, and Chrome saves Only the password with a blank first field.
The solution for this case is to use autocomplete="username", id for the input type is username too, and the name of the field is still email - it is not needed to change it to a username.
'françoise'.match(/[\p{L} ]+/gmu) -> ["françoise"]
'𒀀𒀃𒀆𒀟𒈫𒇺𒌐𒉺'.match(/[\p{L} ]+/gmu) -> ["𒀀𒀃𒀆𒀟𒈫𒇺𒌐𒉺"]
It requires the u (unicode) modifier
I will copy and paste that in my terminal and see what happens
So good. Thank you, Sam.
How do you transmit password in non-plain text ? It “sounds” secure but almost impossible to do using a client/server architecture.
Storing hashed/salted password on the server is a no brained and fairly straightforward after receiving it in plain text from the client.
Can anyone explain how this should be done properly ?
The dislikes are companies that don't follow theese tips...
how the .well-known/changepassword need to do?
👍👍👍
Grid inspect please.
Yes indeed, make it so easy to change password, exactly like google account 😶😶😶
2:20 why do they still use var? Am I missing something?
Could be transpiled code? const/let/var gets transpiled to var after transpiling.
The bigger picture idea behind these naming conventions is that let/const are as benefit to you as a programmer while writing as a means to distinguish scope and intention, to self document through clearer semantics, and though these, you're able to check yourself before making mistakes such as reassigning something never meant to be reassigned. In addition you'll create more readable code that others will appreciate in the future. If you optimize code for machine/computer - you may notice that these are removed and replaced with "var" -- partly for compatibility with older browsers, partly because the machine/computer doesn't care. In this example, "var" is used for educational readability. Many viewers will quickly recognize "var" as variable even if coming from another language background, whereas "let" or "const" may confuse some viewers and require additional explanation.
Gah! I copied and pasted some old code and totally missed this. Thanks for the heads-up. I may have to re-edit :).
Okay
new-password doesn't work for me
Ha, anyone else read "Sign-up for best practices"? Sign me up!
👍👍Sign me up too!
@twilio watch this please. 🤦🏻♂️
pwned is pronounced owned🤷🏾♂️