6 ms·

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 t

by nimish 10y ago

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

SG- 10y ago
The blog article goes into great detail, for performance.
danieldk 10y ago
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?
- oddevan 10y ago
  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.
  - dontblink 10y ago
    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).
- coldtea 10y ago
  >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.
  - toomuchtodo 10y ago
    > 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.
    - coldtea 10y ago
      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.
    - izacus 10y ago
      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.
    - CJefferson 10y ago
      Apple already uses private APIs for iCloud, I'm sure they would love to add some more, to make Dropbox an inferior experience.
    - fenomas 10y ago
      > 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?
  - danieldk 10y ago
    Just a data point: Fastmail got them to implement/support push for Fastmail on iOS (no, it's not just IMAP IDLE).
- 1123581321 10y ago
  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.
  - r00fus 10y ago
    Wasn't that like over 5 years ago under a different CEO?
    - 1123581321 10y ago
      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.
- api 10y ago
  If Apple shipped FUSE this would be a lot easier.
  - 4ad 10y ago
    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.
STRML 10y ago
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?
- azinman2 10y ago
  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.

by nimish 10y ago

SG- 10y ago

The blog article goes into great detail, for performance.

danieldk 10y ago

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?

oddevan 10y ago
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.
- dontblink 10y ago
  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).
coldtea 10y ago
>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.
- toomuchtodo 10y ago
  > 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.
  - coldtea 10y ago
    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.
  - izacus 10y ago
    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.
  - CJefferson 10y ago
    Apple already uses private APIs for iCloud, I'm sure they would love to add some more, to make Dropbox an inferior experience.
  - fenomas 10y ago
    > 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?
- danieldk 10y ago
  Just a data point: Fastmail got them to implement/support push for Fastmail on iOS (no, it's not just IMAP IDLE).
1123581321 10y ago
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.
- r00fus 10y ago
  Wasn't that like over 5 years ago under a different CEO?
  - 1123581321 10y ago
    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.
api 10y ago
If Apple shipped FUSE this would be a lot easier.
- 4ad 10y ago
  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.

STRML 10y ago

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?

azinman2 10y ago
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.