This is an interesting area of app privacy that I haven’t seen before. I wonder how you would regulate access to the clipboard, since it seems like most apps would want at least copy/paste ability. Maybe that could be sandboxed to the long-press menu only?
What does that look like in practice? I tap “like” on a picture of a friend’s burrito. That’s a user action. Can Facebook read the clipboard now? If I have the app open, I’m probably going to initiate some action, so this doesn’t gain any security.
Big picture, few people seem to actually care about privacy. The hypothetical threat here has existed for years but nobody cares until they notice an app making overt actions. If Facebook were doing this maliciously, they’d not reveal it so obviously. Which is not to say that Facebook isn’t or can’t be malicious, but waiting for all the people spying on you to fuck up and reveal themselves is a poor defense.
First question to ask, before copying your secret pin to the clipboard, should be, who can access this? Obvious question, no? But who asks it?
We said substantially the same thing, then jfb edited to add a reply, so I’ll reply to you. :)
So, tedu is absolutely right that this is more a problem about people caring than about the technical fix. Some OS-level fix ought to be possible, though it’s not immediately obvious how. I’m going to explore how it might be implemented, because I think that’s interesting; feel free to stop reading if that seems boring, since it’s certainly not really the actionable topic.
iOS already has a privilege separation thing for custom keyboards; they run as their own process, in their own sandbox, and can only communicate with the host app via the API. This works well to keep them from poking around in the app’s memory, but it provides no assurance that the characters they send are actually being provided interactively; indeed, that’s a feature, and allows keyboards to provide shortcut macros.
Some sort of separation like that is probably part of the solution, but only if the security boundary can be put somewhere that enables needed functionality while providing a guarantee that the user intended this input. That means the roles are probably inverted: The app needs to be in control of the possibly-custom text entry widget, while the system needs to be presenting the “did you want to paste” UI.
One place to break that up would be to put the system in charge of presenting the “cut/copy/paste” popup; the app would make a call across the boundary to request it. That’s not great, because a lot of apps add custom options there (“bold, italic, jump to symbol definition”), and if their custom option needs custom drawing… then they’re running code on the wrong side of the boundary. So the ability to customize the popup would either need to be reduced, or offered through an interface that puts all the custom logic on the app side.
I think the above is probably pretty reasonable. It’s very important to preserve the ability of apps to offer custom text widgets, and this doesn’t interfere with that; a malicious widget would be able to say “bring up the paste popup” at unexpected times, and users might indeed click on it as the only obvious way to dismiss it, but it would annoy them also, so it doesn’t seem like a viable attack.
A draconian possibility would involve trying to put the text widget on the system side of the barrier, but there are a lot of important ways in which text widgets get customized, and it’s actually an area where Apple’s APIs provide much nicer affordances than most of the others I’ve seen. So that’s kind of a last resort.
Sticking “paste” into the keyboard would certainly solve the problem, but (as noted) some apps may want to grab clipboard via custom icons, and the system overlay may break flow.
Returning to the original example, Facebook checking the clipboard for a url and offering to post it is (imo) a valid, friction reducing flow.
Honestly, I’m far less concerned with Facebook peeking at my clipboard than some free “flashlight” app. Stipulating that Facebook “sells my data”, does anybody honestly think they’re selling my bank pin codes? How does that market work? How do I buy this data from Facebook? Malware in the guise of simple utilities seems like the bigger problem.
Id say it can all be addressed by simple permission checks like those used to access camera or photos, etc. Facebook I say “yes” (or “no”); FreeLightUltra I say “hells no!”
How would it work? If I scroll through my timeline, I’m initiating an action. It’s not one that has anything to do with text entry, but the UI toolkit can’t know that without a much more comprehensive model of how copy/paste should be used.
Pocket does this on Android too.
This is an interesting area of app privacy that I haven’t seen before. I wonder how you would regulate access to the clipboard, since it seems like most apps would want at least copy/paste ability. Maybe that could be sandboxed to the long-press menu only?
Why not only allow access after a user-initiated action? That doesn’t seem to impose too terribly many restrictions.
EDIT: Not any user-initiated action – I meant after the user chooses to paste.
What does that look like in practice? I tap “like” on a picture of a friend’s burrito. That’s a user action. Can Facebook read the clipboard now? If I have the app open, I’m probably going to initiate some action, so this doesn’t gain any security.
Big picture, few people seem to actually care about privacy. The hypothetical threat here has existed for years but nobody cares until they notice an app making overt actions. If Facebook were doing this maliciously, they’d not reveal it so obviously. Which is not to say that Facebook isn’t or can’t be malicious, but waiting for all the people spying on you to fuck up and reveal themselves is a poor defense.
First question to ask, before copying your secret pin to the clipboard, should be, who can access this? Obvious question, no? But who asks it?
We said substantially the same thing, then jfb edited to add a reply, so I’ll reply to you. :)
So, tedu is absolutely right that this is more a problem about people caring than about the technical fix. Some OS-level fix ought to be possible, though it’s not immediately obvious how. I’m going to explore how it might be implemented, because I think that’s interesting; feel free to stop reading if that seems boring, since it’s certainly not really the actionable topic.
iOS already has a privilege separation thing for custom keyboards; they run as their own process, in their own sandbox, and can only communicate with the host app via the API. This works well to keep them from poking around in the app’s memory, but it provides no assurance that the characters they send are actually being provided interactively; indeed, that’s a feature, and allows keyboards to provide shortcut macros.
Some sort of separation like that is probably part of the solution, but only if the security boundary can be put somewhere that enables needed functionality while providing a guarantee that the user intended this input. That means the roles are probably inverted: The app needs to be in control of the possibly-custom text entry widget, while the system needs to be presenting the “did you want to paste” UI.
One place to break that up would be to put the system in charge of presenting the “cut/copy/paste” popup; the app would make a call across the boundary to request it. That’s not great, because a lot of apps add custom options there (“bold, italic, jump to symbol definition”), and if their custom option needs custom drawing… then they’re running code on the wrong side of the boundary. So the ability to customize the popup would either need to be reduced, or offered through an interface that puts all the custom logic on the app side.
I think the above is probably pretty reasonable. It’s very important to preserve the ability of apps to offer custom text widgets, and this doesn’t interfere with that; a malicious widget would be able to say “bring up the paste popup” at unexpected times, and users might indeed click on it as the only obvious way to dismiss it, but it would annoy them also, so it doesn’t seem like a viable attack.
A draconian possibility would involve trying to put the text widget on the system side of the barrier, but there are a lot of important ways in which text widgets get customized, and it’s actually an area where Apple’s APIs provide much nicer affordances than most of the others I’ve seen. So that’s kind of a last resort.
Let me know if you see holes in the above scheme?
Sticking “paste” into the keyboard would certainly solve the problem, but (as noted) some apps may want to grab clipboard via custom icons, and the system overlay may break flow.
Returning to the original example, Facebook checking the clipboard for a url and offering to post it is (imo) a valid, friction reducing flow.
Honestly, I’m far less concerned with Facebook peeking at my clipboard than some free “flashlight” app. Stipulating that Facebook “sells my data”, does anybody honestly think they’re selling my bank pin codes? How does that market work? How do I buy this data from Facebook? Malware in the guise of simple utilities seems like the bigger problem.
Id say it can all be addressed by simple permission checks like those used to access camera or photos, etc. Facebook I say “yes” (or “no”); FreeLightUltra I say “hells no!”
How would it work? If I scroll through my timeline, I’m initiating an action. It’s not one that has anything to do with text entry, but the UI toolkit can’t know that without a much more comprehensive model of how copy/paste should be used.