151–160 of 393 posts
Earlier quoted context omitted.
No, but Safari routinely causes many problems that seem utterly basic for Firefox/Chrome.
Because you develop on Chrome, and only occasionally test on Safari. Try the other way around and see which one is buggy.
Earlier quoted context omitted.
Yes. The Chrome devs refuse to accept there are viable cases for not allowing autocomplete.
Are there any viable cases?
Chrome also breaks CSS conventions and mark it as wontfix. Basically Chrome is just awful.
I vaguely remember Apple saying they use ML to parse forms... Could be why. Personally I have this weird thing with Safari passwords - there's 2 sites where password dropdown would appear at top left corner for whatever reason.
Earlier quoted context omitted.
I tend to side with Chrome here. IMHO, the decision of whether to show auto-complete should be with the user and not with the website. When I install an auto-complete add-on or activate a browser feature, I expect the AC to be available on ALL input fields, whether the site owner thought that would be a good idea or not. Now, there is a valid question on how the user should be able to configure the AC behavior, and h…
> IMHO, the decision of whether to show auto-complete should be with the user and not with the website. There's a setting in Chrome where you can disable auto-complete on a field-by-field basis?
Earlier quoted context omitted.
autocomplete="one-time-code" Any others?
good point! But as soon as browsers stop autocompleting fields marked with autocomplete="one-time-code", won't website developers start marking _all_ input fields with this tag? After all, why do people put autocomplete="off" on input fields anyway?
Earlier quoted context omitted.
Yes, but let's be fair, it's a galaxy better than writing it on a post-it or password booklet, and still way better than using a memorable passphrase which will get reused and then leaked. Besides, you can encrypt the local storage with a master password (and if you accept online as a requirement, you could even add 2FA to that).
A (well handled) physical password booklet is much more secure for the average home user, who is unlikely to ever be individually targetted by a third party attacker, let alone to the level of the attacker physically breaking into their home. My parents being victims of a zero-day vulnerability or installing a malicious application by mistake are much more realistic scenarios than their house being broken into and th…
Earlier quoted context omitted.
The seed is all you need. The device is unnecessary.
Sure.
In fact, in Google Authenticator you can even conveniently export all running TOTP to another Google Authenticator without any connection with the apps or anything else whatsoever.
Earlier quoted context omitted.
The product I work on now logs users out after 15 minutes. It's a service where the average user would probably spend a good few hours of their day. We're actively harming the user experience (and driving paying customers away) because of some "expert" advice.
After 15 minutes, or 15 minutes of inactivity? The latter is defensible at least, in e.g. a public area where there is a risk of people leaving their desktops without locking them. I mean that's another policy issue that can be addressed (a policy that locks a system after x amount of inactivity), but as an app developer you can't know much about the system things are running on.
Earlier quoted context omitted.
No, but Safari routinely causes many problems that seem utterly basic for Firefox/Chrome.
Because you develop on Chrome, and only occasionally test on Safari. Try the other way around and see which one is buggy.