Hacker News Reader

Comment by sschueller | Hacker News Reader

Android does not ask for permission to read certain things like the clipboard. So an app can intercept anything added to the clipboard such as passwords copied in by password managers.

View on HN

Wow. The password manager I've been using for the past few years has dedicated buttons/gestures for copying the password to the clipboard (like many others, I'd assumed.)

I feel like the expectations in this case are clear: a copied password should only accessible when the user "pastes" it. (The app even clears the clipboard after a certain amount of time, making it seem like the only weak point in the system is the paste functionality.)

To find out that this is not the case is pretty mind blowing. Does anybody know of any good reasons why the clipboard shouldn't be secure?

> Does anybody know of any good reasons why the clipboard shouldn't be secure?

Seems like a UI issue to me. Right now apps themselves invoke the paste command (e.g. they can put a "paste" button in their UI). If you remove clipboard access from programs, the UI would have to be presented by the OS.

Requiring paste to be initiated by the OS may work alright for text boxes (but you'd now have to sandbox all the text boxes to avoid the app simulating taps), but it wouldn't work for say, pasting images.

Another option is to add a dialog box every time asking the user "did you REALLY want to paste?", but that will quickly get annoying.

I can imagine something along the lines of checking whether user interaction was the root cause of getting access to the clipboard as a middle ground... e.g. on web, popup blockers work this way. If a user interacts with a button, and that javascript series of functions opens a popup, it is allowed. If a non user interaction function in javascript, say a running ad, tries to open a popup, it is blocked. Could try the same approach, where only if the user initiated the current running series of functions, would it be allowed to access the clipboard. Or even ask for elevated user interaction functions, so that security teams would have an explicit list of elevated functions that are allowed to access sensitive data, allowing for easier manual checks. Anything else would have the annoying confirmation.

If you use Lineage OS (or its predecessor, CyanogenMod, both of which are Android forks) you are, ostensibly, given the ability to permit or deny access to read from and/or write to the clipboard via the included permissions manager, Privacy Guard.

That is a solved problem on iOS. There is an API that supports third party password managers.

https://appleinsider.com/articles/18/09/18/inside-ios-12-aut...

There is also an API like this an Android, but some apps don't support filling passwords well.

As far as I'm aware iOS doesn't require permission for clipboard access either. Up until Q a background service on Android could constantly monitor the clipboard however.

Not knowing the underlying architecture, but would it be hard to give each app its own virtual clipboard that only the UI has access to (paste)? And does IOS already account for this? Daily it seems as though I'm reconsidering Lineage. While I like the flexibility of Android I feel as though there are still too many obtuse protections missing.

Why not require both clipboard source and target applications to be running at the same time (i.e. clipboard acts as a channel, not a buffer)? This is implemented in GNOME native apps.

Users will probably be annoyed if the clipboard contents seems to randomly disappear because an app got killed by the OS.

Reply on news.ycombinator.com