Hacker News Reader

Comment by athenot | Hacker News Reader

The <input> elements are not hidden, they are just drawn off the screen. So the browser would have to determine if the item is visible to the user, which is not trivial. Should autofill skip regular form elements that are just a little below the viewport?

Maybe some feedback from the browser detailing which datapoints were autofilled. I don't know...

View on HN

My thinking is the user should explicitly autofill each field. Yes, it involves more work, but it's really not much work to click on a field and pick the right autofill value.

I'm always concerned about using autofill because browsers eagerly fill any field they have data for.

This is how Firefox's autofill worked for me just now. Glad to see some more justification for getting off the Google train!

Firefox works that way and is in my view a much saner default. The best solution used to be in Opera long ago where they showed a little dropdown with the information that was going to be autofilled. You could accept it or deny it.

That sounds like a fantastic idea for an extention.

That would be super bad user experience. Simple and better alternative would be to show everything being auto filled in page in a browser dialog and confirm from user before actually auto filling it.

Another method would be to show a user a list of all fields that are about to be filled in as part of the autocomplete prompt. This isn't very scalable for massive forms, but should be enough of an alert to a user that something is amiss on screen to make up for those cases.

I like this best too. All it does is add one more click (when you select the auto fill info, it pops up with all the data and you just approve) and it also solves a lot of wrong fills that can happen.

There's often sites that are poorly coded, and autofills ends up putting my phone number in some random field and I have to manually delete it.

You can scale it by classifying fields into groups. Then user can decide gradually if he wants to share his name. Later, application may ask for location (browsers can already do this), employer info, contact data etc.

What is needed is integration with permission granting mechanisms, which already exist in browsers.

Actually this problem looks is a lot like how Android App permissions are managed. Not long ago some apps used to ask you at install time that they want access to your google email, contacts, wifi and so on. A better app permission model (which I think is now in android) is to ask these "lazily" as the app needs them and let the user decide at that point.

Safari does this already

In Safari, the autofill dropdown explicitly said it would fill "email, work, address" (and I guess it implies that name is included).

How obvious is this to the user? This seems like a detail that'd be easily overlooked.

It's quite obvious. Just tried it myself [1].

You first select an identity to use to auto-fill. When doing that, it will tell you the data it will insert in the subtitle.

You can also click customize and choose what data to place into each field.

[1] - http://imgur.com/a/HL59q

It's obvious in Safari but not so in Chrome

This is exactly how signing in to gmail works if the browser has the credentials of the account saved.

Initially only the input field for e-mail is displayed. There's also a, hidden to the user's eyes, _next step_ with the password field that gets populated if the browser auto-fills it.

> So the browser would have to determine if the item is visible to the user, which is not trivial

This is not terribly difficult, browsers need to know what is visible because they have to actually display it. If an element isn't drawn it shouldn't be autofilled.

> Should autofill skip regular form elements that are just a little below the viewport?

Sure, but then the attacker can draw the fields within the 'visible' document, but below the 'fold'. If the browser chooses not to fill fields like that, it breaks a lot of autofill on long pages. Those two cases aren't significantly different.

Not necessarily. The browser often paints a much larger area than fits in the viewport, then hands it off to the GPU. (This can be cause performance issues for very tall scrollable pages, which is why I've run into it.)

Well, then simply make them height:0px or put a <div> with a white background over it. Change the input and make it text-color: white; background-color: white; Change it's z-index to be lower than your other elements, etc.

opacity: 0.01;

This makes the case that auto fill just ain't that secure, I guess if we use it we just need to accept that.

There's no need to "just accept" that it's not secure. We need to make it secure. This is a tedious/hard problem, yes. IMHO we've (people) solved tougher problems :)

> If an element isn't drawn it shouldn't be autofilled.

So if a form is too long and you need to scroll, all those fields you can't see won't be auto-filled? Sounds pretty terrible IMO.

To me (as a non autofill user), the published bug sounds way more harmful than a little inconvenience.

It's not just an inconvenience – it's broken and unexpected UI behaviour.

Well why not have it autofill on-draw?

It'd be easy to move the hidden elements on to the screen when the user clicks the submit button, so they'd be filled in and the form would then be submitted, and the information 'phished'.

The solution to this problem is to inform the user which fields will be completed by autofill, with a "not currently shown" highlight on any fields that are currently off the screen so the user understands what's happening.

What if another element is drawn in front of it, and though? I feel like there are a huge number of possible tricks to hide elements on page and trick the browser into thinking they're visible.

  <div style="font-family: Custom non-printing font 101">
    <input type="text" name="address"/>
    <input type="text" name="ssn"/>
  </div>

http://www.catb.org/jargon/html/F/Flyspeck-3.html

Adobe made a font like this, adobe blank: https://github.com/adobe-fonts/adobe-blank

How many pixels does an input need to occupy before it's considered "visible"?

Problem is that a form might be longer or wider than the viewport, which would result in "hidden" elements in genuine browsers too.

It's not trivial but if they do that, then we will be able to finally prevent the browser from autocompleting the fields incorrectly and end this bullsh1t: https://bugs.chromium.org/p/chromium/issues/detail?id=468153

>> which is not trivial

but is something the browser already does, so it's no extra effort.

Reply on news.ycombinator.com