Looks like only Microsoft did it right on their platforms.

On Windows Phone 8 and Windows Mobile 10, a background app doesn’t have access to the clipboard. The API is just blocked for background apps regardless on those application-wide permission settings.

https://msdn.microsoft.com/en-us/library/windows/apps/hh2029...

https://msdn.microsoft.com/en-us/library/windows/apps/window...

Microsoft did a lot of things right with Windows Phone 8, it was a great OS and it's a shame it never took off. Unfortunately their timing couldn't have been worse, they showed up late to the party at the peak of their unpopularity. It never really had a chance.

Professionally, yeah I’ve noticed the platform ain’t a great success, at least so far. I think last time a company approached me asking to do some WP development was over a year ago. Fortunately I also develop for Windows PCs, and those aren’t going from desktops any time soon.

But personally I’m happy with my Lumia 930. It’s old but still works fine (replaced a battery once) and is updated to latest WM10. I don’t care about OS market share as long as my own copy works.

Same here, and the apps I care about do exist as UWP anyway.

On a positive note, I am seeing on consumer stores here in Germany the space that was used by hybrid Android tablets, being increasingly replaced by W10 netbooks and hybrid tablets.

This is absolutely true and terrifyingly unheard of!

CopperheadOS patched this in late 2016. https://copperhead.co/android/docs/technical_overview

Is there that big of a security risk if they can read the contents of your clipboard? The only example I can think of is if the app is a webview that you use to login to sensitive accounts and it scans the page for a login/password field and saves the login and sends back the clipboard info if found. It seems like reading random clipboard info isn't going to get linked to anything though (please correct me if I'm wrong).

I'd say that's a security risk and it's severity depends on the data you have on your device. The example you state is pretty serious: being able to get the master password from your Android Keypass file or LastPass master password would be a game-over situation!

Hmm, I know iOS allowed that as well for a long while (basically free-for-all access to the pasteboard). Was that fixed in later iOS versions?

It's even worse with Universal Clipboard, the feature that seamlessly shares your active clipboard between your mac and iOS devices. I have seen the official Facebook iOS app trigger a "Pasting from <mac-hostname>..." spinner when starting up, because Facebook silently steals your clipboard on startup/resume, and they are probably an API that happens to now possess Universal Clipboard powers and thus are triggering a clipboard content pull from the mac.

I'm still astonished people on HN trust Facebook enough to have any of their apps installed. Since day one their developers have shown complete disregard for users privacy.

I useful Facebook lightly/moderately, but I uninstalled its app from my phone a long time ago, initially because it was a battery sucking monster, but also because it didn't 'feel' right.

These days, I pretty much don't install apps on my phone. I just use it as an everywhere web browser and live with the web version of various things.

I also use their web app, which means I can no longer access the private messages people send me. Sometimes it tells me I've got a new message. Friends, I'm sorry that I'm ignoring you, but I'm not installing the battery sucking privacy steeling app that is required to view those messages. Wish I could disable the ability for people to send me private messages so they would get a notice instead of thinking I'm an a-hole.

I had this problem for awhile. Now I'm using mbasic.facebook.com for a much more functional experience.

I will give that a try, thanks!

> I also use their web app, which means I can no longer access the private messages people send me.

You could actually do that through the Facebook.com web interface much longer than you could through the FB mobile app. Of course, you can still do it on the web, though it's a separate domain (just as, on mobile, it's a separate app.)

But since they really want you to use the Messenger mobile app, to use the web interface on mobile you have to use "Request desktop site".

Yes, this is the big downside.

My 'SLA' for facebook messages is about 24 hours, and people who send me things there learn that over time. I generally just tell them why I don't see their messages right away.

In general, I make a point of not being too responsive with any online/async notification systems, except for SMS. It's one way I keep myself from being so scattered.

If you go to messenger.com and select Request Desktop Site, you can get a web version of messenger which is tolerably ok to use.

Facebook seems to be one of the few apps that gets privacy right, only asking for permissions to certain things (e.g. camera and microphone) when you want to use say a video recording feature. Now what's the general trustworthiness of the company? That's hard to say for sure, but at least they're doing app permissions right.

That's because of how iOS grants camera and mic permissions, not because Facebook did anything right.

It's partially Facebook doing it right, but not exactly noteworthy. iOS devs can proactively request permissions whenever, and tell you whatever useless reason they want, but that usually gets users to tap "Don't Allow" (and may get your app rejected by Apple.)

