Hacker News new | comments | show | ask | jobs | submit login
How Dropbox Hacks Your Mac (applehelpwriter.com)
1037 points by 8bitben on Sept 9, 2016 | hide | past | web | favorite | 412 comments



Hi HN — Ben from Dropbox here on the desktop client team. Wanted to clarify a few things —

- Clearly we need to do a better job communicating about Dropbox’s OS integration. We ask for permissions once but don’t describe what we’re doing or why. We’ll fix that.

- We only ask for privileges we actively use -- but unfortunately some of the permissions aren’t as granular as we would like.

- We use accessibility APIs for the Dropbox badge (Office integrations) and other integrations (finding windows & other UI interactions).

- We use elevated access for where the built-in FS APIs come up short. We've been working with Apple to eliminate this dependency and we should have what we need soon.

- We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).

- We check and set privileges on startup — the intent was to make sure Dropbox is functioning properly, works across OS updates, etc. The intent was never to frustrate people or override their choices.

We’re all jumping on this. We’ll do a better job here and we’re sorry for any anger, frustration or confusion we’ve caused.


> - We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).

To clarify for others: In /Library/DropboxHelperTools, you'll find a folder for each user full of setuid tools which run as root and do various privileged things. I assume that the client is presenting the normal OS X "ask for elevated access" UI and then using that elevated access to configure and install these. (I don't work for Dropbox or anything; I've just been poking around.)

> - We use accessibility APIs for the Dropbox badge (Office integrations) and other integrations (finding windows & other UI interactions).

@newhouseb, I don't have Office, so I've turned off the badge. Is Dropbox now going to leave my accessibility permissions the way I set them? Or is it going to reactivate a permission behind my back that it no longer even needs?

I understand the desire to make your features "just work", but circumventing the user's privacy controls to do that is never acceptable. Especially accessibility, which is basically a general warrant to snoop on everything the user does. You wouldn't be on my system anymore if my work didn't require Dropbox. You're going to lose a lot of trust over this, and it won't even be half of what you deserve.

And it's not even in your interest in the long term. This fiasco has probably made it more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement. Since Dropbox can't really do its job when it's locked in a sandbox, I really don't think that's what you guys want to happen.

Teams like yours are why we can't have nice things.

