Live data from Hacker News

Dropbox Attempts To Kill Open Source Project

razorfast.com

61–70 of 323 posts

Re: Dropbox Attempts To Kill Open Source Project

#61
post #21

This is Arash from Dropbox. We removed the ability to share the project source code because it enables communications with our servers in a manner that is a violation of our Terms of Service. By our TOS, we reserve the right to terminate the account of users in this case. However, we chose to remove access to the file instead of terminating the account of the user. We recently built a tool that allows us to ban links…

You do realize that Dropbox submitted the DMCA request under penalty of perjury, and that if it was in fact incorrect Dropbox has perjured themselves?

Re: Dropbox Attempts To Kill Open Source Project

#62
post #21

This is Arash from Dropbox. We removed the ability to share the project source code because it enables communications with our servers in a manner that is a violation of our Terms of Service. By our TOS, we reserve the right to terminate the account of users in this case. However, we chose to remove access to the file instead of terminating the account of the user. We recently built a tool that allows us to ban links…

You _accidentally_ sent a DMCA notice?! That might be worse than sending an erroneous one. You're technically under penalty of perjury for false DMCA notices.

Re: Dropbox Attempts To Kill Open Source Project

#63
post #41

Consider that maybe what's happening here is boring. Recognize that we all have a cognitive bias towards narratives, and especially interesting narratives. The discussion on this story is trying to build a narrative about Dropbox vs. open source developers. The real story is probably not that interesting. The CTO of a service as technically interesting as Dropbox certainly knows that he can't prevent the disclosure o…

[deleted]

Re: Dropbox Attempts To Kill Open Source Project

#64
post #21

This is Arash from Dropbox. We removed the ability to share the project source code because it enables communications with our servers in a manner that is a violation of our Terms of Service. By our TOS, we reserve the right to terminate the account of users in this case. However, we chose to remove access to the file instead of terminating the account of the user. We recently built a tool that allows us to ban links…

We recently built a tool that allows us to ban links across the sytem (as of a few weeks ago) and I wasn't aware that the email auto-generated and sent a DMCA takedown email. This was a tool built for our support team and I'd never personally used it.

Man you guys are dumb.

Re: Dropbox Attempts To Kill Open Source Project

#65
post #30

Earlier quoted context omitted.

I personally feel that Dropbox removing files from someone's account is completely wrong, regardless of your ToS. Your service is there to backup files. When you delete references to files from someone else's accounts, you're violating the trust that people put in your service.

We didn't remove the file - we simply banned public access to it.

So I'm guessing you could still get it using dropship...

Re: Dropbox Attempts To Kill Open Source Project

#66

However justified you think piracy is, resisting efforts to turn a product you created for legitimate personal file sharing into a better BitTorrent is a valid business decision. That's a really incendiary headline. Yes, they tried to kill an open source product, whose purpose was to facillitate illegal file sharing over DropBox . The PR fallout from this among the tech community is probably nowhere near the fallout…

> Yes, they tried to kill an open source product, whose purpose was to facillitate illegal file sharing over DropBox.

Where are you getting that information? My understanding it that its purpose was explicitly to facilitate legal file sharing over DropBox - Linux ISOs, for example.

Re: Dropbox Attempts To Kill Open Source Project

#67
post #42
post #30

Earlier quoted context omitted.

We didn't remove the file - we simply banned public access to it.

I don't understand why you would bother? If they still had the file, wouldn't they be quite able to post it elsewhere? Why the censorship? I'm not comfortable in the knowledge that Dropbox can willy nilly refuse to allow me to share files on a case by case basis.

I can understand dropbox not allowing you to publicly share files on a case by case basis, or else I could simply put illegal content in my public folder and send out the link.

I understand it a little less if you are say sharing folders between friends.

And I wouldn't like it at all if they deleted something from my dropbox, but it seems we aren't there yet.

Re: Dropbox Attempts To Kill Open Source Project

#68
post #47

Earlier quoted context omitted.

No you won't, but it feels good to grand stand.

I already deleted it. I'm not sure how I can prove it to you as I didn't get an email, and when I clicked the "Delete Account" button to commit to deleting my account it just bounced me to the dropbox homepage. But thanks for trying to call me out.

You don't need to prove it to me because I don't particularly care and it doesn't actually matter, so let's just say I believe you.

This is a tempest in a teapot just like those mass "Quit Facebook" protests that spring up every time the privacy settings change. The entire controversy exists because a tiny, yet incredibly vocal, minority makes a huge deal of it only to drop it the next week. And from reading write ups on freemium services, the vocal minority is also part of the non-paying majority.

Dropbox has a technically exploitable feature which they don't want passed around for file sharing purposes so they stopped their own servers from helping. Big whoop.

Re: Dropbox Attempts To Kill Open Source Project

#69
This behavior is unconscionable when there is such an obviously trivial technical solution to this problem.

Here is my quick and dirty technical solution.

(1) Place a restriction: only allow users who have uploaded a given file to download that file. In essence, keep an "uploaded" flag for each file/user.

(2) Challenge-response to validate local copy of a globally-known file: To continue receiving the benefits of de-dup, don't actually upload an already globally-known file, but perform a challenge-response with the client on the contents of the actual file. This will still leverage most of the benefits of de-dup w.r.t bandwidth savings.

Post reply on HN