Or use Tails, a Linux distro specifically designed for paranoia. You burn it on a CD (or USB stick) and boot from it into a Linux desktop environment specially crafted for privacy and security. All internet traffic is routed through Tor (sic), so after rebooting you should be fine.
German citizen here, and one working it IT Security for almost two decades now. I have been advocating the use of strong encryption and keeping the crown jewels "in the house" to my employers and customers all the time, but managers would often not listen in order to save the odd buck on the next outsourcing deal.
By launching and funding the spy programmes the US government has willingly accepted possibly detrimental effects on the economy.
In my opinion it serves the US companies right that finally the time has come that companies and people all over the world actually start looking at whom they make business with. The USA have decided to spy on every single person on this planet - OK, but now don't complain that this hurts your economy. If US companies don't like what's happening then they should complain to your government and make them change things.
A lot of trust has been destroyed, and it will take the US economy some effort to regain it. Work hard, and maybe some day in the future I will no longer advise my customers and friends to avoid US services.
Just throw in some shell scripts and make her send SNMP traps. Then you can integrate her smoothly in your OpenNMS or Nagios monitoring system.
You will have to define your BabyMIB, of course, for which you will want your own Enterprise OID. A true geek would want to assign e. g. 1.3.6.1.4.1.x.1.n for the n-th kid to monitor. Below this OID you could just add any Trap OID you could imagine.
"Honey, Christine just threw a MyDiapersAreDirty trap! Standard escalation procedure!"
On the other hand, you could of course just use the old-fashioned look-with-your-own-eyes method that worked perfectly for the past few thousands years...
Not exactly a PC story, but back in 1989 I was asked by a customer to fit a C64 computer with static RAM. This was just after leaving high school and before joining university, so I had some spare time and was pretty adventurous.
The customer wanted to use a C64 to control an automated probe that should be used to sample water from a lake over a longer time period. The C64 was to be driven by a car battery and had to work for at least a month - obviously this was only possible by waking it up once a while and going back to sleep after taking the sample.
And, no, he did not want a micro controller solution because he knew the C64 so well...
OK, I took the job as a challenge and tried to add a battery powered SRAM module "on top" of the C64's DRAM. On system startup my additional logic would copy the complete SRAM's content to DRAM and then give control to the C64. When the system was running, all modifications were written to both SRAM and DRAM, making it possible to simply power off the system without losing any data in RAM.
The SRAM module was plugged into a zero-force socket with 27512 compatible pin-out. When the C64 was not running, it could be removed and read by e. g. an EPROM programmer. This was our way to retrieve the collected data, leaving the C64 at its place and just swapping memory once a while with a spare module.
To develop the beast I soldered a 40 PIN ribbon cable to the 6502 CPU in order to attach an oscilloscope and Logic Analyzer. Given the < 1MHz clock speed this was risky but turned out to work in my development system.
More than once I was about to give up on it and was pretty desperate, the DRAM of the C64 was refreshed by the video chip, and RAM access timing was heavily entwined between CPU and video chip. It really was an electronic mess...:-)
I was in contact with a Commodore engineer who kindly provided me with C64 schematics and some tips, but he told me what I was trying to do was impossible.
But somehow I made it, it really worked. The poor development system was turned into a spare unit for sampling data by de-soldering the ribbon cable. Both systems worked fine for more than a year, as far as I know.
I use an encrypted filesystem (BestCrypt, available from Jetico on my Linux notebook to protect sensitive data. The passphrase is queried during boot, if it is not entered, the notebook is basically a stock Linux notebook.
/tmp is on a RAM disk.
In addition I've put up restrictive packet filters (no inbound traffic) via iptables.
Now if I close the notebook, the lid switch detects this and prompts for a password next time the lid is opened. The notebook will lock up after a number of incorrect entries.
If I leave physical vicinity of the laptop I always close the lid (it has become a habit). If someone steals the notebook while I'm away, they got three tries on my password. After this they have to reboot and will find the encrypted partition unaccessible.
Slashdot Mirror
Or use Tails, a Linux distro specifically designed for paranoia. You burn it on a CD (or USB stick) and boot from it into a Linux desktop environment specially crafted for privacy and security. All internet traffic is routed through Tor (sic), so after rebooting you should be fine.
Looks very much like the three letter agencies decided it's time now to start playing hardball.
German citizen here, and one working it IT Security for almost two decades now. I have been advocating the use of strong encryption and keeping the crown jewels "in the house" to my employers and customers all the time, but managers would often not listen in order to save the odd buck on the next outsourcing deal.
By launching and funding the spy programmes the US government has willingly accepted possibly detrimental effects on the economy.
In my opinion it serves the US companies right that finally the time has come that companies and people all over the world actually start looking at whom they make business with. The USA have decided to spy on every single person on this planet - OK, but now don't complain that this hurts your economy. If US companies don't like what's happening then they should complain to your government and make them change things.
A lot of trust has been destroyed, and it will take the US economy some effort to regain it. Work hard, and maybe some day in the future I will no longer advise my customers and friends to avoid US services.
You will have to define your BabyMIB, of course, for which you will want your own Enterprise OID. A true geek would want to assign e. g. 1.3.6.1.4.1.x.1.n for the n-th kid to monitor. Below this OID you could just add any Trap OID you could imagine.
"Honey, Christine just threw a MyDiapersAreDirty trap! Standard escalation procedure!"
On the other hand, you could of course just use the old-fashioned look-with-your-own-eyes method that worked perfectly for the past few thousands years...
Perhaps I should dig out my old schematics (if I can find them in the basement) and throw them on some museum website...
The customer wanted to use a C64 to control an automated probe that should be used to sample water from a lake over a longer time period. The C64 was to be driven by a car battery and had to work for at least a month - obviously this was only possible by waking it up once a while and going back to sleep after taking the sample. And, no, he did not want a micro controller solution because he knew the C64 so well...
OK, I took the job as a challenge and tried to add a battery powered SRAM module "on top" of the C64's DRAM. On system startup my additional logic would copy the complete SRAM's content to DRAM and then give control to the C64. When the system was running, all modifications were written to both SRAM and DRAM, making it possible to simply power off the system without losing any data in RAM.
The SRAM module was plugged into a zero-force socket with 27512 compatible pin-out. When the C64 was not running, it could be removed and read by e. g. an EPROM programmer. This was our way to retrieve the collected data, leaving the C64 at its place and just swapping memory once a while with a spare module.
To develop the beast I soldered a 40 PIN ribbon cable to the 6502 CPU in order to attach an oscilloscope and Logic Analyzer. Given the < 1MHz clock speed this was risky but turned out to work in my development system.
More than once I was about to give up on it and was pretty desperate, the DRAM of the C64 was refreshed by the video chip, and RAM access timing was heavily entwined between CPU and video chip. It really was an electronic mess... :-)
I was in contact with a Commodore engineer who kindly provided me with C64 schematics and some tips, but he told me what I was trying to do was impossible.
But somehow I made it, it really worked. The poor development system was turned into a spare unit for sampling data by de-soldering the ribbon cable. Both systems worked fine for more than a year, as far as I know.
Translation: New device found. Device: Airbus A310. Do you want to start auto configuration now?
Start/Abort
I use an encrypted filesystem (BestCrypt, available from Jetico on my Linux notebook to protect sensitive data. The passphrase is queried during boot, if it is not entered, the notebook is basically a stock Linux notebook.
/tmp is on a RAM disk.
In addition I've put up restrictive packet filters (no inbound traffic) via iptables.
Now if I close the notebook, the lid switch detects this and prompts for a password next time the lid is opened. The notebook will lock up after a number of incorrect entries.
If I leave physical vicinity of the laptop I always close the lid (it has become a habit). If someone steals the notebook while I'm away, they got three tries on my password. After this they have to reboot and will find the encrypted partition unaccessible.
Works for me, and I think it's pretty secure.