The best use I ever found for the Nintendo Power Glove was jerking off, as it felt like Vader giving me a handjob. Kind of like doing it after sitting on your hand for a while, but more high tech. And best of all, that activity didn't even require turning on the console.
Until you can name all hundred thousand of the "planets" in our solar system, we won't be using your definition of planet.
Why do you insist 3rd graders should be able to recite all hundred thousand planets from memory yet refuse to do so yourself even with the Internet as your reference?
Yes this would help a lot, especially for videos though, a lot of times, I just give up and move on, or put up with finding the text in the middle and reading it with no formatting.
Linux has almost two orders of magnitude more code than systemd, and it changes all the time. Security vulnerabilities are far more likely to be in the monolithic kernel.
Yes, that is an excellent reason to add even more vulnerability vectors!
At least when it comes to the kernel and networking, I have iptables in between.
With SystemD starting the network stack before starting anything else (including iptables), I can no longer even firewall off potential exploitable services.
Too bad they didn't bother to include a functional services manager inside the systemd "service manager" that could bring up iptables before the network stack, perhaps using some dependency based system.
But I fully understand how no mere mortal can wrap their head around the concept of renaming a symlink so iptables rules are prefixed with a lower number than your network services and thus load in a plain clear obvious order.
Maybe one day computers will be able to know "10" comes before "20" without 250 megs of additional software. One can dream at least.
That shit doesn't happen to me because I run requestpolicy. When I load up site X.Y.Z and it says "Here load content from a.b.c" It....doesn't load unless I manually approve it. For all sites all the time, and google....almost NEVER gets the approval unless absolutely required.
Sure, if someone curses his mother, they shouldn't be surprised if he slugs them. However, note that if the police get involved it would be the Pope going to jail and being charged with battery, not the person who cursed his mother. You may be expected to have enough self-control not to curse like that, but you're also expected to have enough self-control not to respond to ordinary words with physical violence.
Christ almighty, this beast is a fucking monster. What's next, a shell and a userland?
According to the slashdot editors, the next thing is clearly debiand!
Apparently it is to be the systemd module which uses the Debian logo/filter on front page
After that they will install the new shutupd module, that does nothing but write "Woah slow down there cowboy, you last posted 140*10^12 minutes ago, try again later to give others a chance" to stdout - before repeatedly restarting itself for no good reason, as every proper init service boot manager network shell app should do
Often I think it comes less down to the FDA and more to the interpretation. If you are a hospital using a device that comes with a certification from a vendor saying that you have to buy their drives to maintain certification, a few hundred bucks extra isn't worth the risk of it not being a bluff.
When I was working for a hospital we had a box running an ancient version of rhel (AS 2.1 if I remember) that the vendor swore could not be upgraded or security patched because of fda certs. What did we do? We made an exception.
Which is all the more reason why system designers really should consider themselves as having a duty to care for them. The vast majority of users are not experts and any risks they expose themselves to in using the product really are things they can't be expected to understand. So products intended for non-professional markets especially; should really be designs to not expose inexpert users to risks as much as possible.
> Which means you end up with, at least, a tiny LCD screen to show the pairing code. Which means
> you need enough logic to run the LCD screen and the pairing stuff.
oooh I have been thinking about this.... I think it can be done even easier and cheaper.
Wireless keyboards generally require a wireless dongle. Put a usb port on the kb, used for emergency power obviously.... but... easy pairing. Just plug the dongle into the device, and press a button, they can do a key negotiation over their local USB connection. No LCD needed, maybe.... an LED and a button.
That should put an easy end to easy sniffing. Course if someone is coming into your house and plugging shit into the wall, maybe they can just replace your whole keyboard too.... fake the dongle and keyboard into each pairing with his device and MiTM you? or wholesale replace yours with his lookalike.... but, its certainly not casual sniffing at that point.
In the future keyboard designers should make the protocol more configurable so that on casual observation it is not so easy to determine what packets are data
Thats a very common misconception, but the fact is that is pretty exactly what they should NOT do.
Specifically that is, they should not even attempt to design their own method of securing the data. They should use fairly standard, well tested, modules produced by professional cryptographers. Full stop. These are solved problems, and there are several very well researched and well designed techniques for solving these issues.
There is always room for more such techniques but, to think that some engineer working on a keyboard is going to design one that is even as good as what we have as just....a submodule of his project is just not realistic.
Choose a solution for authentication/key negotiation....choose a cipher. Go back to designing the keyboard itself. That really is the best part.... since its a solved problem.... it really isn't a huge level of effort to fix correctly.
Plus its a keyboard...a "pairing" could be as simple as flipping a switch into pairing mode, then typing some text that shows on the screen of the device pairing with it. Its not like its some headset with only 2 buttons.
DoD are not the only people who require FIPS 140-2. I have worked at shops with various mixes of FERPA, HPAA, and PCI requirements for various parts of their operation, and I have run into it a couple of times; though I can't tell you (because I don't know) whether any of them have been strictly due to a regulatory requirement or a place where local policy simply adopted the recommendations from it.
In short, if such a device existed, it might actually end up on several companies prefered purchasing lists for their employees, or even cause other competing products to get disqualified as just the existence of one could call the others into question.
The thing is, the cipher doesn't do the job alone, once you have a good cipher, you then need good key generation/negotiation, which pretty much requires some sort of authenticated pairing step which requires user interaction to complete.
Still pretty reasonable but, everyone wants "plug and play" and thats hard to reconcile with "safer play"
I would say this is pretty close to how I look at it now. I got a cheap wireless keyboard sure....but anyone sniffing the traffic is going to be bored to tears as I don't ever type anything the least bit confidential on it. Best you are getting is a bunch of youtube URLs and a whole bunch of wwwwwwwwwwwwwaaaaaaaaaaaaaaaasssssssssssssssddddddddddddddddddddddddfff
This is why I hate large swaths of consumer products.
If the keyboard is encrypting keystrokes and sending them to the system....and a third party device sitting in the corner with no configuration involving dumping and loading keys....then the data is NOT encrypted.
If you use the same static key, or one of a few easily derivable keys, I don't care how solid the encryption alcogrythem you use is.... I do not consider it encrypted, because the use case took "strong encryption" and turned it into "weak obfuscation".
So unless there is some esoteric trick they are using to exploit the system and get their hands on a key that should otherwise be secure.... then its a disservice to the public to even call it encryption, because unless that is the case and they were genuinely compromised from a use case that should have otherwise been secure.... then all they did was use a fancy obfuscator.
There are two ways to write error-free programs; only the third one works.
