It depends on where you are. In some parts of the US, hydro and nuclear make up a very large part of grid power.
Because Nakamoto is the one who called the police and asked for them to be present?
That is completely incorrect.
No it's not. Like I said, the MITM device does the cert validation with the actual endpoint. The client does cert validation with the MITM device. The cert chain actually associated with the endpoint doesn't make it to the client unmodified, which means the client can't make any useful security decisions when validating it. All meaningful cert validation decisions are made by the MITM device.
Its your employers machine; id say he has the greater right to decide which SSL certs are and are not trusted. If you need to connect to the DoD, your employer almost certainly knows about it, and if he doesnt you should probably let him know.
The real problem was tricky to summarize in one sentence. By having the MITM do cert validation, it means you can only use one set of trusted roots for all connections on your network: the one installed on the device. This is frequently the wrong behavior, though. I have a computer here that needs to make SSL connections to DoD computers, and so I have their root cert installed as trusted. I have another computer here that doesn't need to make such connections and so doesn't have the root cert installed. If I see a connection signed by a DoD root on that machine, it will fail to validate, correctly, because it's an error. This gets uglier if you want to trust, say, a single self-signed cert or internal root cert. It's best to restrict trusting those to as few machines as possible.
I'm not even trying to get into whether an end user wants to trust things that their employer doesn't. Forget that. It's solely from the perspective of an IT staff trying to minimize the risk of computers on their network making bad SSL connections. A single set of rules at a central location is not ideal.
90% of your objections are basically that a dedicated IT team is writing the security policy (what crypto algos to use, what CAs to trust, etc) rather than you getting a say in it. Guess what: thats not your job, and the employer has every right to enforce the security policy of his choosing. It may even be a legal requirement for him to do so.
Well, it is my job, so I get a say in it regardless. But that doesn't matter.
Despite the fact that most users don't pay attention to these things, delivering bad security information to the user is still harmful. The user has a huge advantage over an automated tool, because they know what their intent was. They can notice (though probably won't) that, for example, their SSL connection to a DoD machine really should have been signed by the DoD root and not by a CA in Turkey (just for example).
That's the lesser issue, though. The problem is that it breaks the ability for software systems to improve certificate validation security. Does your software application use certificate pinning? Too bad, we're rewriting the cert chain! Does Chrome update its CA revocation list 4 weeks faster than your MITM product's vendor in response to a CA breach? Too bad, you're stuck with whatever CA list is in that product! Does your software happen to know that it should never, ever be communicating with a cert signed by a CA that uses only MD5? (My software does, because I'm buying the certs that's on the other end!) Too bad, they won't disable it in the MITM device because it would break half the Internet, and the trusted internal CA of course uses SHA1, so that validates!
It's a terrible technological hack that reduces the ability of the client to make important security decisions. If your employer wants to control how you validate certs, fine. They should control the configuration and software on the computer. If they want to monitor your SSL connections, fine. There are legitimate reasons for that. They should use an actual standard for proxying SSL connections that conveys all of the security information back to the client.
There are so many categories with huge number of bugs that I don't know if I'd go so far as to say input validation is "most" security bugs. It is, however, one giant source of bugs.
Some of them are delightfully subtle, like the one discussed above: "I didn't think a CA would just issue a cert that had a null in the string!" Hey, the data format uses length-counted strings, not C strings. Don't pretend they're also going to be C strings.
Input validation is consistently in any Top N list of security-related programming mistakes.
For now, set aside the question of whether it's acceptable to monitor your employees' encrypted traffic on your network.
Technologically, it's a terrible idea. The client software and the end user no longer have any ability to inspect the actual certificates used for an HTTPS connection. From the client's perspective, all HTTPS connections are really with the MITM device and use the same cert chain. (Well, a dynamically-generated cert for the appropriate site signed by the same trusted CA using, presumably, the same process.) The MITM device is the one doing the actual SSL cert verification, and the client has to simply trust that it's doing it correctly. Moreover, none of the information about the SSL cert used gets transmitted to the client. So, no revoking CAs that are compromised. No noticing that this connection to PayPal is using a cert mysteriously signed by Deutsche Telekom (when it should be Verisign). No using non-default root CAs (say, to connect to DoD sites). No rejecting certs that are only signed with MD5. Let's just hope the MITM device knows not to use functions like strlen() and strcmp() when dealing with certificate fields.
If you make it a static method and use an optimizing compiler, it will actually optimize away the function entirely.
Resulting in exactly what you would have gotten if you used goto.
...because they didn't expect...
Their error was having expectations about inputs they don't control.
I don't know. The people running the "bank" are the most suspicious and the easiest to identify. With the level of security most of these places seem to have, it seems almost as easy, but much lower risk, to actually just hack the places, steal a bunch of bitcoins, launder them, and sell them off slowly elsewhere.
The concept of "terms of service" has, sure, and so have a variety of claims put into ToSes, but you cannot put arbitrary claims in your ToS and expect them to actually be upheld. You can't even put arbitrary terms into negotiated, signed contracts.
Notably, they assert that they are not actually a bank and are not subject to any banking regulations. That, however, is not a matter that is up to them.
Q: Where will my bitcoins go?
A: Bitcoins deposited with flexcoin will be stored on our secure servers. They will remain in your account, and your account only, unless you authorize a transaction with them.
From the Terms of Service:
We have taken every precaution to defend your bitcoins from hackers and/or intruders. However, Flexcoin Inc is not responsible for insuring any bitcoins stored in the Flexcoin system. You are entering into this agreement with Flexcoin Inc. You agree to not hold Flexcoin Inc, or Flexcoin Inc's stakeholders, or Flexcoin Inc's shareholders liable for any lost bitcoins.
steam is always at the same temperature
Uh, no it's not. Boiling water is always at the same temperature. (Except for the effects of altitude and pressure in a sealed vessel.) Steam, as the gaseous phase of water, can get almost arbitrarily hot.
I wondered that, too. I think they're actually trying to eliminate the off-brand K-cup market, though, which is pretty big. It seems that few people that have a Keurig actually use the My K Cup accessory, so that's a tiny market to try to eliminate.
Unfortunately, even with that accessory, the coffee sucks.
Typically coffee snobs go for Italian espresso which is far stronger.
It depends on if they want espresso. There are lots of coffee-snob-approved ways of making coffee that result in dramatically different flavors. Sometimes you want a less-concentrated form of coffee. Just not one that tastes like crap, as automatic drip does.
Off the top of my head, Aeropress, French press, Chemex, single-cup pourover, and cold brewing all make excellent cups of coffee.
Just because most Americans drink automatic drip, that Keurig nonsense, or crappy Starbucks candied beverages doesn't mean that there aren't lots of us who actually know how to make good coffee. I've been to Italy; I had a lot of espresso. I'm pretty sure Italians are just drinking slightly less shitty coffee in a different style.
He would not be a legal occupant, no. However, they could enter if they witnessed a hobo breaking in, since they have very good cause to believe that there is a crime in progress.
Y'all is correct for a couple.
However, in this case, it's possessive, so should be y'all's.