I didn't really think about it until the iOS Facebook app helped itself to my Christmas morning photos this year. I had assumed that Apple had stronger protections in place for users' content. It's one thing to say in an alert or popup or something "did you take photos of the kids opening presents this morning? want to make a photo collage using our helpful tool?" and quite another to access my photos (and, presumably, other personal data) without prompting.

You must have granted the app permission to your photos/camera roll earlier. Still I agree it's sneaky for the app to go in uninvited at a later point in time.

Agreed. It might be nice if Apple extended their "Do you want to continue allowing XYZ to use Location Services" prompt to other permissions, provided it wasn't too aggressive.

Or even better, offer a restricted photo access permission that only works with the built-in image picker. Then at least the user has to tap on an image before it is transferred to the app. I don't care about the fancy custom image pickers with real time preview effects that various apps build in.

You can deny it access to your photos, under Settings -> Privacy -> Photos.

I uninstalled FB from my phone years ago after all of my FB friends suddenly showed up in my Android Contacts.

I'm very outraged that you are right. Just checked with a dubious app that let you display current clipboard with no user action.

Yet you still have to bring the app to the foreground, but this is potentially a huge privacy leak IMHO.

The "doodle fruit ninja run" game I play don't need to now that my girlfriend left me so they can display a tinder ad...