(P.S. plz respect NSFileCoordinator this isn't Tiger anymore kthxbai)


> @newhouseb, I don't have Office, so I've turned off the badge. Is Dropbox now going to leave my accessibility permissions the way I set them? Or is it going to reactivate a permission behind my back that it no longer even needs?

Yep, we’re going to fix this so that if you uncheck it, we leave it unchecked.

> This fiasco has probably made it more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement.

As alluded to elsewhere in this thread, this is already happening in macOS 10.12. We’ll be switching to the same approach that Steam (among others) do to request accessibility.


Honestly, after the last year and a half, anything that wants root access, that is not open source, is out. Now, being open source does not make that automatically safe but it is a step in the right direction. Dropbox, MS Office, etc, are closed source tools that puts too much at stake.

Granted my team is small, but we just uninstalled dropbox today. Going to use the web interface and look for another solution in the meantime.


I'd love to hear what you find. My research has shown that Dropbox is mostly the only sync service supported in mobile apps. iCloud is next. After that it's very rare to see any other integration.

I'd love to see Box or someone else encourage popular apps to support their sync platforms, but I doubt it will happen. I blame Apple for not supporting easy 3rd party integrations.


I have no idea what Dropbox actually is or does (I'm FOSS-only, at home and at work), I've only heard of it, so I may be way off the mark.

With that said, on the assumption that it is a way to exchange files between computers and/or share with other users, it would seem to be the case that ownCloud (nextCloud) fits the bill. You can host it yourself (as I do) or use a third party to host it for you. I have been using it for a number of years and I'm entirely happy with it.

Also, depending on your use scenario, another possible option may be https://www.stackfield.com/ a German end-to-end encrypted storage company. I believe there are others offering similar services.


Seafile (https://www.seafile.com) and ownCloud (https://owncloud.org) both are open source and have mobile apps. Worth checking!


for synching between devices I use BT-Sync, now Sync.. closed source but reliable as a background daemon not needing intervention


box.com as well. We have free accounts, hipaa/gov grade encryption and security, and lots of collaboration options. :)


Have you tried StorageMadeEasy.com ? Connects to dropbox and other clouds too.


But it isn't open source.


I switched from Dropbox to Mega a few years ago and they now have mobile apps, sync clients for multiple operating systems and decent browser extensions in addition to a more generous storage allowance. There is also the added benefit of encryption. So far I remain impressed with their service.


I switched from Dropbox to Mega

Really?

FWIW Kim Dotcom, the founder of Mega, has distanced himself from it, saying the company had "suffered from a hostile takeover by a Chinese investor who is wanted in China for fraud"[1]

So yeah, don't trust Dropbox. Instead trust some shady Chinese characters. Can you name one of them? In comparison, note that Ben Newhouse, a Dropbox employee, is actually posting in this discussion.

There is also the added benefit of encryption

Without full source code to said encryption, all you have to go on is "trust us".

Forced to choose between the two, I know who I'd trust, and it wouldn't be Mega. YMMV.

[1] https://en.wikipedia.org/wiki/Mega_(service)


Luckily, there's third party clients that are open source for Mega.

And they're actually usable.


> Instead trust some shady Chinese characters.

What does Chinese have to do with this?


Mac OS X is a mostly closed source operating system so I don't understand why you are drawing the line with third parties.


Apple has shown itself to be trustworthy.

Dropbox has done the opposite.


I suspect many would like to run something more open than OS X/macOS, but because of the alternatives, it's just not viable for business purposes not to, according to what their needs are. I know that is the situation for me.


Try SyncThing. It's cross-platform (written in Go), fast and secure (BitTorrent Sync style, but open-source).


I use it, but there's no iOS solution so I can't use it for a number of things.


BT-Sync is the original of syncthing with iOS-support but considered bad because its closed source and comercial

I like it though


I don't use BT Sync because if I'm on my local university network they block BitTorrent. It's not a big deal since I've graduated, but I still go there and use the library and meet with people so it would be inconvenient.


I should say, Ben, thank you for coming out in public and sharing your team's perspective. Your users are angry—and I think rightly so—but it does help that we are being told why it was done, that it was merely poor judgement rather than deliberate misbehavior, and that you are working to make the Dropbox client a more responsible citizen. Is it as good as not having done it in the first place? No. But it's much better than radio silence.


Wow, it's stunning that an app would install anything suid root.

Admittedly I'm not a Mac guy, but that can't be common practice.

And then the response isn't "we're going to stop endangering our users with this dangerous practice", it's "we're going to stop doing this one particular thing that happened to be called out this time".


> that can't be common practice.

It's not. It's very unusual.


> more likely that Apple will further lock down the accessibility APIs, possibly even making them unavailable without an Apple-issued, potentially App Store-only entitlement.

Please feel free to duplicate my radar! Accessibility and Productivity/Utility app developers would love a Sandbox entitlement.

rdar://13570189 - Sandbox entitlement for Accessibility API to allow apps for the disabled

The Accessibility toolkit has always been off limits to Sandboxed apps, and no entitlement exists. This seems unlikely to change. It's unfortunate, as this keeps many good and useful apps out of the Mac App Store.


Is it worth adding that to OpenRadar?

https://openradar.appspot.com/search?query=13570189


I don't really see the point of taking a sandbox and then explicitly granting an app inside the privilege to step out of it.


I don't really see the point of banning Accessibility apps that can't be sandboxed but then allowing those same apps to be distributed outside the Mac App Store. Unless you're banning them from macOS entirely, why not allow these potentially "dangerous" apps to operate underneath the additional Reviews and Guidelines of the App Store?


Because an app being on the App Store creates an expectation that cannot be met without the sandbox.

Without the source code and large amounts of resources it is not possible to determine whether an app is malicious or not. The only way would be for Apple to trust that developers actually do what they say they do. The unfortunate reality is that they cannot be trusted. I don't blame Apple for not taking that responsibility. Unfortunately that means the responsibility ends up with the user who cannot make the determination either. Such is life.


Many app stores (even for smartphone) have sandboxes where you can grant additional privileges. Of course the user (who else) has to decide whether they trust the app or not. But I'd be happier trusting a sandboxed Dropbox, especially because it couldn't have hidden its use of Accessibility.


Not from Dropbox but when you remove an app from accessibility permissions OS X will make you manually enable it again.


mikewhy: The article states that it re-adds itself to the list automatically the next time you log in, without asking for permission again. There's no option to keep it permanently disabled.


You could delete all of their suid helper binaries.


Can you also tell us why Dropbox eats lots of CPU cycles anytime there is any filesystem activity?

If I unzip a large archive in /tmp, Dropbox is eating 60% of my CPU.

If I open the new Xcode for the first time (and the system verifies all the signatures) Dropbox is eating 100% of one CPU.

It really seems like the Dropbox client is monitoring the entire filesystem (all FSEvents) instead of just the dropbox syncing folders, and doing it relatively inefficiently at that.

At this point if I'm doing anything filesystem intensive I close Dropbox first.


Bingo.

It started with my laptop running incredibly slow. A bit of digging showed dropbox saturating an entire cpu core despite no recent changes being made to my dropbox folder. What was happening at the time is a lot of disk activity on a folder that Dropbox should know nothing about. I'm not 100% sure but it also seems to me that Dropbox is monitoring all FSEvents on my machine and doing something with them.

I've been a paying Dropbox user for several years, but this has tipped me over the edge. The only way to regain my trust at this point is providing an official explanation of what's going on, with technical details. I'm paying for a service to keep my files safe and sync them across devices, nothing more, nothing less. Now that I got the impression that Dropbox is doing something outside of that envelope, even if that impression is wrong, my money is going to go elsewhere, probably to a competitor.


I feel bad for contributing to the hijacking of this thread, but I simply have to pitch in: please do something about the abysmal performance of Dropbox. We have what are practically supercomputers on our desks, and Dropbox has problems dealing with hundreds or low thousands of files. It is something you need to work on.

As to the original article, I think you have a lot of explaining to do and a lot to clean up. Too much has been swept under the rug.


Just checked this myself on a MacPro. You can see the DropBox process kick in with CPU usage while opening big apps like Photoshop or Xcode. Not a lot on this MacPro (~3%), but it's always in time with an app opening. Oddly there's no corresponding disk access associated with the Dropbox process when looking at it on the Disk tab of Activity Monitor.

Would definitely like an explanation of what's going on here.


Could this be a consequence of the built in FS APIs coming up short, as Ben put it, and forcing DropBox to do things in less efficient ways to work around the limitations?


Doesn't Apple literally have a sync solution on this platform, likely using these same APIs? FSEvents powers a lot of core functionality on macOS so it's surprising to hear it just doesn't meet Dropboxes needs.

It's cool they are moving into the kernel soon anyway, just install their kext...


Is Apple's sync reliable though? There was an episode of MacBreak Weekly last week where both Adam Engst & Andy Ihnatko urged people not to enable the new Sierra sync system, and talked about instances of data loss caused by Apple's various sync features. The segment begins here:

https://www.youtube.com/watch?v=IgE1c-YTEpE&t=65m02s

I thought it was common knowledge that Apple's own sync (nevermind the APIs they provide to third parties) was terribly unreliable. Even long-time Mac developers like Panic & Omni developed their own sync services because the Apple ones were so unreliable.


That and what I take to be the iCloud / System Indexing daemon's (like `mdfind`) kill my battery life. The other's reports of poor Dropbox performance baffles me a bit as it never seems to give me issues, but iCloud/Google Drive both have both had big performance penalties on 3 various macs I've tried them on.


That's also my experience - I tried using OneDrive & Bitcasa at various times, and found they used far more battery than Dropbox ever did. I'd consider switching from Dropbox, but the competitors seem inferior to me (and Dropbox has more universal support).


I can't fathom why you think them being a kext is a good thing. I refuse to use anything anymore that needs that, every app that needs that inevitably is a source of something breaking in OS X


Was complete sarcasm


What do they need different from what time machine uses?


Time Machine needs to be able to ask which files changed when it is preparing to backup. Dropbox needs to be notified when a file changes so it can sync.


Have you checked the version of the Dropbox client you're running? The auto-updater broke and silently failed many months ago (n=5 Macs) and I found a number of problems like that one had already been fixed but effectively never shipped.

(Support was prompt but basically “let us know if it happens again”)


I started to see this really happen when backing up. When Arq is doing some work, Dropbox is slamming the CPU. I checked with the Arq team and they said during the time I was monitoring it, there's no way they would be touching the Dropbox folder, so it really did seem like some kind of global intercept was going on and was killing the box. I guess this is as good a way as any to raise this -- Dropbox team, test with Arq!


Same problem. When working with or moving files in folders other than the dropbox folder, I still find the dropbox application taking up large amounts of CPU. Dropbox also, in the last few months, has been messing up my spotlight database and causing mdworker and fontd to use all available cpu.

Then I start getting console messages like this: mds (Error) FMW: WE ARE DROPPING FMW EVENTS!

All disappears after disabling Dropbox (and rebuilding caches and the spotlight database)

Behaviour seen on multiple macs I own.


I uninstalled the desktop client because of this exact issue. I just drag/drop via the web interface now. Might not work for some people, but it suits me fine.


Just uninstalled too. I was only using it for syncing 1password data and this pushed me to just switch to a 1pass account


1password has had iCloud syncing for a while now, and in my experience, it's been very reliable.


If you think they are so nefarious a company, why do you trust them with your files?


Didn't say they were nefarious—just that their software hogs resources at times when it has no business doing so (i.e., when I'm not reading from or writing to my Dropbox folder).


As important as this question is for usability, it seems off the original post's topic of Dropbox circumventing accessibility prompts.


Same problem here. My 3 year-old i5 Retina MacBook Pro is often slow because Dropbox uses 100 % of one CPU. And it gets hot too …


I noticed a lot of disk activity once and fired up Process Monitor (on Windows). Dropbox.exe was going through literally all the files on my computer. That was when I uninstalled it forever.


Yeah, I'm more curious as to why Dropbox corrupted a few of my PDFs. Has been happening for years for a variety of people.


If you see this happen, please write in to our support team; we take data integrity issues very seriously.

Also I should probably mention that we keep 1 month of version history for free users and even more history for paid users, so if the corruption is recent you should be able to undo it yourself. But please report either way.

(Full disclosure: I work for Dropbox).


I'm a huge fan of Dropbox and I pay a monthly fee. I probably don't need to as my data needs aren't huge, but you guys are frankly the first people I've used that did this sort of thing properly and I believe you are worth paying a subscription fee to.

I'll log a ticket :-) might need to reproduce the issue first. Pretty awesome that you have employees who respond to posts on HN incidentally, that automatically increases my loyalty to a company several notches!


It's very strange that after I remove Dropbox from the accessibility list you think it's ok to add it back in again. That's the reason I'll be closing my account.


Absolutely. I dropped Dropbox some time back, when it became obvious that they didn't respect the user's wishes at all.

This has been a long-standing thing with them - some years back there was some stink about the forced Dropbox branding in the Finder (which we now see is related to this). Many people (including me) found it rude that it insists on adding useless widgets, badging icons and inserting crap in the Finder sidebar. For whatever reason, Dropbox (the corporation) apparently believes that junk to be important enough to their business to disregard what the owner of the machine wants, and now we see the lengths they go through to force themselves on the user.

I used to simply consider Dropbox rude enough to make me not want to use it. Now that I see the company is actively going out of their way to break the intended function of security-related OS components, I now consider Dropbox malware and will begin warning others about the company.


badging icons and inserting crap in the Finder sidebar

Their branding strategy is really annoying. I pay 10 Euro per month for Dropbox Pro, but they have Dropbox Business ads plastered all over the web interface.


For what it's worth I find the finder icons and sidebar additions to be nice touch, but I guess it would be nice to be able to disable that. The office integration on the other hand is beyond useless. The Dropbox badge mostly gets in the way of being able to scroll trough my documents and I have never used it for anything.


You can disable the Finder integration in the preferences, same for the badge.


Most programs don't consider that you might try to explicitly revoke permissions. It's a very understandable bug/behavior. I think it's worth giving them a chance to amend that code.


It didn't even ask for permission the first time.


Why would you even do that? What nefarious and yet undiscovered things did you think DropBox was likely to do specifically with the accessibility permission?

Permission systems in general seem like a solution without a problem to me. Nobody but a minority of people very concerned about theoretical security problems wanted them on platforms that didn't have them, almost nobody cares what permissions programs use on platforms that have them now, and people get along perfectly fine and with less inconvenience shoved in their face running programs without permissions systems aside from a simple admin rights/no admin rights today on Windows and Linux.


What if Dropbox has an exploit they're unaware of. Someone finds a whole in Dropbox and boom, now they have accessibility access.

Even if you trust the software vendor, security concerns can cascade.


This got downvoted and I'd like to know why. This was one of my first thoughts as well while reading the article: what if Dropbox gets hacked? Their client apparently has access to everything.

What if the hack pushes a rogue client? Or one CDN endpoint serves a malicious update? Or a little bit of code is sneaked into the development process? Or an employee gets sour? Or a million other things that you hope never happen. There is a reason we don't run apache/nginx/any networked service as root. (You don't, right?)


