Facebook iOS App Scrapes Your Clipboard?
un-excogitate.org
un-excogitate.org
Previously, Facebook could have scraped it from the background.
Now you implicitly grant permission to read your clipboard whenever you open an app or extension.
My app Workflow[1] has a great workflow in its gallery that you can run from your widget to clear your clipboard if you regularly copy sensitive information.
very cool! was not aware of this change.
Shameless plug, but the app looks awesome. Would be cool (if not already done) if you could plug into IFTTT to fill in features that you can't/don't want to.
IFTTT integration is on the roadmap!
This sort of thing is difficult to detect in the AppStore Review process so apps that may appear benign could quite easily use this method to try to steal sensitive information with little risk of detection.
We've been lobbying Apple for a while now to improve the controls around clipboard data; specifically to allow us a policy that prevents prevents personal / unmanaged apps from seeing data that was copied from enterprise / managed apps. It might not solve the personal privacy issues but would significantly reduce this as a risk for corporate data.
Personally, I find sandboxing not as something desirable, but a symptom of a problem with mobile/web ecosystem.
It can be relevant to some applications: generally applications that are made more useful by being able to infer things about the global state of your OS. E.g., an unarchiver that wants to default to the current directory instead of asking you each time.
But certainly not all. And not even most.
As long as iTerm runs without sandboxing, I am happy ;).
This is widely considered a mistake, but it's also an implication of steady backwards-compatibility in app design -- and in many cases, code -- since the late 1980s. No one expected Lotus 1-2-3 to steal your WordStar documents, partially because neither of these were networked. So the OSes told Lotus 1-2-3, WordStar, and anyone else who came along that they had access to the entire drive and they could be designed as if they had that access, even though they didn't need it. Apps could ship their own Open dialogs; the OS trusted that they would only open files they were told to. A quarter-century later, the Windows and Mac App Stores are trying to reverse this, but the app developers are understandably grumpy because they have a quarter-century of code that never had to deal with such a design principle.
And the Windows and Mac App Stores are attempting to reverse this by reference to mobile app stores. Mobile platforms, being an entirely new mental model for both developers and users, could abandon lots of the design principles that make sandboxing hard. There is absolutely a reason why no mobile app has a desktop-style Open dialog: the OS doesn't trust it with that power. There is also a reason that the mobile AV industry is a tiny fraction of the desktop AV industry, despite mobile use having outpaced desktop use.
Is it? I've heard voices, but I didn't realize it's a very popular opinion. Personally, I think it's a feature and what makes desktop useful as a tool, as opposed to mobile devices being mostly toys.
You might not be able to do absolutely everything you could with unfettered access, but that hardly leads to "mostly toys." The nature of mobile apps stems far more from the use case of the devices (user attention measured in seconds, rather than minutes) than limitations of the software development platforms.
If you have any suspicion that installing an app will cause your phone call with your grandmother to be interrupted, you will really scrutinize what you install.
Early Android devices tended to have more problems than iOS devices when it came to phone calls getting interrupted, so whether this was marketing making an excuse for something Apple wanted on s technical level, it seems sandboxing was with the use case of "keep the phone working" firmly in mind.
I don't doubt that - but the problem is that everything you do with one app must almost always stay within that one. It's only when you want to exchange data between apps that all the power of the traditional full-access model really shines, and the reason why people have resorted to some horribly inefficient workarounds (e.g. upload to some server on the Internet from one app, then download the data in another) to do this.
That said, the notion of a file system isn't inherently incompatible with sandboxing. If you allow the user to grant permission on a per-app basis whether those apps can read/write to a common data store, you essentially have the benefits of a local file system in a way that does not break sandboxing.
You only want to sandbox apps to keep them from touching the OS and other private app data. If it is user-permitted for them to touch a common data store then that means data does not always have to stay within the app in which it was created.
But there's no reason such apps can't live side-by-side. I use Emacs to edit my hosts file, it's pretty convenient. A sandboxed Emacs would not be.
But I don't mind if the painting app I download is sandboxed because I'm going to be dragging-and-dropping my artwork into that program and I don't want it having access to my disk or network outside its sandbox.
http://plash.beasts.org/powerbox.html
I believe that Apple's desktop sandbox does use powerboxes, in that the Open dialog is privileged code and hands the app an open file handle. But it means that you can't tell Emacs to edit an entire source code directory. BBEdit had exactly this complaint about the sandbox.
I consider mobile apps toys because they're designed to contain and own your data, and that impares both the ergonomy of work and limits your capability for doing things to whatever is available in the MVP some startup released. Most apps don't evolve past the point of MVP.
Definitely not a "toy".
Real scissors are toys but plastic scissors are not toys since you can't hurt yourself with them.
The other aspect is that programs are traditionally really bad at being conscientious about your system, even when not being malicious. Windows programs have a tendency to put files wherever they feel like, although UAC has helped this to some degree. Plus, every program and its brother has its own update system that absolutely must run in the background constantly, even when I'm not using it.
As a desktop user I need little to none scrtuiny. My web browser, IDE, toolchains, IM, video player and computer games all work together well and while technically any one could own any other, this simply does not happen. It takes some (little) skill to avoid obvious malware, and then generally you're fine. On the other hand, I get to open my video file in my IDE, edit IM's data files in a word processor, and move things around seamlessly with OS; everything is expected to work and no program tries to lock me in.
> The other aspect is that programs are traditionally really bad at being conscientious about your system, even when not being malicious.
I don't think much has changed here. Phone apps are also not conscientious; they fight for your attention with other apps and with the entire operating system. The changelog of both Android and iOS is full of things done against app developers, because many popular app developers are willing to do anything imaginable to get your attention (and thus ad money).
My point is - the problem isn't with sandboxing itself; it's with the web and mobile ecosystem that makes developers work against the interest of users, instead of for it. The sandboxing is just a symptom - something that is being done to mitigate the damage of greedy "entrepreneurs". Desktop environments don't need that much sandboxing because there isn't that much crap going on.
I think the fact that desktops originally weren't connected to the Internet is a reason we've started with an open system, but it may be worth preserving this flexibility even in the Internet era.
There's something with web/mobile that makes people afraid to do anything without sandboxing the living hell out of every app, even though we've managed to live with unsandboxed desktops without many such incidents. I can't exactly put my finger on what is going wrong (it has definitely something to do with installing random crap and the new business model of companies trying to monetize user's eyeballs and data), but the push towards sandboxing is a symptom of that problem.
Antivirus is mandatory on desktops
It's not just downloading malware that is an issue; you also have to worry about security flaws in the apps you trust. Web browsers are a perfect example; they are constantly downloading untrusted code and executing it. Even when the javascript engine doesn't have a flaw, you have exploits like Rowhammer.js[1] which sidestep them entirely.
> It takes some (little) skill to avoid obvious malware, and then generally you're fine.
I think you're underestimating the knowledge needed to secure your computer properly, and overestimating the savy of the majority of users. The current state of computer security (huge botnets, etc.) is a testament to the fact that the current model isn't cutting it.
> On the other hand, I get to open my video file in my IDE, edit IM's data files in a word processor, and move things around seamlessly with OS; everything is expected to work and no program tries to lock me in.
If the lock in is an open file dialog, or passing a filename by command line, all of the examples you list would work fine.
> Desktop environments don't need that much sandboxing because there isn't that much crap going on.
You are missing an important difference; most users are far more liberal in downloading apps for mobile than for desktop, and if they were just as liberal on their desktops they would be pretty much guaranteed to get malware. Because of this, many apps which are only used in a browser on a computer are used as apps on mobile (which is needed at the very least for performance reasons). Sandboxes aren't perfect, but they move the ability to infect a device via installation from "totally trivial" to "requiring significant vulnerability".
> Desktop environments don't need that much sandboxing because there isn't that much crap going on
You're safe if you install only paid-for software from big companies and open-source software that hasn't been bundled with installer malware. And never install Flash or Adobe Reader. And keep your browser, AV, and anti-malware up to date.
The plural of unsandboxed desktop is "botnet".
Yes, this is tragic and a real threat to open software development.
[0] - most desktop software doesn't need Internet access; even most mobile software doesn't need it in principle, it's only because of lazy business models that they have to have it.
OS X solves this quite elegantly. If an application is sandboxed, it cannot access files outside the sandbox directly. However, when an Open (or Save) dialog is requested, it is handled by a privileged daemon outside the process (it used to be pboxd). This daemon then makes the file or directory available in the sandbox after selection.
You still get app isolation, but it does not impede the user experience. (Of course, it does not apply for every scenario, but sandboxing is not a requirement outside the App store.)
E.g. Finder replacements, tools like Alfred, BootChamp, etc.
Maybe you misunderstood my post but that's exactly what I meant should not be misunderstood as sandboxing. Sandboxing api calls is not the same as hiding the file system.
You shouldn't download and run random executables on your Desktop OS though. Ideally, you only install open-source software, from a fairly secure repository, using a package manager which knows exactly which package is responsible for each and every file outside your home dir ... That's a not-quite-attainable ideal, but some people get quite close to it.
From what I've heard, a lot of them really are websites, as all they do is wrap the OS's browser control and open it to the specified website. In other words, they're nothing more than enormously bloated browser bookmarks. That is a problem, but I think it's more attributable to the lack of support for adding browser bookmarks to the home screen than anything else since the only reason they exist is so people can go to some company's website more easily.
That said, a sandboxing feature for the apps you don't necessarily trust is certainly a good idea; nevertheless, I personally don't see much value in keeping around those which I only somewhat trust, but don't trust with full access. It's either apps I trust completely, or ones I find alternatives to which I can.
The thing we're grumpy about is the lack of respect for the central dogma behind the personal computing revolution: one machine, one owner, one user.
Recently, for example, Apple has literally granted themselves higher access privileges than the admin/owner of a machine running the OS X file system. There are files on the hard drive that they can write to and delete that you, the owner, can't, without extraordinary (and nonstandard) efforts. Naturally, it will only be a matter of time until Microsoft notices this innovative feature and copies it, more or less verbatim, into Windows. At that point, it's no longer "My Computer" -- it's theirs.
And all of this is accompanied by the sound of thunderous applause. Because, you see, it's For Our Security.
In addition, no Intel Macs have any means of operating system lock-in. You can run Windows, Linux, or anything else that can handle standard x86 hardware. So you seem to have full control over the hardware at least (except maybe the SMC, which is not easily modifiable on standard PC hardware either). And given the fact that the Darwin kernel is open source[1], you are free to patch out SIP entirely and run that instead.
Yes, that's what I meant by "nonstandard." Apple has invented a brand-new access control mechanism to keep people from tinkering with files that reside on their own computers. For now you can work around this feature. Once they close that particular gap, I'm guessing we'll still be able to use a debugger to get the job done... and I'm guessing you'll move the goalpost accordingly.
[0] - It's not really "coming" anymore.
So, probably one of the most dangerous things you can do (opening the door to rootkits and an infected BIOS) doesn't take just a click and an undistinguished warning dialog? Also, this has been around since at least Windows 7, its not evidence of us sliding down a slope.
Yes, rebooting Windows one time to do it isn't that bad, but it's a start. I won't be surprised if the next version of Windows (next after Win10) removed that feature completely.
Forcing users to run only signed drivers is a problem because only Trusted Vendors can get proper certification (after paying proper amount of $$ to Trusted Certification Providers). Such restriction will basically kill hardware tinkering, which is one of the goals of the War on General-Purpose Computing.
Not if the Trusted Computing Group has their way; it's already happening with things like Secure Boot. Hopefully things will change for the better, before we get to outlawing debuggers[1]...
It's slightly more difficult than turning of UAC on Windows. In addition, they didn't even try to hide the ability to turn it off; it's available in the documentation [1].
The only way they could seal the more difficult workaround I detailed above would be to either:
1. Rewrite their kernel so they don't have to open source it. In this case, I have no doubt the Hackinitosh community will have a patched version within a week. Goalposts moved I guess. Note you can still edit those files by restarting in another OS, which shouldn't be a problem for anyone who knows enough that they should be messing with such things.
2. Modify the hardware so it can only boot signed OS X. At this point, SIP is pretty irrelevant to the issue, and there doesn't seem to be any strategic advantage in even having it.
Also, I'm not sure what the motive is here. I can still install and run whatever binaries I want, signed or otherwise. I have El Capitan and I'm even using a custom shell. If Apple planned to require signatures for even command line programs to further their evil anti-Turing plan, SIP would again become irrelevant. So what slippery slope are we sliding down?
[1]: https://developer.apple.com/library/watchos/documentation/Se...
But social network or advertising apps are unwelcome on a desktop, and in fact are usually referred to as malware when outside of a browser. I don't have much software on my desktop which isn't either a license I paid for or open source software.
According to Facebook's Privacy Policy [1], "We collect information from or about the computers, phones, or other devices where you install or access our Services, depending on the permissions you’ve granted." Since obviously you've granted it permission to access the clipboard of your device and you've agreed to this Privacy Policy while installing the app, Facebook can legally collect, store and sell the contents of your clipboard.
From the Chief Security Officer of Facebook....
Looks like the FB engineers just pop the URL and check for "https?://"[0] at 0 in the string.
EDIT: found this: http://www.siliconbeat.com/2015/06/24/yahoo-loses-security-c...
Where it is written:
> Stamos also won plaudits this spring at Austin’s South by Southwest festival when he revealed the company will roll out end-to-end encryption for Yahoo Mail by the end of the year.
Except, I don't believe Yahoo ever did "roll out" end-to-end encryption for email?
https://github.com/yahoo/end-to-end/commit/8bf5dca239bb1df3f...
[1] http://yahoo.tumblr.com/post/113708033335/user-focused-secur...
I'm more concerned that iOS gives this ability without any warning or notification to the user, because even if Facebook is virtuous (now) about this, other future apps may be less so.
And if App provides some extended functionality for which it need to constantly monitor clipboard (I never used such app), it needs special request from user and special flag in plist file, so moderator can review it.
I don't like the direction where this is going. We've created an adversarial situation, where software developers go against users and against each other and then instead of fixing that, we keep destroying features of cooperation and interoperability in the name of "security" and "privacy".
sandboxed apps may only access a file outside of the sandbox via an explicit user interaction with a system UI element, i.e. drag-and-drop a file via OS X drag-and-drop API, select a file in iOS / OS X owned file dialog, share sheets, etc.
I wouldn't mind if I opened an app and got a one-time dialog "This app is trying to access your clipboard. Do you want to allow it?"
Adds one more step for setting things up but saves the clipboard as a whole. People using password managers are already people willing to jump through some hoops to set things up, adding one more hoop shouldn't make things worse.
(https://play.google.com/store/apps/details?id=keepass2androi...)
But I don't want that either.
We must be careful to pick up sane defaults; just shutting down everything because "privacy" is not a way to build useful technology.
https://play.google.com/store/apps/details?id=com.cal.pas.ul...
I can tell you, you would be pissed off. But instead, you simply feed ever more information into the Facebook global surveillance system. Good job.
Or as the website claims: it scrapes my clipboard.
This functionality is used to add videos from the web to your Queue for later viewing.
How do we solve these issues once and for all? Is it on the OS level, or consumer education, or must the government intervene?