« first day (3630 days earlier)      last day (1248 days later) » 

10:26 AM
@ConorMancone Where I live alcohol/ethanol not suitable for human consumption must be cut with something to make it improper to drink, to avoid taxes. In the safest case it's some traces of an extremely bitter molecule, in the less safe it's a few % of methanol, which taste similar to ethanol but is extremely toxic and renders blind in one consumption as it attacks the optical nerve first. The advantage of methanol is that is an easy to obtain byproduct of the fermentation.
Methanol poisoning is very common. Methanol is commonly added to ethanol-base fuel to make it safer to use (it burn less easily).
So: don't drink fuel.
 
@A.Hersean Same here. You can sell rubbing alcohol or cleaning alcohol here but it tastes bitter like all hell
Also funny story: Nintendo was worried about the Nintendo Switch cartridges being so small that kids would attempt to eat them. So they coat them in a chemical that is extremely bitter. And so of course, when news of this came around, everybody started to lick their Switch cartridges.
I know it certainly was the first thing I did :D
 
@MechMK1 lol, now I want to go lick mine!
Methanol seems like a bad thing to add to make it improper for drinking, because all of a sudden something that was relatively innocuous is fairly poisonous. I'd rather go the "very bitter" route, or an agent that induces vomiting.
 
I agree.
 
@ConorMancone Feel free to do so. :D
And yeah, I agree. Bitter/vomiting is definitely the way to go.
 
 
1 hour later…
11:52 AM
@ConorMancone very bitter would be the best way.
I would like cleaning agents to have something very bitter too, so small children would not drink it. some bottles are all colorful, full of flowers, and that seems like a good thing for toddlers
 
I wonder how many people actually ate tide pods
 
 
2 hours later…
1:31 PM
@MechMK1 Probably more than you'd hope for
I know most of you are familiar with this story, but it's still a good read
 
@ConorMancone There's actually at least one confirmed case
Just in case you want to see some Liquefactive Necrosis of a Caustic Esophageal Injury
Also, very relatable
 
2:16 PM
Is this off-topic or am I missing something obvious?
0
Q: Are the mobility of the nodes lead to packet dropping in MANETs?

Crystal.HFAs we all know, lots of reasons can lead to normal packet dropping in MANET networks, e.g., unstable wireless channel, overloaded nodes, and so on. I have a question about whether the mobility of the nodes can cause some packets to drop. If YES, what is the relationship between the packet droppin...

 
2:30 PM
Availability is part of the CIA triad...
 
But is this question about security in your opinion?
 
 
5 hours later…
7:28 PM
> This backdoor would allow an attacker the ability to remotely control not only the routers, but also any devices connected to that network.
 
@MechMK1 Pretty sure I don't want to see that...
 
Do I get to be slightly annoyed at the slight exaggeration "also any devices connected to that network"?
 
@FireQuacker Sounds like FUD to me. How would a backdoor in a router allow an attacker to control devices on a network without additional exploitation?
I think you get to be very annoyed
Typical news exaggeration though
 
But it's the original news source... I expected somebody who worked with the security researchers to be more technically accurate
 
Very poorly done. It talks about "backdoors" throughout, but then: "Although they are very different physically and slightly different technically, all three had almost the exact same exploit chain"
exploit chain != backdoor
Completely different concepts, and it's not a matter of semantics.
I mean, just read this sentence:
Backdoors are a means for an authorized or unauthorized person to gain access to a closed system – in this case, a router – by bypassing the standard security measures and take control, which is known as root access
Just... no... clearly written by someone who is not very familiar with these details
Yeah, more details down: this is a stupid vulnerability, not an intentional backdoor. It's crappy reporting all around
 
8:02 PM
people put backdoor, exploit, virus and everything else on the same bag...
 
They all mean hackers are going to hack you AND EVERYBODY IS GOING TO DIE
 
of course! don't you saw what hackers could do to the alien mothership of Independence Day? They wrote a virus that turned off the shields of every ship, remotely!
they could even interface with their main computer without having ever looking at it once
hackers are that amazing...
 