> and people get along perfectly fine and with less inconvenience shoved in their face running programs without permissions systems aside from a simple admin rights/no admin rights [...]

...For values of "perfectly fine" that include millions of malware slaves on the net, hundreds of millions of stolen passwords, targeted 0 days attacking human rights workers, file-encryptor extortion apps, etc. etc. etc.

> What nefarious and yet undiscovered things

If they're undiscovered, how am I supposed to list them?

As far as discovered things, the permission allows Dropbox to sniff the keyboard and interact with any other application as the user. Add that to unrestricted filesystem access, and the right question to ask is what nefarious things Dropbox can't do.


I prefer to know what the apps I install are going to be doing. To this end, OS-enforced permissions for using various services are a godsend. No program should need "admin" rights. And I should be able to know and control what each app I run can and cannot do. This seems utterly obvious to me. Even if most people dont' care, the tools should be there. There've been more than enough cases where apps have collected information they shouldn't have, whether intentionally or lazily. It baffles me that anyone could seriously make the argument you seem to be making.


Right, they have all your files already, so there's clearly some level of trust.


> they have all your files already

Hell no they don't? They have some shared folders between classmates and a few encrypted archives for personal backups.


1. Dropbox asks for root

2. Dropbox does not use sandboxing (at least, the one I have doesn't)

So, they do.


There is a difference between having all my files and being able to access all my files via a client.

1) My files are not on their service and thus not available at their discretion; they would first have to be uploaded.

2) With that logic all applications "have" all my files, but you bet I'd find it weird if I caught Libreoffice uploading files of interest to a service of theirs.

That said, I do see your point. Most desktop applications (as opposed to mobile apps) are capable of a lot more than they need to, and even many popular mobile apps are. I just wouldn't say I implicitly trust them with all of my files.


> 2) With that logic all applications "have" all my files, but you bet I'd find it weird if I caught Libreoffice uploading files of interest to a service of theirs.

On macOS this is not true though, for well-behaved document-based apps! Sandboxing prevents access to anything you haven't explicitly granted access to. I don't know if Libreoffice implements it correctly, though.


And before someone says that this is not feasible for a Dropbox-like application: OneDrive is distributed via the App Store (with its sandboxing requirements).


There's been some downvotes (thanks for the constructive feedback /s), but I'd agree that this is a better way to put it. Anything that asks for root has 100% access at that moment, and possibly in future. It's easy to forget with all the "training" that `sudo`and confirmation dialogs provide, but true. Heck, if you install something (and by install I mean allow itself to integrate into the system, as opposed to say a script), you have to trust something. Either you trust the issuer, the package maintainers, or yourself (after you've checked 100% of the source code and compile it), but there's trust at some point.


They only have (well should only have) access to the files I share on Dropbox, which is pretty much just music files, so if someone steals those files, I won't be too upset.


At this point you need to follow up with convincing technical details of why Dropbox needs the circumvention to counter the accusation and rebuild the damaged trust.

The reason for needing Accessibility API listed in your response is pretty vague, especially for those Mac users not having Microsoft products tainting their systems.

I've deleted Dropbox from my Mac for now. I'm not installing it back till there's reasonable explanation and remedies.


> why Dropbox needs the circumvention

I'm not affiliated with Dropbox, but compare the UX of Dropbox (type in your admin-password and that's it) with the one of Steam (opens the System preferences and forces you to make manual changes). Both need to be allowed accessibility access for one feature or another, but only one of them provides convincing UX.

For us power users, the "official" way is better, sure, but what's the percentage of power-users compared to normal users who actually enjoy the office intrgration and other things made possible by the accessibility API?

I would be happiest if it didn't do the dirty thing and also didn't offer office integration. Maybe that's the change they need to make. But if they insist on doing the things that need accessibility, then the current solution is so much more convenient than the steam dance.


Doing it is only part of of it. Doing it behind users back without a message or warning, or a even an article on their website is the biggest problem.


I agree with you general sentiment, but would Word or Excel really "taint" your system?


Morally?


