What I really love about Onion sites is that if they are big enough, performance engineering really becomes Tor-specific. A few examples:
- Making assets embedded as base64 (img src the header logo as base64, all CSS should be inline, etc.).
- Leveraging CSS as much as possible (if you use animations and transitions, use CSS as much as possible for these, avoid JS for them).
- Make sure your website is mostly rendered on the backend. If you're to have JS, your website should work without it.
- Security becomes REALLY fun, as in, avoid XSS, CSRF, SQL Injection attacks and any other injections as much as possible.
As someone summarizes in another comment[0], keep the chattiness as minimal as possible. By chattiness I understand they mean, pack as much data as you can in the same Keep-Alive connection. Avoid making new HTTP requests as much as possible, as each one might get assigned to a new Onion route making things slow.
If you can ship your website to the browser in a single connection, you've won.
I've always been impressed by performance of these big Onion sites, they really push the limits of software engineering creativity, given these constraints and nature of Tor.
Also DDoS becomes a problem, and the ways it's done are pretty specific to Tor. Double captchas are necessary when you're getting DDoSed, due to performance reasons. Oh, and captchas are also pretty specific to Tor as well.
There's also a problem of site fronting. Anyone could run a proxy pretending to be you, for arbitrary reasons (not even necessarily the obvious forging and credential stealing). Every site, even a personal blog, has dozens of parasitic fronts, either actively malicious or dormant. You need off-site ways to tell users what is the real address, and provide a smoke test for them (often a part of the address as a picture, for example in a captcha).
>avoid JS for them
Using any JS defies the point and makes your site instantly suspicious.
> There's also a problem of site fronting. Anyone could run a proxy pretending to be you, for arbitrary reasons (not even necessarily the obvious forging and credential stealing). Every site, even a personal blog, has dozens of parasitic fronts, either actively malicious or dormant. You need off-site ways to tell users what is the real address, and provide a smoke test for them (often a part of the address as a picture, for example in a captcha).
How can you do this without relying on the normal web? Let’s say you use a normal website to show the onion link, if the website gets taken down, you lost your user-trusted mean to do that.
>How can you do this without relying on the normal web?
How can you trust anything you haven't experienced personally? By using chains of trust, of course. There are directories that list onion sites, and also sites that link to their peers. That way you can be sure you're still in the same bubble at least, and convert the problem into trusting the entire bubble. It's not automated and pretty ad hoc, if that's what you're wondering. Automation in Tor has a history of being circumvented or exploited with novel scams, this is an adversarial environment.
ivanmontillam · · focus · HN ↗
- Making assets embedded as base64 (img src the header logo as base64, all CSS should be inline, etc.).
- Leveraging CSS as much as possible (if you use animations and transitions, use CSS as much as possible for these, avoid JS for them).
- Make sure your website is mostly rendered on the backend. If you're to have JS, your website should work without it.
- Security becomes REALLY fun, as in, avoid XSS, CSRF, SQL Injection attacks and any other injections as much as possible.
As someone summarizes in another comment[0], keep the chattiness as minimal as possible. By chattiness I understand they mean, pack as much data as you can in the same Keep-Alive connection. Avoid making new HTTP requests as much as possible, as each one might get assigned to a new Onion route making things slow.
If you can ship your website to the browser in a single connection, you've won.
I've always been impressed by performance of these big Onion sites, they really push the limits of software engineering creativity, given these constraints and nature of Tor.
--
[0]: <a href="https://news.ycombinator.com/item?id=49872320">https://news.ycombinator.com/item?id=49872320
EDIT: Formatting of bullet points.
orbital-decay · · focus · HN ↗
There's also a problem of site fronting. Anyone could run a proxy pretending to be you, for arbitrary reasons (not even necessarily the obvious forging and credential stealing). Every site, even a personal blog, has dozens of parasitic fronts, either actively malicious or dormant. You need off-site ways to tell users what is the real address, and provide a smoke test for them (often a part of the address as a picture, for example in a captcha).
>avoid JS for them
Using any JS defies the point and makes your site instantly suspicious.
Lucasoato · · focus · HN ↗
How can you do this without relying on the normal web? Let’s say you use a normal website to show the onion link, if the website gets taken down, you lost your user-trusted mean to do that.
orbital-decay · · focus · HN ↗
How can you trust anything you haven't experienced personally? By using chains of trust, of course. There are directories that list onion sites, and also sites that link to their peers. That way you can be sure you're still in the same bubble at least, and convert the problem into trusting the entire bubble. It's not automated and pretty ad hoc, if that's what you're wondering. Automation in Tor has a history of being circumvented or exploited with novel scams, this is an adversarial environment.