Hacker News Reader

Comment by nimish | Hacker News Reader

So instead of using a FS shim to userspace on security grounds they decided to distribute a custom kext that's closed source -- ie a great way for normal bugs to turn into dangerous ones?

I'm not sure I understand the logic here

View on HN

Exactly, we should be moving in the opposite direction: make as much software as possible user-space and sandboxed. I assume a party as large as Dropbox can request Apple to extend the APIs where necessary?

>I assume a party as large as Dropbox can request Apple to extend the APIs where necessary?

As large? Dropbox is like a fly to Apple. Not to mention competitors. And they haven't budged for much larger parties.

So, unless it's something that Apple intends to do anyway, Dropbox's request will don't have much success.

Just a data point: Fastmail got them to implement/support push for Fastmail on iOS (no, it's not just IMAP IDLE).

Interestingly enough, you don't need Apple's support to do that: https://github.com/st3fan/dovecot-xaps-daemon.

Apple didn't have to build an API for them, they simply provided documentation for how to use the existing API.

Ah, that's nice! Though their blog post at the time seemed to indicate that Apple helped them a bit:

https://blog.fastmail.com/2015/07/17/push-email-now-availabl...

Sure, and occasionally the add stuff and consult with Mac software houses and indie devs (or musicians and editors for their Pro stuff) on what to add etc.

But that's not the same as building a bunch of APIs for a competitor.

Like the whole Swift open-source ecosystem.

> So, unless it's something that Apple intends to do anyway, Dropbox's request will don't have much success.

You'd think Apple would be happy to add extensions they themselves could use in the future to replace Dropbox with their own iCloud extension.

On the contrary. Why would they make them open in that case?

They could just add them internally and use them for an "upgraded Finder/iCloud" and not expose them for Dropbox to use.

Implementing them for a competitor so that they "can use them themselves in the future" doesn't make sense as a strategy -- except if they are too benevolent.

Why when they can just keep it a private API only usable by iCloud?

OS X is full of functionality unavailable to 3rd party apps (I'm looking at you Power Nap! -_-) and expecting decent behaviour from them is optimistic.

Apple already uses private APIs for iCloud, I'm sure they would love to add some more, to make Dropbox an inferior experience.

> You'd think Apple would be happy to add extensions they themselves could use in the future to replace Dropbox with their own iCloud extension.

Not that I follow such things closely, but I can't recall ever having heard about Apple being happy to do something for someone who wasn't Apple. Do such things happen?

I'd suspect Dropbox is worse than a fly - it's a direct competitor to iCloud. So, double no.

Especially since Apple already has! There are new extension APIs in El Capitan specifically designed for apps like Box and Dropbox to extend the Finder.

And they also released APIs designed to eliminate the need for KEXTs for virtualization products (see: Veertu and Docker for Mac beta), so I would expect them to also have/make APIs for Dropbox's use case as well.

I was excited for this. Was.

Believe it or not, their APIs have very real deficiencies. To the point where they are subpar to custom solutions. E.g. is how extensions only allow for one application to be active at a time (i.e. you cannot run Google Drive and Dropbox simultaneously and have file overlay icons).

When Dropbox rejected Apple's acquisition offer, Jobs was pretty angry at them, so it is unlikely that Apple is willing to help them now.

Wasn't that like over 5 years ago under a different CEO?

Yes. iCloud, a direct Dropbox competitor, is still part of Apple's strategy, and the current CEO is executing the direction set by the last CEO.

If Apple shipped FUSE this would be a lot easier.

If FUSE semantics would be the same between systems, this would be a lot easier. But I'm not sure how that is possible, FUSE it too leaky, it exposes too much of the semantics of the kernel VFS layer, which is different between kernels.

I complete agree. Are there that many people running performance-sensitive I/O bound apps directly out of their Dropbox? Shouldn't they contribute back to libfuse rather than reinvent the VFS, with all the (sure as death and taxes) pitfalls and CVEs that will come along with it?

I wouldn't if I were Dropbox. Given the size of them, the speed they want to move, the security concerns with other people's code (vs a known beast that you're responsible for that you can limit to just what you need), the custom behavior they want (like new kinds of permissions, and the ultimate flexiblity of being in control of your own destiny... I'd make the same call. Dropbox has the talent to do this right.

The blog article goes into great detail, for performance.

Reply on news.ycombinator.com