It's actually a very interesting frontend platform to design for, because you don't get any Javascript support, but you get full modern CSS support.
I never thought I'd say this, but HTML4, with all its billions of warts, was a pinnacle of this vision. Later developments swung too hard towards an excessively content-focused vision first (XHTML, the "semantic web"), and then swung all the way in the opposite direction, turning web protocols into dumb pipes for the general-purpose VM runtime that modern JS/HTML engines have become.
Unfortunately, the industry always, always wanted this runtime. Plugins, applets, ActiveX -- people just refused to accept basic form-based interaction. DarkWeb properties accept it only because doing otherwise would be too dangerous, in the same way people don't wear jewelry when going through a ghetto.
I've been experimenting with DuckDuckGo's .onion site. Below is example of how to search the light web over Tor without Tor Browser.
I'm curious .onion sites because it sounds like .onion solves the reachability problem. Anyone could have a website. No requirement for reachable IP address from ISP. No requirement for domain name and hosting subscriptions. No commercial middlemen. (Assuming Tor network operators are true volunteers.) Not every website has to be commercial or reach large scale.
pts/1
x=duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
socat -d -d -d tcp4-l:443,fork,reuseaddr,bind=127.0.0.42 socks4a:127.0.0.1:$x:443,socksport=9050
pts/2 # Usage: echo query | $0 > 1.htm;
links -no-connect 1.htm;
firefox ./1.htm;
#!/bin/sh
h=duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
read x;
curl -v0dq="$x" --resolve $h:443:127.0.0.42 https://$h/lite/
Using socat instead of curl #!/bin/sh
h=duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion
read x;
x=q=$(echo "$x"|yy046);
export httpMethod=POST;
export Content_Type=application/x-www-form-urlencoded;
export Content_Length=${#x};
export httpVersion=1.0;
export Connection=close;
echo https://$h/lite/|yy025|if sed w/dev/stderr;then
echo $x;echo $x >&2;fi \
|socat stdio,ignoreeof ssl:127.0.0.42:443,verify=0For example, when using Tor Browser to connect to regular public websites, your goal is usually just to obscure your connecting location, hide your traffic from your ISP, and punch through and firewalls between you and the destination, without first being required to establish a relationship with some specific proprietary VPN company (where doing so might not even be possible if you're in some countries.) So people doing this tend to be willing to enable JS, at least on a per-site basis.
It's only really when you're in the kind of trouble where state actors are trying to correlate your IP address through inadvertent connections you might make to state-owned-honeypot Tor hidden sites, that the full no-JS paranoia is warranted.
But, to vouchsafe the anonymity of those people, it's better for anti-fingerprinting if more people who are using Tor Browser for more mundane things, also have JS disabled. So Tor Browser disables JS by default.
Which means that it's pretty much a given that if you're doing web design specifically for a Tor hidden site, then you have to assume that people accessing your site will have JS disabled. (And that you can't just ask them to enable it — they'll say "nice try FBI" and close the tab.)
We'll build our own internet! With blackjack and hookers!
More seriously, I see echoes of the gentrification cycle. At the end of the cycle nobody wants to live in the soulless corporate hellscape they've helped create, so they follow the cool kids to the next up-and-coming neighbourhood. It works for social media sites, so why not for an entire protocol?
If you can figure out a protocol where ads don't work, I'm in.
Is it even theoretically possible to create such a protocol? Preventing tracking is feasible, but telling apart ads from real content does not sound solvable on a protocol level.
I believe that wherever we go, marketers will follow us. But wouldn't it be great if I was wrong...
The only hope is anti-trust breakup of Google. Chrome has to be pried forcefully from their hands.
We should launch massive campaigns not just in the US, but also Europe and other critical markets.
We shouldn't back down even if they abandon WEI. They'll just keep trying as they have with AMP, Manifest v2, WHATWG [1], etc.
Google can never be allowed to build browser tech so long as they control search.
The web must remain open.
[1] WHATWG took unilateral control over the HTML spec. They abandoned the Semantic Web, which had led to RSS, Atom, etc., and would allow documents to expose information you could scrape and index without Google Search. Google wanted documents to remain forgiving and easy to author (but messy, without standard semantics, and hard to scrape info from)
Mozilla is barely able to fund itself, and a big chunk of that funding comes from Google. Surely Google is careful to avoid any overt impropriety with that relationship, since they don't want to come under more regulator scrutiny. But why would a Chrome, Inc. care about that sort of thing? They'd take the same money from Google Search, Inc. that Mozilla does to keep Google as its default search engine. They'd still happily implement WEI and other garbage that Google Ads, Inc. wants, and Google Productivity, Inc. would still ensure that Docs, Sheets, Drive, etc. are all super-compatible with Chrome (and work with the Chrome team to ensure that's the case), and not care so much about other browsers.
I have no doubt that things would be better if we were to break up big conglomerated companies like this, but I'm not entirely sure that breaking up Google would achieve the goal of helping the web remain open.
I want to see it; I don't know the path there.
Sure. It's really just a matter of mass appeal. We could fork the existing browser base and eliminate the new attestation API. Some projects are already doing this from what I understand.
What will keep attestation from being used is websites will lose business if their customers can't access the site. We went through this with user-agent string checking in the 90's/00's when IE and Netscape/Mozilla were at war and every site had a very strong opinion on which browser they would support. Even today you occasionally see sites that will hit you with "unsupported browser" errors if you aren't running a specific version of something.
The solution to this was everyone realized they were throwing money away by excluding a large portion of their customer base. At the time no single browser really dominated the market share so it was easy to see that an IE-only site was losing 33% of internet traffic. These days everything is basically chrome-based so this hasn't been as much of an issue.
So in the future we'll see this same thing. Non-attestable browsers will be locked out of attested sites and it will be a numbers game to see if sites want to risk losing these customers/viewers.
At the end of the day, you have to remember that everything on the web is just a TCP socket and some HTTP which is a flexible text protocol. We can build pretty much anything we want but it takes inertia to keep it going.
Rather than being completely blocked, I think non-attestable browsers will be subject to more CAPTCHAs and other annoyances, similar to what TOR users see today from anti-DDOS services. Perhaps ad-supported services using large amounts of bandwidth will decide not to support non-attested users, since the ad revenue from those isn't enough to pay for the bandwidth.
What I would like to see is a solution for anonymous microtransactions, so web sites have a monetary incentive to serve users who want to use a non-attestable browser (and don't want to see ads).
I would like to think so but as someone who's tried to hack on the chromium codebase I'd say it's easier to make a new browser from scratch than to figure out how to make meaningful changes to chromium.
Anything that allows companies to exert more control, will be used to exert more control.
And that's fine; if some people want their own sandbox so they can avoid the horrors of the WWW as much as possible, more power to them.
But let's not pretend this is going to be come a widely-used platform where people are going to be able to do but a small fraction of the things they can do on the web. Again: that's fine! But it can't and won't replace the web.