I've been playing with this idea recently. If you want to provide access to a database which is infrequently updated and no bigger than a few megabytes (like the catalogue of a library with 30 000 books), then provide the database with the web page and implement the search function in JavaScript. If you avoid using a JavaScript "framework" then you may find that the web page responds to your typing so instantaneously that you feel like you're back in the 1980s using a Z80-based machine. (You remember those Z80-based word processors that could keep up with a competent typist?)
Of course, on the majority of websites I am not doing any interactions where that would be necessary to me in the first place, and on the majority of websites where JavaScript is used, it's used with little mind towards privacy.
That it isn't inherently evil is a pretty toothless argument that fundamentally doesn't address the proposed solution you're responding to. The fact that the web is a cesspool of scripts ranging from completely useless to directly user-hostile isn't nullified by use cases that are so rare that you from the top of your head can apparently only hypothesize about them.
There seems to be something wrong with a world in which it is in some ways easier/safer to run an untrusted binary, by putting it in a container, than an untrusted web page. You can of course put the browser in a container, but it's crazy that we have to resort to that.
Thanks to Spectre and Meltdown, if you want to be really safe when running untrusted code, you need separate hardware.
But in general: I suppose what we need is a flexibly configurable JavaScript engine that stops and asks permission before any suspicious operation is performed. I don't know enough about JavaScript to know whether or how that might work. I note that the way tujavortaro.net downloads a dictionary is by adding a <script> element to the head of the document (https://gitlab.com/sstangl/tuja-vortaro/-/blob/master/app.js...). HTML+JS is naturally self-modifying, so it's hard to do a static analysis.
Your book-search idea is interesting. Another way is simply to display the list on the web page, minimally marked up, and let the user search using the text search in all browsers - no JS needed. Might be a sizeable page though.
There may be better ways that don't involve sucking bandwidth to deliver a huge list. Bloom filters? I dunno, needs thought and I'm busy - what do you reckon?
But your idea still needs JS. I'm fine with JS if I knew it was doing something minimal and it was highly constrained. That's the problem, not so much running JS as trusting it when it comes from somewhere unknown.
Keep up the good thinking though!
The Web started life as a means of publicly sharing documents and has turned into a network of walled gardens. Rather than trying to fix the web itself, I think the solution is to try to recreate something true to the original spirit where users are publishers and where openness is the default.
What I'm working on specifically is best described as another take on Mozilla's Open Web App project[1] where applications are actually distributed to users for them to run themselves. The difference is that by adding visual programming into the mix, programs are realistically user editable and software freedoms start to take on a real significance to a whole new audience of empowered end-users. If you're interested in finding out more, I'm planning on publishing a blog post outlining the details in a couple of weeks time - watch this space.
[0] - https://vimeo.com/71278954
[1] - https://blog.mozilla.org/blog/2010/10/19/prototype-of-an-ope...
I don't actually use my own server to serve my website, currently, but I have the infrastructure set up to do so if need be.
> writing your own browser engine seems totally pointless - it's the web at fault, not the browser that renders it. If you don't like bits of the browser, remove the code. Don't understand what you're trying to do.
I'm suggesting contributing to an existing web engines, not writing one from scratch (which at this point is fairly difficult to do).
It's a huge pain to make phone calls, or go to the store
But another way when you need not have to use the site to put pressure on the site by not bothering with it if it breaks without JS. Enough people do it and they will get the hint.
Or actually talk to the site owners and ask them - I have done this with a small publisher.
Or if someone post a link to their JS-requiring blog/site on HN, ask them politely to make it usable without (I do occasionally).
If you want to fight back, you have to pay the price. It's a pretty small one for me.
What I was getting at was dead simpl,e: turn off JS and install a hostfile-based blocklist, or other. It really was that simple. I also enable cookies just for HN posting. Else no cookies of any kind ever accepted.
So are people doing that, because if you don't co-operate with their code, tracking you gets vastly harder. You can take back control of you machine - if you choose.
It's simple and you can do it now - if you choose.
@benjaminjosephw: can you give more detail? (glad you're not just all talk!)
@marcus_holmes, @zdkl, @saagarjha: you may need to get together with others to unify the idea of doing your own web servers. A collective not a commercial entity which you are trying to avoid being involved in. That gives you together much more power.
I think that's what @MaxBarraclough is suggesting looking at . I will to.
@saagarjha: writing your own browser engine seems totally pointless - it's the web at fault, not the browser that renders it. If you don't like bits of the browser, remove the code. Don't understand what you're trying to do.