Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Dropbox API

blog.dropbox.com

Post reply on HN
Print view View original

41–48 of 48 posts

Re: The Dropbox API

#41

Post by ThaddeusQuay2 »

bryanh wrote: post #38
chaosprophet wrote: post #36

Earlier quoted context omitted.

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…

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.

So, Snapier is like IF THIS THEN THAT but without the IF?

http://ifttt.com

Re: The Dropbox API

#42

Post by kalleboo »

kisielk wrote: post #39
johns wrote: post #35

Earlier quoted context omitted.

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. 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

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 fa…

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...

Re: The Dropbox API

#43

Post by admp »

count wrote: post #32
gabrielh wrote: post #28

Earlier quoted context omitted.

OAuth 2 is way simpler but requires HTTPS, which may have overhead at scale.

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.

Obligatory reference: "SSL/TLS is not computationally expensive any more."

http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...

Re: The Dropbox API

#44

Post by kisielk »

kalleboo wrote: post #42
kisielk wrote: post #39

Earlier quoted context omitted.

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 fa…

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.

Re: The Dropbox API

#46

Post by wladimir »

kalleboo wrote: post #42
kisielk wrote: post #39

Earlier quoted context omitted.

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 fa…

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...

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.

Re: The Dropbox API

#47

Post by jaredsohn »

kisielk wrote: post #44
kalleboo wrote: post #42

Earlier quoted context omitted.

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.

Re: The Dropbox API

#48

Post by bryanh »

ThaddeusQuay2 wrote: post #41
bryanh wrote: post #38

Earlier quoted context omitted.

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.

So, Snapier is like IF THIS THEN THAT but without the IF? http://ifttt.com

Very similar, ifttt.com is definitely an inspiration (as is Yahoo! Pipes). However, we have a very different and more promising direction (we think!).
Post reply on HN