Well yes, it does make people giggle, but memes are a serious form of communication now, they are used a lot, and are even used in psyops.
So, making a meme that spreads misinformation in 2023 is among the most efficient ways to do so, especially if it does so implicitly and insidiously (by establishing two nonequivalent propositions as “equivalent” in the premise, like here).
And, so, in that context, I argue that it is wrong, and I might add, harmful. It’s nothing against you personally or your “memeability”. It just reinforces the idea of a falsehood that undoes user education infosec professionals have been pushing for years.
To be Frank, who I am not (I’m Hai), I can’t tell if you’re a troll or not. Although, if you’re not, my meme is not “wrong” or spreading misinformation it contains a logical fallacy, as many jokes do. I can list jokes that contain logical fallacies upon request.
It is a great idea, but like most implementations using cryptography in new applications with novel concepts (like cryptocurrencies), it’s half assed, and people are so eager to release and use it that they forego any simulation, testing and staging of their design; so we only get to find about any shortcomings, inefficiencies, or even design mistakes, once said tech has become big and popular (and consequently, a pain to fix and patch).
If the cookie was saved in any way (maliciously or not: session hijacking, restored backup, etc), they are logged in. That’s exactly the problem, thanks for pointing it out.
If they had “logged off” (or closed the session), no amount of cookie resurrection would log them back in: the server would refuse that cookie session the same way it would refuse an expired password.
@7heo@tdawg, i only keep data from sites which i visit every day, no other, using Site Bleacher, it remove automatically cookies, local storages, IndexedDBs, service workers, cache storages, filesystems and webSQLs from all not whitelisted sites. This keeps clean the browser and HD.
Just start with closing the session, eh? Otherwise the app won’t know what session to close.
And hopefully when the session is destroyed on the server, the app also deletes the client cookie. Assuming there will never be any server bugs, so that keeping the previous SessionIDs
around on the client is “no problem”, sounds like your average “famous last words” occurrence.
expired
Fair point, I made the meme to be silly, and, yes, this is one of the many reasons why tokens in general should expire after some point in time.
Also the meme isn’t wrong, memes don’t need logic, they’re supposed to give people a giggle.
Well yes, it does make people giggle, but memes are a serious form of communication now, they are used a lot, and are even used in psyops.
So, making a meme that spreads misinformation in 2023 is among the most efficient ways to do so, especially if it does so implicitly and insidiously (by establishing two nonequivalent propositions as “equivalent” in the premise, like here).
And, so, in that context, I argue that it is wrong, and I might add, harmful. It’s nothing against you personally or your “memeability”. It just reinforces the idea of a falsehood that undoes user education infosec professionals have been pushing for years.
To be Frank, who I am not (I’m Hai), I can’t tell if you’re a troll or not. Although, if you’re not, my meme is not “wrong” or spreading misinformation it contains a logical fallacy, as many jokes do. I can list jokes that contain logical fallacies upon request.
expired
This was the funniest thing I read all day, thank you. Sorry for misunderstanding your tone.
Look at this guy over here, nerding out about the WiFi.
Jk, glad to find someone in the comments correcting the misinformation in the meme. OP is probably a hacker who likes to do session hijacking.
Not a hacker, just a silly goofball.
JWT sounds great on paper until you have to deal with logout and revocations. Might as well use standard session cookies.
It is a great idea, but like most implementations using cryptography in new applications with novel concepts (like cryptocurrencies), it’s half assed, and people are so eager to release and use it that they forego any simulation, testing and staging of their design; so we only get to find about any shortcomings, inefficiencies, or even design mistakes, once said tech has become big and popular (and consequently, a pain to fix and patch).
Fr my thoughts exactly
And what happens next time they load the site?
If the cookie was saved in any way (maliciously or not: session hijacking, restored backup, etc), they are logged in. That’s exactly the problem, thanks for pointing it out.
If they had “logged off” (or closed the session), no amount of cookie resurrection would log them back in: the server would refuse that cookie session the same way it would refuse an expired password.
What about incognito sessions?
expired
Yeah, that’s what I was curious about, the security issues you mentioned as I wasn’t clear in my understanding until now. Thanks.
@7heo @tdawg, i only keep data from sites which i visit every day, no other, using Site Bleacher, it remove automatically cookies, local storages, IndexedDBs, service workers, cache storages, filesystems and webSQLs from all not whitelisted sites. This keeps clean the browser and HD.
https://github.com/wooque/site-bleacher
Similar alternative
https://github.com/Cookie-AutoDelete/Cookie-AutoDelete
expired
Yeah you really should do both. Some session cookies can just be used as tracking cookies later.
Just start with closing the session, eh? Otherwise the app won’t know what session to close.
And hopefully when the session is destroyed on the server, the app also deletes the client cookie. Assuming there will never be any server bugs, so that keeping the previous
SessionIDsaround on the client is “no problem”, sounds like your average “famous last words” occurrence.