News for hackers. Stuff that matters.
Re:Google Chrome Keystone is modifying /var symlink on non S... by Scapeghost on Tuesday September 24, 2019 @08:55PM (#21066466)
Yes, it's one of the first things that befuddled/frustrated me on macOS after coming from Windows (not that that was much better).

Dropbox apparently also used to show you a fake system password dialog which saved your administrator password, and more:

https://hn.algolia.com/?q=dropbox

Re:Google Chrome Keystone is modifying /var symlink on non S... by ryandrake on Wednesday September 25, 2019 @02:26AM (#21068231)
It looks like Dropbox still tries [1] to abuse [2] Accessibility services in order to gain increased access to things on your computer that applications typically shouldn't need access to. Accessibility services are for helping blind people use your software, not for your software to run roughshod all over my system. Jeez!

1: https://help.dropbox.com/installs-integrations/desktop/mac-p...

2: https://applehelpwriter.com/2016/07/28/revealing-dropboxs-di...

Re:Google Chrome Keystone is modifying /var symlink on non S... by colatkinson on Wednesday September 25, 2019 @03:14AM (#21068487)
This isn't entirely accurate. The hack that they used (writing creds directly into the TCC db instead of using the official dialog) was closed by Apple in High Sierra I believe (might've been Mojave? I can't remember atm). Regardless, now they use the official prompt. Of course, while Apple went to the trouble of SIP protecting the TCC db, they didn't actually fix the API for getting Ax permissions, and it's still a massive pain to get it even remotely right.

As for what they're using accessibility for, I believe the official primary use case is tighter integration with the Office suite (e.g. showing users if anyone else has the doc open). So nothing exactly malicious.

This isn't anything new. Keep in mind that Dropbox was offering sync status icons for years before Apple finally created an official API for doing so. IIRC that was using an even dirtier hack, involving monkey patching Finder at runtime. I'd definitely count that as a useful feature as well, and one that Apple had no interest in supporting until it became a user expectation.

I've got no affiliation with Dropbox, and I can definitely see the concern over the TCC hack. But once you try to do any meaningful integration with macOS, you do begin to sympathize. The official APIs are limited, flaky, and prone to deprecation at a moment's notice (see Quicklook plugins in Catalina for a fresh example). And Apple, despite making it impossible for third parties to innovate in their ecosystem, gets to paint themselves as saints.

Security is paramount, of course, but needlessly restricting how users and developers can use the OS will either lead to even dirtier hacks, or only Apple apps being allowed to do new, interesting things. And I don't particularly like either option.

Re:Google Chrome Keystone is modifying /var symlink on non S... by ymolodtsov on Thursday September 26, 2019 @04:09AM (#21079122)
A number of respectable apps uses Accessibilty features, for instance Alfred.
Re:Google Chrome Keystone is modifying /var symlink on non S... by Shank on Tuesday September 24, 2019 @09:05PM (#21066541)
> not that that was much better

At least on Windows, I could with confidence say that Sysinternals Autoruns + Process Hacker would get you 99.9% of the way. I too went from Windows to macOS, and I tried countless tools (Lingon X, CleanMyMac, App Cleaner, App Cleaner & Uninstaller Pro, etc.) to no avail in my quest to kill Dropbox.

Re:Google Chrome Keystone is modifying /var symlink on non S... by fortran77 on Wednesday September 25, 2019 @08:41AM (#21070175)
Agreed! The Macs are still a crazy mess. Not that much different from the old days with chains of Inits.
Re:Google Chrome Keystone is modifying /var symlink on non S... by apostacy on Wednesday September 25, 2019 @12:02AM (#21067486)
At least with Dropbox, they needed that access to modify menus and make changes to benefit the user. And they also made it clear that this is what they needed it for.

When Google does it, they are just elbowing their way into your computer.

I really wish there was a way I could revoke an App's ability to request access.

Re:Google Chrome Keystone is modifying /var symlink on non S... by jbverschoor on Wednesday September 25, 2019 @01:11AM (#21067802)
Which I don’t want or need. They gave no respect for your system.
Re:Google Chrome Keystone is modifying /var symlink on non S... by pilif on Tuesday September 24, 2019 @11:17PM (#21067273)
Back then it turned out the password dialog wasn't fake but was the standard OS dialog apps can request sudo access with. The text in the dialog is app-customizable.
Re:Google Chrome Keystone is modifying /var symlink on non S... by api on Tuesday September 24, 2019 @10:49PM (#21067116)
A lot of these things are hacks to streamline user experience.