# Gateway sandboxes

The current subdomains on arweave.net exist as browser sandboxes. Local storage, cookies and other features are bound to that sandbox, so if I push an app that uses local storage on `subdomain-a.arweave.net` a malicious party can’t push a transaction that interacts with it as they’ll be in a different sandbox`subdomain-b.arweave.net`. In future these sandbox URLs will likely be helpful for better integration of custom addressing solutions, as current DNS solutions work at a host level e.g. `subdomain.arweave.net` and not `subdomain.arweave.net/my-tx-id`.

### Current implementation
The sandboxes are derived from the transaction ID and block height, hashed together, base32 encoded and then take the first 12 characters, seen [here](https://github.com/ArweaveTeam/arweave/blob/master/apps/arweave/src/ar_domain.erl#L29). This means the subdomain is effectively random so a malicious party can’t try and for example get the same subdomain as an app they’re looking to attack. Base32 is used instead of 64 as it’s case insensitive as all domain labels must be ([rfc4343](https://tools.ietf.org/html/rfc4343)).

At the moment when you request a piece of data you do this:\
**1.1**- `arweave.net/:txid` -> 301 -> `:subdomain.arweave.net/:txid` -> 200

**1.2** - `:sandbox.arweave.net/:txid` -> 200\
This isn’t recommended as the sandbox are an implementation detail of the gateway, and are subject to change.

**1.3** - `invalid.arweave.net/:txid` -> 301 -> `:subdomain.arweave.net/:txid` -> 200\
This works as the subdomain is checked on each request. It’s actually useful if you want to do relative links across arweave transactions too as I can do `<a href="other-txid">` in my content. When a user clicks that link it’ll go to `:subdomain.arweave.net/:other-txid` -> 301 -> `:other-subdomain.arweave.net/:other-txid` and transfer across to the correct sandbox in a secure way.

### Future implementation constraints

I would like to improve this but there is some tension in the constraints and some issues with the current logic.

**2.1** - Only using the first 12 characters of the base32 encoded hash will have collisions at some point (totally possible it’s already happened?).

**2.2** - If the sandbox urls are too long they become unusable and are not at all user friendly. They look like a total mess visually, and make it harder for people to trust it. A lot of botnets linked to ad spam popups and click fraud do things like this with dynamic, random, long domains, so I don't think it's reasonable for people to be reflexively suspicious.

**2.3** - If the sandbox subdomain isn’t a reversible encoding of the transaction id, then the txid will likely have to remain in the URL which is bad for users as it's again aesthetically unpleasing in a way that developers do notice (and they are our audience, so...). Devs are also used to working at the root of a host, and lots of tools/routers etc assume this too (create-react-app being a massive example of this).

**2.4** - Base64 can’t be used because subdomains _must_ be lowercase, so on the backend if you have to do a case insensitive lookup you're going to have a bad time. I have personally witnessed cases of seemingly similar tx ids, where the only difference is casing, so that doesn’t work or scale at all.

**2.5** - If the txid needs to be in the URL, then this limits custom domain possibilities and makes DNS a mess. You can CNAME to `subdomain.arweave.net`, but not to `subdomain.arweave.net/txid`. This also makes integration with other decentralized custom domain solutions messy, and relies on TXT records which can’t easily be updated.

**2.6** - Any method of going from a subdomain to a transaction **must** be relatively easily reproducible. It should ideally just be a simple operation on the transaction ID, so if arweave.net disappears links can still be used (or converted/mapped easily and simply to another gateway).