Vs. Apple? That seems thin...


Fanboys be blind to the hypocrisy and all that jazz...


Not everyone shares your same sense of morality.


I can't stand the `~/Documents/"Microsoft User Data"` folder, but that's what I get any time I open an Office app.


"We use elevated access for where the built-in FS APIs come up short."

One wonders what Dropbox would say if someone decided to obtain elevated access on their servers by surreptitious means because Dropbox's API "came up short".[1]

[1] https://www.dropboxforum.com/hc/en-us/community/posts/204550...


I really wish there was some type of option to go "I really don't want all that fancy crap; give me the version that works via standard APIs"


That is the web UI.


> We use elevated access for where the built-in FS APIs come up short.

Can you please provide an example of such shortcomings and accessibility APIs that are better?


Setting the icon of a folder. Seriously. That's what they are using it for.


> The intent was never to frustrate people or override their choices

When you designed an agent that specifically overrides the user's choice to turn off Accessibility rights for Dropbox, frustrating that attempt, I suspect that was intentional.


Note: not excusing Dropbox, but understanding how they reached here.

Bob (who less technically savvy) installs Dropbox for use with Office. Chuck (someone more technical than Bob) removes Dropbox from the accessibility list. Chuck has now broken Bob’s Dropbox, and Bob (being less technically savvy) blames Dropbox resulting in another ongoing thread about broken Dropbox.

I completely understand how Dropbox reached this point, and purely from a technical support point of view, how it is justified. There are probably better ways for them to have done this (still have the “hack”, but only insert it if Office applications are detected to be installed; have an option that can turn it off even if Office is installed, but warn about it and make it “easy” to turn back on).


In the long run, the best way to demonstrate that your software is trustworthy is to release the source code for your client software under an open source license.


Regardless of the password issue, if you are legitimately working with Apple to get the granular access to implement the useful features you want, why would you in the meantime subvert Apple security mechanisms (by using a sql vulnerability - this already more than qualifies you as malware IMO) to sneak the features in rather than asking the user to grant the accessibility permission?? No, this is more than a "my bad," this is deceit and violating.


Uh, nope. You've just ensured Dropbox will never be installed again on any of my machines or devices. Ever. You fuck up like this, you never earn that trust back.


>We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).

If that's the case, How is it that the accessibility preferences are changed without root authorization?


Once you type your password into the Apple dialog, you grant Dropbox root access. That's the purpose of this dialog in all cases.


Per the original article, even root doesn't automatically have permission to modify the system.preferences.accessibility list.


I think you're wrong. It's a bit vague with all the unfamiliar systems (I have no experience with OS X), but root is mentioned in a few places:

> "The allow-root property specifies whether a right should be allowed automatically if the requesting process is running with uid == 0. This defaults to false"

So the agent does not (by default) make an exception for applications running with uid 0. It does not say anything about modifying a certain file, it's just about the agent (if I understand it correctly).

> "In other words, if allow-root isn’t explicitly set, the default is that even a process with root user privileges does not have the right to perform that operation. Since that’s not specified in the default shown above, then even root couldn’t add Dropbox to the list of apps in Accessibility preferences."

Same thing again. Agent won't allow, but file permissions are not mentioned.

> "Root wasn’t allowed to override Accessibility, and authenticate was on, so it couldn’t be this way that Dropbox was hacking my mac."

Same again.

And that's all places where root is mentioned. Later on, however, sudo is used:

> "To insert an app in the list, you grab it’s bundle identifier (in the case of Dropbox, that’s com.getdropbox.dropbox), and issue:

> sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db “REPLACE INTO access VALUES(‘kTCCServiceAccessibility’,’com.getdropbox.dropbox’,0,1,1,NULL, NULL);”"

So sudo, which makes a command run as root, can modify that database.

And as far as I know this makes sense, because at least in Linux file permissions are simply not checked when uid is 0 (root user). Darwin/BSD might differ, but my unix family tree knowledge doesn't go that far.

Also, how else could Dropbox do it? As mentioned in the article, one of the helper applications contains an SQL statement (see the part about running "strings"), so it does seem to be directly modifying that database.


Agree. I now see the agent it installs is suid root.


Office Integrations: Worthless for a huge swath of users who don't have Office. Also undesirable for a large group of users who have Office but have no use for the integration.

Other Integrations: Too vague to justify what is potentially a large security threat. You've really got to do better than that.


The dialog box you see is a native OS X API (i.e. made by Apple).

Which API are you using that allows you to circumvent the OS X Accessibility Permissions control dialog? Or do you mean you're simply asking for administrative permissions in order to write directly to TCC.db? And in that case, what mechanism are you using to circumvent the permissions structure to permit you to rewrite to TCC.db without re-requesting the user's permission?


The Accessibility Permissions dialogue doesn't just show up. You as a developer can control when it is shown (using AXIsProcessTrustedWithOptions).


It would be awesome to have it not use accessibility APIs. I'm going to be following the instructions to revoke those rights.


I still don't understand how this allows for accessibility circumvention dialog.


If I understood correctly, using the root permission granted by the user when the prompt for the password comes up, they hack the database containing the accessibility settings, and add themselves to the list.


>but unfortunately some of the permissions aren’t as granular as we would like.

Nice euphemism for "catch all" permissions...


I'm not really concerned about Dropbox's intentions, or even the accessibility integration. What worries me is:

- There are numerous setuid binaries without any documentation or source code available. These have the potential to breed nasty zero-day privilege escalation exploits, possibly worse.

- Dropbox goes out of its way to obfuscate its Python bytecode. This doesn't prevent intellectual property theft: there will always be people capable of reverse engineering it (e.g., https://github.com/rumpeltux/dropboxdec). The only effect that it has is to significantly decrease the security of the application: technical users can't easily review the inner workings without a substantial time investment. Hackers, on the other hand, have massive profits to gain from reverse engineering something as popular as Dropbox, and won't hesitate to do so. This represents a lack of regard for security on Dropbox's part, indicating that they favor intellectual property protection over the security of their customers. When I buy a car, I can open it up, check the brakes, and be sure I'm not going to crash into a tree. I expect to be able to do the same with the software on my computer.


It looks like DropboxHelperInstaller can be used to extract an arbitrary tarball as root into /Library/DropboxHelperTools, preserving permissions. It takes two arguments: the first is a number (doesn't seem to matter--maybe PPID for callback?) and the second is the bath to the GZIP'd tarball. It seems to require that the tarball have an RSA signature appended to the end, but there are signs that the check may be less than ideal and possible to circumvent.

Output from extracting a Dropbox-signed tarball (in this case, DropboxHelperInstall's own tarball):

    <pid>52229</pid>
    crypto error while Verifying Signature: block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1)
    crypto error while Verifying Signature: padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT)
    mkdir '/Library/DropboxHelperTools' 0755 -> 17
    extracting ./._DropboxHelperInstaller
    extracting DropboxHelperInstaller
    <ok>
Output from attempt to extract a third-party tarball:

    <pid>52286</pid>
    missing magic number
    unable to read_digest
    couldn't verify signature
    <failure> -1
