Yes, just like the Steam Deck, it’s a pre-built that functions like a console and can do other desktop stuff too.

I think so. It’s trying to compete with Microsoft and Sony consoles in much the same way that Steam Deck competed with the Switch. Taking on the largest segment of gaming outside mobile is pretty ambitious. It seems to be launching along with a new VR headset and a new controller, so they seem to be targeting high volume sales for the living room gaming market.

The hardware isn’t the ambitious part, the target market is.

This change will be available in Rust Nightly tomorrow, and should ship as part of Rust 1.93.0 in January.

Neat!

Original comment:

Here’s a fun fact: phone manufacturers know this. So what they call “100%” is not actually 100%.

My response, which was a small clarification:

That depends on the manufacturer, some do, some don’t. My phone has a setting to control the max charge, so I set it to 80% when I got it.

And the follow up from a different user:

Yes, but that 100% is not really that. It has been programmed to display that percentage, when i reality its 80%.

And my response:

No, I’m saying that not all manufacturers have that limit, and it’s a relatively new setting (last few years). If you have an older phone or something not from the top few manufacturers, it might not have that feature.

Then our conversation started. That’s the context. Here’s your first comment:

Exactly, which is neither a user setting or relatively new. Battery manufacturers have always had to decide what voltage is what state of charge (percent).

The user setting where you limit it to 80% is on top of what the previous commenter was describing

And then my response:

Sure, if the manufacturer sets it to not charge to the max. I’m saying some manufactured charge to the max by default, hence why that setting is useful.

My point is and has always been that this isn’t universal, so don’t just assume that your phone stops charging at 80% if battery longevity is important to you. Check if your phone does it so you can know.

If anyone is trolling here, it’s you.

The OP said “all phone ma manufacturers stop charging at 80%.” That means phone manufacturers have a definition for 80% and 100%, and they use 80% universally while showing 100%. The first part is true, the second part isn’t. Some manufacturers show 100% when it’s actually their definition of 100%, meaning charging to 80% manually on those phones has value in prolonging your battery, whereas charging to 80% manually on the phones that cap at 80% doesn’t have value.

It is a security threat, and to claim it doesn’t count is absurd.

Oh, absolutely.

Replay attack is the wrong term, here’s the threat model I’m talking about. Basically, the attacker watches the authentication flow and uses the resulting session (token?) to make web requests as you, stealing whatever data it wants. There’s no attack on the authentication scheme, but on the shortcuts web services use.

It doesn’t matter if you use passwords, TOTP, or webauthn, there’s going to be some vector to attack the system without breaking the authentication mechanism.

The average user isn’t going to see much security benefit from webauthn vs TOTP in the same way that adding a better lock to your front door is unlikely to improve your overall home security, because at a certain point, the burglar will just smash a window. TOTP is good enough because it’s safe from attacks on email and SMS that worse one-time code systems use. You should definitely have a lock on your door, but at a certain point, the lock is no longer the weak point in the system.

And yes, I’m using “code generation” as a generic catchall. I group auth systems like so:

• offline threats - e.g. passwords that can be broken by seeing the hash
• reliant on third party service that can be attacked separately - email and SMS
• “code generation” - uses some cryptographic mechanism to generate some unfakable code that can’t be reused; seeing more examples doesn’t help, and codes can’t be reused

If your password manager handles the second factor, the user experience of TOTP vs webauthn is nearly identical, and the security is nearly identical to your average attacker, to the point where they won’t attack the authentication mechanism itself, but something else on the website or the password manager itself.

The problem is that most people do only use plain old passwords. If we can get any kind of extra security, even TOTP, then all the better.

Exactly. The difference between TOTP and webauthn only really matters if you’re a government or something else where state-level actors are part of your threat model. If your service uses one or the other, the distinction isn’t important to the average user.

The only MITM attack I’ve seen is entering codes before the user does. That’s not breaking TOTP in any meaningful way (which is what I was trying to get at), so it would be similar for password entry or even passkeys if they have sufficient control over the device or network to essentially do a replay attack.

I’m basically saying that generating codes with TOTP and passkeys are a similar process and are subject to similar threats. Passkeys are slightly better since codes can’t be generated independently, but AFAIK that’s not a significant threat for TOTP anyway, because if they have that level of control, they already have your data.

The choice between TOTP or passkeys is not a significant one, if your provider offers one or the other, your account will be reasonably secure. If your TOTP solution is built in to your password manager, it’s basically the same thing so you should probably prefer passkeys.

Yeah, the implementation is very different.

I’m just saying that it’s similar from an average user point of view. You set it up once, then your app generates a unique code that the server can associate with you in a way that can’t be broken by a third party watching traffic.

Weird. As a Linux user, I don’t remember the last time I visited their website since I just install it from the package repos.

Yup, it’s closer to TOTP than a password/number.

Until it’s not

How relevant are Firefox release notes after the subsequent release? That’s one resource I don’t mind not being archived.

I’m pretty inclined to downvote any post that is a link without a short summary or context.

Why? The summary of Firefox release notes is the Firefox release notes.

I agree there should be a summary for other things, esp. videos or long articles, but for release notes, they’re already generally in a condensed format. This one is a few pictures with a couple sentences explaining what’s new in them.

That really depends on the community. When I was there, I would avoid the larger communities and seek out smaller communities. When I first joined Reddit, it was to avoid the attention-seeking posts by humans, and near the end it was to avoid attention-seeking posts by bots and humans alike. The best content IMO is on subreddits with <100k subs and <5 posts per day.

All I want is a game that’s not a buggy mess.

That fits pretty much every game where you control a main character. MCs rarely have a suitable explanation for why they’re so special beyond the rule of cool. Why can Gordon Freeman take out teams of special ops? Because he’s the MC. He’s a pretty bland character that doesn’t say anything, but he’s loved by millions.

“The max” is the highest voltage the battery can safely store with reasonable losses, and “empty” is the lowest voltage the battery can safely charge from. Or something like that, I’m not a battery engineer. There’s surely a bit of buffer here since users will use it outside of ideal circumstances (ambient temperature, heat dissipation, etc).

Regardless, those numbers come from the battery manufacturer. I’m guessing phone manufacturers add some extra buffer given the properties of the phone (heat generated by electronics, heat dissipation of the case, etc).

None of that has anything to do with what I’m talking about.

The 20-80% range is on top of that and is based on efficiencies in battery tech. That’s the sweet spot of battery longevity, and some phone manufacturers limit charging to the top end and most (all?) warn when you hit the lower bound. But not all manufacturers report 100% when it hits that upper bound of that range. Many do, but not all. Some report 80% and let you bypass it, and some don’t cap that upper bound.

Sure, if the manufacturer sets it to not charge to the max. I’m saying some manufactured charge to the max by default, hence why that setting is useful.

I’m saying when your phone charges to 100%, some manufacturers take that to mean 80% of capacity, whereas others actually charge the battery to 100% of capacity.