371–380 of 435 posts
Earlier quoted context omitted.
If that's the case, How is it that the accessibility preferences are changed without root authorization?
Presumably with one of the suid executables you authorized when you typed your root password to the dialogue. And one of them is writable by anyone -- great security, guys!
Earlier quoted context omitted.
>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.
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…
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…
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.
Earlier quoted context omitted.
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...
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.
Earlier quoted context omitted.
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 fo…
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.
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 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.
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).