Output from attempt to extract a third-party tarball with the signature copied from a Dropbox tarball:

    <pid>52142</pid>
    crypto error while Verifying Signature: block type is not 01 (in rsa routines:RSA_padding_check_PKCS1_type_1)
    crypto error while Verifying Signature: padding check failed (in rsa routines:RSA_EAY_PUBLIC_DECRYPT)
    crypto error while Verifying Signature: bad signature (in rsa routines:INT_RSA_VERIFY)
    couldn't verify signature
    <failure> -1
It's probably worth reverse engineering DropboxHelperInstaller to ensure that the signature check can't be evaded. Even then, I'm not sure I like the idea of anyone with Dropbox's private key being able to install arbitrary setuid binaries on my machine. Given recent events, it's quite possible the private key has already been stolen.


That office integration is a PITA, is there anyway to disable it?


On a Mac: Click Dropbox Icon in the menubar -> Options (gear in bottom right) -> General -> set Dropbox badge to "Never Show"


Now a malware can target your scripts and get a free ride to all your system yay.


@newhouseb

Off topic: can you help me understand why when a file is locked (e.g. Outlook accessing .PST file) this causes Dropbox to peg the CPU to 100%.

I've opened multiple bug reports over the years and support dismisses my finding.

This makes Dropbox un-usable for me. I literally have to run Dropbox as "paused" 90% of the time and only "unpause" Dropbox when I close Outlook.


>We never see or store your admin password. The dialog box you see is a native OS X API (i.e. made by Apple).

Is it a native OS X dialog API, or native OS X authentication API? I could make a password prompt myself, and call that "being official Win32 API".

Can you show me the class where you invoke it, so I can judge for myself?


It's a standard OS X authentication API. The overview of the authorization stuff is discussed in:

https://developer.apple.com/library/mac/documentation/Securi...

If you look under "Authorization Services Tasks" you'll see there's details about calling a privileged installer.


You are really just digging the hole deeper at this point. This needs a mea maxima culpa.

Apple really should kick you from the App Store and blacklist dropbox as malware.


I don't think Dropbox is listed on the App Store (I doubt it meets the sandboxing restrictions)


I meant the IOS App Store, not the Mac App Store. But this does highlight why Mac App Store app restrictions exist.

