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

Dropbox API v2 launches

blogs.dropbox.com

Post reply on HN
Print view View original

21–30 of 85 posts

Re: Dropbox API v2 launches

#21

Post by mtgx »

flyt wrote: post #16
cryptoz wrote: post #11

Is the Dropbox client fully open source yet? I won't use a spying tool that hires international spies to be on the board if they continue to be closed-source and intent on spying. Their new SDKs seem to be open source - why not their main client product?

What are you worried about in the client app that would require it to be open source? Should they also open source their backend systems and give you access to them?

They don't necessarily need to do that. What they could do however, is allow files to be encrypted locally before they are synced and uploaded to their servers. The vast majority of people would still not do it anyway, but those that care would.

I really like how Cryptomator works, and I think Dropbox could easily provide similar functionality, and perhaps in an even more user-friendly way, too, since they can just integrate it with their Dropbox app, rather than this functionality being in a whole separate application.

https://cryptomator.org

Dropbox is not an advertising company like Google. They still have some of the highest fees for cloud storage around. So why do they care about seeing what's in people's files? Why not allow people to encrypt the files locally before uploading them?

And lest we forget, in the PRISM slides, Dropbox was mentioned as "coming soon". So unless they want to admit they are already part of the PRISM program, then what better way to dispel those rumors (not made any better by getting Condoleezza Rice on their board) that they are cooperating with the NSA.

http://www.zdnet.com/article/fbi-nsa-said-to-be-secretly-min...

Re: Dropbox API v2 launches

#22

Post by hitekker »

ohitsdom wrote: post #19
flyt wrote: post #16

Earlier quoted context omitted.

What are you worried about in the client app that would require it to be open source? Should they also open source their backend systems and give you access to them?

There was serious concern with some evidence a few years back that the Dropbox client was touching files in folders that weren't shared. Not sure if that is what OP's concern is. But I agree with your point, the client is only one small piece of the puzzle and won't reveal much.

The "international spies" probably refers to: http://bits.blogs.nytimes.com/2014/04/18/protests-continue-a...

Re: Dropbox API v2 launches

#23

Post by flyt »

mtgx wrote: post #21
flyt wrote: post #16

Earlier quoted context omitted.

What are you worried about in the client app that would require it to be open source? Should they also open source their backend systems and give you access to them?

They don't necessarily need to do that. What they could do however, is allow files to be encrypted locally before they are synced and uploaded to their servers. The vast majority of people would still not do it anyway, but those that care would. I really like how Cryptomator works, and I think Dropbox could easily provide similar functionality, and perhaps in an even more user-friendly way, too, since they can just i…

Take a look at nCrypted Cloud for an option: https://www.encryptedcloud.com/

Realistically, though, Dropbox can't offer many of the features that differentiate them in the marketplace (collaboration, previews, sharing, etc) if all of the files they store are opaque to them. Playing in the "generic blob storage" market alongside S3 is a losing game for pretty much everybody.

Re: Dropbox API v2 launches

#25

Post by sdegutis »

flyt wrote: post #16
cryptoz wrote: post #11

Is the Dropbox client fully open source yet? I won't use a spying tool that hires international spies to be on the board if they continue to be closed-source and intent on spying. Their new SDKs seem to be open source - why not their main client product?

What are you worried about in the client app that would require it to be open source? Should they also open source their backend systems and give you access to them?

Not OP, but personally, 100% of the Dropbox functionality I care about is the storage and synchronization of explicitly allowed files (even if that only means "everything in ~/Dropbox"). So how the client-side synchronizer works shouldn't be a trade secret, assuming it's doing exactly what I'm paying it for and nothing else.

Re: Dropbox API v2 launches

#26

Post by morgante »

swax wrote: post #12
robitor wrote: post #9

Why would they choose RPC style endpoints over REST?

Because REST is a superficial standard and people are starting to figure that out? APIs don't need to be complicated. Give me an endpoint to call and parameters to send. I don't need verbs, cool looking URLs, overloaded headers, special versioning schemes, and a never ending debate of what REST is and what it isn't. Also if anyone replies to this with 'you just don't understand REST' I'm going to put another nickel i…

You understand REST.

Re: Dropbox API v2 launches

#27

Post by oldmanjay »

swax wrote: post #12
robitor wrote: post #9

Why would they choose RPC style endpoints over REST?

Because REST is a superficial standard and people are starting to figure that out? APIs don't need to be complicated. Give me an endpoint to call and parameters to send. I don't need verbs, cool looking URLs, overloaded headers, special versioning schemes, and a never ending debate of what REST is and what it isn't. Also if anyone replies to this with 'you just don't understand REST' I'm going to put another nickel i…

It seems like the only thing Dropbox doesn't have is the verbs.

On the other hand, I've never much cared about the "no true REST" crap that the conversation always seems to turn into. I'm too pragmatic to care if I'm adhering to someone's concept of a convention.

Re: Dropbox API v2 launches

#28

Post by BinaryIdiot »

swax wrote: post #12
robitor wrote: post #9

Why would they choose RPC style endpoints over REST?

Because REST is a superficial standard and people are starting to figure that out? APIs don't need to be complicated. Give me an endpoint to call and parameters to send. I don't need verbs, cool looking URLs, overloaded headers, special versioning schemes, and a never ending debate of what REST is and what it isn't. Also if anyone replies to this with 'you just don't understand REST' I'm going to put another nickel i…

You are apparently me.

I've done REST and "rest" for many years and every single time it starts out really simple. Oh I just need the profile data so let's make a RESTful endpoint just for profile. So easy! Oh wait the profile page need data from X, Y and Z. Well we gotta be RESTful so let's make 4 HTTP calls. Oh, latency sucks on mobile and terrible networks and we have to cut down on HTTP calls? Sorry, can't, we're RESTful...okay fine ONE RPC endpoint for the profile page's information.

I think REST has it's place; it's good if you want a really intuitive way to access a very specific resource. Beyond that? For developing web apps? Almost always have to go down the RPC route and there is nothing wrong with that. Not everything has to be "RESTful" damn it!@

Re: Dropbox API v2 launches

#30

Post by aikah »

swax wrote: post #12
robitor wrote: post #9

Why would they choose RPC style endpoints over REST?

Because REST is a superficial standard and people are starting to figure that out? APIs don't need to be complicated. Give me an endpoint to call and parameters to send. I don't need verbs, cool looking URLs, overloaded headers, special versioning schemes, and a never ending debate of what REST is and what it isn't. Also if anyone replies to this with 'you just don't understand REST' I'm going to put another nickel i…

The problem with RPC style calls is you can't take advantage of "natural" server features like caching and such. You need to re-implement all this on top of both the client and the server.

I agree with your point about REST though, it's not even a standard. If it was there would be no debate about what REST is and what it isn't. It's a vague set of idea and its author himself kind of said his paper was targeted at "specialists" and not classical "developers".

People keep on telling me "read the spec", well there is no normative spec.

Post reply on HN