Create, upload, and share
Find help to solve issues with creating, uploading, and sharing files and folders in Dropbox. Get support and advice from the Dropbox Community.
Hi, I just came across this blog post detailing some, shall we say, unorthodox ways Dropbox is circumventing OS X security features and tricking users into sharing their admin password:
http://applehelpwriter.com/2016/07/28/revealing-dropboxs-dirty-little-security-hack/
I found the same happened on my system (OS X 10.11.6), Dropbox v9.v.49). Can you explain why you do this?
My reaosns for this are actually true because..:
(a on one hand while the dialg asking for authentication "could" be fake, Apple takes a different view, saying this just cannot happen..
(b many app apps for authentication. not just dropbox as valid reason
and
c) The fact dropbox appears in accessibility, puts the fear into everyone thinks the whole thing its a phish attempt..
oh ya ..and
(d the dialog is miss-leading... (you can argue this for anything)
I got a reply from support. Took them 133 hours instead of 24-48 for paying customers. And the answer was a non response that they would pass it on to development.
So disappointing...
I got an answer within 48 hours, but the answer was a template one which had nothing to do with my question. Great work, Dropbox.
You expect support to hand craft a reply to each of the thousands of *extra* tickets this issue caused to be raised, rather than helping people with actual problems?
Support is there for support, not for Public Relations comments. You wanted a PR reply, not support.
... thousands of *extra* tickets this issue caused...
Seems a bit of an excessive estimate, probably more like a couple of dozen or so.
Richard, no, I expect them to actually give me an answer that at least has remotely to do with my question, and not a template reply that has nothing to do with anything of what I asked. They could at least craft a response that has to do with this issue, and not just push random buttons in their ticket system.
You might not see this as important or that bad, but I do. The way the company has handled this is really bad, and considering I actually pay for this service, they should be extremely transparent in what's going on, and remedy the situation ASAP. Because, as mentioned above, there is no reason for doing what they do, at least not without asking us if it's OK during install.
"Seems a bit of an excessive estimate, probably more like a couple of dozen or so:
Doesn't matter if it's excessive.... it should have not happened in the first place.
Just by saying .. We have to get round it, so we would rather give "full remote access to an app" is not the solution to do stuff. when u'r supposed to care about users privacy and security
This is the total reversal of what is stated on their website regarding privacy & security..
Not only is there no need for full remote access, there is also no need to fake OS X's dialog (which in my view gives the whole thing away anyway)
And Apple thought these dialogs could not be faked 🙂 Well.. Dropbox did it.
Once again, the dialog is NOT being faked - that claim has been debunked a lot in the past week or so since the claim was made, its a perfectly normal OSX privilege raising authentication dialog.
The "fake dialog" determination was based on the fact that some of the text is misaligned and its general look and feel, but you can reproduce that with your own OSX authentication dialog by supplying the same text to the call -
Its a proper OSX dialog, just using an older system C API available on OSX since 10.3 whereas most people have moved over to the newer ObjC and Swift based calls which look different, hence the confusion.
Jared, repetition of a debunked conspiracy theory doesn't make it any less so.
Kudos though to a certain no-mark blog nobodies ever heard of for the boost to their page views. Shame there's no willingness to correct the misinformation, even when a DB dev takes the time and trouble to personally reach out, but there you go.
Jared as the guys have said it's not being faked. it's an older call, it's that simple. not everybody does things "modern" at times and sometimes it's more efficent to use an older call. specifically if it dont mesh with your current build, because let's say somebody fell behind,so you cant implement all the next features.
I'll never understand why people lose their minds over things such as requiring a password to elevate an install or to set a service level. rather dropbox have it, then some random hacker. least I feel safe with these guys.
Hi there!
If you need more help you can view your support options (expected response time for a ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!