Re blacklisting, I'm referring to Apple's Xprotect (https://www.intego.com/mac-security-blog/topic/xprotect/).


Upgrading your privileges is against sandboxing rules, so no it can't be sandboxed.


> We only ask for privileges we actively use -- but unfortunately some of the permissions aren’t as granular as we would like.

And as for the rest of the privileges, we just take them without asking. Who knows, someone might refuse!


I removed the Dropbox app from my iPad when they started to require a active GPS to upload files. [about two years ago] If you disallow GPS for that app, it disallows you to upload files. Stupid decisions!?


wat. I just checked, I have Location Services set to 'Never' on Dropbox and it uploads files fine.


It was about two years ago. I removed the app, never looked back. But recently came across a news that Dropbox got hacked and all passwords were captured and leaked. At the same time I received an email from them, not mentioning that (as far as I remember) but what they mentioned they will delete my account if I don't login in the next x weeks. It seems Dropbox had its peak, and it's going down-hill from there -except they do an IPO or find a someone to sell (maybe they already do just that).


Just wanted to give the author a shoutout for being awesome. This article is published with an AMP version[0] too, which is pretty unusual for smaller blogging sites.

AMP articles are so much easier on my eyes (and the author can't include their own javascript on an AMP page, so there is less bloat). I wish all bloggers started to publish AMP pages.

[0] - http://applehelpwriter.com/2016/08/29/discovering-how-dropbo...


AMP is not the solution. Anyone willing to use AMP to reduce bloat could also just not add bloat to HTML pages in the first place. And, using AMP itself adds bloat[1]. I couldn’t even read the author’s AMP version without enabling JavaScript.

[1] https://www.ampproject.org/docs/get_started/create/basic_mar...


AMP is bastardized HTML used as an excuse to making a website fast in the first place. I totally agree.

Additionally, AMP wants to become the arbiter of the mobile web. Just look at their list of "Supported ad networks." [1]

Who gave them the authority?

AMP worries me greatly.

[1] https://github.com/ampproject/amphtml/blob/master/builtins/a...


They've been pretty good about accepting PRs to support any ad network from what I've heard: https://github.com/ampproject/amphtml/pulls?utf8=%E2%9C%93&q...


Yes, just as ABP has been good about accepting PRs to add "unobtrusive ads" - until they started demanding money.

NEVER give this power to a central authority that's not democratically controlled.

And yet, some people still do that mistake.


I agree that their current process should become more democratic, and that this is a real concern. There is also benefit in moving quickly to try and solve a real problem and prove that this approach will work. I'm still cautiously optimistic.


All open source projects have some kind of "central control" in the sense that they can accept or reject pull requests and define what the official version is.

But you can fork them, so it should be okay, right?


Exactly, but I can’t fork AMP – as Google decides which fork gets preferred treatment by them


This is what really confuses me about AMP. All it does, really, is force authors to strip their page down to core, performant components.

Another way to do that is to strip your page down to core, performant components without loading a JS library from Google. But Google dangles the carrot of improved SEO with AMP, so everyone has to do it anyway.

(note: they don't actually prioritise AMP pages, they prioritise page load speed. But AMP pages are put inside a Google CDN, so, what do you know, they load fastest)


> Anyone willing to use AMP to reduce bloat could also just not add bloat to HTML pages in the first place.

AMP is not meant for page authors — usually, they are painfully aware of how much bloat they add. They don't have a choice when sustainability is in the balance.

AMP is for the ad networks. It draws sane restrictions to what they can do. On their end, ad networks agree to that because Google is a large partner of them and because the worst possible outcome would be having everybody use ad blockers.


> They don't have a choice when sustainability is in the balance.

This is not solved by AMP, it's absolutely the choice of publishers.

> AMP is for the ad networks.

Not really, you can see their official roadmap. Many of the original principles have already changed and many of the intrusive ad formats are already back in (like autoplay outstream video units). The only real optimization is better async loading which could already be done with proper coding by publishers and ad networks.


I can read all mentioned pages with NoScript enabled. But fully agreed that static pages such as blogs shouldn't require JS to show the primary content.


That depends. What about blog posts that have inline JS demos?


One example: in my static blog I provide very nice maths using MathJax, but I also provide fallback PNG renders of the formulae. The small JS my blog has, it reads these pictures' alt texts and renders the latex if found. This stuff is not rocket science, people just don't want to spend time on this kind of stuff.


You might want to switch to katex instead - and katex can also be run on the server to return HTML directly.


KaTeX looks very good, but currently I let org-mode do the backend lifting for me. Maybe if I rewrite my blog engine once again... ;-)


At least use it on the client then – it’s a lot faster than MathJax :)


Clearly that's an exception, I don't think that really needs to be discussed or considered when talking about static blogs not needing JavaScript.


That would be a reasonable exception. Of course, I'd only give the page a 5/5 rating if the JS code would be still readable even if no output would be produced.


Echoing others, as blog posts go, that's the exception and not the rule. Inline demos are furthermore not "primary content" but supplementary material.


> just not add bloat to HTML pages

This isn't really a solution when many authors use a CMS, like WordPress and others, where the bloat is built-in. Sure you can write a custom theme etc, but not everyone (1) has the ability to do that, and (2) wants to dedicate the time to do that.


Creating AMP pages requires just as much ability and time.


The site is running on WordPress.com where every site has AMP enabled: https://en.blog.wordpress.com/2016/02/24/amp-for-wordpress-d...

AMP integration still a work in progress, but getting better: https://github.com/Automattic/amp-wp


I'd be a lot happier with AMP if they'd stop hijacking the scrolling behavior on iOS (speed and momentum is different than on a regular web page). It drives me absolutely crazy.


Oh no!! I never heard of AMP before but now I hate it with a passion. Anything that spreads the terrible gmail style scrolling behavior is all bad in my eyes.


Why not an "HTML with minimal styles and no JavaScript" version? Oh wait, that's not reactive.



Ever so slightly more polished: https://codepen.io/dredmorbius/full/KpMqqB/


That's hard on the eyes, and the headings look like links. The top-level headings look just plain broken when they wrap.


Wrapping is all-but-inevitable given dynamic display widths. What would your preference be? Smaller fonts for headers?


It's the bottom border that looks off when wrapping. Since the headings are already distinguished by whitespace, size, weight, and color, the border doesn't really add anything. Overall, the page is not conveying a hierarchy to me at all. It looks very disjointed.

My preference would be to remove the borders/underlines, also remove the bold, and make the margins equal above and below the h3+ headings. If I were to actually use more than three headings, I'd probably do something completely different at the deepest levels (e.g. inline the headings or indent the whole text).

But I think we agree that it's worth some effort to fix up the browser's default styles. It's too bad they can't all just switch to something like Firefox's reader view without breaking the web.


So, I'm really not a graphics designer, though I know what I like, what I don't like, and have a pretty good sense for what does and doesn't work well across a large range of display sizes.

This design isn't responsive other than having some reasonably sane defaults. It's derived from a more complex style that does resize headers and such as the pagesize varies. As far as niggling over header formatting ... that's getting into layout-weenie stuff and sweating the small stuff. The point is to have distinguishable headers. How you distinguish them ... is somewhat moot, though size, colour, underline, margin, typeface, etc., are some obvious dimensions. What I've given here does not, I'll posit, for the most part suck.

It may offend some sensibilities.

What I've started taking a strong liking to, actually, is using CSS numbering to create numbered sections (see https://reddit.com/r/dredmorbius/wiki/faq for an example -- I actually contributed the Reddit code, all one line of it, to enable this). It's a bit technical-documentation-ish, but tends to give a sense of place and structure within a document.

In practice, having too many levels of nesting is probably distracting. A book might have: Parts, Chapters, Sections, and possibly Subsections. That's H2 - H5 in a standard HTML hierarchy, with H1 reserved for the title.

A paper will rarely have more than Sections and Subsections -- H2 and H3 elements, plus h1 for the title. My reddit styling and docs tend to reflect this.

I will use more detailed breakouts when I'm outlining stuff, though I'll make pains to try to flatten the structure reasonably as I can. I'm often digging in the weeds myself, in complex topics, and achieving a workable structure is a considerable effort.


But nobody actually makes web sites like that any more. Have you seen the one for Emacs? It looks like a page for some barista's Node.js side project, it's got so much hipster cruft now.


> I wish all bloggers started to publish AMP pages.

I wish all bloggers with sites so bloated that AMP is a fundamental difference didn't feel they needed to include large image assets, custom fonts, and fancy JavaScript libraries (not suggesting this blogger does - just a general complaint).


Hey, I remember WAP!


AMP is terrible for publishers though. It would be better if the site would publish simpler HTML/JS than use AMP.


Kudos to the OP for doing it, and for anyone using WordPress, it's pretty easy for you to do it too:

https://wordpress.org/plugins/amp/


In case there are any Wordpress bloggers and authors out there who would like to add AMP functionality to their websites Automattic put together a nice plugin tool to do just that.[0] I wonder when this will become part of the wp-core?

[0] https://github.com/Automattic/amp-wp


I hope never. This is clearly the sort of thing that should be optional--which is exactly why Wordpress has a plugin system.


This is how the entire web should be, honestly.


I agree, it was a great read!


I work Syncplicity, a Dropbox competitor and investigated building a feature that is similar to the Dropbox badge. (We call it the App Tab. Basically, it's UI that tacks onto Office that tells you that someone else is editing the same document.)

We've had requests for this feature for years. I can't stress how much customers request this feature; it's put a lot of egg on our face that Dropbox beat us to it.

In order to do this on Mac, we'd need to register ourselves as an accessibility client. I don't remember the details about registering ourselves, but from what I remember, it doesn't require hacking into OSX.

We've had to hack into OSX in the past: Adding menu items and icons to Windows Explorer is supported via well-documented Microsoft APIs. It wasn't until about 2014 that Apple supported this, prior to that, we had to reverse-engineer Finder. We didn't get OSX APIs to do this until we hired a contractor with "connections" to Apple he petitioned his connections to provide an API. I know that Dropbox, Google Drive, Box, and an open-source project called Liferay-Nativity all performed the same hack.

Based on my Syncplicity experience is that, what happens in these cases, is that a product manager gets so focused on the pixels that he/she is completely blind to the practical implementations. There's probably a bit of "I told you so" coming from some of Dropbox's engineers now.


Or maybe, just maybe, the PM doesn't care about having to "hack" into Mac, because most Dropbox customers just don't care and would rather the service they are paying for is functional. Just a thought.


Nobody cares about security, until they have a security problem.


It looks like in 10.12 Apple has added TCC.db to SIP, so this will no longer work — Dropbox will, hopefully, actually be forced to request accessibility access like they're supposed to. I'm sure they'll still demand your admin password via a dialog that tries super hard to look like a system one to use for whatever other more or less nefarious purposes. Would be nice if there was an alternative that actually syncs as reliably and performantly, but in my testing that's very much not the case.

I appreciate the trend of Apple forcing Dropbox to stop doing dumb shit, though. (Previously, of course, the SIMBL-style Finder hacking)


That last comment is ironic, given that Dropbox would literally not exist today without the runtime patching of the Finder.

There was no other way to do what they did. The only reason Apple added API was because Dropbox came up with an idea that demonstrated the need for such an API to exist.


Their only feature which necessitated that, as far as I know, was the sync status badge display which is hardly necessary to the product.


Seamless "filesystem integration" -- which includes the Finder badging -- was central to what made Dropbox a novel product.

It's also a very useful feature that served people well.


Their filesystem integration would have been just as seamless without the badging. I admit the badging is a useful feature, and certainly made Dropbox better but by no means is it core to the product.


You're talking past each other — other, more fundamental features used to require hacking OS X. See for instance https://news.ycombinator.com/item?id=12467149. IIRC ArsTechnica wrote at some point that monkey-patching Mac OS/Mac OS X was standard on the platform.


I use owncloud (and then dropbox inside it so some files are double backed up). I find it to be just fine. Have you had any problems with it?


Yes, last time I tried it, had a variety of conflict issues plus the client had some problems, performance and otherwise. If you're just using it as a backup solution (does it even keep file history?) from a single machine + mobile/web access, it may well work acceptably.


Being curious. What is "a variety of conflict issues"? Also could you perhaps expand on "the client had some problems"? Which client? I know an official Windows client exists as well as an Android client (this latter I use), but all communications are via HTTP (DAV for file transfers / calendar / etc. & REST for admin stuff), which means that a specific client is not necessary.

Personally, I use KDE's file manager (Dolphin). Plus a curl-cased Bash script for when I need to upload an arbitrary file from one of my home computers via my phone (SSH from phone to computer, sometimes over sat link, run "~/bin/upload.sh /some/file").

I manage my own ownCloud servers (one personal, one company), but hosted options are available.

And yes, it does keep file history (optional, enabled by default), as well as encrypted storage (optional, disabled by default).

Neither the client, nor the server even, require any administrative access.


I honestly am not sure, it was quite some time ago. I recall being quite unhappy with something about how it handled a sync conflict but I'm not sure of the specifics.


I had couple conflicts in the few years Ive used it, but they were few and were actual conflicts (a file on a client was updated at the same time the server copy was updated). It does keep a limited file history. I'm not really using it for file history so I'm not sure exactly what the rules are for retaining old versions.


We use OneDrive at work and it works pretty much exactly as well as I recall Dropbox working back when I used it.


When I last tried it the performance was abysmal, almost as bad as Google Drive. Also, no Linux client. I didn't use it enough to know if it has the same conflict issues as many of the other ones I tried — Microsoft may well have managed to get that right.


There is an open onedrive client that works great.


Non-clickbait title: "How Dropbox uses the root access that you give it during installation to give itself Accessibility authorization without triggering the usual popup".


Great summary. But it's still some kind of hack.

If every app I installed did this then my mac is closer to getting hacked.

Anyway, Apps that asks for root password on installation always makes me cringe, e.g. they could turn on SSH and put a pubkey into authorized_keys, or they could upload SSH identity files. But I still proceed to enter my password.


> Anyway, Apps that asks for root password on installation always makes me cringe, e.g. they could turn on SSH and put a pubkey into authorized_keys, or they could upload SSH identity files. But I still proceed to enter my password.

You don't need root to do any of those things. If you're going to run the SSH server on port 22, sure, but it can be run on any port above 1024 by a regular user in user space.

If you're already running an SSH server, a non-root app can most likely edit your ~/.ssh/authorized_key file. It's just a regular file, nothing special about a malicious app adding an entry to it.

Think a NAT is going to save you? A malicious program can SSH out and create a reverse tunnel to circumvent it.

Short answer: running anything you don't know or trust is dangerous, root access just makes it more dangerous.


>If you're already running an SSH server, a non-root app can most likely edit your ~/.ssh/authorized_key file. It's just a regular file, nothing special about a malicious app adding an entry to it.

That file is -rw-r--r--, so only the owner or root can change it, unless I am misunderstanding you?


That app is running as you, so it is the owner of the file at that point.


You're absolutely right.


How's that any different compared to Linux? AFAIK apt packages can run arbitrary scripts as root.


It's slightly different, because Dropbox board members support warrantless surveillance: http://www.drop-dropbox.com/


This is not the main difference (which is that apt packages are checked by package maintainers), but thanks for sharing the link, didn't know that. It makes this hack even more serious.


There's a world of difference, as long as you are using only default repositories (which you should). Apt itself is root, of course, but it is (or should be) trustworthy. All other apps never see root access unless they need it - and if it is needed, then the package maintainer has checked the package to make sure it only uses root when necessary. Kind of like Apple checking apps on AppStore.


No respectable package would put up a fake sudo prompt only to stash away your password for later use.


It's a good thing Dropbox isn't doing that, then.


Then please explain how it manages to set the accessibility privilege at every login after the user explicitly revokes it. I can see only two options:

1) the Dropbox client stores the password and uses it to hack the accesses db at every login.

2) the Dropbox client runs as root and does the same thing.

