Customer Service Agents Can See What You're Typing in Real Time
gizmodo.com
gizmodo.com
https://www.theguardian.com/technology/2017/jan/10/browser-a...
Open https://anttiviljami.github.io/browser-autofill-phishing/ , enter some auto-fill info, click "Submit" and monitor your "Network" tab requests. You'll find your browser leaked way more info than those 2 information...
The browser was submitting the form with auto-fill details that failed the validation checks for those fields. Hard to show an error message for fields the user can't see.
Yes, it is more robust to have code on the server side discard input that isn't expected rather than validate it, but it annoying extra work when those fields have no security impact.
The alternative is to tell the browser not to auto-fill those fields, but doing that feels broken too.
Firefox seems to save passwords per domain name. This may not be specific enough in certain cases. E.g., if I have a password on domain.com, but domain.com offers web hosting at domain.com/username, then my understanding is it would be relatively easy to obtain my credentials for domain.com with the right phishing site at domain.com/username. Correct me if I'm wrong.
I can think of one site I had to use recently for event registration which suffered from the flaw I mentioned. (Note that I have no choice over which service to use here, as I don't run the event.) The site puts each event under different directories, not subdomains as it should. Firefox saved my login details for one past event and wanted to use them for another event. I don't know the extent by which the event pages can be customized, but if you could put the right JS on one event page then it seems there are multiple approaches to getting credentials and potentially obtaining sensitive information. Fortunately in this case an attacker wouldn't obtain much of value best I can tell.
If you really need the kind of security or peace of mind that this situation is not suitable for, type everything into a text editor and paste it into the website when you're ready to send it. Otherwise, you can't ever have any expectation of privacy on the web.
Whenever there's a story like this every hn response is "always assume you are being watched at all times!" - but nobody can maintain that kind of hyper vigilance forever, and it isn't a healthy way to live.
I do. Nobody who goes on HN will be. But the layman who spends 80 hours a week working a minimum wage job who has no time for computers and just wants a Disney vacation for his kids, absolutely would be floored by this. It seems very reasonable to apply conventional logic to computers. You can write all you want on a piece of paper and then throw it away and nobody would see it. The same doesn't apply on the internet, but it's not a big leap for people who barely know how to log in.
I go on HN, and although I'm not surprised that this is possible, nor shocked that it's done, it is the kind of thing I could easily fail to think about, or assume is probably not actually being done by anyone I deal with.
That's actually happened to all the major vendors like LastPass and OnePass, and to some of them it's happened the exact same way multiple times - a UI re-design re-introduces the same JS interop mistake.
some linky links: https://twitter.com/taviso/status/941711305668411393 https://twitter.com/taviso/status/769378052254015488
I've promoted password managers for a long time! Just not fancy convenient commercial ones, those are a huge mistake.
1Password wrote an extended post in response to that vulnerability talking about defenses and threat models https://discussions.agilebits.com/discussion/70301/backgroun... and I don't see evidence that the vulnerability ever recurred.
And it was not a threat that allowed one website to get passwords for another website. It's true that other password managers have had such vulnerabilities - multiple times - but that's a reason to comparison-shop the various password managers and pick a secure one, not to write off the product category entirely.
The author probably meant if the site gets/is hacked, or if they are later bought by another company, or if a new employee joins and you can see chat history... etc.
And their ad networks might well be infected with malware. But because of deep packet inspection and editing, you can't tell that the malvertising in question actually came from AT&T or Spectrum instead of Gmail.
I'm sure Google would not be happy with content injection into gmail.
It's similar to the old adage about driving: "Drive like everyone else is an idiot out to kill you. Don't be right, be predictable."
Edit: In the worst-case, as per the GP's point.
The difference is that if I own the server, I can see your information even though it was a direct server connection. You directly fed the information to me. That is what is happening in these scenerios.
And plenty of ISPs will do exactly that, if you give them half a chance.
I remember plugins for various IM clients would do the same thing in a chat window some decades ago. And I remember my days as a sysop in the good old single line dial up BBS days. You could watch users browse and type all the way back in the mid-80's and I'm sure this has existed about as long as multi-user computers have.
If you're typing into an application which is any part of a networked or multi-user system, assume someone can see what you do while you're doing it (and can log same for later review).
...maybe I'm just old and don't understand the kids these days... or maybe it's a slow news day...
Imagine this scenario: Copying and pasting a debug log, realizing it contains personal or important information (such as password, SSN, or anything else) and it is sent to the agent before you have a chance to redact that info. Or it could be accidentally pasting the wrong thing. I know that I've accidentally pasted Twitter links into my code before.
EDIT: Just to clarify my point. If you're going to break deeply entrenched user expectations, especially in ways that are often used maliciously: explicitly say you are subverting those expectations.
The same reason there are "This call may be recorded" messages when calling in, it shouldn't hurt much to add a "For quality assurance purposes, your keypresses may be logged in the chat window".
And if it does hurt, then you should realize your subversion is malicious.
Maybe you have more discipline, more sense of control and focus all the time. I don't and I know I am prone to making simplifying assumptions about things, because thats .. well .. human.
So.. I think either you are in denial about when you too make these kinds of mistakes "oh no: that only happens to other people, never happens to me" or .. you are a cyborg from the future.
I FOR ONE WELCOME OUR NON-FOOLABLE ROBOT OVERLORDS
https://en.wikipedia.org/wiki/Talk_(software) if you're on macOS, you have this command installed
http://mailman.postel.org/pipermail/internet-history/2002-De... (click on "Previous message" a few times too)
...but I recall that it was great fun (for about 5 minutes) answering questions before they had been fully typed and sent since I was the faster typist.
As you mentioned, I am shocked that the HN audience is shocked by this. I could see my parent's being surprised to discover this, but most HN readers should have figured this out a long time ago.
Sounds like that assumption is well-founded!
https://chrome.google.com/webstore/detail/password-alert/noo...
Doesn't that require maintaining a database of all credentials?
That page does say this:
The problem with this kind of CSS UI tracking is that we get only the first occurrence of the event. For example, take the :active pseudo class example. The request for the background image is fired only once. If we need to capture every click then, we have to change the URL, which is not possible without JavaScript.
It's also not clear to me how you could capture any keystrokes with this technique. Still, I did find it interesting.
input[value] {
background-image: attr(value url, 'no-input');
}
There was a demo (dead now - I'll fix it) that was a text adventure, that keylogged. And it was interesting to see typos and changes of wording. It did provide some insight that wasn't always apparent in the final submitted text commands.
Even though in 2005 it was known you could do this (long before ajax), still today I'm a little taken-aback about being keylogged on a random website: despite having written a bloody article about it 15 years ago!
Although, this will certainly depend on the Chat software used. Back when we used Olark at our company, there was no preview available, although we could "co-browse" and redirect the user's webpage, which was helpful in some cases.
When you are typing a message to customer service as a customer you should have a chance to compose your thoughts, and should have an expectation of privacy in whatever you are writing before hitting enter.
But I appreciate it. Thank you.
There's been more than a few times where I was up late, on a chat support, and quite upset about something or other... and decided to re-write my message before hitting the "Send" button. Composing your thoughts is valuable...
The point another poster made about secrets is a valid one but I'd argue that the kind of secrets you're likely to be pasting are the same ones the support operator would have access to anyway (payment details, address, order details, etc). But if you're really worried, other HN posters said it best when they commented about typing in a desktop text editor then paste your text into the chat window.
You lose so much with typed text which makes good customer services a lot harder. Thus as long as any pre-posted text isn’t stored anywhere (I fully expect posted chat logs would) then I don’t see an issue with support operators using real time text as a glimpse into the customers mood.
[edit]
To the people who voted me down: I get that you disagree with me but I have been on courses regarding just this (which is weird because I couldn't be in a less customer facing job....) so what I'm talking about here isn't just some random junk I've invented off the cuff. It's what I was taught how customer services (the good ones anyway) work.
Anyone who's ever done a stint on 1st line tech support will understand just how much of a thankless job it is. If this helps them to serve me better then I welcome it.
I think the real complaint being made is that you didn't realise they were using these visual clues. But that's why I keep coming back to how other forms of customer services are trained to read vocal tones and body language. Would you also feel cheated if you learned your favourite high street store's customer services team had training on reading body language while you hadn't so they have an advantage in gauging your temperament but they didn't let on they had that training?
Don't get me wrong, I do see and understand your point. I'm very privacy minded so this is the kind of thing I'd normally get annoyed by as well. But at least this time the anti-privacy tools are genuinely being used to improve customer experience rather than just to monetise them (yes I know good customer experience can lead to repeat custom - but more often than privacy is sold to the detriment of customer experience)
I’m not usually paranoid - but moments like this remind me to hit the Mute button whenever I’m not directly conversing with an agent. You just never know what they’ll pick up.
Ever heard a concept of comfort noise [0]? Maybe some call center software can add something analogous when necessary. Like noises you'd expect in a call center.
I worked at a call center for a month or two one summer and when you'd put someone on hold you'd still hear them. I was only talking to network mechanics (ISP internal call center), but I am sure that the customer call center worked in the same way. I, after this experience, always assume someone can hear me.
Update: "I, after this experience, always assume someone can hear me." when I am on the phone with customer services, not in general. Although in today's technological world it would not be that much of a stretch.
I contact support when something is broken. There is a critical bug, or there is something down, or there is a physical defect. Every single time, it's just me getting jerked around, often times for an hour or more.
Just in the last week: an hour with Google Support with them insisting that I factory reset my phone for a hardware failure (hours of work to re-setup), or my ISP insisting that the "limits are set in the lines" and that a technician would have to come out to inspect their own modem so that they can determine why I'm being throttled to 10% of my paid speed, rather than 90% which is what I'm apparently entitled to. I hate that I have to get pushy/mean and insist that, Google, either send me a replacement or start processing a refund. I have no idea what to do with my ISP, they seem incompetent at every layer that I have any way to contact and they have a non-compete negotiated with their competition so I have no other options; their technician based had nothing to suggest and agreed with my conclusions.
I have also never had a chat experience where I didn't feel like I had to very carefully word my sentences to make myself understood, or where I wasn't waiting an exorbinant amount of time for the other side to read/reply. I can't fathom how peek-ahead would help any of these custom service experiences.
After rolling it out and enjoying this for ourselves as we handle our own customer support using our own software, it's become a "why didn't we do this earlier?" type of thing.
Overall, there's already a ton of asymmetry of information when a customer contacts a support team (e.g. our product pulls in order history, subscription details, stripe transactions, etc) that streaming a text preview is really just a drop in the bucket, and it's actually a win-win for both sides since it leads to faster answers.
Also keep in mind that any questions you ask may be used to feed machine-learning systems, like chatbots, which is true for our product as well. Just something to be aware of, that I think is a fair tradeoff for better customer experiences long-term.
Disclaimer: I'm the founder of https://reamaze.com
Because it's invasive.
The user consents to sending you information when they hit Send(explicit). They can remove any incorrect or unrelated information from the text box before they do so.
Especially if they paste in to the text box and inadvertently paste the wrong thing(be that sensitive info or similar).
The experience is all in the context, and since this is only general behavior for customer service chats (where you're expected to send everything you type and the other end is simply trying to help resolve an issue), it's not really a realistic issue in terms of privacy. I agree that if facebook messenger started doing this and showed the other person what you are typing, this would be unexpected and potentially unwanted behavior, but the likelihood of unwanted behavior in a customer support context is extremely rare.
How would most people know to complain about something they don't know is happening?
How many of those 10k people even know this is happening? I suspect, given the other comments here and the fact that this article exists, that it's a very small number. Try informing all 10k people first, then count how many 'may not have an issue' with it.
It's unsettling to know that a customer service agent would see that and think I'm being impolite.
Or perhaps simply the xhr requests could be blocked.
I don't actually use that plugin but I have gotten the Vim keystrokes so ingrained in my brain that I've gotten in the habit of having a terminal open whenever I need to type into web forms...Now I finally have an excuse to not feel silly doing it.
Maybe a simple blocker for this could be the next must-have extension/browser functionality. Something that doesn't send your input events until you press shift+enter.
A related maxim: "Never be rude to an airline gate agent."
HappyFox: https://zapier.cachefly.net/storage/photos/3fe2e4f896499b131...
Olark: https://zapier.cachefly.net/storage/photos/d53ec47e6affe26a5...
LiveChat: https://zapier.cachefly.net/storage/photos/26c01334ea7335635...
Denying support techs the extra 10-30 seconds that live streaming your typed words buys them for privacy reasons seems strange to me.
Your typed words are no more an indication of your deepest private thoughts than a phone support session full of ums and errs and “oh, actually I meant…”.
If you make me feel self-conscious about what I'm typing, I'm going to consider each word rather than type then correct/revise and send.
So, it seems there are different types of writers. That’s a small moment of enlightenment for me. :)
I usually type my questions in a text editor first and then paste it into a service agent chat when I am sure that it is exactly what I want them to see.
I have tendency to type if I pissed off then either delete it or amend it before sending/posting.
Imagine if on the phone, you would have to hold down a button to talk. At the end of the recording, you're given the change to edit any mumblings, rephrase things, or start all over. If it later turned out that the other end can hear every word, that is probably surprising to the vast majority of people.
It reminds me of the "talk" (and ytalk, ntalk) programs, where all parties can see in real-time what the others are typing. It's a cool technology that, unfortunately, is not used on the web.
Education in what? That they shouldn't trust companies because they eavesdrop on them? Please don't blame deceitful practices on the victims.
> if they expect their typed input to a website to be private.
Most chat apps work that way. Others only see what you typed once you send it. Just because the now obscure `talk` worked differently is no excuse.
The deception starts where the agents' responses are not relayed as they type! I don't see how you could explain this asymmetry in innocent terms. It clearly benefits the shop without them being open about it.
Education in how the web works. That typing something into a text field, or moving the mouse, or any interactions with a website can be read on the other side. Many users expect this behaviour when they use, for example, Google search or Google Translate. If users expect their text to be private in one context, but shared in another, then there is clearly a lack of understanding of how the web works.
> Please don't blame deceitful practices on the victims.
I didn't blame anyone for anything. It's not a priori deceitful. Presumably some of the motivation is to enable faster responses to client queries.
Apparently we don't have the same standards as to what constitutes deceit. To me it's enough when the chat is asymmetric in that the agent's typing is not visible until they send it but the visitor's is relayed immediately to the agent. If visitors could watch the agents type they would understand that their typing is visible on the other end.
> Presumably some of the motivation is to enable faster responses to client queries.
Sure. Then why not offer the same privilege to the client? If it's so beneficial?