The aliens were probably using 1234 as the password
Interfacing technology is like the giant dragon that almost nobody thinks about
Iron Man tells JARVIS to shut the garage door while fighting monsters in mid-air -> Real technologists are like, "Wait, how did he get that to work???"
 
Iron Man tells JARVIS to tell the time while fighting monsters in mid-ar -> How the heck could voice recognition understand that?
 
There needs to be a Real Iron Man movie where JARVIS randomly turns on because it misinterprets words
Tony: "Do you really want to start this-"
JARVIS: "Hello."
 
8:53 PM
I don't think I can find a question here about "testing backups". I wonder if I should ask it myself. Basically I've always wondered what "experts" mean when they say you should test your backups.
 
It may skirt the line of on topic, but I'm not sure so you can always go for it
From my perspective "test your backups" means verifying that your backup process actually works and you can quickly restore from backups if needed
 
I personally just make backups of files, and rely on their checksums for "testing". But I'm not a company, I don't need to backup lots of machines, nor configurations, etc. And I don't need to recover from backups as quickly as possible to stay within the allowed downtime.
 
For instance, at work we license an enterprise "secret manager" and I am responsible for managing the servers and infrastructure (along with a couple other guys)
we were doing an upgrade and wanted to test it first (because it is an involved process and there aren't great roll-back options)
in doing so we discovered that the version of the software we had just upgraded to had a bug that made it impossible to restore the snapshots that the software generated itself!
Took weeks to straighten out that mess and upgrade our systems... stupid backups
The last thing you want during an upgrade is to discover that your backups don't work. Fortunately we found out while testing the upgrades. It would have been better if we had found out immediately after upgrading to the affected version because we reguarly tested our backup/restoration process
In short: things get much more complicated when you move to the "managing infrastructure for a global organization" rather than just personal backups
 
You said "verifying that your backup process actually works and you can quickly restore from backups if needed", and that's the problem. Because in theory, that's what I've been reading everywhere. But in practice, how often do you do that? And where do you restore the backups? Obviously you can't restore them for real, you probably need other machines to test the backups...
There is probably a lot of stuff that I'm missing, since I don't have experience with large infrastructures (and I don't want to have anything to do with such a mess, LOL). But I find it hard to imagine what the whole process could look like. I imagine lots of employees sitting in front of lots of machines, and a technician saying "Ehm, today we are going to test our backups..."
 
I once (2003-ish) worked on a startup that had a big (for the time) FAT32 external drive taking care of full backups of source code, and it worked for a while... until the backup file went over 2GB and the backup script compressed the file as a tarball and tried to copy it to the FAT32 drive...
six months went by, until one dev wanted a file back, and got to the backup and... there's no backup file...
 
9:55 PM
@reed Like everything, it's rarely perfect, but you test it as best as you can. In our case the goal would be to restore a production snapshot to a test cluster that is otherwise an exact duplicate, and then test out our backup/recovery process there
Of course if you get to something like AWS S3, then testing out the full backup process is literally impossible because that would literally require making duplicates of every single data center... however, I'm sure there are ways that they can and do test the process for availability zones, or accounts, or whatever, that gives them the confidence they need to know that their process is working
 
I just asked the question
 
(although that's also a bad example, because it's not like S3 has backups. Rather, it has high durability)
@ThoriumBR Don't you hate it when you only realize your backup process is broken when you need the backup?
Toy story came this close to death for that same reason...
 
Hopefully it will be accepted by the community. You know, it's hard to know... you would think that yet another question like "generate my passwords with an algorithm" would not be well received... but you are wrong, those questions keep on being asked and keep on getting votes, lol
 
Failed backup stories should be considered a subcategory of horror movies
 
10:01 PM
:) They are if you experience them yourselves
Yeah, some questions get a very surprising reception
I just down voted and VTC one about backups :)
 

« first day (3630 days earlier)      last day (1248 days later) »