Readit NewsAlso you should know that the launch/landing window of a lunar mission does not occur everyday. And it's predetermined by orbital mechanics.
https://www.youtube.com/watch?v=2VZ3LGfSMhA
It made the rounds on HN a couple months ago: https://news.ycombinator.com/item?id=14101405
It's the only piece of fiction that has made me feel deathly ill in quite the same way Threads did.
The video is incredible. It's one of the best pieces of realistic fiction I've ever seen.
But how was it made? Who made it? And why? I counted at least 10 professional-quality actors with convincing, in-character costumes. See this timestamp: https://youtu.be/2VZ3LGfSMhA?t=1053
The uploader of the video is "Ben Marking", only 8k subscribers, and no online presence. They left a comment: http://i.imgur.com/MJVh31d.png Other than that, no one's taking credit.
So why make it? It's wonderful art, but is there anything more to it?
Whoever's behind this has also uploaded nine revisions since last year: https://www.youtube.com/channel/UCA9r2NNlWMitk1hhR7yj8SA/vid... including a Canadian and Australian version.
This kind of attacks are hard to pull off and one'll have to nail it on the first try. It would be sad for the hackers, if they failed because of a poorly made fake news video.
Practice makes perfect.
The storage space and network bandwidth is not free.
But when is the last time we see any technology successfully prevented people from being silly?
1. Overall, no net benefit. We still had to query a k/v store on every action to check that the token wasn't revoked.
2. Less secure because there's no way to make it act like an HTTP-only cookie (no access from JS).
3. No way to revoke all of one user's tokens because there is no list of those tokens. We want to limit (or be aware of) the number of active logins and let the user sign out from all locations (as you can in Gmail). If the token is only stored on the client, there's no way to do this. You could store a list of all granted tokens and only use it for these revocations, but that's yet another level of complexity. (When we dropped JWT, the diff was -1200+95 LOC because we had to handle a lot of scenarios like this.)
4. Adding tokens to client-side requests is a pain. The common example for e.g. Angular is to use an HTTP interceptor to add a header. More code, but it works... Except for img and a (anchor/link) elements where you can't add a header. So you put the token in the URL query instead, and now you're vulnerable to session leaking if a user shares a URL with someone else. And you have to manually update those embedded tokens when they expire, as many JWT folks recommend you make the expiry short.
Good riddance.
The expectation should be reduce in database io, not getting rid of it entirely.
Overall you could issue tokens with short lifespan, say 5 minutes. And having the client refreshing tokens periodically. Reading database every 5 min is certainly an improvement over reading it on every API call. You could also only check revocation table if the performed operation is security-critical or sensitive enough. I wouldn't care if the user is trying to perform a read-only operation on some public data with a revoked token that is going to expire in a few minutes anyway.
>3. No way to revoke all of one user's tokens because there is no list of those tokens
I don't see why one would not maintain such a list, since generally issuing a token requires database io anyway. Storing a token when issued is just one additional write op.
I imagine you can certainly drive people crazy with this thing. For some one who doesn't know this kind of technology's existence, it's pure magic.