Open dweekly opened 2 weeks ago
Firstly, let me just say I am very excited to see the efforts beginning on this draft.
🙏
To be clear, we care less about screen shots per se (which are not, as far as I'm personally aware, a common part of an attack pattern today) than live screen sharing and telling that there might be a remote observer or remote pilot.
Thanks for this input. I've filed #3 in response.
Firstly, let me just say I am very excited to see the efforts beginning on this draft.
I run the innovation team at Capital One. A not-uncommon attack pattern is that we see our customers getting convinced by fraudsters masquerading as technical support to install a remote-control application like TeamViewer and log into their bank accounts. The fraudster then can perform actions from the user's computer and logged in as our valid customer.
Knowledge that the web session is being remotely-controlled (or even remotely-observed) would be a very useful signal that we should be cautious about money movement in that session. We might want to consider extra out-of-bound validations with a user, such as sending them a push notification to their phone or a text message asking for confirmation and emphasizing that they are not actually on the phone with us.
To be clear, we care less about screen shots per se (which are not, as far as I'm personally aware, a common part of an attack pattern today) than live screen sharing and telling that there might be a remote observer or remote pilot.
For clarity, we don't necessarily want to block such activity, since there are legitimate use cases for remote observation and even control: an adult child may be helping their elderly parent review and confirm transaction and pay bills, for instance. But it would be helpful to apply extra scrutiny to the proposed actions in such a session.