2FA stuff and login timeouts aside, how come a nearly 20 year old platform doesn't support multi-user/shared access to accounts by now? Seems like a lot of effort has gone into making sure nobody can say anything mean in the comments or lest the creator themselves play more than 3 seconds of Start Me Up..
This is why Tiktok is winning.
Using hardware security keys has become a definite must these days.
And don't use a phone app to replace a hardware security key. May be better than nothing, but there are security flaws all over the place with smartphones.
Now of course, the more employees you have and the greater the risk. LTT is not your average YT channel, I think they have nearly 100 employees?
Using hardware security keys has become a definite must these days.
And don't use a phone app to replace a hardware security key.
FYI, this forum supports 2FA via Google Authenticator, which is very common with crypto exchanges and the like.
For hardware keys I recommend the Yubikey
I expected it to be another silly video about enabling the file extensions, wasn't expecting that at all!
I expected it to be another silly video about enabling the file extensions, wasn't expecting that at all!
This LTR/RTL stuff was also successfully used to inject security holes in the source code that easily passes regular human review.
With C and other older languages you need to be creative, but many modern languages accept Unicode in the main language part. There are lot of Unicode tricks work and can easily pass reviews.
For code editors and review tools, display of hidden characters should be a standard feature.
That's one of many reasons for being ultra-cautious before accepting Unicode in a programming language. It's fine in string literals, but I for one am not convinced for anything else.
Of course you can always restrict Unicode support to avoid all these weird "characters", but I'm not so sure it's even possible, given the gigantic number of Unicode characters available.
And of course same should be done for file names if possible.
Anyway, "interesting" that Unicode be a potential source of security holes.
And that said, the core point with session IDs is a freaking disaster. Good thing if it makes more people aware of that.
Google is particularly bad with this actually (even if it's far from being the only one.)
Take your Google accounts - you can stay connected to them almost indefinitely. On your mobile phone, it's always connected. You enter your account password ONCE when configuring your phone, and that's it. It never asks for it ever again. In a web browser with gmail, almost the same thing. I have a tab opened with one gmail account. It stays open almost all the time, and it almost never gets disconnected on its own. Sure that's convenient for users, but that's a disaster security-wise.
I expected it to be another silly video about enabling the file extensions, wasn't expecting that at all!
me too. Totally wasn't expecting that, had no idea it was possible.
https://xkcd.com/1137/
Always scan files you receive by e-mail. Even if they look like PDF.
Gmail always does that for me, and if it detects something sus then it doesn't import it just leaves it on my server and sends me an email. It's got a built in viewer for PDF too, so I don't need to open an external PDF viewer.
https://xkcd.com/1137/
Always scan files you receive by e-mail. Even if they look like PDF.
Gmail always does that for me, and if it detects something sus then it doesn't import it just leaves it on my server and sends me an email. It's got a built in viewer for PDF too, so I don't need to open an external PDF viewer.
From the other thread, the fake pdf file was zero-padded to be 700MB. Which meant gmail did not scan it for viruses (100MB limit).
https://xkcd.com/1137/
Always scan files you receive by e-mail. Even if they look like PDF.
Gmail always does that for me, and if it detects something sus then it doesn't import it just leaves it on my server and sends me an email. It's got a built in viewer for PDF too, so I don't need to open an external PDF viewer.
From the other thread, the fake pdf file was zero-padded to be 700MB. Which meant gmail did not scan it for viruses (100MB limit).
Even if it didn't scan it, would code actually be able to exectue using the internal gmail PDF viewer?
Even if it didn't scan it, would code actually be able to exectue using the internal gmail PDF viewer?
No, it wouldn't execute using the internal PDF viewer.
But it was also zipped. Gmail won't let me read the PDF if its in a zip file. It only lets me see the file names in the zip, and then download said zip file. Maybe there is a way around it but its not obvious.
"Hey heres our sponsor package, please see terms inside: sponsor_docs.zip" something like that.