While exodus is a good minimum bar, and I use it, its list of detected trackers is incomplete. I have reported two known trackers, but their signatures are not yet detected by exodus.
It is difficult to know these signatures because the good trackers share their SDK only under an NDA.
For the first problem, you need to ensure that you exercise the muscles along with fasting, to nudge the body away from salvaging proteins from muscle tissue. (Not a bio chemist either, this is what I have read in most articles about intermittent fasting)
htmx sounds great! I am interested in this from the security angle. If browsers were to natively support htmx (or something similarly declarative), it might reduce the need for Javascript and hence improve security.
Agreed; a determined programmer could solve almost any Captcha given sufficient time and resources.
But we are not trying to create an unsolvable Captcha. For those websites that need something good enough to deter generic bots while not compromising privacy of their users, this might be a good enough alternative to reCaptcha.
Imagine a docker image which just works with out-of-the-box generators. Those who need more variety could create a custom generator with Javascript and drop it into a docker volume.
The idea is to develop a framework for Captcha generators. A few sample generators are provided out of the box, but new ones can be written easily. The framework takes care of storing entries in the database, serving them as challenges through an HTTP API, and checking the responses.
From the README, why libreCaptcha:
* Eliminate dependency on a third-party
* Respecting user privacy
* More variety of CAPTCHAs, tailored to your audience
The implementation has a long way to go (it was written by students trying to learn Scala), but would appreciate thoughts on the concept.
We don't need a new web; just more browsers that respect the user's privacy. There are many ways to achieve this. At gngr[0], we are taking a "safe by default" approach. This is very similar to the NoScript / uMatrix approach, but with one difference: the browser itself is offering this and is hence more water tight. There are no behind-the-scenes requests that a plugin can't block.
It forces all tabs into inactive state on startup. Also creates a new tab page (or switches to an existing one) to avoid loading the focussed historical tab.
We can't stop people from naming their projects/products the way they want. However, I think headlines in HN should be editoralized a bit to provide context, followed by the actual headline from the webpage.
You can try increasing `N` in the nbody problem, and also measuring the memory overhead.
You could also try one of the hashing / crypto algorithms in JS. They should involve a lot of integer arithmetic that should make WebAssembly stand out.
More tips:
* for performance measurement, setup the benchmark so that JS run takes atleast 30 seconds. (Increase N, etc)
* close all other applications and tabs
* If you have linux, set the CPU governor to performance
* Measure the CPU temperature and make sure you let the CPU cool down between runs. In modern CPUs, the cores get throttled automatically when they reach a certain temperature.
Thoroughly solving security problems would of course take time. But the parent comment asked a very high level question: How does the security of this new proposal compare to a client-server model such as that of OpenGL? One can simulate one model over another, but in that case, performance can suffer due to overheads. This sort of thing needs to be addressed at the outset, because graphics needs performance and the web needs security; neither can be compromised upon.
128MB was the total RAM in the VPS including OS + nginx + JVM + Postgresql. The heap allocated to the JVM process was about 64MB, but bear in mind that this was an actual application. So, it's hard to do a detailed comparison between JVM and Go without standardising on the application. All that I am claiming is that JVM is in the same ball park.
Just imagine the energy savings!