~ekez/negativefour

ref: a3ba218efef2773e5826b94d9ca3c096795b3ddc negativefour/docs/initial-idea.md -rw-r--r-- 4.0 KiB
a3ba218eZeke Medley Fix race condition between apache restart and status check 8 months ago

#"Vercel for Tor Hidden Services"

Vercel is a website hosting platform. Developers can create an account and point it towards a git repository containing a website and Vercel will manage its deployment.

This is a reasonably competative space. A small list of other services that do basically exactly the same thing:

  1. Netlify
  2. Cloudflare Pages
  3. sourcehut pages
  4. GitHub Pages

I'm sure there are a number that I am missing.

#Problem

I would like to have a version of my personal website that runs as a Tor Hidden Service. This is not purely a vanity thing. There are a number of advantages to running a non-clearnet version of a website:

  1. Traffic to hidden services do not go through exit nodes which reduces load on those nodes.
  2. Traffic is subject to stronger encryption than regular HTTPS.
  3. Anonymity loves company. Encouraging regular use of the Tor browser can help those who legitimately need it.

#Existing Solutions

There are a number of results if you look up "tor hidden service hosting". Trouble is that all of them involve renting some physical / virtualized hardware that you can run your service on. This costs upwards of $20 a month and is way overpowered for what someone who just wants a Tor version of their website.

#Possible Solution

Provide a Vercel-like hosting provider. Create an account, point the service towards a git repo, and get an union domain.

#What this is not

An explicit non-goal is hosting websites that are illegal in the United States. At the same time, where possible we ought to minimize the amount of information that we know about customers.

See the Payments and User Accounts below for more information about how we might limit user information collection.

We may choose to mirror sourcehut pages' permissible use policy.

#Hackathon Goals

  1. Clear instructions ought to be given on how to enable Union-Location.
  2. Webpages ought to be served over HTTPS (this is a requirement of Union-Location).
  3. New commits on a selected main branch ought to result in a new deploy for the webpage.
    • This will limit the number of repository providers that we can support initially. GitHub might be a fine start.
  4. Our server ought to follow reasonably good security best practices.
  5. We ought to have some payment processing mechanism.

#Stretch Goals

  1. Can this also host a clearnet version of the webpage?

#Payments and User Accounts

I am a massive fan of the method used by Mullivad. On Mullivad instead of a user account you have a secret, random identifier. For our purposes each git repository would have an associated random identifer. Customers then make payments to that identifier which "charges up" the associated git repositories.

For example, if we accepted Monero payments we could use the payment ID field to identify what repository the payment was associated with.

I'd suggest that an initial implementation does not support recurring payments as I am unsure how that might be implemented without some more sophisticated user account information.

#Some Security Thoughts

While our goal isn't to be secure in the face of a three letter agency it seems appropriate that we would make some efforts to lock down our system.

Tor has some information about this process in step 6 of this article. This writeup about running a hidden service has some basic information as well. I have also previously done some reading on firewalling rules for TOR.