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
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.
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.
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.
The way we work is changing. Share and discover new ways to work smarter with Dropbox in our community.Sound good? Let's get started.
For more info on available support options, see this article.
If you found the answer to your question, please 'like' the post to say thanks to the user!