4 ms·

I think putting in the effort and basically hard coding many popular solutions is an underutilized strategy in dealing with these sorts of things. Many times I

I think putting in the effort and basically hard coding many popular solutions is an underutilized strategy in dealing with these sorts of things. Many times I see programmers try to come up with a general solutions which becomes a much more difficult sort of problem.

gumby 9y ago
> Many times I see programmers try to come up with a general solutions which becomes a much more difficult sort of problem. Ouch, are you looking at me? I just chopped out a fragile "general case" implementation of something today and replaced it with something that robustly gets the job done for the small number of cases we have. I was the writer of that fragle cruft a couple of months ago.
twhb 9y ago
The problem is getting hardcoded values updated as websites change. This is where it’s useful to be Apple: if your website breaks 1Password then that’s 1Password’s problem; if your website breaks iPhones then that’s your problem.
- dewey 9y ago
  It’s not exactly breaking them. You’d just have to adjust the pre filled values with something that fits the requirements of the site which is something most people are already used to anyway.
  - st3fan 9y ago
    If you have ever used Safari's password generation feature, you know that is pretty much impossible.
niftich 9y ago
Hand-harvesting data is a perfectly legitimate solution, although it comes with a steep initial cost and an ongoing maintenance cost. However, this enables the data to be curated and validated. For this, they wanted to accurately capture the exact rules each site uses, which makes sense to do out-of-band -- ahead of time, and validated by humans -- than to try to discover from the site dynamically, especially because the latter solution, in a world without sites making their own requirements available in a programmatically readable format, would have been complex and brittle. In a program, this sort of data may be hard-coded directly in the code, or dynamically loaded from config files. That's largely an implementation detail.
- Bromskloss 9y ago
  > a world without sites making their own requirements available in a programmatically readable format About that, is there a standardised way to do it?
  - chrismorgan 9y ago
    Not well for arbitrary rules, but for simple syntactic rules at least, regular expressions in the `pattern` attribute of the <input type=password> will do it. Bonus points for using look-ahead assertions for more complex restrictions. The following, for example, creates a password field that requires exactly six ASCII letters, including at least one uppercase and one lowercase letter, and forbidding having the same character twice in a row: <input type=password pattern="(?!.*(.)\1)(?=.*[a-z])(?=.*[A-Z])[A-Za-z]{6}">
    - blattimwind 9y ago
      If your stateless password rules are stronger than a backtracking RE engine, I have bad news for you.
      - deleted 9y ago
        [deleted]
      - chrismorgan 9y ago
        Few password rules can’t be expressed in such a regular expression, but there are definitely some where doing is impractical or absurd. To take an example I’m familiar with, on FastMail and Topicbox we use Dropbox’s zxcvbn (a truly excellent library embodying a sound approach to password security), and flat-out deny passwords that are expected to take less than 10⁶ guesses, as too weak. I shudder to think how many megabytes long a regular expression to validate that would be, and how atrociously it would perform. (Other rules may embed restrictions on use of names, dates, &c. associated with the account. Those may be painful to shoehorn into a regular expression, but doing so is probably generally not too impractical.) Fortunately, the likes of zxcvbn are very password-generator-friendly, as they’re encouraging the sorts of strong passwords password generators like to make; so long as they also have similar accidentally-weak-generated-password protection, zxcvbn is unlikely to cause any trouble and can probably be ignored in defining a pattern for the generator to use. So long as the form uses setCustomValidity to do its complaining when pattern isn’t enough, and the browser’s password generator knows to look at that and try again, you’re good to go. (This is all hypothetical—I don’t believe any tools actually look at password field validation to see if they did the right thing.)
xya3453 9y ago
It's a perfect example of "doing things that don't scale", an immediate UX improvement and differentiator in the sea of password managers.

gumby 9y ago

> Many times I see programmers try to come up with a general solutions which becomes a much more difficult sort of problem. Ouch, are you looking at me? I just chopped out a fragile "general case" implementation of something today and replaced it with something that robustly gets the job done for the small number of cases we have. I was the writer of that fragle cruft a couple of months ago.

twhb 9y ago

The problem is getting hardcoded values updated as websites change. This is where it’s useful to be Apple: if your website breaks 1Password then that’s 1Password’s problem; if your website breaks iPhones then that’s your problem.

dewey 9y ago
It’s not exactly breaking them. You’d just have to adjust the pre filled values with something that fits the requirements of the site which is something most people are already used to anyway.
- st3fan 9y ago
  If you have ever used Safari's password generation feature, you know that is pretty much impossible.

niftich 9y ago

Hand-harvesting data is a perfectly legitimate solution, although it comes with a steep initial cost and an ongoing maintenance cost. However, this enables the data to be curated and validated. For this, they wanted to accurately capture the exact rules each site uses, which makes sense to do out-of-band -- ahead of time, and validated by humans -- than to try to discover from the site dynamically, especially because the latter solution, in a world without sites making their own requirements available in a programmatically readable format, would have been complex and brittle. In a program, this sort of data may be hard-coded directly in the code, or dynamically loaded from config files. That's largely an implementation detail.

Bromskloss 9y ago
> a world without sites making their own requirements available in a programmatically readable format About that, is there a standardised way to do it?
- chrismorgan 9y ago
  Not well for arbitrary rules, but for simple syntactic rules at least, regular expressions in the `pattern` attribute of the <input type=password> will do it. Bonus points for using look-ahead assertions for more complex restrictions. The following, for example, creates a password field that requires exactly six ASCII letters, including at least one uppercase and one lowercase letter, and forbidding having the same character twice in a row: <input type=password pattern="(?!.*(.)\1)(?=.*[a-z])(?=.*[A-Z])[A-Za-z]{6}">
  - blattimwind 9y ago
    If your stateless password rules are stronger than a backtracking RE engine, I have bad news for you.
    - deleted 9y ago
      [deleted]
    - chrismorgan 9y ago
      Few password rules can’t be expressed in such a regular expression, but there are definitely some where doing is impractical or absurd. To take an example I’m familiar with, on FastMail and Topicbox we use Dropbox’s zxcvbn (a truly excellent library embodying a sound approach to password security), and flat-out deny passwords that are expected to take less than 10⁶ guesses, as too weak. I shudder to think how many megabytes long a regular expression to validate that would be, and how atrociously it would perform. (Other rules may embed restrictions on use of names, dates, &c. associated with the account. Those may be painful to shoehorn into a regular expression, but doing so is probably generally not too impractical.) Fortunately, the likes of zxcvbn are very password-generator-friendly, as they’re encouraging the sorts of strong passwords password generators like to make; so long as they also have similar accidentally-weak-generated-password protection, zxcvbn is unlikely to cause any trouble and can probably be ignored in defining a pattern for the generator to use. So long as the form uses setCustomValidity to do its complaining when pattern isn’t enough, and the browser’s password generator knows to look at that and try again, you’re good to go. (This is all hypothetical—I don’t believe any tools actually look at password field validation to see if they did the right thing.)

xya3453 9y ago

It's a perfect example of "doing things that don't scale", an immediate UX improvement and differentiator in the sea of password managers.