Mama told me not to come.
She said, that ain’t the way to have fun.
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:
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, they try to make the game more “fair” (i.e. help those who fall behind), but the game was intentionally designed to be unfair, so “fixing” it just drags it out.
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.
“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.
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.
Nope:
Betteridge’s law of headlines is an adage that states: “Any headline that ends in a question mark can be answered by the word no.” It is based on the assumption that if the publishers were confident that the answer was yes, they would have presented it as an assertion; by presenting it as a question, they are not accountable for whether it is correct or not.
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.
Yup, I use the terminal every day at work, my workflow is VIM + tmux, and I self hosted a Minecraft server using systemd (and a bunch of other stuff), so CLIs are kinda my thing.
I don’t use MPV. Why? I watch my content on my TV. If I’m on my computer where MPV could be used, I’ll play video games or work on personal projects, not watch content. Jellyfin is easy enough that I had to block the app on my TV since my 3yo was watching it before I got up. It works really well, it’s easy to set up, and even a child who can’t read can use it.
What does MPV provide?
My SO is reasonably technically inclined, and still keeps forgetting they have the SMB share on there. It’s literally a folder like any other on their PC.
They do remember both the IP/port (our TV sucks and loses WiFi periodically, and Jellyfin forgets the info) and the URL (can’t use TLS on the TV apparently…). And that inconvenience is way less of an issue than dealing with an already mounted SMB share.
So yeah, MPV is a nonstarter.
Yeah, I’m not connecting my computer to my TV to watch something. Jellyfin streams to it without that nonsense, why would I go back to essentially sneakernet?
It misses the primary use case for me: streaming to TV. I used to use minidlna, but the UX on my TV sucked, and Jellyfin was a pure upgrade. I can count the times I’ve watched more than 30a of my media (to test something) on anything other than my TV on one hand, and all of those are on a tablet using cached files.
If I did watch media on my laptop or desktop, I’d mount a network share and use VLC or something.
Original comment:
My response, which was a small clarification:
And the follow up from a different user:
And my response:
Then our conversation started. That’s the context. Here’s your first comment:
And then my response:
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.