Increase adoption by offering integration options for developers

LogicSabre

1Password X already embeds HTML tags into web pages to offer context menus for filling login forms. It does this exclusively through attempting to correctly guess what constitutes a login form and what does not. As a result, we end up with false positives like multiple email fields on one form all having the little 1Password X helper icon in the inputs and false negatives like a TOTP token field not having one.

If developers could have a guide to work from to know how to indicate a form is a login form and what type of data fields for 1Password are present in that form, it'd make your product just that much more accurate.

Consider something like this:

<form action="/login/" method="post" data-op-type="form">
  <input type="text" name="lkjahdsfkl" data-op-type="username" />
  <input type="password" name="kljhawlekurliu" data-op-type="password" />
  <input type="text" name="lkihaserliough" data-op-type="totp" />
  <input type="text" name="email" data-op-type="none" />
  <input type="text" name="username" data-op-type="none" />
  <input type="password" name="password" data-op-type="none" />
</form>

Or, consider the following which would tell 1Password that nothing about the form references login data:

<form action="/login/" method="post" data-op-type="none">
  [...]
</form>

The result of this would be that the appropriate fields would be detected and filled with the appropriate values for the end user while false positives and negatives are potentially eliminated. This could also dovetail nicely with your identity cards feature.

This could, of course, be beefed up even more with requiring developers to register a developer account, adding domains they manage to their account (complete with several methods to prove ownership like DNS change, HTML file with a particular value at a predefined location, etc.), and public keys they include in the form tag that the 1Password X extension could verify for existence and permission to manage the domain the page is located on. If it can't be validated for the domain the page is hosted on, the data-op-* attributes are ignored.

For example:

<form action="/login/" method="post" data-op-type="form" data-op-key="43b60c75c3bf45a3bbd371309eef43b7">
  <input type="text" name="lkjahdsfkl" data-op-type="username" />
  <input type="password" name="kljhawlekurliu" data-op-type="password" />
  <input type="text" name="lkihaserliough" data-op-type="totp" />
  <input type="text" name="email" data-op-type="none" />
  <input type="text" name="username" data-op-type="none" />
  <input type="password" name="password" data-op-type="none" />
</form>

Curious to hear your thoughts on this.

---

1Password Version: Not Provided
Extension Version: X
OS Version: Not Provided
Sync Type: Not Provided

Mitch

Hey @LogicSabre,

This is a really great idea and one we've talked about many, many times. And those discussions have only gotten more frequent in the age of 1Password X. It's challenging enough to fill a password in the right place upon request, but another thing altogether to identify a login form when a page loads without finding false positives.

It's tempting to write up a spec for "1Password-compatible forms". Make it an open standard and work with the other password managers, like we did several years ago on iOS with our 1Password app extension.

But I personally hope we don't have to go that way, because there already is a way for web developers to ensure compatibility with 1Password — and at the same time, improve accessibility, usability, and performance: use semantic HTML.

Some examples:

• Use <form> tags to group logical forms, so we won't draw little 1Password icons all over the place or in the wrong places.
• Use <submit> fields and a form action, so we can submit forms and detect submissions reliably.
• Set the type attribute on input fields semantically instead of making every input type=text.
• Use autocomplete attributes on password fields so we know when to suggest a random password.
• Use the maxlength attribute so we know how long a generated password can be

The list goes on. These are simple requirements, but I can tell you horror stories about sites that ignore all of the above and are structured in completely non-standard ways. One example that made me tear my beard out recently was a site which used an image as its submit button for a form. There was no way to detect it short of adding a custom exception.

If every page was written semantically, there'd be no need for custom op attributes. As is, we need to employ all sorts of rules, heuristics — even machine learning — to make decisions on pages.

I'd love to provide guidance for developers, as you've suggested. We have an article about compatible website design that desperately needs to be updated and fleshed out, and you've given me motivation to do so. :)

-Mitch

LogicSabre

If every page was written semantically, there'd be no need for custom op attributes.

Mitch, I can assure you that even semantically written pages could still use some help from the developer. Take any login form that follows up with a TOTP token field on the subsequent page. I already know that one issue you're struggling with is correctly identifying TOTP token fields for sites that use MFA and being able to assist the user of your extension to properly fill that field. I've suggested using the previous approach of copying the TOTP to the clipboard, but was told by Brenty in another thread that it "wasn't possible" (which I don't fully accept as an accurate answer). So, barring that solution, the only other is to detect the field. How much easier would it be for the extension if it could just look for a field with a data attribute identifying the field as one that's expecting a TOTP token? Even better, this self-identification would aid in your machine learning as you could use the heuristics around this particular field to better identify them on other sites that aren't self-identifying.

AGAlumB

@LogicSabre: Begging your pardon, that's totally not what I said. I apologize if my comments were unclear in the context of a more general discussion though. You're right that TOTP fields are a bit of a specific case, and we continue to evaluate different strategies with regard to filling in general as well. Thanks for your suggestions here! :)

LogicSabre

Brenty, my mistake. My original reading came off as "we can't because... (list of reasons)". My recollection may have skewed my perception of your response even further in that direction than I'd originally read it. Going back and reading it now, I see that's not at all what you said.

For context, I develop software, too, and often have to resort to answers that read as "can't" or "won't" because I don't have the energy to explain that "it's difficult" and "cost/benefit analysis seriously impacts this item's priority" and "are you sure you want to know all the nitty gritty details of why it's complicated?"

At the end of the day, 1Password is one of the most mature, useful, and regularly used services/pieces of software I use. I'm just trying to offer my two bits about how to make it even better, how to get more people using it, etc.

AGAlumB

@LogicSabre: Hey, no worries! And I hear you: "can't" and "won't" are a lot easier than trying to give a long explanation that may or may not make us cringe at later when re-reading! :lol: Thanks for not only being passionate about 1Password like we are, but also understanding where we're coming from when we err on the side of brevity now and then. The best is yet to come. I'll leave it at that for now. ;)