(Oh, god if an evil ad developer come here don't take this as a good idea)

This is a big problem. If I try to paste something on my iPhone, my iPhone pauses for 5 - 10 seconds while it fetches the clipboard. Plus apps being able to read it with no user action is not acceptable to me. I don't like that Facebook can or that Facebook does read my clipboard to every time I start it up.

It's not obviously blocked, as far as I can see:

https://developer.apple.com/reference/uikit/uipasteboard

Then there's the usual "no running in the background" obstacles, but assuming you can get around that…

Why are you assuming that? There are multiple permissions that would become dangerous if it was trivial to bypass those checks.

I believe apps can no longer read clipboards while not in the foreground since iOS9 though I can't seem to find documentation that confirms that behavior.

Can they access this while running in the background?

Yes, you can write a background service that will be called when there is a change in the clipboard. You can even close the app and it will be restarted in the background when a clipboard change happens.

I know this because I wrote an app[1] that does precisely this and looks for a specific URL in the clipboard. I was surprised when I found out I don't need to ask for permission to read clipboard changes.

[1] https://play.google.com/store/apps/details?id=net.schueller....

Ouch, that sounds like something that should have a permission. Permission for background or programmatic access, none needed to receive pastes initiated by user seems reasonable IMHO.

That would require reliably deciding whether the action was in fact initiated by user, which is hard in browser environment and probably impossible for android.

The answer to that may actually be quite simple: The keyboard app is the one that should be allowed to read from the clipboard. Now can a keyboard spy on you clipboard contents? Sure. But it can also spy on all your keystrokes, so the trust must already be there.

That assumes that clipboard can only contain text, which I'm not sure whether is so on Android, but on all major desktop UI systems clipboard can not only contain arbitrary data, but even allows for negotiation of supported formats between source and destination.

But, that's done on websites as well, and frankly it's annoying. Giving apps the ability to put stuff into the clipboard and extract it out again has been made too hard (and one of the few remaining applications of flash).

I'd even settle for the ability to put stuff in the clipboard programmatically ...

This is a case of overly broad security imho.

> But, that's done on websites as well

Can websites running in background tabs access the clipboard contents on the Desktop?

In my experience browsers won't let you see the clipboard at all unless the user initiates a paste event.

The spec says no, but there's no guarantee that a browser implementation doesn't "through an implementation-dependent mechanism" give this access by default. https://www.w3.org/TR/clipboard-apis/#event-handlers-that-ar...

This is, incidentally, used by KDE Connect and possibly other apps to do clipboard synchronization with PCs.

Wow. That's insane.

For what it's worth -- there are frameworks that allow EXTREMELY granular permission controls. This [0] => http://imgur.com/a/XVulF is what happens when an app tries to access the clipboard and I haven't granted it.

There are steps people can take to maintain the "safety" of their information -- but not many do, instead they complain loudly and hope a first-party will give them the controls instead. This is basically never going to happen.

Using AOSP, CyanogenMod/LineageOS, CopperheadOS builds are one of the first steps. If you (not you, but persons) can't climb over that relatively low barrier, it's likely that they're going to be stuck at the level of complaining loudly until someone provides the equivalent of a pacifier -- something to quiesce, but not actually provide any real controls.

[0]. It's XPrivacy, and yes, it requires XPosed, which requires a modified system partition, which generally requires root, which most people won't give up mobile payments for. It all comes back to security vs convenience. There's always a choice, most people are picking the "wrong" one and complaining about it.

A little too condescending for my taste. No choice is wrong, and not everyone is technical enough to even think of rooting the phone and installing all those custom frameworks - and even if some people can, they may not find the need of it and it's perfectly fine. I rooted my first Android phone when the manufacturer decided not to upgrade my version to Jelly Bean, and tried almost all of the popular custom ROMs. All of them had their own special feature set, but all of them their limitations too. They were unstable, and had various random crashes. Overall, I was happy that I could stretch my old phone for longer and get those new features, but I also had to face embarrassment when my phone crashed in front of people or restarted in the middle of talking. When I got my Nexus 5, I just rooted it but stayed away from these custom ROMS. When I got my Nexus 6P, I didn't feel the need to root it.

Let's accept it, most of the people are going to use the default settings, it does help to shout about your issues, and the first-parties do listen if you shout loud enough.

I'm off finding a suitable Android build for this company issued S6 Edge. Oh .. wait.

In other words: Some devices are more equal than others, Android isn't a really open platform and your suggestion, while something I personally sympathize with, is impossible in general. :/

Hm. What mechanism does password managers like Onepass and Lastpass use?

I only use KeepAss, but it provides it's own keyboard so that when you have an entry selected in the app you can press the "user" and "password" keyboard buttons without copying.

I assume (hope) the others do it the same way. Clipboard memory has _never_ been safe not on PC and not on phones.

Which app do you use? I'm using KeePassDroid, which seems to be the most popular, and as far as I can tell it only supports the clipboard method.

I'm not the person you replied to, but Keepass2Android [0] has the custom keyboard for password entry.

[0]. https://play.google.com/store/apps/details?id=keepass2androi...

Sorry for the late reply, but I use this too (I wrote the original keepass post)

I use KeepShare, which has a custom keyboard for password entry, but also uses the accessibility APIs to auto-fill.

Could you explain why you say that about the PC? As far as I know, the browser isn't going to let someone snatch your clipboard info. An application running locally, sure, but an application running locally could also be doing keylogging, I'd think.

The same argument is true on smartphones. Only an application you've installed is able to snatch your clipboard info.

Treat your phone like you've always treated your desktop - only install trusted applications and use tools like XPrivacy to analyze sketchy applications and block "features" for the ones you absolutely need to use.

It is probably better now, but you used to be able to copy clipboard content from javascript or flash.

Keepass for windows and linux use autotyping or clears the buffer after a few seconds if you copy.

Oh, I see. Yeah, Flash is a different story, I guess, but for JavaScript you can't get at the clipboard unless someone pastes in all the browsers I'm aware of.

There's a library for accessing the clipboard within JS[1]. As far as I can tell, the HTML5 APIs for it are designed to stop this from being used to steal your clipboard but I somewhat doubt its effectiveness.

[1]: https://clipboardjs.com/

That seems to let you write to the clipboard, not read it.

The API used (document.execCommand) supports "paste" which lets you paste the current contents of the clipboard. However, it doesn't appear to work in my version of Chromium.

LastPass either hooks up to the Accessibility framework (scanning for password fields and filling them in directly), provides a keyboard (filling directly) or standard copy/paste.

AFAIK, LastPass still uses clipboard, even when accessibility APIs are available. Probably because new-style autofills (like pass implementation Password Store uses) are possible since relatively recent API revisions and there are still a lot of 4.x Androids out there.

Maybe I'm wrong, but at the very least, XPrivacy indicates it accesses clipboard shortly after requesting auto-fill - don't have a hook for setting text there.

As far as I can tell LastPass also clears the clipboard after you've pasted a password or something from the app. The other day I had to paste my Google password twice and noticed that it was cleared from the clipboard in the meantime.

This is why I have a separate gmail account for my phone that I don't use for any other purpose, and I don't access other email, my bank accounts, etc. from my phone.

Maybe Google and iOS do it deliberately to deliver ads perfectly. Just a thought, though highly vague.

Wow I did not know that. Thanks for posting. Sad that this is "just the way it is".

So don't use password managers? That is the most common way to take a password from one of those and input it.