>What's full-disk encryption do if Facebook et al are going to funnel the data off your devices anyways?
Serious answer: the threat model FDE aims to address is cold physical attacks. That's it, everything hot (or even warm) and online is outside of scope. Facebook would be more akin in class to gray non-persistent malware, although they aren't actually malware in the strict sense and do face some bounds from the law which should make filtering and keeping them off a sensitive system more straightforward. At any rate, FDE is a good idea for a bunch of reasons given how cheap it is at this point, but it's just one of many needed pieces.
More fundamentally and beyond Facebook specifically, we need better ways to control data exfiltration and transfers from our datastores to and between software and services, period. Whitelisting should be the default. Data channels like clipboard APIs should either simply not exist at all or at least require explicit user per-application sign off (and preferably even then with restrictions like requiring code signatures, timeout options etc). While single purpose hacks are generally not justified, the specific instance of passwords & keys might be important enough in reality to justify operating systems providing some much more explicit "secure pasteboard" system that is far more heavily mediated.
The Firefox Focus app for iPhone pushed out an update a few months ago that showed an active clipboard tray below the URL bar, which was shocking and freaky to see.
Anyone know whether the update had added the API or just made it visible? With the desktop browser it's enabled by default, but at least can be disabled through about:config.
> What's full-disk encryption do if Facebook et al are going to funnel the data off your devices anyways?
We have more-or-less mandatory full-disk encryption at work (outsourced software development) in order to prevent source code and data access in case the dev boxes are confiscated by some third-party agency. I believe it's still a good measure for this case, if you don't blatantly upload the data into the internets. (And have a religious prescription on keeping any work-related data off your personal devices.)
Ironically, at the same time, most of our people use Google Drive to share project docs and discuss most of the work-related stuff via Skype. Though, I guess the disk encryption is there for plausible legal deniability as well.
> What's full-disk encryption do if Facebook et al are going to funnel the data off your devices anyways?
Since you mention it, full-disk encryption does nothing if your computer is on or asleep, which is the case for most users most of the time. It only works if your computer is off.
> It works for asleep as well given the user would need your password to log back in after waking it up from sleep.
The disk is not encrypted when the computer is asleep. There may be other security mechanisms that may work, such as an OS-level password on wakeup, but not FDE.
(The details of FDE are a bit more complex, but practically the above is true.)
The disk is encrypted when it is asleep. The key to decrypt its content is available to the OS after it wakes up, but if you don’t know the account password, you can’t log in to access it.
When handoff was first introduced, it was obvious that facebook was auto-scraping the pasteboard, because as soon as you foregrounded the facebook ios app, iOS would show a "pasting from macbook handoff..." type dialog despite no user interactions performed.
If I remember correctly, the facebook iOS app would also auto-prefill a new post draft for you if it found an URL in the pasteboard?
Oh! I've seen this a few times, it must be in Messenger/WhatsApp. I don't know why Apple let them do that because it's awful UX and I just assumed Apple had screwed it up and sometimes couldn't background the copy/paste aross devices properly.
I think they got caught red-handed with an existing pasteboard API that suddenly gained handoff powers but at the same time started showing modal system overlays UIs when accessed? At least it came off like that.
As a data point, my Samsung Galaxy J7 came with the Facebook app and I was able to uninstall it without issue. So it looks like this doesn't apply to all Samsung phones.
I use copyq[1] on Linux and earlier used Ditto on Windows. I don't actually use it that often, but when I need it, the history of copied things is extremely useful. It's a built-in function in Emacs[2] and Vim and honestly, it should be also implemented by the OS or thereabouts (X/Desktop Env/WM in the worst case). And BTW, for keeping tabs on more than just the clipboard, I use selfspy[3], which is a really neat... keylogger, basically. It's great for filling timelogs!
Anyway, what I want to say is that there are legitimate uses for nearly every API. Some should be protected with permissions and so on, but once an API is there, you should always assume it's central to someone's workflow.
I guess KDE Connect uses this kind of API to share the clipboard between the phone and the computer. This is very convenient, but this can be a bit scary too. This means your phone which is full of proprietary blobs accesses everything that is copied from the computer. This is even worse if you have any app you do not fully trust on the phone.
Maybe a solution would be to have a manual button "share clipboard with the phone", instead of automatically sharing the clipboard.
Stupid question: Why not get hold of an image of the facebook app and check if there is suspicious code? If it were an android app, you could even try to decompile it, but even so, there should be suspicious calls to the clipboard API somewhere in the code, shouldn't there?
Because all of these companies go to great lengths to hide their "anti-malware" libraries and do a bunch of stuff like code obfuscation and ASLR outside of even the compiler tooling.
If you spend a little time getting used to working with obfuscated apps, they are easy enough. Facebook's app is no different. And ASLR has literally nothing to do with preventing reverse engineering.
Based on my understanding from the tweet, it sounds like it can only see the type of data i.e. URL/plaintext and will only be able to get access to URLs and not necessarily the actual text (ex: if you copied a password), can anyone verify this?
"This recognition software prevents the app from scraping text that does not look like a URL, like passwords or emails, Harrison said. It’s not a perfect system, though: broken or fake links like “FacebookHasAccessToMyData.com” are still automatically recommended for posts."
I'm pretty sure Chrome (for iOS) does this too, and presumably it could be sent to Google's servers. Otherwise they wouldn't be able to suggest opening a URL that has been copied (and show the URL before any user confirmation) by simply tapping on the address bar. Whether or not they use it for ad targeting is anyone's guess.
seriously? lots of sites block pw autofill. copy/paste is a must, and frankly, the whole idea that any installed app would have unfettered access to clipboard contents is outrageous.
though to be fair, this is an issue with most OSs.
A lot of circumstantial evidence for extreme pervasive surveillance by Facebook apps is mounting.
Edit: another possibility is that other apps are doing the monitoring and selling the data to Facebook or to data brokers that then sell it to Facebook. Lots of "free" apps ask for every permission.
In any case security researchers now have something new to tear apart in 2018.
I'll point to this next time someone questions my stallman-esque stance.
What's full-disk encryption do if Facebook et al are going to funnel the data off your devices anyways?