5 ms·

They really should’ve used some end to end encryption to protect themselves against DMCA bullshit. As it stands they will be abused for copyright infringement

They really should’ve used some end to end encryption to protect themselves against DMCA bullshit. As it stands they will be abused for copyright infringement and the rights holders will not only ask for the files to be taken down, but for them to preemptively prevent those same files from being uploaded again. A huge rabbit hole full of bullshit.

nilsocket 8y ago
Indeed yes, but files were hosted for 14 days.
- jgrahamc 8y ago
  I would be much more concerned about people using this site for the transfer of illegal material (such as child abuse imagery). That's something literally any file sharing/image hosting site has to deal with. The 14 day limit won't make a difference as people disseminating that type of material are likely used to having to move it around frequently.
  - gorbypark 8y ago
    I built a proof of concept project that was a lot like transfer.sh at one point in time. My solution was to not only have a time limit but a download limit as well. I'd guess most people transferring files from the command line want to transfer something from one machine to another, or maybe to a few other machines. I was going to allow a transfer limit of 10 transfers before the file/link went dead, which would hopefully deter most nefarious people using it to widely spread files around..
    - vageli 8y ago
      Unless you are storing hashes, what would prevent someone from writing a script that simply reuploads the file to your service after downloading? That would increase the share limit.
      - tafycent 8y ago
        Let's say you generate the identifier for the upload based on the file hash. If you add a timestamp or random nonce then they'll have to redistribute the link to the file every time they re-upload as it will change every time.
        gorbypark 8y ago
        Exactly. Nothing would stop someone from re-uploading it, but they'd end up with a different url which would go dead pretty quick if used to share something publicly.
  - goatsi 8y ago
    This is a real problem for people hosting filesharing services. Depending on who abuse material gets reported to you might not even be told to remove it, you might just get raided. https://fuwafuwa.moe/nr/freeme/ https://fuwafuwa.moe/nr/freeme/
coatmatter 8y ago
This is the first thing I was wondering about as far as what the intended/eventual use-case of this tool is. The website and GitHub page doesn't go into a lot of detail for what it's intended to replace. If I'm not confusing matters, in the past people might have sent files to each other by dropping stuff off in an ftp directory, or they might have used DirectConnect to host files up, or even Windows file sharing / samba. If it were designed to be used within a local network on the other hand between untrusted users, it might make more sense but I think there would then also be simpler ways to go about that?

nilsocket 8y ago

Indeed yes, but files were hosted for 14 days.

jgrahamc 8y ago
I would be much more concerned about people using this site for the transfer of illegal material (such as child abuse imagery). That's something literally any file sharing/image hosting site has to deal with. The 14 day limit won't make a difference as people disseminating that type of material are likely used to having to move it around frequently.
- gorbypark 8y ago
  I built a proof of concept project that was a lot like transfer.sh at one point in time. My solution was to not only have a time limit but a download limit as well. I'd guess most people transferring files from the command line want to transfer something from one machine to another, or maybe to a few other machines. I was going to allow a transfer limit of 10 transfers before the file/link went dead, which would hopefully deter most nefarious people using it to widely spread files around..
  - vageli 8y ago
    Unless you are storing hashes, what would prevent someone from writing a script that simply reuploads the file to your service after downloading? That would increase the share limit.
    - tafycent 8y ago
      Let's say you generate the identifier for the upload based on the file hash. If you add a timestamp or random nonce then they'll have to redistribute the link to the file every time they re-upload as it will change every time.
      - gorbypark 8y ago
        Exactly. Nothing would stop someone from re-uploading it, but they'd end up with a different url which would go dead pretty quick if used to share something publicly.
- goatsi 8y ago
  This is a real problem for people hosting filesharing services. Depending on who abuse material gets reported to you might not even be told to remove it, you might just get raided. https://fuwafuwa.moe/nr/freeme/ https://fuwafuwa.moe/nr/freeme/

coatmatter 8y ago

This is the first thing I was wondering about as far as what the intended/eventual use-case of this tool is. The website and GitHub page doesn't go into a lot of detail for what it's intended to replace. If I'm not confusing matters, in the past people might have sent files to each other by dropping stuff off in an ftp directory, or they might have used DirectConnect to host files up, or even Windows file sharing / samba. If it were designed to be used within a local network on the other hand between untrusted users, it might make more sense but I think there would then also be simpler ways to go about that?