Live data from Hacker News

X0.at: upload files from cURL

x0.at

61–70 of 93 posts

Re: X0.at: upload files from cURL

#61
post #53
post #48

Earlier quoted context omitted.

How do they "get burned" by that? Not having a license means you don't get to use it and are violating their copyright if you do so (possibly except the things specified in Github ToS: look at the code on github)

So not having a license means a default one was used? Which licence is that?

The default is that you don't have rights to code unless they are explicitly given to you. The Github ToS do specify some rights that are granted through uploading to GH, but they don't constitute any usual license, nor one that makes any of it usable to you.

Re: X0.at: upload files from cURL

#62
post #53
post #48

Earlier quoted context omitted.

How do they "get burned" by that? Not having a license means you don't get to use it and are violating their copyright if you do so (possibly except the things specified in Github ToS: look at the code on github)

So not having a license means a default one was used? Which licence is that?

"Not licensed" is the default. Its similar to what the IP industry calls "stealing".

Re: X0.at: upload files from cURL

#63

Earlier quoted context omitted.

Drive and Dropbox are at least moderated.

Source? ...moderated via automation or human?

https://support.google.com/a/answer/172541?hl=en

> Google Drive scans a file for viruses before the file is downloaded or shared. If a virus is detected, users cannot convert the infected file to a Google Doc, Sheet, or Slide, and they'll receive a warning if they attempt these operations.

So at least some degree of automated moderation is going on. Frankly, I'd be astounded if some amount of scanning isn't being done for illegal content and/or phishing stuff.

Re: X0.at: upload files from cURL

#64

Earlier quoted context omitted.

> Uploading files without auth layer - is asking for trouble IMHO. If you make it super user-friendly and advertise it as the next Megaupload, sure. But if you keep a small audience of good-faith users it's not asking for problems. If you can teach me to make my file upload as hacker-friendly as this service while implementing auth, i'd be glad. Here the entire point is you don't need further configuration/credential…

1. How are you blocking someone from uploading millions of files programmatically? 2. How do you know someone is from small audience of good-faith? 3. What if a file has virus and corrupt all the files on your end? If you don't need auth, there are few measures you can take on your end: 1. TTL - Make these files temporary - They will be erased after x hours. Eg. x=1 2. Throttle - Limit number of uploads from a given…

4. Block IPs known for abuse. This includes VPNs, Tor exit nodes, and more.

Re: X0.at: upload files from cURL

#66

Earlier quoted context omitted.

Drive and Dropbox are at least moderated.

Source? ...moderated via automation or human?

Automation; the bare minimum would be to scan for known child sexual abuse material hashes - if you're not doing that, then opening up anonymous uploads is very risky, as for CSAM (unlike most other things) you may be personally liable even if it's distributed there without your knowledge. Cloudfare's CSAM scanning tool is one option that may help, there are other options.

You can't rely on the good faith of users, if your service is easily usable for crime, it will be used for it.

Re: X0.at: upload files from cURL

#68
One can upload a file to their Dropbox via a cURL post, provided they have created an app and have an access token, which just takes a few minutes to set up.

curl -X POST https://content.dropboxapi.com/2/files/upload --header "Authorization: Bearer ACCESSTOKEN" --header "Dropbox-API-Arg: {\"path\": \"/DROPBOXFILEPATH/DROPBOXFILENAME\"}" --header "Content-Type: application/octet-stream" --data-binary @/LOCALFILEPATH/LOCALFILENAME

Re: X0.at: upload files from cURL

#70
post #56
post #32

Earlier quoted context omitted.

This is incompatible with using curl as your client, but one “hacker-friendly way to do auth” is to use Github’s public SSH keys API. You can stand up an (SCP/SFTP-subprotocol-only) SSH server, and tell the user to log in with their GitHub username + GitHub SSH key. Then configure your SSH server to call[1] a check on GitHub’s API to map the provided username to the GitHub user’s set of public SSH keys. From there, t…

That's a neat idea, but I would try to simplify it a bit. Now, the details are fuzzy as I haven't set up anything like this but I know the theory behind it. You could setup a website which accepts file uploads at username:file_signature@example.com , when a request is accepted you retrieve the public ssh key for "username" and validate that the "file_signature" is valid for the file uploaded. It's a bit unintuitive t…

The point of including GitHub in the chain is that it's acting as an SSO provider, thus:

1. letting you ban bad actors from your system by creating a blacklist of GitHub usernames; and

2. putting a stumbling block in the way of getting around #1 by signing up for 1000 accounts (signing up for a GitHub account takes a while; adding a unique new SSH key[1] to that GitHub account means generating a new SSH keypair, which takes another while; etc. Having a GitHub account with an associated SSH key constitutes a very small proof-of-work, similar to an e-stamp.)

[1] IIRC, a given SSH public key cannot be associated with more than one GitHub account at a time.

Any SSO provider would provide the same guarantees; but GitHub is the only SSO provider that has people's SSH pubkeys on file and accessible through a public API, and so GitHub is the only SSO provider you can use as an SSO provider through SSH.

Also, as a separate "benefit" (though some would argue it's the opposite), GitHub accounts — SSO accounts generally — are more-often-than-not associated with people's personal identities. SSO identity-provider sign-up processes usually collect quite a bit of PII, and often do a bit of KYC with phone verification, etc. This means that requiring sign-in through SSO is an almost-perfect ward against criminal use of your service — since any criminal stupid enough to SSO into your site and then do something illegal, can be quickly-and-easily identified by the police by sending a warrant to the SSO provider.

-----

Besides all that, the point here is to make the process of uploading a file as simple as possible for the end-user (presuming the end-user is a developer familiar with common CLI tools.) The backend complexity isn't really a concern, if it presents a simple and straightforward API.

With GitHub-identity-supported SSH-pubkey-auth, anyone who has a default SSH keypair and a GitHub account (and who has registered their default SSH keypair against their GitHub account) can directly jump to typing `scp ./file mygithubuser@uploader.example.com:` and it'll "just work" — without having to ever even visit uploader.example.com to register an account! Most developers have a GitHub; and most developers have used SCP before at some point. It's a very familiar process. Less confusing, even, than GitHub's own requirement of needing to SSH into github.com as the "git" user.

With your scheme, meanwhile, the user has to figure out how to sign a file using SSH — something I don't think more than a handful of people in the world will have ever had previous experience with. That's not quite "easy" on the level of "just use cURL" or "just use SCP" :)

Post reply on HN