It's a recurring problem in the IT industry. Anything that is partially secured gives users the warm fuzzy feeling that their data is protected, when it's not.
SMTP TLS does absolutely nothing for security if even one provider in the chain doesn't use it.
Check the full headers on some emails you've received from outside your ISP's domain. You'll find that they're often routed through a handful of servers. As long as any one of those server-server communications are done without TLS, your headers are vulnerable to sniffing.
You can *not* assume that every ISP in the email route is competent, energetic, and cares about security. You have to assume that at least one of them is incompetent, lazy, and doesn't give a shit about your security. Which means you have to assume the email is routed in plain text. Any competent security professional will tell you the same thing.
Note: I'm talking about the traffic between email servers, not the communications between the email client and a given email server. They're different protocols, at least historically. So while they can't sniff your browser session's HTTPS connection to the email web server, they can and do sniff the traffic that leaves or enters the email server itself.
There is also the minor fact that the server-to-server communications behind the scenes are rarely encrypted, but usually sent plain text. Using an SSL connection to your email server may give you a warm fuzzy feeling, but it does nothing to protect your email once it leaves the server.
By the way, the email headers are never encrypted. Only the body of the email is, so they can always get the "meta data" for your email message indicating who it's to/from and such, regardless of whether you encrypt your email or not.
The other reason for the black boxes is to capture email between GMail users, for example. But as soon as you email someone with an address on a different email provider, your email contents are fired out plain text over the backbones between those servers, so they can capture it using the traffic sniffing approach.
The only way your email would be safe from the sniffers is if you only emailed people on the same out-of-country ISP you're proposing, and used SSL for all your email client's connections to/from that server.
But there is no way to secure your email from sniffing between the servers other than to encrypt the contents of your email yourself.
The "back door" boxes that the NSA has installed on US services like GMail make it easier for them to collect the data, but they can do it regardless of whether a given ISP cooperates, as long as they know the IP and port of the email server the ISP is running.
What? You thought the NSA had their little black boxes installed here in Canada? Hell, no!
HTTPS only encrypts the traffic between the server and your client.
Most email traffic is transmitted in plain text between the servers connected to the pipes, not over SSL.
The way it works is this:
Set up the monitor/sniffer to watch the IPs that are running mail traffic. All you need is the IP address and the port number.
When a request comes in to connect to the mail server, enable a responder watch to capture the port that is assigned by the server for the TCP stream. You don't even need to know what the client's port is going to be.
Set up a stream sniffer to capture all traffic to/from the IP address and port that was assigned to the TCP stream.
Analyze the header data for the email traffic pattern. If it's not email, stop sniffing the stream. Of course you could opt to monitor any kind of stream, not just email traffic.
Tear down the contents of the uploaded stream being sent to the server, or downloaded from the server. As it's all based on open protocols, this is easy to do.
In theory, only keep the email header data. Again, we only have the NSA's word that they're doing this. They've got the full message contents at their system's fingertips.
The Norway data pipes probably run through the UK, as do most of the pipes in the EU. So rather than installing back doors on Norway's servers, the UK just sniffs the big data pipe traffic and captures that directly. And they give not one whit about your constitutional protections, any more than the US respects the Canadian constitution and Charter of Rights when they sniff our traffic while it passes through the big data pipes south of the border.
I don't think people are getting it yet.
Between Australia, the UK, and the US, something on the order of 90% of the global data traffic runs through the leeching backbone nodes that have sniffers attached to them. They don't need the cooperation of your local governments and ISPs to do their dirty work.
If you are emailing people who use GMail, Live, Yahoo, or a US ISP for their email provisioning, your emails to/from them are still tracked. So unless you're planning to drop all your US contacts as well, you're not helping yourself much.
Here in Canada we have a bigger issue -- all of our network pipes connect to the bigger pipes in the US. So even though we might be emailing a fellow Canadian from one Canadian ISP to another, the traffic still gets routed and sniffed through US servers.
The same is a problem for people in the EU -- the emails get routed through the pipes that are monitored by the UK's spy agency.
The NSA doesn't have to install backdoors on email servers to monitor you at all. And they *don't* typically make requests when they're spying on someone in particular -- they just sniff the traffic on the big data pipes directly.
And seeing as all those pipes run through the major partner countries like the UK, Australia, and the US itself, we're *all* fucked.
The American people should be so proud. Their government has managed to surpass China's internet monitoring through automation. Next steps: Censorship and pre-crime arrests.
It's an entertaining presentation, but I don't think it's anything nearly as insightful as the summary made it out to be.
The one thing I take away from his presentation is that old ideas are often more valuable in modern times now that we have the compute power to implement those ideas.
As a for-example, back in my university days (early-mid 1980s), there were some fascinating concepts explored for computer vision and recognition of objects against a static background. Back then it would take over 8 hours on a VAX 7/80 to identify a human by extrapolating a stick figure and paint a cross-hair on the torso. Yet nowadays we have those same concepts implemented in automatic recognition and targetting systems that do the analysis in real time, and with additional capabilities such as friend/foe identification.
No one who read about Alan Kay's work can fail to recognize where the design of the modern tablet computer really came from, despite the bleatings of patent holders that they "invented" anything of note in modern times.
So if there is one thing that I'd say students of programming should learn from this talk, it is this:
Learn from the history of computing
Whatever you think of as a novel or "new" idea has probably been conceptualized in the past, researched, and shelved because it was too expensive/complex to compute back then. Rather than spending your days coding your "new" idea and learning how not to do it through trial and error, spend a few of those days reading old research papers and theories relevant to the topic. Don't assume you're a creative genius; rather assume that some creative genius in the annals of computing history had similar ideas, but could never take them beyond the proof-of-concept phase due to limitations of the era.
In short: learn how to conceptualize and abstract your ideas instead of learning how to code them. "Teach" the machine to do the heavy lifting for you.
Another possible reason for the non-increase of accidents is that although the phone users are more dangerous, the roads are safer with less traffic on them because rush hour is over.
What you're saying is that the foundation's funding isn't run by the same people as it's charity branch. This is no surprise, as very few charitable organizations and investments are profitable, and if the foundation is to survive long-term, it has to earn revenue.
Now that's not to say that I agree with the idea of developing something like clean energy technologies while investing in oil companies, but I can understand the rationale. One could even look at it as a classic case of robbing Peter to pay Paul -- taking the oil company's own profits to develop the technology that will put them out of business.
To say they're trying to recreate a brain in a box is a bit of misnomer. They're not trying to recreate the forgetfulness, random irrelevant thoughts, and other such aspects of a human brain.
Then again, maybe those random thoughts are an important part of cognition. If one follows up on those random ideas, new concepts can be born of the misfiring synapses.
Secondary footnote: It's like going to McDonald's, spending $18 on your meal instead of $6, and having the goobermint slather on another $696 of meals for staff who weren't in your budget to begin with.
Slashdot Mirror
It's a recurring problem in the IT industry. Anything that is partially secured gives users the warm fuzzy feeling that their data is protected, when it's not.
SMTP TLS does absolutely nothing for security if even one provider in the chain doesn't use it.
Check the full headers on some emails you've received from outside your ISP's domain. You'll find that they're often routed through a handful of servers. As long as any one of those server-server communications are done without TLS, your headers are vulnerable to sniffing.
You can *not* assume that every ISP in the email route is competent, energetic, and cares about security. You have to assume that at least one of them is incompetent, lazy, and doesn't give a shit about your security. Which means you have to assume the email is routed in plain text. Any competent security professional will tell you the same thing.
Tunneling means the whole traffic stream is encrypted, not that the headers are encrypted.
Only the body of the email is encrypted if you use email encryption, not the headers.
Whether the whole traffic stream is encrypted is entirely up to the email provider and not under your control.
Typical traffic routes from Ontario to Saskatchewan route through the US. Try doing a traceroute.
Times do indeed change.
But still, you have no guarantees that server to server communications are run over TLS.
i.e. I'm not talking about the POP3 and SMTP connections that your email client can run over SSH, but the inter-email-server messaging.
Note: I'm talking about the traffic between email servers, not the communications between the email client and a given email server. They're different protocols, at least historically. So while they can't sniff your browser session's HTTPS connection to the email web server, they can and do sniff the traffic that leaves or enters the email server itself.
There is also the minor fact that the server-to-server communications behind the scenes are rarely encrypted, but usually sent plain text. Using an SSL connection to your email server may give you a warm fuzzy feeling, but it does nothing to protect your email once it leaves the server.
By the way, the email headers are never encrypted. Only the body of the email is, so they can always get the "meta data" for your email message indicating who it's to/from and such, regardless of whether you encrypt your email or not.
The other reason for the black boxes is to capture email between GMail users, for example. But as soon as you email someone with an address on a different email provider, your email contents are fired out plain text over the backbones between those servers, so they can capture it using the traffic sniffing approach.
The only way your email would be safe from the sniffers is if you only emailed people on the same out-of-country ISP you're proposing, and used SSL for all your email client's connections to/from that server.
But there is no way to secure your email from sniffing between the servers other than to encrypt the contents of your email yourself.
The "back door" boxes that the NSA has installed on US services like GMail make it easier for them to collect the data, but they can do it regardless of whether a given ISP cooperates, as long as they know the IP and port of the email server the ISP is running.
What? You thought the NSA had their little black boxes installed here in Canada? Hell, no!
HTTPS only encrypts the traffic between the server and your client.
Most email traffic is transmitted in plain text between the servers connected to the pipes, not over SSL.
The way it works is this:
The Norway data pipes probably run through the UK, as do most of the pipes in the EU. So rather than installing back doors on Norway's servers, the UK just sniffs the big data pipe traffic and captures that directly. And they give not one whit about your constitutional protections, any more than the US respects the Canadian constitution and Charter of Rights when they sniff our traffic while it passes through the big data pipes south of the border.
I don't think people are getting it yet.
Between Australia, the UK, and the US, something on the order of 90% of the global data traffic runs through the leeching backbone nodes that have sniffers attached to them. They don't need the cooperation of your local governments and ISPs to do their dirty work.
If you are emailing people who use GMail, Live, Yahoo, or a US ISP for their email provisioning, your emails to/from them are still tracked. So unless you're planning to drop all your US contacts as well, you're not helping yourself much.
Here in Canada we have a bigger issue -- all of our network pipes connect to the bigger pipes in the US. So even though we might be emailing a fellow Canadian from one Canadian ISP to another, the traffic still gets routed and sniffed through US servers.
The same is a problem for people in the EU -- the emails get routed through the pipes that are monitored by the UK's spy agency.
The NSA doesn't have to install backdoors on email servers to monitor you at all. And they *don't* typically make requests when they're spying on someone in particular -- they just sniff the traffic on the big data pipes directly.
And seeing as all those pipes run through the major partner countries like the UK, Australia, and the US itself, we're *all* fucked.
I expect a copier to copy an image of the page, not to perform an OCR scan and reprint it.
What's next? An NSA back door so the scanned text can be fired off to the US spy network?
Oops. I forgot. They already have "pre-crime" arrests: extraordinary rendition for suspected terrorists.
The American people should be so proud. Their government has managed to surpass China's internet monitoring through automation. Next steps: Censorship and pre-crime arrests.
It's an entertaining presentation, but I don't think it's anything nearly as insightful as the summary made it out to be.
The one thing I take away from his presentation is that old ideas are often more valuable in modern times now that we have the compute power to implement those ideas.
As a for-example, back in my university days (early-mid 1980s), there were some fascinating concepts explored for computer vision and recognition of objects against a static background. Back then it would take over 8 hours on a VAX 7/80 to identify a human by extrapolating a stick figure and paint a cross-hair on the torso. Yet nowadays we have those same concepts implemented in automatic recognition and targetting systems that do the analysis in real time, and with additional capabilities such as friend/foe identification.
No one who read about Alan Kay's work can fail to recognize where the design of the modern tablet computer really came from, despite the bleatings of patent holders that they "invented" anything of note in modern times.
So if there is one thing that I'd say students of programming should learn from this talk, it is this:
Learn from the history of computing
Whatever you think of as a novel or "new" idea has probably been conceptualized in the past, researched, and shelved because it was too expensive/complex to compute back then. Rather than spending your days coding your "new" idea and learning how not to do it through trial and error, spend a few of those days reading old research papers and theories relevant to the topic. Don't assume you're a creative genius; rather assume that some creative genius in the annals of computing history had similar ideas, but could never take them beyond the proof-of-concept phase due to limitations of the era.
In short: learn how to conceptualize and abstract your ideas instead of learning how to code them. "Teach" the machine to do the heavy lifting for you.
I agree as well. The world doesn't need transparency; it needs the US to freakin' STOP THE BULLSHIT.
More to the point: When have you last seen a new machine with a floppy drive?
When was the last time you saw floppies for sale at a shop?
When was the last time you dusted off a floppy you own and inserted it in your machine?
I have a floppy drive. I installed it so I could do BIOS updates 10 years ago. It's never seen a disk.
Another possible reason for the non-increase of accidents is that although the phone users are more dangerous, the roads are safer with less traffic on them because rush hour is over.
Lies, damned lies, and statistics.
What you're saying is that the foundation's funding isn't run by the same people as it's charity branch. This is no surprise, as very few charitable organizations and investments are profitable, and if the foundation is to survive long-term, it has to earn revenue.
Now that's not to say that I agree with the idea of developing something like clean energy technologies while investing in oil companies, but I can understand the rationale. One could even look at it as a classic case of robbing Peter to pay Paul -- taking the oil company's own profits to develop the technology that will put them out of business.
To say they're trying to recreate a brain in a box is a bit of misnomer. They're not trying to recreate the forgetfulness, random irrelevant thoughts, and other such aspects of a human brain.
Then again, maybe those random thoughts are an important part of cognition. If one follows up on those random ideas, new concepts can be born of the misfiring synapses.
Secondary footnote: It's like going to McDonald's, spending $18 on your meal instead of $6, and having the goobermint slather on another $696 of meals for staff who weren't in your budget to begin with.
Reboot? What's that?
I don't power down unless I'm doing security updates that require a reboot.
Oh, you must be talking WindBlows, where the first line you hear from "tech support" is "Have you rebooted the machine?"