Boxopus lets you download torrents to Dropbox anonymously + w/o a Torrent client(torrentfreak.com)
torrentfreak.com
Boxopus lets you download torrents to Dropbox anonymously + w/o a Torrent client
http://torrentfreak.com/boxopus-downloads-torrents-to-dropbox-120623/
70 comments
I've done something similar with an IFTTT recipe, where I can email the URL of a .torrent file and it will be automatically added to a folder in my Dropbox. Then I have my torrent client setup to watch that folder for .torrent files. This works nicely when I'm not at my computer and want to start downloading something.
Here's the recipe: http://ifttt.com/recipes/100
Here's the recipe: http://ifttt.com/recipes/100
Can you seed with this?
Wow, in before API access is cut to prevent the mountain of lawsuits that would hit Dropbox if it's not. API cut in 3... 2... 1...
Why would Dropbox be hit by lawsuits now due to their API? Amazon's web services and every other cloud storage site has no less risk. I am betting on lawsuits for this Boxopus service since they're actually doing the downloading and distributing, even if it's on a user's behalf.
why would they be suing boxopus? that would be like suing the creators of the bittorrent client. boxopus doesn't store any data, nor provide links to torrents for people, it's simply a service like your bt client. If anything, this seems like this would be an easier way to catch the actual users.
Valid logical points; However the RIAA and MPAA don't operate on Logic or Validity.
So they'd sue boxopus to get their user data (IP addresses)? Or is this an RIAA/MPAA honeypot?
They'd sue them to try and bleed them into the grave regardless of if they have any legal basis to do so.
Why not? But it'd be better than an IP address you'd have their dropbox account.
Because Boxopus actually downloads the content? They're not just a BT client, they actually run instances of it.
I think they would probably claim to be a service provider under the DMCA.
" (a) Transitory Digital Network Communications. - A service provider shall not be liable for monetary relief, or, except as provided in subsection (j), for injunctive or other equitable relief, for infringement of copyright by reason of the provider's transmitting, routing, or providing connections for, material through a system or network controlled or operated by or for the service provider, or by reason of the intermediate and transient storage of that material in the course of such transmitting, routing, or providing connections, if - (1) the transmission of the material was initiated by or at the direction of a person other than the service provider; "
To make that claim, they need to register a designated agent first; I can't find their agent on their online listings or their website, but I presume that they will do that before they get too big.
Disclaimer: IANAL, this is not legal advice.
" (a) Transitory Digital Network Communications. - A service provider shall not be liable for monetary relief, or, except as provided in subsection (j), for injunctive or other equitable relief, for infringement of copyright by reason of the provider's transmitting, routing, or providing connections for, material through a system or network controlled or operated by or for the service provider, or by reason of the intermediate and transient storage of that material in the course of such transmitting, routing, or providing connections, if - (1) the transmission of the material was initiated by or at the direction of a person other than the service provider; "
To make that claim, they need to register a designated agent first; I can't find their agent on their online listings or their website, but I presume that they will do that before they get too big.
Disclaimer: IANAL, this is not legal advice.
They are an interesting data point between the two:
* A generic provider of CPU/storage/bandwidth who isn't (generally speaking) responsible for users copying stuff using provider's resources.
* A service who clearly and obviously caters to pirates (those do actually get in legal trouble)
A lawsuit would probably be interesting for the class of cases where it is not clear who is legally responsible for actions performed by software (author, owner of box, user starting the action, etc.)
* A generic provider of CPU/storage/bandwidth who isn't (generally speaking) responsible for users copying stuff using provider's resources.
* A service who clearly and obviously caters to pirates (those do actually get in legal trouble)
A lawsuit would probably be interesting for the class of cases where it is not clear who is legally responsible for actions performed by software (author, owner of box, user starting the action, etc.)
Maybe they won't be hit by a lawsuit but it would be dumb for them to even risk the possibility. Far better to just cut off API access and be done with. It's not like Dropbox's business model depends on the availability of anonymous torrent downloads and the people who want that.
Possibly the opposite, in fact.
This is basically a torrent VPN service that goes through DropBox.
Excellent innovation. This is like waving a red flag in the face of the MPAA, RIAA, and all the other entrenched monopolies that are seeking to extend their outdated business models by using old-school Mafioso tactics.
I would be very surprised if Boxopus, Dropbox (or both) wasn't pressurized to discontinue this service in some way.
API changes by Dropbox (or TOS violation based suspension), Lawsuit for BoxOpus, etc to follow...
You do realize the trade groups (riaa, mpaa) exist to prevent collusion? Aka mafioso tactics?
Not saying the represent a valid continual business model (currently, we can hope for evolution) but lets leave the hyperbole at the door.
Not saying the represent a valid continual business model (currently, we can hope for evolution) but lets leave the hyperbole at the door.
This brings to mind lots of questions like, Does this take advantage of Dropbox's single instance file storage? As in, are they uploading completed files and saving themselves the bandwidth of having to actually do the upload because dropbox likely already has a copy of that file hosted? Also, if multiple users are requesting the same file is Boxopus downloading this more than once?
Doesn't this make Boxopus a honey pot for MPAA subpoenas?
That hadn't occurred to me until I read your comment, but I came over here to ask a related question: What is the business model? Who is paying for the bandwidth boxopus is using by downloading all these torrents for people?
Pretty much boilerplate, but don't think this is going to protect you if the torrents being downloaded are illegal:
"Boxopus may disclose Personally Identifiable Information if required to do so by law or in the belief that such action is necessary to: (a) comply with law or legal process, court order or a subpoena served on Boxopus or the Site to cooperate with law enforcement authorities; (b) investigate, prevent or take action regarding suspected or actual illegal activity or fraud on the Site;"
"Boxopus may disclose Personally Identifiable Information if required to do so by law or in the belief that such action is necessary to: (a) comply with law or legal process, court order or a subpoena served on Boxopus or the Site to cooperate with law enforcement authorities; (b) investigate, prevent or take action regarding suspected or actual illegal activity or fraud on the Site;"
And even if Boxopus claimed to protect you like some VPNs do, unless they also encrypt the files before uploading them to Dropbox, wouldn't you still be at legal risk with Dropbox? Or are Dropbox contents automatically encrypted upon upload so that employees have no way of knowing what they contain?
As long as you're not sharing your Dropbox, it doesn't matter at point. Copyright Infringement is a crime of distribution (or more strictly speaking, reproduction), NOT possession.
In the US copyright includes the right to make copies. As an individual you do not have the right to freely make copies for yourself. That's reproduction, and is expected to get you in trouble. The idea that "it's legal to download, just not upload", is a defense that's been long been claimed, but to my knowledge, has never been tested in court.
To be fair, though, I believe they (the RIAA, MPAA) haven't tested that case either. Maybe they're not 100% sure either.
Now, in Canada? I believe private-use MUSIC downloading is legal. (Due to shenanigans involving the fine levied on blank media made for the purpose of burning music. Basically, Canadians already pay the fine for music piracy, so, they get to do it. That's my understanding.)
To be fair, though, I believe they (the RIAA, MPAA) haven't tested that case either. Maybe they're not 100% sure either.
Now, in Canada? I believe private-use MUSIC downloading is legal. (Due to shenanigans involving the fine levied on blank media made for the purpose of burning music. Basically, Canadians already pay the fine for music piracy, so, they get to do it. That's my understanding.)
In the UK it's not legal to download, but the only damages are the costs of one copy of the item. Doing all the paperwork and filing all the legal stuff is time consuming and expensive, thus companies don't bother with it just to recoup £14 for a movie.
But if you're uploading then the costs are the cost of the media * number of people in the swarm. And going after those people has -they hope- a chilling effect, preventing people from doing it.
This is "civil law" (A UK lawyer probably knows the correct terminology.)
If you're infringing copyright as part of trade -selling bootleg DVDs on a market stall, for example- it becomes a criminal offence, and is enforced by police and trading standards officers.
But if you're uploading then the costs are the cost of the media * number of people in the swarm. And going after those people has -they hope- a chilling effect, preventing people from doing it.
This is "civil law" (A UK lawyer probably knows the correct terminology.)
If you're infringing copyright as part of trade -selling bootleg DVDs on a market stall, for example- it becomes a criminal offence, and is enforced by police and trading standards officers.
Got a citation on the damages amounts? Haven't heard that before.
I don't think it is that simple. I bet that you click-accept something like "By ordering this file, you state that you have the necessary permissions and you clear our asses of any responsibility" when ordering a file. And even if you don't, it's still you who ordered the torrent download (resulting in re-distribution to other clients), which (I believe) matters more than the fact that you're not the owner of the client box.
You didn't order Boxopus to upload anything back to other torrent users and they are the ones who have chosen to send you the data they received. Seems pretty obvious that they are participating in infringement regardless of what their ToS say. I hope they have some good lawyers on hand.
[deleted]
Torrent Reactor has already added a Boxopus ("Download to Dropbox") option to their torrent pages.
Has anyone been able to download through this? I tried about 30 minutes ago and the torrent still says it's waiting in their queue. This seems like a very slow way to download a torrent.
[deleted]
This is relevant but forgetting torrenting for just a moment.. I believe Dropbox uses hashing to identify files in their system, since sometimes you can copy a large file into your Dropbox and it syncs immediately (without an upload).
Given this, rather than using torrents, could there theoretically be a way to tell your Dropbox account you "have" a certain file that, indeed, you do not, merely by using the hash? For example, if I know the hash for the latest episode of a TV show is "ab12de" (gross simplification!) and I can make Dropbox think I "have" that file, if someone else already uploaded that file to their Dropbox, I could grab it too?
Given this, rather than using torrents, could there theoretically be a way to tell your Dropbox account you "have" a certain file that, indeed, you do not, merely by using the hash? For example, if I know the hash for the latest episode of a TV show is "ab12de" (gross simplification!) and I can make Dropbox think I "have" that file, if someone else already uploaded that file to their Dropbox, I could grab it too?
This has been done and the exploit has been (mostly?) closed. Google "dropship" for all the details.
How does their dedupe method work now? Shouldn't it still be possible under the same principle?
Client: I have the file with hash 0x47fed9.
Server: Okay, tell me what byte 1257 (randomly chosen) of that file is and I'll mark you as having the file.
Client: Ummm ...
Server: Okay, tell me what byte 1257 (randomly chosen) of that file is and I'll mark you as having the file.
Client: Ummm ...
The way you said it is x100 times better than just explaining it.
Thank you
Do they ask for exactly one random byte for every 4mb hashed block?
For a <4mb file, if you just guessed a random byte and try 256 times, wouldn't you probably get it right at least once?
Still, they could easily change the scheme to ask for more bytes to reduce the chance of a correct guess, plus it would be hopeless for large files.
For a <4mb file, if you just guessed a random byte and try 256 times, wouldn't you probably get it right at least once?
Still, they could easily change the scheme to ask for more bytes to reduce the chance of a correct guess, plus it would be hopeless for large files.
They could give you a sufficiently long random salt and ask you to calculate the hash of the salt and block contents. This scheme seems to be secure.
So a client could theoretically talk to another client that knows what byte 1257 is and the file would appear to answer what the question implied.
If there is cooperation with another client who has the file you could just get the file from them in the first place.
You don't need to "get" the file from anyone, you just need convince Dropbox to mark your account as having that file.
Maybe I'm missing something. What possible purpose (other than getting the file) could there be to convincing Dropbox that you have a file?
By "get" I just meant download directly, which could be slow and eat a lot of bandwidth. And then if you actually want that file in your Dropbox, you'd eat even more bandwidth doing the upload again. But syncing once from Dropbox is faster than downloading from someone else and then uploading to Dropbox and then waiting for your other computers to sync. And since you don't have to get the file from the original sharer, they don't have to have enough bandwidth to go around, just let Dropbox handle the copying.
I think you missed the part where byte 1257 was "randomly chosen"
It depends. If I already have the full file, it's much easier (and efficient) to tell you the value of a random byte and let DB give you the file than having to transfer it all.
If you're dealing on a small scale (e.g. "Hey, icebraining, let me grab that file from you!"), it's going to be easier to just send a share request from your Dropbox account to mine, which has the same end result (flipping an ownership bit in Dropbox's system).
That doesn't really scale, no, but sharing hashes doesn't really either, unless you want to spend a significant amount of time building infrastructure to keep track of who has what files and automate the management of sharing hashes.
That doesn't really scale, no, but sharing hashes doesn't really either, unless you want to spend a significant amount of time building infrastructure to keep track of who has what files and automate the management of sharing hashes.
Of course, but then you still need infrastructure to figure out who else has the file, how to keep things private, etc. You can't just distribute a hash and be done with it.
I didn't miss that part, I was simply saying that a client that had the file could tell what byte 1257 was to the other client (or some other random byte, as requested by dropbox).
How long does it wait for an answer? Basic maths will allow you to work out what Chunk is required from the torrent swarm to get the answer pretty quickly.
Clever...
Google "dropship dropbox". Googling "dropship" wont get you anywhere.
Im pretty sure that the way this works is by their own server downloading the file into a dropbox folder on the server. Then they use a copy-reference (https://www.dropbox.com/developers/reference/api#copy_ref) and pass that to the user who will then receive the file. So, in essence is the same as what you said, only using the reference instead of the hash. This reference stuff must be the way it works because you cannot upload a file greater than 150mb through the dropbox api. Lastly, the way that dropbox prevents abuse of the copy-ref api is by bandwidth limiting the reference.
Google App Engine's SDK used to (still does?) use a very similar scheme.
Please vote this http://news.ycombinator.com/item?id=4153077
Flagged for spam.
I have actually had similar service running on my servers for a while now (took me about almost 3 months to design, code and test), though it makes legally no sense to make it available to the public, as you will need a solid ISP that will guarantee you that it won't abandon you as soon as they receive a letter from the Copyright Mafia. The service will eventually resemble a glorified cyber locker, since it makes no sense to delete the most popular files. Secondly, you aren't really protecting your customers unless you can provide payments through bitcoin, but even that wouldn't be safe enough.
Let's say I'm a copyright holder and I see my content on the bittorent network. Would the IP address of the downloader on the network belong to boxopus? If so, if I then asked boxopus to hand over the all user's details (dropbox accounts and email addresses I guess) that accessed the torrent in question through their service, would they have that data on their servers?
Does this have a file size limit? I'm pretty sure dropbox's API has a 300MB limit.
They undoubtably put the file in their own Dropbox, then copy it into yours. That also allows the dedup algorithm to run to save bandwidth.
And the limit is 150mb otherwise.
And the limit is 150mb otherwise.
I kind of feel like at this point my data should be stored a in a 'RACS' configuration: a Redundant Array of Cloud Storage.
At least with DB you usually also run the d/t client and so have the data 'checked out' in local drives, but I do know people who just use the web client (locked down computers).