Yep, that is why I referenced jelly time. From what I understood from most people out there, the latest exclusive to 5000 series frames gen feels like walking in gelatin, because it has that much smearing

This gen is going to be known for 2 things:

• jelly time
• the succession of the tis (or ties, like the other presentation)

Nice catch. I’ll be sure after do run the real thing

Thanks, managed to have it installed locally bia pocket pal (termux was giving me errors constantly on compile). Out of curiosity, I made a very “interesting” prompt, and frankly I am not even surprised

EDIT: decided to be a little spicier, didn’t fail to amuse me

So what you want to do, effectively, is to have different security requirements for different accounts. Correct? And all in the same file.

For now I just want to get a few things out of the way:

• with this strategy, what are you protecting against?
• how likely is this to happen?
• what is your contingency plan?

I believe its good to have different levels of security for different things, but you also have to understand at what cost you need it.

I can propose a different thing altogether: for the very important passwords, like banks and such, use the pepper method. This means, you have on your password manager part of your password, and a small portion is something you know. Example: generate a 25 chars password, and have at the beginning or end, more 5 chars that you know (can be letters and numbers, and can be something you remember every day, like the first letters of your address plus house number).

With this approach, there are a couple of benefits:

• you can still have computacionaly heavy passwords
• if an attacker gets a hold of your open vault and try to login, it will fail since the password is effectively not complete

Biggest downside I see is remembering the pepper always. And make sure is not written anywhere. And of course, yo can always argue it is possible at some point to get the correct password with the base password known. But at this point, thus should give you enough time to change it and thwart the attack. Remember: there is no perfect security solution, only sufficiently good ones that can be usable and effective.

One of the problems I personally see is the reliance on a standard that was done since the dawn of the internet and got stitches all these years.

Emails as a service is useful, and has several properties that make sense to exist. However, it is simply not easy nor intuitive to have encryption on it (and even then, there are limitations).

What we would need on the long run is simply replace email with a common standard that actually encrypts in transit (at very least) with auto negotiated keys on exchange.

But we would need to change the mind of a lot of people to make that a priority… (For better or worse, it is the market that states the incentives and priorities. And it is abundantly clear security is not on the top list)