While I respect your technical prowess and make great use of your work, every time you go off like this, you move a little further down the "crackpot" scale. You know, the one anchored firmly by RMS...
Instead of blowing a gasket, why not nicely suggest that a read of the source code will show that rdrand is just one of the entropy sources used, and it is used in such a way that it cannot compromise the end result. Vitriol is no way to go through life, son.
...Most of your time is likely spent parsing the patterns.
I second that. And as your rules have built up, there are likely some that have never been used beyond when they were first put in. I'd instrument your next solution to identify outliers and cull them over time so your parser doesn't have to work so hard.
"And for keeping even the envelope info private, just run a private email service of your own (with no external mail gateway)..."
And ensure no TCP traffic to your gateway goes through any compromised Internet nodes.
Those ellipses conveniently left off the rest of the quote instructing to allow access only via VPN or SSH. Good crypto is designed to defeat MITM and eavesdropping attacks. Listening in? Fine with me; all you'll get is ciphertext. Modify even a single bit and I'll be alerted.
What percentage of you have downloaded the source code, verified the MD5 of the source code against what is reported, then compiled it yourself using compilers that you trust aren't compromised?
The authors of those programs make it easy to verify by publishing the hash along with the source and encouraging people to verify their downloads. I expect your distribution's maintainer follows those protocols when building the released version. That build is automatically signed when built and verified upon download when installing it on your system.
As for trusting your compiler, I assume you're referring to Ken Thompson's seminal Reflections on Trusting Trust (PDF). It's an interesting academic exercise, but I'm pretty sure if such a compiler were out there and in common use, someone would have noticed. Especially now that there is a published way to detect it.
Installing the distro's version is likely safe, although you must realize you're opening up your circle of trust to include the distro's maintainer and server farm instead of just the original author(s) and their source repository.
The bad part of this is, until we get NSA's unconstitutional programs back under control, simply encrypting your emails may be enough to trigger their systems to preserve it.
Encryption should be end-to-end. How can you trust someone else to do it for you?
I was thinking the same thing; Phil Zimmerman had it figured out decades ago. As long as both ends keep the snoops out of their computers, with PGP or GnuPG, all they can read is the envelope information between SMTP relays. As far as we know, anyway...
That method requires a little more technical skill than having some SaaS provider do it, but if you've got secrets to protect, that's a small price to pay. Use big keys and EC to help future-proof.
And for keeping even the envelope info private, just run a private email service of your own (with no external mail gateway), and keep the snoops off of it. Allow access only via VPN or SSH tunnels.
Better yet, since PGP/GnuPG compress content before they encode it, and they have base64 armoring, just encrypt your archive file with armoring and print that out.
However, since OCR can be finicky, I'd suggest some sort of Reed-Solomon or Hamming code for error correction on the printed file. Perhaps you could break it up into digestible chunks and make a series of QR codes out of them... in which case, you'd be better off using the non-ascii format.
Remember, the more it resembles a numbers station, the less suspicious it is...
It's a common fallacy spouted by those who foist surveillance on us. See here,here, or any other of the many hits when you search for privacy "nothing to hide"
People like you that are trading your long-term liberty and privacy for a current sense of security are going to rue this day eventually. These essential freedoms need constant vigilance. Many of our forefathers died defending them. They're rolling in their graves now seeing how so many are nonchalantly pissing them away.
Here's your homework. Go read the Constitution of the United States of America. No, really. Read it line by line and understand why some say it's the most important and influential document created in the last 1000 years.
At younger ages, pure software is not always that interesting. I'd suggest starting out with a hardware/software mix, like Arduino. Make something cheap with blinking lights that they can take home with them. Buy a few AVRs, a handful of resistors and caps, some LEDs, voltage regulators, and mini breadboards so you can make Arduino clones. If they want to keep them, sell them at cost; it's only a couple days of lunch money.
Once they've outgrown that, move their skills over to the Raspberry Pi and have them blink a LED using Java or Python. Now, they're on a cheap, fully functional (albeit a bit underpowered) Linux system. They can learn BASH, Python, C/C++, etc. by seeing and tweaking what's already there. And if they break it, you're only out $35. Or if they want to continue playing at home, they're only out $35 plus accessories.
The 10000 attempted attacks per month is the CIO's way of justifying their core firewall. Every SYN packet that hits port 22 is an attempted attack.
You see, they need big scary numbers to justify to the CFO why they need a maintenance contract on their overpriced Cisco what-cha-ma-call-it doothingy that separates their network from the wild and caa-razy internet. "10000 attempts?!? Wow! Good job, Biff. Here's your budget."
If data is sent via the Internet, the world's biggest public network, and isn't encrypted, then why should anybody need anything to read it? . . .
Encrypt your messages and then an argument can be made for 4th Amendment violations.
You're not distinguishing between data in transit and data at rest. And it's an important distinction. Using Google's mail service as an example, my gmail is encrypted in transit via SSL. Always. I use HTTPS-Everywhere plugin to ensure that.
That said, I don't know how Google stores it while it rests on their servers, but it is in that state that the government claims they have a right to inspect it without a warrant. I hope it's encrypted, but it's not under my direct control. And it sounds like government is insisting Google not only give them access but share any keys they use to encrypt the data at rest. That means, if it is encrypted on their servers, that only helps protect it from hackers and accidental disclosure, not from authorized (by Google) agents.
The solution, as you hinted at, would be to encrypt your messages with something like PGP or GnuPG before sending them (in transit) or storing them (at rest) in either your or the recipient's mailbox. That puts the encryption keys squarely under your control, and makes the stored ciphertext inaccessible to the government, but comes with its own usability and key management issues. It's not something your everyday user is going to be comfortable with.
I don't believe that should mean that the less technically adept experience less privacy, but that's just my humble opinion...
You're talking about Community Antenna Television, or CATV, which is what gave birth to the whole cable TV industry. Somewhere along the historical timeline, they made a poor concession to the broadcasters (or the broadcasters paid the right officials off), and instead of viewing CATV as a service to extend their viewership, broadcasters treated CATV as a leech to their profits and demanded fees to allow them to carry their signal. Make no bones about it. Fox is getting paid by the advertisers as well as the service that carries those ads to the eyeballs.
Now, tell me. If you were getting a deal this sweet, wouldn't you raise a huge fit to try to keep it from ending? I'm just sayin'...
FWIW, the same double-dipping game is my biggest objection to Hulu. I'm paying for specific content streams, and you're STILL going to bombard me with ads? And worse yet prevent me from fast-forwarding through them?!? No. Thank. You.
Why do you think they wouldn't be thrilled to blow up a low-yield dirty nuclear weapon over a major US city?
They might want to, but the latest reports I've seen (search google for citations) indicate they have enough fissile material for a mere handful of weapons, and their longest range missile won't yet reach the US coast.
Except for maybe Alaska, but last I knew, nobody was calling Anchorage a "major city."
j/k, Alaska.. We still love you, you gorgeous, scenic, oil-rich babe!
To me, it's all about your "expectation of privacy." At least in the USA, that's the legal standard they use to determine whether a warrantless search is permissible. If my cellphone is locked, that is a very strong indication that I expect the contents to be private. I'm glad that at least the Canadian courts agree. I just wish the US courts did as well, but they seem to be eroding individual privacy as much as they can get by with.
A btrfs style filesystem already has this problem with local storage, it just doesn't become immensely evident unless you are using media where the burst transfer rate gets swamped by the amount of data in a set of consecutive data transfers. As soon as you overwhelm the steady state average rate, the effective burst transfer rate drops to the sustained transfer.
You can see this relatively easily on Samsung and Sony ARM devices with eMMC mass storage instead of SSD, and you can see it on SSD mass storage for small values of 'mass', where the transactions can be split over many chips to effectively get a parallel bus for transfers, or on bigger SSD devices where the controller isn't clever enough to use that trick.
At which point, I'd say that btrfs is the wrong tool for the job in this environment.
What filesystem would you suggest? YAFFS?
It would seem to me that there are parallels between the write limitations of flash memory and the need to avoid latency in distributed writes to cloud providers. I'm envisioning a YAFFS filesystem built on same sized blocks that are individually encrypted (and compressed) and written to the various cloud providers. Each block could be replicated (raid1) or broken into stripes of blocks used to calculate parity (raid5).
I think the technology exists, and all the components are proven, they've just never been assembled in exactly that way before.
I wish the OP the best of luck. Even if it isn't practical in the end, it sure sounds fun..
The VPS provider notices the continuous high bandwidth you're using and cancels your account for violating their TOS long before the authorities get around to raiding them.
Out of curiosity, what made you run third party rather than trying to fix things from within?
Fix things from within what? There are some people who identify with neither conservative nor liberal speaking points. The moderate viewpoint is entirely ignored in the two-party system, except when an extremist candidate from one of the two parties is trying to court moderate votes.
Associating yourself with either party implicitly indicates to the rest of that party that you agree with at least most of their views. It's easy, then, to label a true moderate (or libertarian) vote as outside the party lines, leading those who believed the implicit ideological alignment based on party affiliation to label the voter a turncoat.
I'd love to see an alternative voting system in place that encourages votes for parties other than the big two. It will never happen, of course, while they're in control of congress...
While we're dreaming, let's get rid of gerrymandering too.
This single incident will do more than any other event in recent history in helping to reign in the DMCA. This will finally get the legislature's attention focused on this bad law and give them the incentive and public pressure to try to fix it.
My suggested solution would be a check-box when submitting media confirming that you hold copyright, and any infringement claims should be brought to you directly. If this affidavit is checked, and the user's contact information has been verified as valid, the carrier can maintain their safe harbor by forwarding the complaint instead of removing the media.
Yeah, I know that's similar to how things worked before DMCA (less the contact verification), but I also understand that congress-critters never admit they're wrong, and this looks more like a tweak to them than an outright repeal.
Slashdot Mirror
While I respect your technical prowess and make great use of your work, every time you go off like this, you move a little further down the "crackpot" scale. You know, the one anchored firmly by RMS...
Instead of blowing a gasket, why not nicely suggest that a read of the source code will show that rdrand is just one of the entropy sources used, and it is used in such a way that it cannot compromise the end result. Vitriol is no way to go through life, son.
...Most of your time is likely spent parsing the patterns.
I second that. And as your rules have built up, there are likely some that have never been used beyond when they were first put in. I'd instrument your next solution to identify outliers and cull them over time so your parser doesn't have to work so hard.
Free association is what is threatened here.
True. So if that's a concern, connect to that darkmail system via a VPN over TOR.
"And for keeping even the envelope info private, just run a private email service of your own (with no external mail gateway) ..."
And ensure no TCP traffic to your gateway goes through any compromised Internet nodes.
Those ellipses conveniently left off the rest of the quote instructing to allow access only via VPN or SSH. Good crypto is designed to defeat MITM and eavesdropping attacks. Listening in? Fine with me; all you'll get is ciphertext. Modify even a single bit and I'll be alerted.
What percentage of you have downloaded the source code, verified the MD5 of the source code against what is reported, then compiled it yourself using compilers that you trust aren't compromised?
The authors of those programs make it easy to verify by publishing the hash along with the source and encouraging people to verify their downloads. I expect your distribution's maintainer follows those protocols when building the released version. That build is automatically signed when built and verified upon download when installing it on your system.
As for trusting your compiler, I assume you're referring to Ken Thompson's seminal Reflections on Trusting Trust (PDF). It's an interesting academic exercise, but I'm pretty sure if such a compiler were out there and in common use, someone would have noticed. Especially now that there is a published way to detect it.
Installing the distro's version is likely safe, although you must realize you're opening up your circle of trust to include the distro's maintainer and server farm instead of just the original author(s) and their source repository.
The bad part of this is, until we get NSA's unconstitutional programs back under control, simply encrypting your emails may be enough to trigger their systems to preserve it.
Encryption should be end-to-end. How can you trust someone else to do it for you?
I was thinking the same thing; Phil Zimmerman had it figured out decades ago. As long as both ends keep the snoops out of their computers, with PGP or GnuPG, all they can read is the envelope information between SMTP relays. As far as we know, anyway...
That method requires a little more technical skill than having some SaaS provider do it, but if you've got secrets to protect, that's a small price to pay. Use big keys and EC to help future-proof.
And for keeping even the envelope info private, just run a private email service of your own (with no external mail gateway), and keep the snoops off of it. Allow access only via VPN or SSH tunnels.
My favorite is Cole's Law...
...aren't so amazing when you look at the track record of Russian manufacturing.
Before we Americans point too many fingers, let's not forget NASA is not immune to similar mistakes.
Better yet, since PGP/GnuPG compress content before they encode it, and they have base64 armoring, just encrypt your archive file with armoring and print that out.
However, since OCR can be finicky, I'd suggest some sort of Reed-Solomon or Hamming code for error correction on the printed file. Perhaps you could break it up into digestible chunks and make a series of QR codes out of them... in which case, you'd be better off using the non-ascii format.
Remember, the more it resembles a numbers station, the less suspicious it is...
"Passport please."
*swipe*
*clickity-clack*
*suspicious glance*
...
"Mr. Smith? Do you go by the online handle ozspeed?"
...
*Stamp* "Please follow Agent Proubb to the digital goods inspection station."
Wrong, wrong, wrong! And wrong!
It's a common fallacy spouted by those who foist surveillance on us. See here, here, or any other of the many hits when you search for privacy "nothing to hide"
It goes right along with the "privacy and security are mutually exclusive" fallacy.
People like you that are trading your long-term liberty and privacy for a current sense of security are going to rue this day eventually. These essential freedoms need constant vigilance. Many of our forefathers died defending them. They're rolling in their graves now seeing how so many are nonchalantly pissing them away.
Here's your homework. Go read the Constitution of the United States of America. No, really. Read it line by line and understand why some say it's the most important and influential document created in the last 1000 years.
"Regional production fell by 15 percent last year, putting nearly 400,000 people out of work, and that’s just a taste of what’s to come"
Ha, ha, ha! Nice one!
Agreed. Java by itself is boring.
At younger ages, pure software is not always that interesting. I'd suggest starting out with a hardware/software mix, like Arduino. Make something cheap with blinking lights that they can take home with them. Buy a few AVRs, a handful of resistors and caps, some LEDs, voltage regulators, and mini breadboards so you can make Arduino clones. If they want to keep them, sell them at cost; it's only a couple days of lunch money.
Once they've outgrown that, move their skills over to the Raspberry Pi and have them blink a LED using Java or Python. Now, they're on a cheap, fully functional (albeit a bit underpowered) Linux system. They can learn BASH, Python, C/C++, etc. by seeing and tweaking what's already there. And if they break it, you're only out $35. Or if they want to continue playing at home, they're only out $35 plus accessories.
The 10000 attempted attacks per month is the CIO's way of justifying their core firewall. Every SYN packet that hits port 22 is an attempted attack.
You see, they need big scary numbers to justify to the CFO why they need a maintenance contract on their overpriced Cisco what-cha-ma-call-it doothingy that separates their network from the wild and caa-razy internet. "10000 attempts?!? Wow! Good job, Biff. Here's your budget."
Sad. But true.
If data is sent via the Internet, the world's biggest public network, and isn't encrypted, then why should anybody need anything to read it? . . .
Encrypt your messages and then an argument can be made for 4th Amendment violations.
You're not distinguishing between data in transit and data at rest. And it's an important distinction. Using Google's mail service as an example, my gmail is encrypted in transit via SSL. Always. I use HTTPS-Everywhere plugin to ensure that.
That said, I don't know how Google stores it while it rests on their servers, but it is in that state that the government claims they have a right to inspect it without a warrant. I hope it's encrypted, but it's not under my direct control. And it sounds like government is insisting Google not only give them access but share any keys they use to encrypt the data at rest. That means, if it is encrypted on their servers, that only helps protect it from hackers and accidental disclosure, not from authorized (by Google) agents.
The solution, as you hinted at, would be to encrypt your messages with something like PGP or GnuPG before sending them (in transit) or storing them (at rest) in either your or the recipient's mailbox. That puts the encryption keys squarely under your control, and makes the stored ciphertext inaccessible to the government, but comes with its own usability and key management issues. It's not something your everyday user is going to be comfortable with.
I don't believe that should mean that the less technically adept experience less privacy, but that's just my humble opinion...
You're talking about Community Antenna Television, or CATV, which is what gave birth to the whole cable TV industry. Somewhere along the historical timeline, they made a poor concession to the broadcasters (or the broadcasters paid the right officials off), and instead of viewing CATV as a service to extend their viewership, broadcasters treated CATV as a leech to their profits and demanded fees to allow them to carry their signal. Make no bones about it. Fox is getting paid by the advertisers as well as the service that carries those ads to the eyeballs.
Now, tell me. If you were getting a deal this sweet, wouldn't you raise a huge fit to try to keep it from ending? I'm just sayin'...
FWIW, the same double-dipping game is my biggest objection to Hulu. I'm paying for specific content streams, and you're STILL going to bombard me with ads? And worse yet prevent me from fast-forwarding through them?!? No. Thank. You.
Why do you think they wouldn't be thrilled to blow up a low-yield dirty nuclear weapon over a major US city?
They might want to, but the latest reports I've seen (search google for citations) indicate they have enough fissile material for a mere handful of weapons, and their longest range missile won't yet reach the US coast.
Except for maybe Alaska, but last I knew, nobody was calling Anchorage a "major city."
j/k, Alaska.. We still love you, you gorgeous, scenic, oil-rich babe!
To me, it's all about your "expectation of privacy." At least in the USA, that's the legal standard they use to determine whether a warrantless search is permissible. If my cellphone is locked, that is a very strong indication that I expect the contents to be private. I'm glad that at least the Canadian courts agree. I just wish the US courts did as well, but they seem to be eroding individual privacy as much as they can get by with.
A btrfs style filesystem already has this problem with local storage, it just doesn't become immensely evident unless you are using media where the burst transfer rate gets swamped by the amount of data in a set of consecutive data transfers. As soon as you overwhelm the steady state average rate, the effective burst transfer rate drops to the sustained transfer.
You can see this relatively easily on Samsung and Sony ARM devices with eMMC mass storage instead of SSD, and you can see it on SSD mass storage for small values of 'mass', where the transactions can be split over many chips to effectively get a parallel bus for transfers, or on bigger SSD devices where the controller isn't clever enough to use that trick.
At which point, I'd say that btrfs is the wrong tool for the job in this environment.
What filesystem would you suggest? YAFFS?
It would seem to me that there are parallels between the write limitations of flash memory and the need to avoid latency in distributed writes to cloud providers. I'm envisioning a YAFFS filesystem built on same sized blocks that are individually encrypted (and compressed) and written to the various cloud providers. Each block could be replicated (raid1) or broken into stripes of blocks used to calculate parity (raid5).
I think the technology exists, and all the components are proven, they've just never been assembled in exactly that way before.
I wish the OP the best of luck. Even if it isn't practical in the end, it sure sounds fun..
The VPS provider notices the continuous high bandwidth you're using and cancels your account for violating their TOS long before the authorities get around to raiding them.
Out of curiosity, what made you run third party rather than trying to fix things from within?
Fix things from within what? There are some people who identify with neither conservative nor liberal speaking points. The moderate viewpoint is entirely ignored in the two-party system, except when an extremist candidate from one of the two parties is trying to court moderate votes.
Associating yourself with either party implicitly indicates to the rest of that party that you agree with at least most of their views. It's easy, then, to label a true moderate (or libertarian) vote as outside the party lines, leading those who believed the implicit ideological alignment based on party affiliation to label the voter a turncoat.
I'd love to see an alternative voting system in place that encourages votes for parties other than the big two. It will never happen, of course, while they're in control of congress...
While we're dreaming, let's get rid of gerrymandering too.
Or "Never go in against a Sicilian when death is on the line."
A-ha! A-ha-ha-ha! A-ha-ha-ha-ha-ha.... *thud*
Oh, where are my mod points when I need them...
Well played, sir. If snark was a way to measure midi-chlorians, I'd be sending you to Yoda to give him lessons.
Oops! s/reign in/rein in/
Thank you, Scripps Local News!
This single incident will do more than any other event in recent history in helping to reign in the DMCA. This will finally get the legislature's attention focused on this bad law and give them the incentive and public pressure to try to fix it.
My suggested solution would be a check-box when submitting media confirming that you hold copyright, and any infringement claims should be brought to you directly. If this affidavit is checked, and the user's contact information has been verified as valid, the carrier can maintain their safe harbor by forwarding the complaint instead of removing the media.
Yeah, I know that's similar to how things worked before DMCA (less the contact verification), but I also understand that congress-critters never admit they're wrong, and this looks more like a tweak to them than an outright repeal.