241–250 of 435 posts
Earlier quoted context omitted.
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.
2. Dropbox does not use sandboxing (at least, the one I have doesn't)
So, they do.
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…
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.
Earlier quoted context omitted.
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.
> "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.
Earlier quoted context omitted.
After Rice joined I actually completely stopped using Dropbox, transferred files, and deleted my account.
Ditto; now I use SpiderOak which has a solid no-knowledge replacement, but I hear Box is also good.
Earlier quoted context omitted.
> 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.
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.
Earlier quoted context omitted.
Why not an "HTML with minimal styles and no JavaScript" version? Oh wait, that's not reactive.
It can be: http://motherfuckingwebsite.com/
Earlier quoted context omitted.
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.
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 pl…
...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.
Earlier quoted context omitted.
Not really. Sure you can make a replica of it but it won't behave the same because you'll be able to minimize or close it but the secure desktop you can't do jack to until you either accept to decline whatever it's asking.
Disable the minimize button? Hook into alt tab? There's endless opportunities!
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…