Had a very interesting chat today with Sebastian from Mozilla who's working on their android components project: https://github.com/mozilla-mobile/android-components
If you want to make a browser for android, this is the place to look. Well written, well-tested, modular and composeable components covering all of the different parts of the browser. This will make making browsers and browser-like apps much easier!
"Why should I use a Reverse Proxy if Node.js is Production-Ready?" by Thomas Hunter https://medium.com/intrinsic/why-should-i-use-a-reverse-proxy-if-node-js-is-production-ready-5a079408b2ca
Really well-written and interesting post. I appreciate it has a benchmark to back up the performance argument.
Thank god the entire industry hasn't decided to revolve around Blink/Chromium for 95% of the web's browser traffic, or else Google would have an unlimited ability to push forward whatever bullshit standard they wanted.
Wait hold on, my producer is telling me something [places finger on my ear piece]
Been writing up how basic Dat support is implemented in Firefox with dat-fox:
Next post will be how dat-webext fixes all the shortcomings that dat-fox has!
“These companies are unavoidable because they control internet infrastructure, online commerce, and information flows. Many of them specialize in tracking you around the web, whether you use their products or not. These companies started out selling books, offering search results, or showcasing college hotties, but they have expanded enormously and now touch almost every online interaction. These companies look a lot like modern monopolies.”
BTW, you can now browse `dat://` archives using Datmobile on Android.
The performance has been shown not to hold for adblocking extensions (https://whotracks.me/blog/adblockers_performance_study.html), and there are many other problematic webextension APIs w.r.t. privacy.
The solution to these issues should be institutional, not technical. Google should impose performance constraints on extensions, and audit what data extensions are sending home. However, looking at the rampant malware on all their stores, this is something they're unlikely to do, so instead they'll nerf extension's capabilities.
Disagree with this article's thesis that the Webextension webrequest API should be removed.
By moving to a declarative blocking API you are limiting the possible ways for extension to function to blocking and redirecting. This is a very narrow use-case, based on the current prevalence of blocking extensions.
But this is not the only way to solve problems such as blocking ads and improve privacy, as shown by privacy badger and Cliqz' tracking protection.
A product's privacy claims are only as good as its default settings.
Providing options to change the default privacy-violating settings in some "Advanced" section doesn't make your product a privacy-respecting one.
@liaizon Mastodon would need to be able to speak over the dat protocol and make the query to confirm. so we'd have to add a dependency to Mastodons server of a library that can essentially do "curl dat://" and then use that to confirm the link
Great post by a colleague on benchmarking adblocking engines. The level of optimisations in these engines is incredible! https://whotracks.me/blog/adblockers_performance_study.html