“Did you copy/paste the info? Facebook seems to read all pasteboard data”

> 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?

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.

> 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.

Hope you dont use the Google keyboard provided with your phone.

I find protecting my data from the marketing parasite is a constant compromise with usability.

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.

just buy a pair of scissors

I wonder what happens when redirecting to 0.0.0.0 instead of localhost

OP's tweet is about the iOS app.

blocklist aggregator: https://github.com/jakeogh/dnsgate

You should be able to disable it though - it's effectively the same as uninstalling it.

> It also happens that the Facebook app is pre installed on Samsung devices and cant be removed.

It can be disabled, which is as good as removed. Now if Samsungs own apps could be disabled, I would be happier.

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.

This is why I’ll only use Vanilla Android (your second point, not your first one).

The customisation OEMs do to Android reminds me of the old, bad, days of Windows XP.

I know google maps uses this too. When I have an address on my clipboard and go to google maps it’ll be filled in.

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.

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.

[1] https://hluk.github.io/CopyQ/

[2] https://www.emacswiki.org/emacs/BrowseKillRing

[3] https://github.com/selfspy/selfspy

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.

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.