So does Windows, though you may confuse the Win32 API if you use it. NTFS is case-preserving and the native APIs are case-sensitive. Win32 functions can use FILE_FLAG_POSIX_SEMANTICS to require case-sensitivity, and Interix (Microsoft's POSIX-on-NT environment that runs in the Subsystem for Unix Applications or SUA) does so by default. I don't know of any way to make Win32 case-sensitive by default without doing some kind of crazy hooking of the relevant APIs or installing a filter driver to enforce it.
Actually, Microsoft themselves has an API for accessing NTFS drives in a case-sensitive manner, and I'm not talking about the native NT API or even the FILE_FLAG_POSIX_SEMANTICS Win32 file API flag. All versions of NT from 3.1 (the first) to 6.2 (Win8; it was removed from 8.1) have support for a POSIX operating environment - basically a full Unix-like OS running atop the NT kernel - and for proper Unix-like-ness it is case sensitive.
Mind you, Win32 programs do tend to get confused by it all. For example, CMD's "dir" command will list both "test.txt" and "TEST.TXT" in the same directory, and even correctly note if they have different sizes or datestamps. However, the "type" command (print file contents) on *either* name (or some other-cased version of the name) will instead print the contents of one of the files - doesn't matter what you type, the OS will pick - and it will print it twice (once for each copy of the file with that name).
I've been using the Interix (name of the Unix-like operating environment that runs in the NT POSIX subsystem, as reported by the uname command) build of git for years now. I should probably stop - the repo my package manager used has died, and I haven't bothered to set up a different package manager yet so my packages are outdated - but I am, humorously enough, not vulnerable to this particular attack even with that outdated version.
I was just about to say... this is a preview. I wouldn't expect pre-release versions of the new feature to be rolled out across all platforms. We can hope that it will happen once the feature leaves beta, though.
And no navy and airforce large enough to protect it as they make their way across the pacific.
I'm imagining an attack sub commander shooting his tubes empty blowing away converted fishing boats loaded down with soldiers and then wondering what the hell to do about the rest of them. On the other hand, we have torp bombers as well, and those can just go back to bas to re-arm. As you say, it's not like North Korea has the air force or navy to protect them against a carrier group.
But yeah, South Korea is in a shitty situation. Strong economy, high-tech society, powerful allies... and within bombardment range of enough heavy artillery to basically reduce their capitol city if NK decides to let all their crazy out.
Well said. More info, for the curious: http://en.wikipedia.org/wiki/C...
A lot of people don't even realize that web browsers have the ability to generate key-pairs of which only the public portion is ever sent to a CA or anybody else. It's actually a fairly sane system. If you need to export the private key (for example, to copy it from your PC to your phone, or to back it up) then you have to do so through the web browser or through whatever keystore it uses (Windows, for example, has a built in one you can access through certmgr.msc, though Mozilla products use their own store instead of the system-wide one).
Preflight is only required for non-standard verbs or non-standard headers. If you're just requesting data (rather than trying to take some action on the server), preflight is not used.
Similarly, the highly-infectious diseases that the current generation of American parents grew up with - chicken pox, the flu, etc. - tend to have minor effects. Some people die of them every year, but the number is miniscule and most people show no sign of having ever been sick a week after the infection runs its course. Compare with things like Polio (used to kill people by paralyzing their chest so they couldn't breathe and suffocate where they lay, though more often it simply left you with misshapen and crippled limbs for life), Smallpox (scars covering your body even if you made an otherwise-full recovery), and so on. I'll bet a lot of the anti-vaccination crowd, whether they know it or not, think that even if they get infected it'll basically mean they have to stay home from school/work for a few days, maybe take some medicine. They don't ever think about things like being confined to iron lungs (not that we use those anymore, but hospitals used to have entire wards full of them)...
Slippery slope fallacy ahoy! Just because one decision is made for a sound and logical reason of communal good does *NOT* mean that other (unjustified) decisions will be made even if they are promoted on the basis of communal good. Each choice needs to be evaluated on its own merits. Just because some idiots or fraudsters will try to claim that something unwise should be "done for the greater good" doesn't mean doing things for the greater good is invalid as a reason to do things, and the reverse is also true.
Incidentally, did you know that the government is already empowered to arrest you for spreading infectious diseases. If you knowingly infect other people, or if there's an outbreak and you attempt to violate it, you can be prosecuted as a criminal.
Mind you, if you want to withdraw from society and go live in your own little 21st-century equivalent of a leper colony with all the other plague vectors, be my guest. You won't get many visitors - nobody can be 10% sure a vaccine will protect them, so we are all potentially dependent on herd immunity - but you are sure as hell not welcome to freeload on our herd immunity without a valid medical reason!
Your driver's license (or other ID card) seems like one option. If you get found with the "unvaccinated" sticker on your card (sort of like the "organ donor" sticker, but for people who want to endanger others rather than save them) in a public place and aren't masked or whatever, it's a fine. Or maybe you just get thrown out of the establishment. Have fun going to bars (or buying alcohol at a store), or doing much of anything else that requires ID.
This *sounds* awful - a government-mandated mark of belonging to an unpopular minority - but it's a self-selected minority that puts all the rest of us at risk. I see no reason that people intentionally acting as potential plague carriers should be able to hide among the general populace. Maybe if they had to show their true colors they could get through their thick skulls just how horrible what they're doing is...
Boosting the signal, for those who don't read ACs:
Well, you can pre-pin a cert (Google does this with their own properties, for example, and as of Firefox 32, Firefox does it for Mozilla stuff and I think some Google stuff). You can also always manually check a certificate's fingerprint before you send any data over it. That leaves the question of what you check it against, of course, but that's the whole key distribution problem; at some level you have to have a trusted source of key identity.
I really do wish there was more support for TOFU (Trust On First Use) in browsers today, though. For example, I *can* explicitly trust a self-signed certificate for example.com. However, if I later get a different cert for example.com, my browser will simply evaluate it the way it would evaluate any cert (for example, if it's signed by a Chinese government-controlled CA, the browser will trust it unless I've removed trust for that CA). None of the major browsers will stop and say "Hey, that is *NOT* the cert I expect for this site!" the way SSH (or Remote Desktop, for that matter, which also uses TOFU) will. This greatly irks me. Certificates don't change that often, and most of the time it's just an update to the expiration date or adding a new subdomain or something else innocuous like that. Even a change to the public key isn't that big a concern, especially if the old key is revoked; people rotate keys sometimes as a matter of good practice. But a change to the CA, or a change to a pinned leaf node (where I basically said "this shouldn't change"), ought to raise warning flags.
Um... I hate to rain on your Mozilla parade here, but Chrome has full certificate pinning for Google properties, and has had it for quite a few versions now. Using any unexpected cert, no matter how trusted, for a Google property (or the handful of others that Chrome supports) will be detected and blocked. Mozilla has certificate pinning now as well, but only since version 32 (which is what, a month ago?). If the organization in question wanted to MitM Firefox's traffic as well as Chrome's, they would (until recently) have found it much easier to do on Firefox than on Chrome.
Sigh... I can't tell if you're arguing this because you don't understand the English language, of if you're just trolling.
If somebody has to "be presenting their own" certificate, then they are NOT PASSIVE!! A passive network attacker is, for example, somebody sitting at a coffee shop with the WiFi card in promiscuous mode, watching all the traffic that gets sent over that (open) network. In that position, the attacker cannot do a damn thing about a self-signed cert. Now, if they are able to use ARP spoofing or DNS hijacking or can configure the router's upstream host or something like that, then they can intercept traffic and present their own certificate, sure. That requires an *active* attack, though.
The reason that passive attacks are so concerning right now is that it's pretty trivial for ISPs and governments to record all network traffic that they want to. It just costs money for storage and storage bandwidth. However, they aren't actively intercepting that traffic, just passively recording it for later data mining. TLS, even using anonymous Diffie-Hellman or a self-signed certificate, is sufficient to completely defeat that kind of monitoring.
You're basically arguing that since an armored car can't tae a hit from the cannon of a main battle tank, there's no point in armoring them at all and it would be better for them to go unarmored so as not to lure people into a false sense of security. Turns out that's bullshit: the typical threat to people moving valuables is from small arms (which an armored car can shrug off just fine), and the typical threat to browser privacy is from pervasive passive monitoring, which self-signed certs defeat. Not that I would ever argue that it's better to have a self-signed cert than a CA-signed one, but it's not as *much* worse as you seem to think.
Besides, there's things you can do to make a self-signed cert even more secure. For example, you (the user) can add *just that cert* to your trust store. Now, if an attacker tries to substitute their *own* self-signed cert, your browser should object, or at least won't show the site as truly secured. For applications (including a few browsers) that support certificate pinning, this can also be used with self-signed certs in a trust-on-first-use basis (take a look at, for example, HTTP Public Key Pinning).