Well, the police should be operating exclusively within the U.S. Anyone within the U.S. has 4th Amendment rights, regardless of whether they are a citizen, a resident, or a foreigner. While there is a foreign-intelligence exception (per court findings, not per the text of the amendment), that exception only applies when the intelligence-gathering is directed against a foreign entity reasonably believed to be located outside the US.
I'd love to see the justification someone gins up for tracking individuals that must be physically located within the US for the purposes of gathering intelligence on individuals that are required to be located outside the US.
You do know that it's possible to criticize bad things done by the US government
Sure it is. How's that working out for Assange and Snowden?
Making public a ton of classified documents is not criticism. It might be right, it might be wrong, it might be some of both, but it's not accurate to describe it as "criticism".
How's criticizing the government going for all the people who criticize their handling of Manning? For the people who are criticizing the NSA now?
I get the same thing on some browsers/devices. The color difference ends up being almost undetectable. (Then, on other browsers, it's perfectly clear.)
The holdover of calling it "metadata" is a little odd.
All metadata is, naturally, data. That's not the odd part; people should know that.
It's reasonable to call it "phone call metadata". That's what it is. That indicates that it is not the content of the calls, but it's other data about the calls. So in the context of phone calls, it's metadata, because it's not the phone call content itself. Once it's separated from that context, it's just "data".
Saying "it's just metadata" makes no sense at all, since the "meta-" part give you no information about the data's value.
I think the angle they are trying for here is suggesting that they were not confronted about editing articles about themselves because they were donors. That is implying that others who are not donors were confronted about editing articles about themselves. In other words, the donation is buying them out of the policy against editing articles about yourself.
I don't think the article actually presents any evidence to support that insinuation, but I think that's what they're aiming for.
Google, Twitter and Facebook adding SSL is useless in face of third party doctrine...
It's useful in that it forces agencies that want the data to at least request (or demand) it directly, rather than obtaining it without anyone else knowing and without oversight. It's useful in that improvements to that oversight consequently affect their access to data. It's useful in that parties that are less friendly to you than the NSA and that have no legal power against Google, Twitter, and Facebook are stymied.
The problem is that what data is "yours" is a tricky legal question.
Don't tell me it's not. It is. Certainly lots of people disagree with the current legal opinions on ownership of data and what that means for 4th-Amendment protections. That's fine. But sorting out ownership of data held by third parties is difficult, so simply pointing at the 4th Amendment is facile.
The problem is that the NSA really is looking at data about you that is held by third parties. (At least, that we know of.) Things like telephone call records and bank activity are gathered and stored by a party that is not you, but the data itself is about you. Currently, this data is not considered "yours", and thus is not protected by the 4th Amendment. If the data were instead sitting on your computer, it would be protected and would require a warrant. (This gets uglier with a service like Gmail, where the data is stored by a third party, but could very reasonably be considered "yours". Uglier still if, say, you're using AWS to host a site.) So the NSA can simply ask these third parties for the data. Law enforcement agencies can and have been doing this for a long time, but their requests are at least more targeted.
The short answer to why the NSA shouldn't be doing this, though, is that their charter stipulates that, like the military, they are only permitted to target non-Americans. It's law enforcement's job to target Americans.
In my area (upstate New York), more than 50% of electricity is made by a combination of nuclear, hydroelectric, and "other renewable". (This last is almost negligible.) The remainder is natural gas and coal, favoring natural gas.
Of course, we are one of the cleanest-electricity regions of the country. But we're not the only cleaner-electricity region. For example, parts of Tennessee get most of their electricity from hydroelectric.
Useful links: EPA eGrid NYT article on the regional dependence of electric-vehicle cleanliness
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.
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.
Slashdot Mirror
Well, the police should be operating exclusively within the U.S. Anyone within the U.S. has 4th Amendment rights, regardless of whether they are a citizen, a resident, or a foreigner. While there is a foreign-intelligence exception (per court findings, not per the text of the amendment), that exception only applies when the intelligence-gathering is directed against a foreign entity reasonably believed to be located outside the US.
I'd love to see the justification someone gins up for tracking individuals that must be physically located within the US for the purposes of gathering intelligence on individuals that are required to be located outside the US.
It's almost like you don't know that Cops has been on the air for 25 years.
You know that's a TV show, where they edit out all the interactions that are boring, right?
held in contempt of court
That's not the route they seem to usually go.
much less charged by a DA
In national-level news (i.e., in a serious or well-publicized case), a couple of weeks ago.
much less convicted
About a month ago (same caveat as above).
Sure, because they don't already do that with most-wanted lists, just less accurately.
This sound like pretty clear evidence that police think they can get away with bending the law as long as no one (except the victim) sees them.
This is the LAPD we're talking about. I think that fact was already pretty well-known.
Sure it is. How's that working out for Assange and Snowden?
Making public a ton of classified documents is not criticism. It might be right, it might be wrong, it might be some of both, but it's not accurate to describe it as "criticism".
How's criticizing the government going for all the people who criticize their handling of Manning? For the people who are criticizing the NSA now?
I get the same thing on some browsers/devices. The color difference ends up being almost undetectable. (Then, on other browsers, it's perfectly clear.)
The holdover of calling it "metadata" is a little odd.
All metadata is, naturally, data. That's not the odd part; people should know that.
It's reasonable to call it "phone call metadata". That's what it is. That indicates that it is not the content of the calls, but it's other data about the calls. So in the context of phone calls, it's metadata, because it's not the phone call content itself. Once it's separated from that context, it's just "data".
Saying "it's just metadata" makes no sense at all, since the "meta-" part give you no information about the data's value.
Only if they actually do it, and only if someone with authority ends up considering it illegal.
If you're backing up a collection of movies and music, what does it matter?
You want cheap backup and information security? This is one case where encryption is actually magic fairy dust that will solve your problem.
I think the angle they are trying for here is suggesting that they were not confronted about editing articles about themselves because they were donors. That is implying that others who are not donors were confronted about editing articles about themselves. In other words, the donation is buying them out of the policy against editing articles about yourself.
I don't think the article actually presents any evidence to support that insinuation, but I think that's what they're aiming for.
That is particularly complicated.
The third party (e.g., Verizon) does have some degree of protection.
I suppose the ugly version is that they're less motivated to protect your data than you are (or, equally, than they are to protect their own data).
You already get random audits.
TS/SCI frequently requires a polygraph. It's also pretty common for it to take a couple of tries before passing.
Google, Twitter and Facebook adding SSL is useless in face of third party doctrine...
It's useful in that it forces agencies that want the data to at least request (or demand) it directly, rather than obtaining it without anyone else knowing and without oversight. It's useful in that improvements to that oversight consequently affect their access to data. It's useful in that parties that are less friendly to you than the NSA and that have no legal power against Google, Twitter, and Facebook are stymied.
The problem is that what data is "yours" is a tricky legal question.
Don't tell me it's not. It is. Certainly lots of people disagree with the current legal opinions on ownership of data and what that means for 4th-Amendment protections. That's fine. But sorting out ownership of data held by third parties is difficult, so simply pointing at the 4th Amendment is facile.
The problem is that the NSA really is looking at data about you that is held by third parties. (At least, that we know of.) Things like telephone call records and bank activity are gathered and stored by a party that is not you, but the data itself is about you. Currently, this data is not considered "yours", and thus is not protected by the 4th Amendment. If the data were instead sitting on your computer, it would be protected and would require a warrant. (This gets uglier with a service like Gmail, where the data is stored by a third party, but could very reasonably be considered "yours". Uglier still if, say, you're using AWS to host a site.) So the NSA can simply ask these third parties for the data. Law enforcement agencies can and have been doing this for a long time, but their requests are at least more targeted.
The short answer to why the NSA shouldn't be doing this, though, is that their charter stipulates that, like the military, they are only permitted to target non-Americans. It's law enforcement's job to target Americans.
I'm not sure what you're asking.
In my area (upstate New York), more than 50% of electricity is made by a combination of nuclear, hydroelectric, and "other renewable". (This last is almost negligible.) The remainder is natural gas and coal, favoring natural gas.
Of course, we are one of the cleanest-electricity regions of the country. But we're not the only cleaner-electricity region. For example, parts of Tennessee get most of their electricity from hydroelectric.
Useful links:
EPA eGrid
NYT article on the regional dependence of electric-vehicle cleanliness
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.
Extremely.
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.