Thanks for the post. There’s no question DB is handy, but there are trade-offs which I’m not willing to make. Fortunately, iScriv can be synced and managed through iTunes, for example, or by zipping up a project.
As far as are there plans…? This KB article excerpt (and the included link within it, at the KB) explains the plans and reasons :
To be honest, this whole line of thinking sounds rather off the beam, at least as an opinion from here.
Trying to think this through, I would first say as a caveat that if you’re a journalist or otherwise writing in a location unfriendly to your work, you don’t want to be syncing at all, and you do want to be taking maximum serious security precautions on your device if you use one and on its content, as you surely are aware.
Then, as far as responding to this posting’s line, if you want to read about ‘huge security implications’, try this journalist-hacked article – on Apple, and on Amazon’s data provider, the underlying technology for so many cloud services: darkreading.com/attacks-and- … body_cross.
Or perhaps you’re talking about the latest tempest in a teapot from Hacker News – then you can find out that what Dropbox is doing is not unsafe: it uses Apple’s own security methods, and is in concert with efforts to get Apple to provide what they would prefer to use: techcrunch.com/2016/09/09/dropb … -security/
in any case:
if you’re keeping your bank passwords or such in Scrivener, that’s not its intention. And to be actually secure, you’d have to encrypt and possibly hide the Scrivener files themselves, against the possibility of someone stealing your phone or device.
whatever you are editing in Scrivener with syncing, if you want to feel even safer than it already is, you can use Dropbox’s provided two-factor authentication, one of the best tools we have at present for any security situation.
as far as iCloud as an alternative, let’s not go there. Keith has explained why it is incapable of supporting iOS Scrivener.
I really had to think about whether to post this, but it seems fair rather than allow vague scary-sounding assertions to go unchallenged.
Agreed. The Dropbox “vulnerability” is hugely over-hyped. There are some outright errors contended as well, some of which have been addressed/debunked in Dropbox’s response to the accusations, for example see macrumors.com/2016/09/12/dro … cusations/
At issue (and Dropbox admits this) is some unfortunate choices in Dropbox’s permissions request on installation. The user’s admin password is needed to enable badging (basically, MS Office collaboration). It’s not clear from the dialog boxes currently presented what’s being requested and why. That’s bad, and it’s being corrected. But it’s not true that Dropbox stores the user’s password, and it’s unfair and incorrect to describe this as a “phishing” of the user’s credentials.
Dropbox’s response to this was quick and laudably open and devoid of corporate-ese and double-talk.
It’s also a don’t-care if you’re working solely on iOS. And even if you’re on a Mac, any threat is purely fanciful. (Now, “Project Infinite” might be another matter, but that’s in the future anyway.)
Why DB doesn’t use the normal way, I don’t know. Even if there’s a valid technical reason, at the time of installation, why they don’t fully disclose that they are using an alternate method to increase privileges for their process(es), again, I don’t know. Each user and potential user will have to decide to what extent (if at all) DB has harmed its reputation.
Apple needs to eliminate this alternate method or to make it work as the normal method does - notification, disclosure and requirement of a user action(s) to allow the escalation of privilege.