Both options are simply terrible from a security point of view


Not sure if this is how they do it, but OS X has another option (which is in fact recommended by Apple for all tasks needing elevated permissions): installation of a privileged helper tool.[1] The helper tool communicates with the main app via IPC, ideally such that the only things the app can ask are precisely the things it's supposed to do (e.g. the helper will only sneak in accessibility for the dropbox app, and nobody else). The helper tool removes a lot of the surface area for security holes, assuming the IPC protocol is well written (not something like "here's this string, run it as a shell command with root privileges).

[1]: https://developer.apple.com/library/mac/documentation/Securi...


3) Dropbox installs some helper programs with the SUID bit set.

And this is what they actually do.

    % ls -l /Library/DropboxHelperTools/Dropbox_u501
    total 256
    -r-s--x--x  1 root  wheel    9632 Sep  8 20:10 dbaccessperm
    -r-s--x--x  1 root  wheel  116668 Sep  8 20:10 dbfseventsd
(Note the SUID bit and the root owner, meaning that these binaries will run with the root UID when started by a normal user.)


Linux packages come from the distribution and are controlled by the distribution, not some random 3rd party business.


"Accessibility authorization" sounds benign, but the "authorization" it gives itself is full control of the Mac via the Accessibility API.

So, "How Dropbox uses the root access you give it during installation to gain full control of your Mac without triggering the usual popup."


Corrected proposed non-clickbait title: "How Dropbox fakes an authorization prompt to trick you into entering credentials that it then caches in order to bypass restrictions on what root is able to do so that it can persist a security bypass mechanism."

The first bit, for me, is key.


It doesn't do that. It doesn't cache the credentials. It doesn't even see your password.


How is it adding itself back to the list after being removed, then?

