I'm just wondering if there is any real modern pocket cyberdeck with the form factor of those old phones, with a slide out physical keyboard.
Readit Newsantran22 commented on Nokia N900 Necromancy yaky.dev/2025-12-11-nokia... · Posted by u/yaky
antran22 commented on Icons in Menus Everywhere – Send Help blog.jim-nielsen.com/2025... · Posted by u/ArmageddonIt
antran22 commented on Zen, a Arc-like open-source browser based on the Firefox engine zen-browser.app/... · Posted by u/femou
I checked this out and I gotta say it is still in a very early stage. The features they are presenting seem nice, but not very usable, with a lot of rough edges.
Then I found this issue, where essentially they left a huge backdoor open with Remote Debugger: https://github.com/zen-browser/desktop/pull/927. The guy claims that it was due to ignorance, but seeing this really shakes up my paranoia. Luckily I haven't typed any credential into the app. From a security-minded user's perspective, this is not a good sign. I hope that they would really put privacy & security forward, get some 3rd party security audits.
Deleted Comment
antran22 commented on Apple Fell Behind in the AI Arms Race wsj.com/tech/ai/apple-ai-... · Posted by u/fortran77
I sincerely hope that Apple don't pull a Recall move, because at that moment I'll be forced to migrate off the ecosystem (maybe I'll install Asahi Linux on my M-series machine).
So thank you, Apple, for not running in this arm race. Not every race is worth participating.
> Revocation is essentially the Achilles heel of JWTs
By the nature of the problem you have to store some kind of a list of tokens. Either a black list as with JWTs or a white list as with classic session tokens. There is no way around it. This makes both approaches practically the same.
One can argue that the black list will in general be shorter than the white list, but in a case of a serious attack, would it really be so?
I am afraid that the community will now abandon JWTs and move to biscuits, macaroons, buns and meringues as they did with classic session tokens, throwing away the tools and security practices.
In the case of a serious attack, the blacklist should be every token. You can still handle this quite nicely with JWT by rotating the previous verification key. Depends on systems and configuration, this can be as easy as changing the HMAC private key or push a new RSA key to every verifier.
I don't get why that's a reduction in attack surface?
I guess DDOS attacks - if we're checking the session ID on every request then that's a potential attack if you just make up uuids and throw them at the server.
But JWT's themselves are an attack vector, surely? If there's any mistake in the encryption (or any vulnerability in the libraries used) then this is a door open very wide indeed.
The beauty of session IDs is the simplicity of it - very few moving parts, so very few opportunities for mischief. JWTs seem to be the opposite: lots of moving parts, lots of opportunities.
JWT doesn't encrypt (by default) the payload. The header & payload is passed through base64 and appended with a hash to produce a JWT. JWT verifying doesn't require making API call, and is essentially a hash check. Any verifier with a public verification key can determine if the JWT is bogus by a quick hash check and reject the request right away.
Comparing to session IDs, you have no way to know if an unique id is bogus or not. You have to check from a list, be it a cache or a database. This limits the scalability of the solution. I'm not an expert, but AFAIK JWT verifier can be stationed on the edge of the application network, and I have not checked this but I suspect they can even make a hardware solution for those kind of activity. That's definitely a big reduction of attack surface in terms of DDOS.
IMO JWT doesn't have that many moving parts. Encryption parameters are handled by libraries according to tested standards. The only real thing you need to do is to keep your private key safe.