We could probably argue about the differences between "built-in" and "applied after" for a good long while, but I'm not sure we'd have fun doing it.:-)
So let me just say that you are of course correct, but there seems to be a misunderstanding about what I was trying to say.
"... it should be possible to have an encryption designed in a way that a wrong byte corrupts a single file within the container and not the entire container..."
Of course. Just encrypt each file separately. Obviously that's not very convenient, but if that's what you want an encrypted container is probably not the right solution for you.
Maybe you need to use a lot of small containers that each hold a few files, so the damage caused by container loss is never excessive. (For some value of excessive.) If you don't like truecrypt, you can probably do this pretty easily with zip and GPG.
(Keep in mind that there's probably a very sound technical reason why truecrypt containers are fragile that way. I haven't the faintest idea what in particular that reason is, but if they could eliminate that fragility without breaking something important I'd think they would have done so.)
Yep. The only thing you can reliably do with a tagging system is mark objects that are known. It does nothing to help with unknowns.
The only thing this system could do is tag legal immigrants to make sure they don't overstay their visas. But there has to be enforcement, too, so federal immigration agents have to have chip readers to determine that a given suspected immigrant's status. The reader alone is not enough; the ID has to be checked against a central database. This database system could be quite large, so it'll have to be built in a way that is very scalable.
Of course there are not enough immigration enforcers to do the job properly, so someone will propose that the readers and database access be given to law enforcement more generally.
Once that happens, the infrastructure is in place to tag anyone. At first it would be a convenience... get your driver's license implanted or something. But the system would then be in place to allow mandatory tagging to work.
While it may not be intended as a pilot project for mandatory tagging of all citizens, this proposal would effectively be a damn fine pilot project for it. Reason enough to say no, IMHO.
Losing one file to a disk crash due to a power failure is one thing, losing the entire partition is NOT. Wake me where there's some built in redundancy, and no, don't tell me to put it on a RAID as it's 2 different problems.
As I have said elsewhere in this thread, there's a natural conflict between pivacy and integrity of data. Any redundancy built-in to the encrypted contaner would weaken privacy by making cryptanalysis somewhat easier. (Possibly much easier.) If you need to bother with encryption in the first place, this is likely to be unacceptable.
If you need to preserve integrity of any data, not just encrypted data, the only viable solution is to keep multiple copies of it. Multiple copies within a single encrypted container don't do a lot of good for integrity, and again could seriously weaken the encryption's protection. Therefore whatever redundancy is required to get your desired level of data integrity needs to be applied on a level outside your encrypted container.
(Note also that multiple encrypted containers with the same data and different keys will also reduce overall security, possibly by a lot.)
RAID might be a good solution, exactly because you have two different problems. RAID allows you to keep multiple copies on multiple physical disks easily and for a reasonable expense. (Obviously you may still need offsite backups, but that's yet a third problem.) To do what you seem to want to do, you need to use encryption (such as truecrypt) to make the data private, and RAID (or backups or whatever) to preserve data integrity.
Sorry of you don't like that answer, but there is no all-in-one solution.
I think your scheme may have a data integrity problem. It seems unlikely that Alice and Bob are identical copies, so you seem doomed to some data loss in that sort of attack.
(Or maybe you're just using some unusual naming scheme for your kids.)
My first impression was that this is very clever. But the more I think about it, the more I think it probably won't have much protective benefit. The sorts of opposing forces one would need this level of deniability against can probably be counted on to do a complete clone of the drive and work only on a backup copy.
Of course, by bias is towards preservation of data. The idea of deliberately destroying valuable data gives me the willies.:-)
Truecrypt has a clever dodge for this. They offer the ability to make a hidden encrypted volume. They do this by making an encrypted volume, and filling its blank space with random data. Yet inside of that random-filled blank space is another truecrypt container, which holds deniable data. If you don't know the key, you never see anything other than random padding in that blank space. See their page on it here.
Integrity of the inner volume seems quite fragile, due to the possibility of it being overwritten through the outer volume, but aside from that it seems like a good plan.
For many years, offsite backups have been all about preservation of data integrity, not data privacy. After all, backups are not what's important... restores are what's important. If your offsite backup is encrypted and no one has the key after a disaster, your tape may as well be blank. Now we need to make sure offsite backups preserve privacy as well as integrity, and those are somewhat contradictory goals.
So encrypting offsite backups is a big step, and unless it's done right it can be seriously counterproductive. That said, it's also not that hard to do right... but it needs to be built into the company's disaster plan.
I recommend writing the disaster plan document to durable media, like a CD or a keychain drive. That media should include the keys to the backup media. (Possibly in an encrypted container like Password Safe, but of course then you need to make sure you distribute that key in a different way...) Make several copies of the disater plan media, and distribute them widely among trusted employees/officers/partners/board members. Then encrypt the backup tapes, and send them to a safe-deposit box or home with an employee who does not have a disaster plan key.
With this method, in the event of a theft you've either lost a key or a backup tape, but not both at once. Yet in the event of a disaster, if your backup tape and one key survive, you can get back in business. (Even better, but slightly dodgy legally, is to make the disaster plan media a portable hard drive containing images of all software install disks needed to get the backup restored onto a system.)
Of course, this is just one way to do it. But in order to encrypt those offsite tapes, something like this will need to be in place. If it's not, there's not much point in running backups.:-)
You may not need to bother with hardware VPN devices. There are some reasonable software solutions that can run right on the endpoint computers.
I've heard good things about Hamachi, but I haven't used it myself. I have used OpenVPN, and I love it. It's pretty simple to set up, even using certificate-based authentication and encryption. You can have everyone download and install it themselves, then you can send them configuration files.
Before you do all this, though, there's an important question to ask: Is a VPN worth the additional risks? If all the machines are in a pseudo-local network over the VPN and someone gets a worm, you could all go down together. Unless you're planning to do something which actually requires pseudo-local network access, you might be better off to make whatever you're planning to do be web-based.
"Using a laptop and a simple RFID broadcasting device, they tricked the system into letting them fill up for free."
As in so many things on slashdot, the definition of "free" matters here. In this case, it could mean 1) no one was charged for the fuel by ExxonMobil.
or 2) some other ExxonMobil customer was charged for the fuel, but the pumper was not charged.
or 3) the fuel was liberated.:-)
It seems to me that #2 is by far the most likely, which is probably what the GP poster was getting at.
As for calling it "identity theft", as the GP did, that's daft. It's just a plain run-of-the-mill theft.
My father was a community college professor in a technical subject. In his case, diesel engine service. The particular course in which this incident took place required students to tear down and rebuild a variety of fuel injectors, then hook them up to a test stand to prove they operated correctly and held under pressure, then adjust them on the stand to the proper flow rates.
One particular kid just could not tune his injector right. He could tear it down, rebuild it, and hook it up to the stand, but when it came to adjustment he just couldn't get his first injector to come into line. Adjustment was a simpe matter of turning a screw: one way for more fuel, another way for less. Eventually, my dad just stood there and watched the kid work. Eventually dad had his eureka moment that revealed the problem. Being an old-school industrial instructor, he just grabbed the guy by the wrist, pulled him away from the test stand, and pointed him at the wall clock.
"What time is it?" my dad asked.
The student tried to look at the digital watch on his wrist, but dad's wrench-hardened hand had his wrist clamped tight and covered the watch. The kid looked at the analog wall clock again, and couldn't say what time it was.
He couldn't read an analog clock. He didn't have know what was meant by "clockwise for less" and "counterclockwise for more" and had been too embarassed to ask.
A) It's not a creation myth B) Neither I nor the USGS take it any more seriously than any other myth C) It's a follow-up to a comment that is obviously a joke D) All of the above E) User ID 116316's sense of humor is down for maintenance today.
Yeah, but it sounds better than the real message: "As far as we can tell this is not very dangerous outside the crater, but volcanism is not a well-understod phenomenon. This volcano surprised and killed a lot of people 26 years ago. There might be severe and dangerous surprises ahead. If you hike up there this afternoon and get your head blown off, don't come crying to me."
Yep. Sunday May 18th, 1980. I was asleep, but my Dad rousted my brother and I out to go look when he got the news. From Southwest of Portland, the ash plume was a vertical column appearing thicker than my thumb held at arms length. It was quite a sight.
And if anyone is ever in the area, the view from the Johnston Ridge observatory is amazing.
"Northwest Indians told early explorers about the fiery Mount St. Helens. In fact, an Indian name for the mountain, Louwala-Clough, means "smoking mountain". According to one legend, the mountain was once a beautiful maiden, "Loowit". When two sons of the Great Spirit "Sahale" fell in love with her, she could not choose between them. The two braves, Wyeast and Klickitat fought over her, burying villages and forests in the process. Sahale was furious. He smote the three lovers and erected a mighty mountain peak where each fell. Because Loowit was beautiful, her mountain (Mount St. Helens) was a beautiful, symmetrical cone of dazzling white. Wyeast (Mount Hood) lifts his head in pride, but Klickitat (Mount Adams) wept to see the beautiful maiden wrapped in snow, so he bends his head as he gazes on St. Helens.
-- Excerpt from: U.S. Department of Agriculture, Gifford Pinchot National Forest "Mount St. Helens" Brochure, 1980
"Microsoft is damned if they do and damned if they don't."
As often as I hear people say "Damn it!" or "This damn computer [rant]" or something to that effect in reference to the Microsoft software they're using, it seems like they're pretty damn damned no matter what.
While he has a point (I visit particular sites from at least two different networks on a regular basis) there are a couple things he doesn't take into account.
Firstly, every DSL I have ever worked with is a peristent connection. (Why would anyone bother with an on-demand DSL?) It may not be a fixed IP, but it is a pretty darn sticky IP. It only changes when one endpoint of the DSL circuit is reset, and that generally doesn't happen much more often than monthly. If you're tracking unique IPs over the life of your site, then sure... hits from IPs assigned to DSL users will be very inflated by this effect. But if you're tracking unique IPs in the last month or so, then the inflation will be pretty minimal.
(Incidentally, the same effect will occur as users change ISPs; your unique users will move to different IP pools each time they switch. Is that worth taking into account?)
Secondly, he doesn't take into account NAT. That's obviously not a big deal when counting home users, but it is a big deal when counting anyone on a corporate network. Tere could be one or one thousand unique users behind every NATted address... if you're counting just unique IPs, there could be a serious undercount of unique users in this space.
Wouldn't it be easier to say "Unique IP hits bear only a loose relationship to unique user hits" and leave it at that? The measurement may be inflated, but it is simiarly inflated for most websites. And when comparing one site to another, that seems good enough.
In OpenBSD, the UNIX manual pages are considered authoritative. If a program or function call does not behave exactly as the manual describes, this is considered a bug. This is reflected in the development process, which does not allow any code that result in a user-visible change to be committed to the tree without an accompanying update to the documentation.
So if something in the base install does not work as documented, report it. Bug reporting instructions are here.
Go to openvpn.net. It's very straightforward to get a multiuser openvpn server up, using pre-shared keys or certificates. It's free, it's simple, it's multiplatform, and it's sufficiently secure for business purposes.
(However, if by "compatible with common network gear" you mean you need to host a VPN endpoint on a Cisco box, then OpenVPN probably won't work. If you can pass the connection through a firewall to a DMZ server, though, it should work fine.)
If you want a completely free solution, use OpenVPN hosted on an OpenBSD (or other free OS) firewall.
As I have said elsewhere, I think that Apple will probably release OSX for non-Apple PCs someday. The conditions for such a release have not yet been met, but could possibly happen before long.
After that, it's possible that Apple could open-source OSX. But they'll do it only if they decide to get out of the PC business entirely. Apple won't go straight to open source OSX without trying a broad commercial release first, and they won't go open-source unless a broad commercial release of OSX utterly fails to be profitable. Open-source OSX is the last fallback position for Apple. It would be both a generous and a vengeful move on Apple's part, and it would probably not enhance shareholder value.
(Or, to quote Open Source: The Wrath of Jobs: "To the last, I grapple with thee... From Hell's heart, I stab at thee... For hate's sake, I spit my last breath at thee.")
Apple isn't ready to blow themselves up just to make a noise. Maybe someday, but not yet.
The pebble-bed concept is relatively new (in production, anyway) and represents a big advance in reactor safety. The fuel will be contained even in the event of complete coolant failure.
While nothing involving such high temps and radioactivity can ever be called completely safe, I'd have little worry living downwind of a reactor based on this sort of design.
But the fellow in TFA is playing on his name and background to lend his message credibility. He's making an ad hominem appeal to credibility, as it were. Inasmuch as that is so, it's appropriate for others to question if his background as a Greenpeace founder is still relevant to this discussion, or if it really means as much as it tries to imply. In this case, an ad hominem riposte is a completely appropriate way to counter that part of TFA's message... other parts of TFA's message may be addressed separately.
(That said, I'm inclined to agree that careful use of nuclear power is looking like a good idea these days.)
"Samuel Adams never sawed random people's heads off because he really disliked England."
No, but President John Adams jailed or deported people he didn't like. (See "Alien and Sedition Acts") His supporters beat up various writers and publishers who spoke out against the President and his unnecessary war with France. (See the book "American Aurora.") I expect there were political murders, too, but I don't have proof offhand.
While there is most likely a difference in scale and brutality, don't give our founders a complete free ride.
Slashdot Mirror
We could probably argue about the differences between "built-in" and "applied after" for a good long while, but I'm not sure we'd have fun doing it. :-)
So let me just say that you are of course correct, but there seems to be a misunderstanding about what I was trying to say.
"... it should be possible to have an encryption designed in a way that a wrong byte corrupts a single file within the container and not the entire container..."
Of course. Just encrypt each file separately. Obviously that's not very convenient, but if that's what you want an encrypted container is probably not the right solution for you.
Maybe you need to use a lot of small containers that each hold a few files, so the damage caused by container loss is never excessive. (For some value of excessive.) If you don't like truecrypt, you can probably do this pretty easily with zip and GPG.
(Keep in mind that there's probably a very sound technical reason why truecrypt containers are fragile that way. I haven't the faintest idea what in particular that reason is, but if they could eliminate that fragility without breaking something important I'd think they would have done so.)
Yep. The only thing you can reliably do with a tagging system is mark objects that are known. It does nothing to help with unknowns.
The only thing this system could do is tag legal immigrants to make sure they don't overstay their visas. But there has to be enforcement, too, so federal immigration agents have to have chip readers to determine that a given suspected immigrant's status. The reader alone is not enough; the ID has to be checked against a central database. This database system could be quite large, so it'll have to be built in a way that is very scalable.
Of course there are not enough immigration enforcers to do the job properly, so someone will propose that the readers and database access be given to law enforcement more generally.
Once that happens, the infrastructure is in place to tag anyone. At first it would be a convenience... get your driver's license implanted or something. But the system would then be in place to allow mandatory tagging to work.
While it may not be intended as a pilot project for mandatory tagging of all citizens, this proposal would effectively be a damn fine pilot project for it. Reason enough to say no, IMHO.
Losing one file to a disk crash due to a power failure is one thing, losing the entire partition is NOT. Wake me where there's some built in redundancy, and no, don't tell me to put it on a RAID as it's 2 different problems.
As I have said elsewhere in this thread, there's a natural conflict between pivacy and integrity of data. Any redundancy built-in to the encrypted contaner would weaken privacy by making cryptanalysis somewhat easier. (Possibly much easier.) If you need to bother with encryption in the first place, this is likely to be unacceptable.
If you need to preserve integrity of any data, not just encrypted data, the only viable solution is to keep multiple copies of it. Multiple copies within a single encrypted container don't do a lot of good for integrity, and again could seriously weaken the encryption's protection. Therefore whatever redundancy is required to get your desired level of data integrity needs to be applied on a level outside your encrypted container.
(Note also that multiple encrypted containers with the same data and different keys will also reduce overall security, possibly by a lot.)
RAID might be a good solution, exactly because you have two different problems. RAID allows you to keep multiple copies on multiple physical disks easily and for a reasonable expense. (Obviously you may still need offsite backups, but that's yet a third problem.) To do what you seem to want to do, you need to use encryption (such as truecrypt) to make the data private, and RAID (or backups or whatever) to preserve data integrity.
Sorry of you don't like that answer, but there is no all-in-one solution.
I think your scheme may have a data integrity problem. It seems unlikely that Alice and Bob are identical copies, so you seem doomed to some data loss in that sort of attack.
(Or maybe you're just using some unusual naming scheme for your kids.)
My first impression was that this is very clever. But the more I think about it, the more I think it probably won't have much protective benefit. The sorts of opposing forces one would need this level of deniability against can probably be counted on to do a complete clone of the drive and work only on a backup copy.
:-)
Of course, by bias is towards preservation of data. The idea of deliberately destroying valuable data gives me the willies.
Truecrypt has a clever dodge for this. They offer the ability to make a hidden encrypted volume. They do this by making an encrypted volume, and filling its blank space with random data. Yet inside of that random-filled blank space is another truecrypt container, which holds deniable data. If you don't know the key, you never see anything other than random padding in that blank space. See their page on it here.
Integrity of the inner volume seems quite fragile, due to the possibility of it being overwritten through the outer volume, but aside from that it seems like a good plan.
For many years, offsite backups have been all about preservation of data integrity, not data privacy. After all, backups are not what's important... restores are what's important. If your offsite backup is encrypted and no one has the key after a disaster, your tape may as well be blank. Now we need to make sure offsite backups preserve privacy as well as integrity, and those are somewhat contradictory goals.
:-)
So encrypting offsite backups is a big step, and unless it's done right it can be seriously counterproductive. That said, it's also not that hard to do right... but it needs to be built into the company's disaster plan.
I recommend writing the disaster plan document to durable media, like a CD or a keychain drive. That media should include the keys to the backup media. (Possibly in an encrypted container like Password Safe, but of course then you need to make sure you distribute that key in a different way...) Make several copies of the disater plan media, and distribute them widely among trusted employees/officers/partners/board members. Then encrypt the backup tapes, and send them to a safe-deposit box or home with an employee who does not have a disaster plan key.
With this method, in the event of a theft you've either lost a key or a backup tape, but not both at once. Yet in the event of a disaster, if your backup tape and one key survive, you can get back in business. (Even better, but slightly dodgy legally, is to make the disaster plan media a portable hard drive containing images of all software install disks needed to get the backup restored onto a system.)
Of course, this is just one way to do it. But in order to encrypt those offsite tapes, something like this will need to be in place. If it's not, there's not much point in running backups.
You may not need to bother with hardware VPN devices. There are some reasonable software solutions that can run right on the endpoint computers.
I've heard good things about Hamachi, but I haven't used it myself. I have used OpenVPN, and I love it. It's pretty simple to set up, even using certificate-based authentication and encryption. You can have everyone download and install it themselves, then you can send them configuration files.
Before you do all this, though, there's an important question to ask: Is a VPN worth the additional risks? If all the machines are in a pseudo-local network over the VPN and someone gets a worm, you could all go down together. Unless you're planning to do something which actually requires pseudo-local network access, you might be better off to make whatever you're planning to do be web-based.
"Using a laptop and a simple RFID broadcasting device, they tricked the system into letting them fill up for free."
:-)
As in so many things on slashdot, the definition of "free" matters here. In this case, it could mean
1) no one was charged for the fuel by ExxonMobil.
or
2) some other ExxonMobil customer was charged for the fuel, but the pumper was not charged.
or
3) the fuel was liberated.
It seems to me that #2 is by far the most likely, which is probably what the GP poster was getting at.
As for calling it "identity theft", as the GP did, that's daft. It's just a plain run-of-the-mill theft.
My father was a community college professor in a technical subject. In his case, diesel engine service. The particular course in which this incident took place required students to tear down and rebuild a variety of fuel injectors, then hook them up to a test stand to prove they operated correctly and held under pressure, then adjust them on the stand to the proper flow rates.
One particular kid just could not tune his injector right. He could tear it down, rebuild it, and hook it up to the stand, but when it came to adjustment he just couldn't get his first injector to come into line. Adjustment was a simpe matter of turning a screw: one way for more fuel, another way for less. Eventually, my dad just stood there and watched the kid work. Eventually dad had his eureka moment that revealed the problem. Being an old-school industrial instructor, he just grabbed the guy by the wrist, pulled him away from the test stand, and pointed him at the wall clock.
"What time is it?" my dad asked.
The student tried to look at the digital watch on his wrist, but dad's wrench-hardened hand had his wrist clamped tight and covered the watch. The kid looked at the analog wall clock again, and couldn't say what time it was.
He couldn't read an analog clock. He didn't have know what was meant by "clockwise for less" and "counterclockwise for more" and had been too embarassed to ask.
Sometimes the basics really matter.
"WIndows thin clients cost MORE than desktop PCs"
Umm. The ones I bought don't. Admittedly there's still TS licensing to buy, but that costs less than what I saved in hardware. YMMV.
A) It's not a creation myth
B) Neither I nor the USGS take it any more seriously than any other myth
C) It's a follow-up to a comment that is obviously a joke
D) All of the above
E) User ID 116316's sense of humor is down for maintenance today.
Yeah, but it sounds better than the real message: "As far as we can tell this is not very dangerous outside the crater, but volcanism is not a well-understod phenomenon. This volcano surprised and killed a lot of people 26 years ago. There might be severe and dangerous surprises ahead. If you hike up there this afternoon and get your head blown off, don't come crying to me."
Yep. Sunday May 18th, 1980. I was asleep, but my Dad rousted my brother and I out to go look when he got the news. From Southwest of Portland, the ash plume was a vertical column appearing thicker than my thumb held at arms length. It was quite a sight.
And if anyone is ever in the area, the view from the Johnston Ridge observatory is amazing.
Maybe so.
"Microsoft is damned if they do and damned if they don't."
As often as I hear people say "Damn it!" or "This damn computer [rant]" or something to that effect in reference to the Microsoft software they're using, it seems like they're pretty damn damned no matter what.
While he has a point (I visit particular sites from at least two different networks on a regular basis) there are a couple things he doesn't take into account.
Firstly, every DSL I have ever worked with is a peristent connection. (Why would anyone bother with an on-demand DSL?) It may not be a fixed IP, but it is a pretty darn sticky IP. It only changes when one endpoint of the DSL circuit is reset, and that generally doesn't happen much more often than monthly. If you're tracking unique IPs over the life of your site, then sure... hits from IPs assigned to DSL users will be very inflated by this effect. But if you're tracking unique IPs in the last month or so, then the inflation will be pretty minimal.
(Incidentally, the same effect will occur as users change ISPs; your unique users will move to different IP pools each time they switch. Is that worth taking into account?)
Secondly, he doesn't take into account NAT. That's obviously not a big deal when counting home users, but it is a big deal when counting anyone on a corporate network. Tere could be one or one thousand unique users behind every NATted address... if you're counting just unique IPs, there could be a serious undercount of unique users in this space.
Wouldn't it be easier to say "Unique IP hits bear only a loose relationship to unique user hits" and leave it at that? The measurement may be inflated, but it is simiarly inflated for most websites. And when comparing one site to another, that seems good enough.
Serious question:
What constitutes a "forensic quality workspace"?
Go to openvpn.net. It's very straightforward to get a multiuser openvpn server up, using pre-shared keys or certificates. It's free, it's simple, it's multiplatform, and it's sufficiently secure for business purposes.
(However, if by "compatible with common network gear" you mean you need to host a VPN endpoint on a Cisco box, then OpenVPN probably won't work. If you can pass the connection through a firewall to a DMZ server, though, it should work fine.)
If you want a completely free solution, use OpenVPN hosted on an OpenBSD (or other free OS) firewall.
As I have said elsewhere, I think that Apple will probably release OSX for non-Apple PCs someday. The conditions for such a release have not yet been met, but could possibly happen before long.
After that, it's possible that Apple could open-source OSX. But they'll do it only if they decide to get out of the PC business entirely. Apple won't go straight to open source OSX without trying a broad commercial release first, and they won't go open-source unless a broad commercial release of OSX utterly fails to be profitable. Open-source OSX is the last fallback position for Apple. It would be both a generous and a vengeful move on Apple's part, and it would probably not enhance shareholder value.
(Or, to quote Open Source: The Wrath of Jobs: "To the last, I grapple with thee... From Hell's heart, I stab at thee... For hate's sake, I spit my last breath at thee.")
Apple isn't ready to blow themselves up just to make a noise. Maybe someday, but not yet.
The pebble-bed concept is relatively new (in production, anyway) and represents a big advance in reactor safety. The fuel will be contained even in the event of complete coolant failure.
While nothing involving such high temps and radioactivity can ever be called completely safe, I'd have little worry living downwind of a reactor based on this sort of design.
Well, that's true.
But the fellow in TFA is playing on his name and background to lend his message credibility. He's making an ad hominem appeal to credibility, as it were. Inasmuch as that is so, it's appropriate for others to question if his background as a Greenpeace founder is still relevant to this discussion, or if it really means as much as it tries to imply. In this case, an ad hominem riposte is a completely appropriate way to counter that part of TFA's message... other parts of TFA's message may be addressed separately.
(That said, I'm inclined to agree that careful use of nuclear power is looking like a good idea these days.)
"Samuel Adams never sawed random people's heads off because he really disliked England."
No, but President John Adams jailed or deported people he didn't like. (See "Alien and Sedition Acts") His supporters beat up various writers and publishers who spoke out against the President and his unnecessary war with France. (See the book "American Aurora.") I expect there were political murders, too, but I don't have proof offhand.
While there is most likely a difference in scale and brutality, don't give our founders a complete free ride.