Sure, but a credentialed person is more likely to be familiar with other research in the area and have expertise with state of the art techniques in the field.
So an uninformed reader (with less background than either to critically evaluate the work) should, all else equal, prefer the analysis of an expert. That's not to say the expert cannot be wrong, but a non-expert has a greater need to establish the credibility of their argument.
Because by doing this you have misrepresented the truth in order to extract more money from your employer than you agreed (presumably, in your employment contract).
(As I commented elsewhere, whether you think paying by local cost of living is the right policy is valid to debate but isn't the point here.)
It's uses gn, a build system developed for Chromium. That said, on an Ubuntu system the steps to build Chromium are fairly well-documented and straightforward, as long as you have an appropriately beefy system (unfortunately it's a long wait and a fair amount of RAM is required, and Googlers tend to use a distributed build system).
Executing JavaScript every frame is not that heavy, but if the main thread is blocked because of something that is, which may even be in another tab, the animation will stutter.
The animations built into the platform can run and remain smooth under a broader range of conditions, which is why they should be preferred if you don't need the level of control that running script via requestAnimationFrame gives you.
Something running with your privileges could similarly use your existing sudo ticket, or manipulate the memory of your terminal emulator, or modify your shell to grab your credentials the next time you authenticate (and pass those to sudo), etc.
This isn't tmux's fault; this is fundamentally the sort of thing that's possible under the security model of modern Linux desktops.
Most desktop OSes aren't designed to defend applications run by the same user from one another. As a consequence an attacker running unsandboxed code with your user privileges is an attack that's very difficult to defend against.
If you can run code with the same privileges as Chrome (under an authenticated user account), then on most desktop OSes, you can do whatever Chrome can do, including access the password
store.
This may be a more convenient way to do so, but ultimately it's an attack that's rather hard to defend against under the usual desktop user-based access control model.
> Maybe browsers could do some static analysis for the simple cases?
The risk here is that you end up where cases where non-obvious changes cause the static analysis to no longer work; at least in the current world there's a clear line between having a non-passive event listener and not having one. Attempting a heuristic could cause both unpredictability and interoperability issues (since the heuristic will surely vary by browser vendor).