Yes, there seem to be really valid security concerns about the current extension interface. Perhaps Google is making the wrong tradeoffs here. I don't know, it's very complicated, but the article is not really engaging with those tradeoffs.
They will work over the internet. You should use SSH or a VPN like Tailscale because the native protocol is not encrypted.
Bandwidth and latency effects will have some effect on how well it will scale, but on a reasonably high latency and low RTT connection it's probably still faster than purely local compilation. Sending work over the network takes time but not much CPU, so the local CPU is freed up to do other work.
Yes, that's correct: reusing developer's computers means you're trusting all of them. At small scale, that may be acceptable because you probably trust them all a lot anyhow, and perhaps are unlikely to have a strictly hermetic and isolated build system.
When the team is bigger or when security is more important, it's important to have a build system where you're confident that no one can subvert the output, and that includes ensuring that very few people can control machines running distccd.
Another way in which it shows its age is that, by default, there are only netblock based restrictions on clients, and connections are over unencrypted TCP by default (last time I looked), although there is an option to use SSH (or I guess Tailscale or similar.)
> Ability to link to documents, bookmark, meaningfully use history and save pages to the disk for offline use. Ability of the users to customize standard behaviors without reverse-engineering your JavaScript code. Transparency, which often leads to much, much easier debugging and improved usability. No need to run a quad-core 4GB desktop to use the website.
You can manipulate the page url/browser history from js, and you can use the url to set the application state. History and bookmarks work perfectly well in gmail, for example.
This does take explicit coding. But, if fragments of the page are being replaced as bcx does, then you need to do similar coding anyhow. Otherwise, you're doing whole page loads on every request.
js works pretty well on modest smartphones, at which level network latency is usually the major concern...
The problem with "what do you know" questions is not (or so much) that they may reject people who know stuff but recall it differently, but that they aren't selective for having the ability to stick with something for an extended time. Avoiding distraction with the internet, or the more subtle types of distraction into futzing with things rather than doing the most important but more discouraging tasks.