(Not disbelieving you at all, I just haven't understood this part.)


It adds a suid binary to /Library/DropboxHelperTools. This binary executes as root's effective user ID no matter who executes it and adds Dropbox to the accessibility list.

Dropbox doesn't save your password.

...But I am wondering why one of these suid binaries is world-writable.


ah, it turns out none of the binaries is world-writable in a default installation. My mistake.


toomim is correct. Upon reading the update, it looks like it pops an OS X auth dialog to update a file (TCC.db) which is used to bypass the normal restrictions on what the root user is able to do. This bypass is used to manipulate the AX config.

Slimy, slimy, slimy.


Not exactly. If you remove dropbox from the accessibility auth list while the client is still running (without removing /Library/DropboxHelperTools) it just adds itself back in. Also it prompts for the password after installation.

So it's more like "how dropbox uses the root access you give it after installation to install software which will permanently re-add itself to accessibility even if you attempt remove its authorization".


That skips the important point that it's not supposed to be possible for even root to do this without a prompt.


No, it's not that the point. The point is that they somehow store your sudo password to set again the accessibility permission at every login. I honestly don't see why the title should be considered a click-bait, it looks pretty much very accurate to me.


Lots of people getting mad at Dropbox for this, which is fine, but should we not also get mad at Apple for making their "security" system so easy to circumvent?

Being an app developer that was bitten in the ass by the new "security" in El Crapitan, and having spent 2 weeks trying to get our app back to normal, this makes me really mad that Apple makes us developers jump through all these hoops for security that isn't actually secure anyway.


I have given Dropbox access to my files, admins rights, and ability to run in the kernel. I'm not freaking out about the Accessibility API.

setuid binaries:

  $ tree -p /Library/DropboxHelperTools/
  /Library/DropboxHelperTools/
  ├── [-r-s--x--x]  DropboxHelperInstaller
  └── [drwxr-xr-x]  Dropbox_u501
      ├── [-r-s--x--x]  dbaccessperm
      ├── [-r-s--x--x]  dbfseventsd
      └── [-r-s--x--x]  dbkextd
kernel extension:

  $ kextstat -b com.getdropbox.dropbox.kext
  Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>
    163    0 0xffffff7f835b5000 0x6000     0x6000     com.getdropbox.dropbox.kext (1.7.5)


Dropbox on Linux needs none of that. Sure it doesn't have the fancy icons in file managers, but it also runs in user-space without a kernel module.


There are plugins that give you the fancy icons for some file managers, and they still run in user-space (and as non-root).


> plugins

Finder doesn't have plugins, hence the accessibility API shenanigans necessary to get the same effect.



Since the arrival of FSEvents I don't understand why DB needs a kernel mod at all



Great article, but poor conclusion. He finds that Dropbox is untrustworthy, a finding that likely surprises no one, and reaches for iCloud as the solution. Why move into another walled garden driven by corporate interests? OwnCloud or a similar self hosted solution would be better. I just use NFS and a dead simple storage server to make ~/shared available on all of my machines.


If you're going to use a Mac, you're trusting Apple already. How does using iCloud make you trust them more?


Because Apple doesn't have a mechanism to access files on your Mac, while they do have a mechanism to access files on iCloud. This means someone guessing your security questions, or somebody with a warrant, or somebody abusing their access rights can get to your files.


They do provide the OS, so they implicitly have access to all your files at a level that dropbox would have a hard time achieving.


> so they implicitly have access to all your files

If you can demonstrate how Apple has access to my files on an OS X installation with no iCloud configured, I will round up a massive bounty.


Open your finder. Every file that you see has just been touched by apples code.

Your OS does have access to all files that you have on your computer. It manages all network connections. It exposes all information that tools such as little snitch display to you. Apple signs and provides all software updates to you. They control SPI and app sandboxing. I'm not saying that Apple does access your files. I do trust them not to since they've shown that they at least attempt to step up and defend themselves and their users. Still, they could if they wanted to.


lil snitch is one of the best tools out there, and it's what inspired me to never use apple software again... so I did the right thing and gave my lil snitch registration code to a friend.

I'm still looking for a linux alternative to lil snitch that is just as robust and intuitive - but I'm stuck using a few different things to achieve the same effect. Anyone have a recommendation with a slick GUI (for some reason I really like a GUI for firewall management)


I really like EtherApe btw for visualization - would love recommendations for similar tools


You can melt your MacBook in the oven but not your iCloud account. You're comparing apples to oranges (pun intended).


burn.


What he meant to say was "code can do anything! waves hands"


I wouldn't use a Mac, either :)


And if you're using Ubuntu, you're trusting package managers, and if you're using Gentoo, you're trusting original developers (how often do you audit source code?)


>And if you're using Ubuntu, you're trusting package managers, and if you're using Gentoo, you're trusting original developers

This is correct. Consider, however, the motivations of the people involved. Apple's motivations are to make money from you. Debian's motiviations (intentionally avoiding Ubuntu here) are to make a good user-centric system. Packages are signed by named individuals that I can personally get to know and trust, and with an accessible process - I can download their package sources and build or verify or tweak them the same way that the maintainer can, report bugs and ask questions directly to them, etc. I trust this model much more than I trust the model of a company who, at the end of the day, has a bottom line and will make compromises to ensure it remains where they need it.

Apple is very well known for using proprietary formats, adapters, you name it. Apple's cloud is also write-only, they intentionally make it difficult for you to pull data out of it and interop with other services. These decisions serve the company's interests, not yours.

>how often do you audit source code?

You would be surprised!


Who do you think employs vast majority of Linux developers? Who do you think writes they paychecks? Ever looked into who the biggest Red Hat customer is? Hint, it's the DoD.


Source?


>>how often do you audit source code?

>You would be surprised!

It doesn't really matter if you do. OpenSSL is one example showing there are critical mistakes of grand level everywhere, same as there might be cleverly hidden backdoor in that multi-100k source tree (or any of the myriad of dependencies) you "audited".


It's still a lot better than not having the source. There are tons of other benefits too. The one downside is CPU cost to compile everything yourself.


>> how often do you audit source code?

> You would be surprised!

How often do you audit OwnCloud's source code? (I'd describe it as "naive.")


I actually don't use OwnCloud, so never.


Something to consider when you're comparing products based on "trustworthiness."


It's interesting because at some level, particularly with closed source products trusting the company developing the product is important. Apple have made some effort to stand up for the privacy of their users. Dropbox on the other hand have board members who support and have authorized warrantless wiretaps:

http://www.drop-dropbox.com/


> board members

Plural? Who else?

There's a difference between bringing in a single famous person and the rest of the board agreeing with them on certain issues.


I personally think their privacy stance was mostly to protect their own interests rather than any concern for the common man, but they were able to spin it really well and get great publicity as usual. It hurts me to say this as an owner of 2 MBPs and a mac pro which I love, but Apple is not on our side and it's painfully obvious.


That's exactly right and what people complain about. That Dropbox betrayed the trust they(users) were giving to them(Dropbox).

I don't necessarily agree with them, but that's the sentiment here.

Edit: by the way, regarding open source projects, it doesn't matter if you don't look at the code personally. Somebody else does, and if there is problem with it, it becomes a huge public scandal sooner or later.


"OwnCloud or a similar self hosted solution would be better."

Perhaps better for limited use cases that don't really apply to the vast majority of Dropbox's user base.

You start off comparing apples to oranges, and with your latter solution, you aren't even comparing to fruit anymore.


What happens when you take a laptop to another network?


Everything freaks out, unfortunately. I would work on a better solution, but I'm not particularly inconvenienced by this issue.


Isn't a bit naive to think that your solution, which has obvious flaws is one-size-fits-all?

I use cloud storage (e.g.) have access to my password file between my computers and my mobile devices. NFS shares on ~/share that only work on the local network don't really solve this issue.


Did I say it was a one-size-fits-all, or that it was flawless? I also suggested OwnCloud before describing my own setup. All of your software choices come with tradeoffs.

For my passwords I use pass and store them in a private git repo on a server I trust. http://password-store.org


Yes, you implied that you know better when you critiqued the author's choice to reach for iCloud and suggested your self-hosted 'alternatives' instead as better. Except the one you prefer is not an alternative. It's not even playing the same game.

Some people are willing to spend their finite life building personal infrastructure and the rest pay others to do it. You conflate the two at your peril. The best decision I've ever made was to stop running all of my own stuff -- you get literal days back in your life. Days.


In many cases self hosted is better. One needs to consider that this also needs some time to maintain, though. Personally I also like ownCloud but still mostly use Dropbox.


agreed. The cost of hard disk/ssd storage is constantly falling, I hate having my crap locked up in the "cloud" knowing that if I miss a couple payments it's toast.

More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: