My sister (Eva) needed to use Hellofax a few days ago after I asked her to sign something digitally. She didn't know how, but when she got your automated "Let me know if you need any help" email, she wrote back with some questions. You (assuming you're Joseph) helped her figure out how to use it, and then she called me and was absolutely GLOWING about how cool it was to email back and forth with you, get help, and have a fun conversation. She also loved the "Stay Faxy" line you used somewhere.
Just wanted to say thanks, awesome job, and I think you converted her into a Hellofax customer for life.
Finally, Dropbox lets apps request access to only a single folder. Now you can try out an app without worrying that you're giving access to your private data.
I'm hoping someone will tell me why it's a security problem, but yeah, for a whole slew of apps, I'd like eliminate server logic or at least make it simple to swap out backends.
It is much cheaper to scale an application putting data onto peoples' Dropbox folders instead of S3. For S3, you would have to pay for the total amount of storage used by your customers; with Dropbox you wouldn't have to pay anything for storage, and for the most part your users wouldn't have to either since each gets a certain amount for free.
Exactly. With Dropbox, you're making storage the customer's problem and not yours. You could argue this is bad for the customer, but you end up with a web app with next-to-no server overhead: just serve your static files and everything else is taken care of. No different than the many mobile apps that sync to iCloud/Dropbox already.
You can do cross-domain POSTs. You just cannot get a response from the server. Often times though you can get the length of the response. This can be used to do a POST to change settings on an unsecured Wi-Fi routers, for example and checking whether the call succeeded or not by the length of the response.
This is excellent: I especially like revision control and "undelete" (still not as powerful as Google Docs but enough for majority of apps).
Allowing access to only a single folder is an excellent feature (Google Docs does not have that): basically you can make Dropbox as a dropbox or sendbox.
And shameless plug: if you need to real-time replication of multiple Basecamp/Google Doc accounts with Dropbox try this: https://cloudHQ.net/ (and you probably understand why we are excited to finally get "single folder access feature").
I've been working with the Dropbox API (among MANY others...) for my early stage startup Snapier (http://snapier.com/), and I must say it is a pleasure to work with. Very sensible and logical. I can't say that about all API's...
Another example of how Dropbox is gonna keep its momentum. With it, it should be rather straightforward to bake in some cool iCloud type of preview/revision stuff into native apps.
In Snapier, it will be better if you have a message why you are asking for emails. More importantly, provide a message which is a little more than "Thank you very much" when I enter my email. Though I got an email within a second, it will be more user friendly to give a "We'll connect back soon" in the site itself.
Also, in the email you mention 'check us out on Twitter' but fail to provide the twitter id.
Just my two cents. If any of that sounds badly phrased, I blame the clock for showing 3 AM. Cheers :)
Also, it would be nice to have a better description of what Snapier does exactly. 'A simple way to automatically sync data between Skype and Facebook'? What kind of data would I want to sync between those two services? I read your blog and if I understand correctly, Snapier would be something that get's my credentials for a bunch of API's and then interconnects them, so that I don't have to roll out a script to do it. If my understanding is correct, then this is not very well reflected in your landing page.
You do understand correctly, and we think this is a big challenge for us. We are trying to stay away from "technical" terms (save for the API nod in the name) but stay light on the marketing speak. I could go on and on about our plans here... but, to cut it short, you are absolutely right, it isn't reflected correctly on the landing page.
Kudos to the Dropbox team for developing their product into a platform. Giving developers an opportunity to develop things on top of their product keeps not only the community excited about things to do with Dropbox, it also gives them fresh ideas from how people consider to use it.
This is interesting although I really really wished they had used oauth v2 since it is so much better and is designed to give a first class experience on mobile devices.
In fact I can't think of any good reason to use the older version but I would like to hear if there are anybody who has different experiences since I haven't worked much with it.
Everything has overhead at scale. I think the 'HTTPS is hard on computers' stage has passed by though...its just not that computationally intensive on modern hardware.
Before the redesign they had a page that explained the API is not for desktop client use, only mobile and web apps. I can't find the new equivalent, but maybe I'm missing something.
I understand that, but what keeps someone from pulling your key and secret out of your app and creating a trojan app? For example the app could look like your app, use the same key and secret, still authenticate as the user, but then steal their data and upload it to a third party server.
That may not be easily doable with iOS since Apple does a good job of curating their market, but I can imagine someone making a fake app like this that runs on Android and getting in to the Android market.
That is a risk, Twitter has the same risk, and when they switched over to OAuth-only there was a debate about this. Twitter's stance was that it's the developer's responsibility to obfuscate your app secret. People promptly pulled apart the official twitter iPad app and found they had done a terrible job of obfuscating it themselves...
In my opinion the big difference here is that a compromised Dropbox key would give the malicious app access to data it wouldn't normally be able to access. A stolen Twitter API key just lets the app act as any other Twitter app does, there's not really any additional data it would be privy to.
I haven't had a chance to look into exactly how authentication works, but if going to the page would require that the user regrant access each time (and if the page would indicate the app name as well), this difference could be nullified.
That's a weird reasoning of them. If the app-secret is ever sent over the network directly (either HTTP or HTTPS) there are plenty of ways to intercept it without having to dig into executables. I quickly skimmed over the OAuth code and that seems to be the case. But maybe they support digest-based authentication as well.
47 comments
[ 3.0 ms ] story [ 88.0 ms ] threadplaintext: http://itunes.apple.com/us/app/plaintext-dropbox-text-editin...
http://ifttt.com
https://www.hellofax.com
http://greplin.com
Here's a screenshot of how to integrate HelloFax with Dropbox https://img.skitch.com/20111021-b2qqr3rbh5uew4jxh4c4n83pe7.j...
Hope that helps!
Just wanted to say thanks, awesome job, and I think you converted her into a Hellofax customer for life.
- https://agilebits.com/onepassword/android
- http://www.quickoffice.com/quickoffice_pro_android/
Many people were asking about this feature on Hacker News just yesterday: https://news.ycombinator.com/item?id=3136098
It's an OSS project that kind of aims at doing that kind of stuff. (if I'm not mistaking your post)
Everything their SDKs do can also be done using their REST API (https://www.dropbox.com/developers/reference/api) and they support JSONP to allow cross-domain GET queries. However, my understanding is that JSONP is not supported for other REST methods, most importantly POSTs. A person claims to have found a workaround for doing POSTs via JSONP here: http://stackoverflow.com/questions/5345493/using-put-post-de....
Has anyone tried that or know of a way to do cross-domain POSTs?
The method described in the SO answer is similar, from what I can tell, to what DISQUS uses. I believe they call it JSONPI: http://alexsexton.com/thirdparty/#forms-are-cool-too
Allowing access to only a single folder is an excellent feature (Google Docs does not have that): basically you can make Dropbox as a dropbox or sendbox.
And shameless plug: if you need to real-time replication of multiple Basecamp/Google Doc accounts with Dropbox try this: https://cloudHQ.net/ (and you probably understand why we are excited to finally get "single folder access feature").
I'm still hoping that POST notifications / webhooks will be introduced soon. That will definitely make the web a better place.
Another example of how Dropbox is gonna keep its momentum. With it, it should be rather straightforward to bake in some cool iCloud type of preview/revision stuff into native apps.
Also, in the email you mention 'check us out on Twitter' but fail to provide the twitter id.
Just my two cents. If any of that sounds badly phrased, I blame the clock for showing 3 AM. Cheers :)
http://ifttt.com
In fact I can't think of any good reason to use the older version but I would like to hear if there are anybody who has different experiences since I haven't worked much with it.
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...
For example in https://www.dropbox.com/developers/start/authentication#pyth... you set both APP_KEY and APP_SECRET. Of course anyone can read the source and get these, so what keeps them from impersonating your app by using the same key and secret?
For iOS and Android this is probably less of an issue, but someone could probably glean the values by searching your binary.
For mobile you can embed the key and secret, because they only work in combination with someone authenticating their account to use your app https://www.dropbox.com/developers/start/authentication#ios
That may not be easily doable with iOS since Apple does a good job of curating their market, but I can imagine someone making a fake app like this that runs on Android and getting in to the Android market.
Imagine how easy it would be to build a multi-user pseudo-P2P file search/share app on top of Dropbox now.
Or imagine when a user can sync/export their settings from a "cloud" service to a SQLite file in their Dropbox automatically.