I've been using Vimium since I use firefox (for around 3 years).
It's annoying that Vimium can no longer control the browser UI and is limited on some pages (New Tab, mozilla.org) but this is necessary for security.
Why? You can't read the source of this addon and evaluate whether or not it should have this access? This should be a permission that you can grant to an addon, we're not children that must at every juncture be managed so they don't burn their fingers.
Children are everywhere. They shouldn't drive cars, so we don't let them. If they shouldn't manage browser plugins, we shouldn't let them. This is really incredibly immaterial to the point - which is that browsers treat everyone like they have some sort of mental handicap.
In a competitive market, which browser is going to win, the one that says "no one under the age of 16 can use this browser because they're too likely to fall victim to the security holes we intentionally didn't fix" or the one that says "we fixed that security hole"?
I actually use a vim-style plugin in Firefox and this seems obvious to me, how do you think the majority of users feel?
Surely a Dyson sphere would not emit what we naively expect. Look at us, we can speculate about these and even try to spot them but are millennia away from building one.
What if the external shield of the sphere would be artificially heated to 4000K or higher ? Completely invisible.
What does low tech means in this context ? It's still a computer, with complication on top: solar panels, battery.
All the hardware they use requires some energy to be built, the network consumes a lot of energy too.
How does this compare to a VPS server at a cloud provider or using the grid electricity (no solar panel) ?
I'd expect individual VMs to use less energy compared to a decicated computer.
Is it really greener to stop using the grid electricity but instead buy a small solar panel ? Surely that'll be less green than the grid 20 years in the future.
The article contains many sources but doesn't compare other solutions. 2.5 watts is impressive, though.
The server could hash again the hashed password sent by the client. Especially if the client use an insecure hash algorithm (no secret salt for example).
I feel like if the client always hash passwords as soon as it is typed (the javascript never sees the unhashed password), no one would notice. (except some with crazy password rules that would disallow a hash-looking password)
The various ZKP approaches are considerably more complex to implement properly vs the trivial approach of a client side hash. There are obvious tradeoffs, of course, but I wouldn't fault someone for an additional hash step on the client.
Hashing on the client still seems redundant though. In the end, whatever value is sent to the server is essentially plaintext, because it's all an attacker needs to know to authenticate. Whether it's the raw text the user typed or some transformed version of it isn't really relevant.
In a world where password reuse is rampant, whether it's the raw text the user typed or a hard-to-reverse transformation on it is absolutely relevant to the user, just not to the service provider.
The actual reason is to make you practice your password so you don't forget.
You might scratch your finger or the sensor might get dirty or break. Biometric in (current) phones is convenience, not security.
