Explaining how Android Secure-Copy-Paste (US10754929B2) works
Back in the days of 2016 I worked for BlackBerry, they don’t make phones anymore but they were doing Android phones back then!. A security issue that I was very unhappy about in AOSP was the security of data transferred across applications via the Global Clipboard.
To solve this I provided a design to our development teams that leveraged something called a ContentProvider and an implicit feature of Android copy/paste called CoerceToText
. This design was later patented in US10754929B2 / EP3208713B1 which is a bit sad, and I hope it doesn’t limit someone from using this approach today 🤞.
I think this design has some modern relevance since in iOS 16 Apple have chosen to introduce a Pasteboard permission
to address the security issue in a different way, whereby if a target application wants to paste, a user is asked every time if they should allow
or disallow
(UIPasteControl. Whether this stays as is currently, whereby the user of the device needs to confirm access for every-single paste or they allowlist the app for a target app forever, neither of these are as good for UX or security as the approach described here. I do wonder if Apple considered the inverted approach and why they did not want to go with that 🤔.
Overview
Key Components
Sharing Sequence Diagrams
N.B I chose not to overlay this on the diagram above as there are too many dimensions (e.g. time) to display it nice and simplicistic
Wrap up
It would be nice to see some end to clipboard-stealing malware, one of the earlier articles I was aware of for Android was in 2014 and for the most part it’s still here today almost 10 years on.
Personally I don’t like either the UX or the security of Apple’s approach in iOS 16 as it is:
- More frictionful as you need to approve the target app for every single paste (or if too many users complain about this it will be made less secure with some time-bound or forever-bound allowlist that defeats the point of the feature).
- More susceptible to social engineering, the “victim” is already interacting with the malicious app, and hence it would be easy for said malicious app to convince a user to just breeze through some “allow this” checkbox without really comprehending the impact of it. The approach laid out above let’s the user make that decision at time-of-copy when their context on the content is more fresh and they know (in 99% of cases) which app(s) it should be going to.
- There is a confused deputy opportunity, as the allow/deny UI that is presented to the user does not make it clear what the current clipboard content is or where it is coming from hence they may inadvertently grant access to a stale piece of sensitive data.
If Apple can use the above design without some patent issues that would be dope, and I’d love to help in anyway if someone from there stumbles upon this :)