4 ms·

Autofill for offscreen elements gives me the creeps even without the data getting misinterpreted

by VMG 7y ago

dmix 7y ago
This is why form elements should never be hidden after loading. Display none should be the default in the HTML for non-relevant content, which should be enough for most autofillers. It also prevents flashing of content when autofillers try to populate it, causing the hiding to delay, which I recently saw in a production app. Frameworks like React and Vue don’t even render the HTML into the DOM until conditions are met so the situation is improving. Another positive step away from jQuery hackery!
- pantalaimon 7y ago
  If you want to be malicious and capture wrong auto fill data, wouldn't a simple AJAX request on change be enough to capture sensitive data before the user gets a chance to correct it?
  - AJ007 7y ago
    Yes, and there are popular third party analytics platforms that record all activity on a page, which includes not just every key press, but the speed at which it was done, with or without a submission of the form. Web browsers should never, ever use auto fill unless the user has already entered that information on that domain already. Popular domains that host third party content should never be able to auto fill.
  - HeavyStorm 7y ago
    I'm not really sure but I think the behavior is a bit different with autofill. While the browser show the field highlighted, the data is there for _the user_ but the actual form field has not been actually changed and no dom event is fired.
- meredydd 7y ago
  If you think late rendering or "display:none" will put Chrome off, think again! The anvil.works IDE is Angular, so it's all rendered post-loading, and Chrome still autofills the weirdest things. Relentlessly. Search boxes? Sure! App titles? Yeah, one week a bunch of our users' apps got renamed to the author's email address. Being an IDE, of course, there are lots of places where inserting random text will break things. When I open up the console and see it filled with "'meredydd@anvil.works' is not a valid Python identifier"? That's the signal to go hunting for which dynamically-generated off-screen text box Chrome is stuffing credentials into this week. TL;DR Chrome's autofill is out there. It can't be bargained with. It can't be reasoned with. It does not feel pity or remorse. And it will not stop.
TazeTSchnitzel 7y ago
Oh yes. I seem to recall it was demonstrated as a way to covertly steal user information from the browser a while ago.
Hamuko 7y ago
Haven't browsers already done changes to combat that?
throwaway_bad 7y ago
And worse part is that autofill still works in incognito.
yk 7y ago
That begs the question, at which point does autofill happen in an iframe? So I pay for an ad, and have a password, creditcard number, address etc. form in the background. Does the browser autofil, or does it autofill when the user starts to fill in a form in the foreground? Asking for a friend.
- calcifer 7y ago
  > That begs the question Offtopic, but no it doesn't [1]. [1] https://grammarist.com/rhetoric/begging-the-question-fallacy/ https://grammarist.com/rhetoric/begging-the-question-fallacy...
  - eli 7y ago
    When a phrase is used the “wrong” way more often than the right way, it ceases to be wrong.
    - jvolkman 7y ago
      What about "I could care less"? Seems like that one is just always wrong.
      - atroche 7y ago
        Thinking about language usage as "wrong" or "right" might not be the most helpful way to think about it: https://stancarey.wordpress.com/2010/02/16/descriptivism-vs-prescriptivism-war-is-over-if-you-want-it/ https://stancarey.wordpress.com/2010/02/16/descriptivism-vs-... (p.s. not saying there's no wrong or right when it comes to ideas themselves)
      - redshirtrob 7y ago
        Yeah. But people say it enough I've started mentally converting it to: "I _could_ care less (but I can't be bothered)."
        basch 7y ago

Autofill for offscreen elements gives me the creeps even without the data getting misinterpreted

by VMG 7y ago

Autofill for offscreen elements gives me the creeps even without the data getting misinterpreted

dmix 7y ago

This is why form elements should never be hidden after loading. Display none should be the default in the HTML for non-relevant content, which should be enough for most autofillers. It also prevents flashing of content when autofillers try to populate it, causing the hiding to delay, which I recently saw in a production app. Frameworks like React and Vue don’t even render the HTML into the DOM until conditions are met so the situation is improving. Another positive step away from jQuery hackery!

pantalaimon 7y ago
If you want to be malicious and capture wrong auto fill data, wouldn't a simple AJAX request on change be enough to capture sensitive data before the user gets a chance to correct it?
- AJ007 7y ago
  Yes, and there are popular third party analytics platforms that record all activity on a page, which includes not just every key press, but the speed at which it was done, with or without a submission of the form. Web browsers should never, ever use auto fill unless the user has already entered that information on that domain already. Popular domains that host third party content should never be able to auto fill.
- HeavyStorm 7y ago
  I'm not really sure but I think the behavior is a bit different with autofill. While the browser show the field highlighted, the data is there for _the user_ but the actual form field has not been actually changed and no dom event is fired.
meredydd 7y ago
If you think late rendering or "display:none" will put Chrome off, think again! The anvil.works IDE is Angular, so it's all rendered post-loading, and Chrome still autofills the weirdest things. Relentlessly. Search boxes? Sure! App titles? Yeah, one week a bunch of our users' apps got renamed to the author's email address. Being an IDE, of course, there are lots of places where inserting random text will break things. When I open up the console and see it filled with "'meredydd@anvil.works' is not a valid Python identifier"? That's the signal to go hunting for which dynamically-generated off-screen text box Chrome is stuffing credentials into this week. TL;DR Chrome's autofill is out there. It can't be bargained with. It can't be reasoned with. It does not feel pity or remorse. And it will not stop.

TazeTSchnitzel 7y ago

Oh yes. I seem to recall it was demonstrated as a way to covertly steal user information from the browser a while ago.

Hamuko 7y ago

Haven't browsers already done changes to combat that?

throwaway_bad 7y ago

And worse part is that autofill still works in incognito.

yk 7y ago

That begs the question, at which point does autofill happen in an iframe? So I pay for an ad, and have a password, creditcard number, address etc. form in the background. Does the browser autofil, or does it autofill when the user starts to fill in a form in the foreground? Asking for a friend.

calcifer 7y ago
> That begs the question Offtopic, but no it doesn't [1]. [1] https://grammarist.com/rhetoric/begging-the-question-fallacy/ https://grammarist.com/rhetoric/begging-the-question-fallacy...
- eli 7y ago
  When a phrase is used the “wrong” way more often than the right way, it ceases to be wrong.
  - jvolkman 7y ago
    What about "I could care less"? Seems like that one is just always wrong.
    - atroche 7y ago
      Thinking about language usage as "wrong" or "right" might not be the most helpful way to think about it: https://stancarey.wordpress.com/2010/02/16/descriptivism-vs-prescriptivism-war-is-over-if-you-want-it/ https://stancarey.wordpress.com/2010/02/16/descriptivism-vs-... (p.s. not saying there's no wrong or right when it comes to ideas themselves)
    - redshirtrob 7y ago
      Yeah. But people say it enough I've started mentally converting it to: "I _could_ care less (but I can't be bothered)."
      - basch 7y ago