Comment Re:The reason I got it (Score 1) 96
kWh battery. Knew I'd miss that at some point.
kWh battery. Knew I'd miss that at some point.
Okay, that's amazing.
Here (Australia, all AUD) I pay 28 cents per kWh and get paid 5 cents per kWh. I have 12kW solar which was great when they paid 12cents, but now it's not so I got a 30kW battery and it's paying for itself pretty quickly. Battery was $6k AUD installed.
For at least a year (maybe more) I thought that it was go-dot, kind of a play on dotnet. Especially with the work on adding c# support.
I so dumb!
I can't find any reference to this. Not saying it hasn't happened, I just don't see it on the internet. A link would be useful.
I've had Linux kill a motherboard (would boot, but fans and sensors didn't work so it would overheat and crash pretty quickly) setting up lm_sensors.
Wait, no electric windows? That's not a luxury feature since the late 90s.
I like the idea of this (here in Australia there's no inexpensive EV utes), but that's a step too far.
A bit like the ship of thesus
75% is pretty close to a monopoly
I hate snap, but for an average computer user (not Linux enthusiast) there is nothing wrong with it. Steam was an issue for a while but that's been resolved.
I found the setting for this: chrome://password-manager/settings has a "Use Windows Hello when filling passwords". It was off for me - I can only assume that is the default, as I have several Chrome profiles over several PCs and it's off in all of them.
Also noticed there's this:
Set up on-device encryption
For added safety, you can encrypt passwords on your device before they're saved to your Google Account
which, if I click on, takes me to a page that just says "On-device encryption canâ(TM)t be used for this account. Sign in to another Google Account and try again."
Ah interesting, never seen that before! I've just turned it on to see how annoying it is.
Chrome does require authentication for every password retrieval. It uses Windows Hello as well so in theory you don't even have a password to intercept since something like facial recognition authentication via a FIDO2 handshake is what ultimately allows Chrome to fill a single password on a single site.
Maybe I'm misunderstanding what you mean by 'auth' here, but on my PCs (Windows 10):
It does require auth for passkeys, I think every time, but not for regular saved passwords in the browser. I have Windows Hello set up for a couple passkeys and I have to auth via Hello when I use them.
But I have regular saved passwords for almost every other website I use routinely and am not prompted to auth via Hello for that. My understanding is that for these, the auth/unlock is done once at user login and then the session has access to the unencrypted passwords.
(I posted elsewhere in this thread about Chrome using DPAPI as of 2024 - this was news to me so it's possible I'm just way out of date).
Been trying to figure out how Chrome does this because my recollection was that Chrome had the exact same problem - I remember making a similar point to you in forum threads a couple years back with people complaining about it then.
It looks like in 2024, Chrome added support for something called the Data Protection API (DPAPI), which provides some mitigation against arbitrary memory reads:
App-Bound Encryption relies on a privileged service to verify the identity of the requesting application. During encryption, the App-Bound Encryption service encodes the app's identity into the encrypted data, and then verifies this is valid when decryption is attempted. If another app on the system tries to decrypt the same data, it will fail.
Because the App-Bound service is running with system privileges, attackers need to do more than just coax a user into running a malicious app. Now, the malware has to gain system privileges, or inject code into Chrome, something that legitimate software shouldn't be doing. This makes their actions more suspicious to antivirus software â" and more likely to be detected
It's not clear from my quick read if this defends against this class of "attack" in all cases but it reads like it might provide at least some protection?
If that is the case, it of course raises the question why Microsoft - who created DPAPI in the first place - wouldn't use that same service in the same way. (i.e. maybe it just sucks and they know it's a waste of time
Posting a commit message is not a legally binding authoring attribution and doesn't magically change things.
It's just like if I published a git tutorial site that had "coauthor: my_actual_name_here" hidden in an automation file. That would not magically give me copyright of every piece of code submitted by anyone who followed my git tutorial.
Clink also worth a look: https://chrisant996.github.io/...
Except in this environment they'll just raise a few extra billion dollars and buy all the water anyway and price out anyone that is not a VC funded AI company
Pie are not square. Pie are round. Cornbread are square.