Hacker News Reader

Comment by duxup | Hacker News Reader

How do they know what the difference is between a keylogger and auto-complete?

I use auto complete A LOT and my customer's love it. On the back end I sure could be storing that information (I don't)...

There's some good use cases that easily could be a keylogger, but aren't, or at least we don't know. Even if they store something that isn't auto complete it could be legitimate "hey are people stumbling over those stupid dashes all the time?" exploration of how the users do things.

Real dark patterns, and legit features tend to intermix sometimes and the devil is in the details...

View on HN

You hit on my first thought. There are numerous legitimate user experience cases where keystroke by keystroke or field by field processing is beneficial. Autocomplete for address data is one I see commonly used. Saving a partially filled out form field by field in the event a user becomes disconnected and would like to complete it later is another. From a security perspective, I know of numerous tools that examine the speed and cadence of the act of typing to discern between bot entry in a field versus human entry. There is also software like FullStory that records everything client side, including mouse movement, so companies can determine exactly how people are interacting with their sites in an effort to improve the UX. And from a tinfoil hat perspective, if a user is interacting with a webpage, they should assume everything they are doing on that page is subject to observation by the page author. If the researchers were surprised by this, I fear it's from inexperience.

Even if it is beneficial, the user might still want to disable it. (Possibly a option in the browser for manual/auto calculate; if manual, then events are disabled until you push submit or recalculate. This might improve speed, too. Another thing that might be useful may be ARIA mode (which can also have other advantages, although other things are needed too anyways).)

Saving a partially filled form is something that should be a feature in the browser, you can do "File > Save Form Data" (and then specify the file name) and "File > Recall Form Data".

I generally disable JavaScripts. Sometimes the web page will still be displayed if CSS is also disabled (and sometimes I want to disable CSS anyways), and sometimes links to original data, etc can be found if you view the source.

Your customers probably wouldn't love auto complete if they knew it was implemented as a key logger. Try doing it client side.

>Try doing it client side

Do what client side?

Store all the auto-complete possibilities client side? I think that doesn't make sense.

But my larger point is you can't tell for sure if it is a keylogger or just something else.

Nor does the difference matter to me as a user. If you're transmitting my keystrokes to your server.. it's a keylogger.

It’s really hard to have a meaningful discussion if we’re warping the definitions of words so much that “keylogger” now means something other than “a thing that logs keys” :(

If you are sending my keystrokes server side.. and your server has logs (as servers tend to do), don't you think you might be logging my keystrokes?

You are literally transmitting my keystrokes through several log keeping machines, to a piece of software that probably keeps logs.

I feel like at that level of skepticism you're well on your way to the "just copy and paste" kind of thing. I think that advice is kinda horrible / difficult, but I think we're at that level where not much would assure you that X or Y isn't happening anyway.

I think, especially in an age of heroku/lambda/etc, we can assume requests are logged by infrastructure. It is a trivially easy mistake to make - most devs forget that requests tend to be logged by infrastructure. This happens enough to get it's own CWE - https://cwe.mitre.org/data/definitions/532.html

Copy and paste won't help you here. This usually happens on focus changes and frequently is done not as part of form submission but to see if people bounce from the page and for stats - meaning it goes to a less secured database and usually has widely available access to it.

The fix here, in my opinion, is a mixture of technical (browsers aggressively disabling this sort of thing) and legal (penalizing accidental disclosures heavily). As a user, you can't do much.

> You are literally transmitting my keystrokes through several log keeping machines, to a piece of software that probably keeps logs.

I mean, yes, this is the internet we're talking about. I think this discussion is breaking down because keylogger = surreptitious, like when you are being logged by a third party when typing to a second party (ie you type a Google search into google.com and person who is not Google listens and logs that). It would be weird to describe you performing a search on Google as keylogging, though Google used to "transmit your keystrokes through several log keeping machines" to get auto-complete working

You don't need to send queries that return very few results.

Once you send a partial text that returns a few hundred results, any additional typing can be completely handled on the client side. If you only have a few hundred options at all, you don't need to send any text.

That's just good software engineering, by the way. Autocomplete queries are quite expensive, you want to minimize them. But, of course, that won't stop sending data pasted in a single step.

Anyway, the article isn't about auto-completing fields.

>Once you send

At that point you're sending anyway ... I'm not sure someone seriously concerned about keylogging to the point that they object to auto complete cares if you send 5 or 6 characters.

I think at that point you're addressing all your users on behalf of a few who are so concerned that they're not going to be happy with any "solution" outside turning it off altogether.

Reply on news.ycombinator.com