I didn't know that telomerase was necessary for sperm production, but in retrospect it's kind of obvious - sperm need to have their telomere clock reset so that the cells that they become have their 'division counter' reset. I did some googling, and found this
But that makes you wonder - if you did block telomerase and didn't try to repair damaged DNA, the cancer cells would either repair themselves or die. They certainly wouldn't be able to keep dividing and spreading, so surely the cancer would be less dangerous. Maybe you could have another treatment so that the cancer cells all stick together to make it easier to remove them surgically once they hit their division limit.
Is it as easy that? Would a telomerase blocker stop cancer from spreading, or can it still do it without telomerase, just a bit slower?
And it's uber cool that real (as far as I can see) scientists are talking seriously about living for thousands of years given fixes for oxidative stress, telomere shortening etc.
I wonder if the FBI is interested in scientifically impractical threats to the President on the Internet.
If not, do they have some Dr Strangelove character who decides -
GMan: Umm, and we have a threat to kill the POTUS using a half dog, half aligator hybrid and some beef. Should we subpoena the AC's IP address and make a visit. Mad Scientist: Beef can be produced simply by SLAUGHTERING lifestock, but the General Secretary^WPresident's life is safe. All my reptile/mammal chimerae died in the first trimester.
What sort of port are they connected to? If it's PS/2 then you probably get a generic PS/2 driver, because the port doesn't let you query hardware ID in a standard way.
They're not overdone like on Windows though (for example, if there's no useful action, you'll get no context menu at all, rather than a "what's this" that points to an empty documentation string, or some such bullshit). Also, unlike some Windows software, there's usually an alternative way to get the job done just in case you can't right-click.
The right windows key usually brings up a context menu in Windows. It's up the application whether a window has a context menu or not though.
I get the impression that only Eduvision can send updates to these devices. Maybe the reason they are so cheap is that they are loss leaders to get Kenyans into a vendor lock in. Could end users reflash with a new kernal for example? If it were an open system, there should be some documented protocol for updates, and a spec for the platform, and they would have mentioned it as a selling point. If it's closed, they'll keep quiet about this sort of thing, and make sure the boot rom will only load digitally signed software kernels, in which case the 'it runs Linux' line is highly disingenuous.
Plus as TFA points out, rechargeable Pocket PC's are not that practical in a village with no electrical power. Come to think of it, what happens when the batteries wear out - slim PDAs usually have Lithium Ion batteries that have a rather short life. Batteries are pretty expensive in Africa too, hence the idea of a wind up radio.
Still, it's good to see that the minister is skeptical, it's all to common for third world countries to get suckered into trend schemes that are cripplingly expensive in the long run because the politicians have been paid off by the vendor.
After the war, the directors were put on trial, and the company had it's assets siezed. Not that I'd expect anything that dramatic to happen to US companies doing business in China, but once the Chinese government changes I'd expect a few fairly devastating lawsuits from people that were forced to work for them.
If I were a shareholder, I'd definitely want them to avoid getting involved in slave labour etc.
The cigarette companies didn't offer a warranty either, and they still got sued. Hell, fast food companies might get sued even though the people buying the food should know it's bad for them, and McDonalds doesn't give you a health warranty.
If mobile phone do turn out to have health problems, companies that sold them probably would get sued on the grounds that they ignored studies like this.
Which is completely unfair in my opinion, because this study isn't conclusive on its own.
Unless it's a Bluetooth hands free kit, then you'll still get the evil radiation;-)
Can't say I believe in this stuff. The RF from a mobile phone is fairly low power, aimed away from your head, and the wrong frequency to be biologically active. Interestingly Bluetooth and WiFi are both the same frequency as a microwave oven, e.g.
But unless there is a sudden increase in cataracts/cancer/something nasty with a decent statistical link to one of these technologies, I'm not going to worry to much.
If you're a space flight or fusion geek, you might want to try and convince the government that energy self sufficiency is a National Security thing, so we should do it now regardless of the short term problems with fusion. I mean, no one did a cost benefit analysis on Desert Storm as far as I can see.
Yeah, but most corporate buyers use ancient MS operating systems, e.g. Windows 2000.
Unless these UEFI boxes still allow you boot with the old Bios, you won't be able to install this sort of thing on them, and they won't sell. And if they need to boot 5 year old MS operating systems, they'll boot any untrusted OS.
It has limitations on which parts of the disk it can boot from..
If your PC was built after around the mid 90's, the Bios has Int 13h extensions. That means you pass a 64 bit LBA to the read and write functions, which is enough for a very long time - 137GB* is 28 bits of LBA for example, so you can have drives of 2^36 times 137GB. I.e big.
The OS should test for this at install time, and write a LBA bootsector. This can read anything you can reach with a 64bit lba.
So the current interface is OK essentially forever.
Implementation wise, a Bios released after >137GB drives became available already supports at least 48 bits of the 64 bit LBA. So you should be able to handle disks of 144 petabytes without reflashing.
INT 13 may be primitive, but it's not a limiting factor, and it hasn't been since the mid 90's. Primitive software tends to be relatively easy to make bug free, and advantage that you shouldn't underestimate. It's also an open standard, unlike this UEFI. I can't see a spec on the download page.
* 2^28 is 128 Gigabytes, where a GB is 1024^3. Unfortunately hard disks manufacturers call 1000^3 a GB, so they call this a 137GB drive.
Ok, but you'd need to write a _kernel_mode_ trojan, and flash it into the device, in the code that handles the USB protocol. Most mass storage devices have the USB protocol handler in a masked rom - you can change the device ID and so on in a e2prom, but that's fixed length anyway. So you can do it with something like a CypressUSB board where you can hack the protocol, doing it on a cheap USB flash disk is likely impossible. Also, I think the size of data after an overflow will be quite small.
Notice that the device is the one to signal the end of the transfer with a short packet.
Now when the device driver on the host asks reads, it passes a length, so it should be safe. But the problem is probably that most of this happens in hardware.
E.g. imagine I'm a device driver, and I want to read 160 bytes from a usb endpoint with fifo size 64. I ask the Windows USB stack to do it, and it programs the host controller to read 160 bytes. The host controller has to split the transfer into 64 byte chunks, so it will read like this on a good device.
I'm assuming that it knows too stop a transfer if too many bytes are transferred, but it can't stop in the middle of packet, for the purposes of this example. I don't know if this is a problem with any real USB host controllers, it's just an example.
Packet 0 - 64 bytes Total=64 Packet 1 - 64 bytes Total=128 Packet 2 - 64 bytes Total=192 ( 32 bytes extra ! ) ****Host controller signals an overrun, USB stack issues a bus reset****
The fatal problem is that software only gets control after Packet 2 has been transferred, by which time the buffer has been overrun.
So, if I were designing a malicious device, I'd always send too much data. Somewhere in the USB stack there's probably a place where I'd burst a buffer - the secret in this case is to make sure your buffer has one fifo's worth of unused padding. In fact, that would be a good WHQL test - if the machine with the driver can survive a device that sends too much data. Still at least in the USB case the infrastructure is in place to handle this.
But the same applies to anything where the device controls the transfer length - e.g. bus master DMA . In general, hardware has de facto 'root acces' in this case, as it can always crash the system by writing too much. And most of the time writing drivers this is the sort of hardware bug you spend time working around, so it's not true that "USB drivers are written with very little data validation and security awareness". Security awareness comes naturally if not having it means a blue screen of death.
Also, if you read the article it seems a bit suspicious. No one has released details or told Microsoft, and yet they are already selling a product to protect people against this vulnerabilty.
I meant Encrypted FS - secure against booting into Knoppix. Data is encrypted on disk, not just locked as the post I was replying to stated.
However, EFS could be cracked in theory if you had a util that could extract the keys from the profile. I don't know if this has been done, because I don't use it and have never had to get access to encrypted files.
Syskey is designed to be _more_ secure - the idea is that you move the keys to a floppy and then lock it in a safe. In which case, you can't get the keys off the hard disk - you need the floppy to get access to the files.
But you can't use syskey to crack an encrypted box because it requires that you can log on to. You can't even reset the password with a hacker tool, because that gets hashed into the encryption key. If you reset the password, the data is essentially gone.
Mind you if you have (local|domain) admin rights and can still boot there are ways around this
So if you were admin, you could repair the machine, making sure you don't do anything that will damage the user's profile, change their password with the NT tools, which won't cause the encryption keys to get screwed and get access that way.
What caused the machines to be borked to the point of unbootability BTW. That's some hard core borking.
You plug in the device, and Windows reads the device class and id. It looks in the registry to see if it has a driver for that class and then the device id in that order. E.g. for a USB mass storage device, it will always find the default windows driver. If it doesn't, the user can provide a driver, but the user needs to have local admin rights to do it.
Now if they have local admin rights, they can install whatever they want anyway, including a root kit.
With a sane network admin, people don't have local admin rights unless they are doing something techie like developing, in which case they handle their own problems without calling the support people. And there's a firewall, so root kits will be somewhat limited in what they can do. You can also fire people with admin rights who install malicious software.
Encrypted NTFS files are encrypted with an DESX or 3DES, with the decryption key in the (encrypted) user profile.
So booting into a different OS wouldn't let you access the unencrypted files, though you could get access to the encrypted data.
Of course, since the key is stored on the hard disk somewhere, it could in principle be extracted.
There's a utility called syskey.exe in XP which can move the keys onto a floppy though. In which case the only way to get the files back without the floppy would be to crack 3DES.
Slashdot Mirror
Does that mean that energy is not conserved in a non flat spacetime in GR?
Oh, I know! We need a Goa'uld sarcophagus, isn't there one buried on P3X-928?
I didn't know that telomerase was necessary for sperm production, but in retrospect it's kind of obvious - sperm need to have their telomere clock reset so that the cells that they become have their 'division counter' reset. I did some googling, and found this
http://gslc.genetics.utah.edu/features/telomeres/
But that makes you wonder - if you did block telomerase and didn't try to repair damaged DNA, the cancer cells would either repair themselves or die. They certainly wouldn't be able to keep dividing and spreading, so surely the cancer would be less dangerous. Maybe you could have another treatment so that the cancer cells all stick together to make it easier to remove them surgically once they hit their division limit.
Is it as easy that? Would a telomerase blocker stop cancer from spreading, or can it still do it without telomerase, just a bit slower?
And it's uber cool that real (as far as I can see) scientists are talking seriously about living for thousands of years given fixes for oxidative stress, telomere shortening etc.
I wonder if the FBI is interested in scientifically impractical threats to the President on the Internet.
If not, do they have some Dr Strangelove character who decides -
GMan: Umm, and we have a threat to kill the POTUS using a half dog, half aligator hybrid and some beef. Should we subpoena the AC's IP address and make a visit.
Mad Scientist: Beef can be produced simply by SLAUGHTERING lifestock, but the General Secretary^WPresident's life is safe. All my reptile/mammal chimerae died in the first trimester.
What sort of port are they connected to? If it's PS/2 then you probably get a generic PS/2 driver, because the port doesn't let you query hardware ID in a standard way.
USB should be ok though.
Opera 8.02 doesn't pass either.
They're not overdone like on Windows though (for example, if there's no useful action, you'll get no context menu at all, rather than a "what's this" that points to an empty documentation string, or some such bullshit). Also, unlike some Windows software, there's usually an alternative way to get the job done just in case you can't right-click.
The right windows key usually brings up a context menu in Windows. It's up the application whether a window has a context menu or not though.
I get the impression that only Eduvision can send updates to these devices. Maybe the reason they are so cheap is that they are loss leaders to get Kenyans into a vendor lock in. Could end users reflash with a new kernal for example? If it were an open system, there should be some documented protocol for updates, and a spec for the platform, and they would have mentioned it as a selling point. If it's closed, they'll keep quiet about this sort of thing, and make sure the boot rom will only load digitally signed software kernels, in which case the 'it runs Linux' line is highly disingenuous.
Plus as TFA points out, rechargeable Pocket PC's are not that practical in a village with no electrical power. Come to think of it, what happens when the batteries wear out - slim PDAs usually have Lithium Ion batteries that have a rather short life. Batteries are pretty expensive in Africa too, hence the idea of a wind up radio.
Still, it's good to see that the minister is skeptical, it's all to common for third world countries to get suckered into trend schemes that are cripplingly expensive in the long run because the politicians have been paid off by the vendor.
Only about mundane stuff like office politics and the weather.
"The bus I was running for _blew_up_, and I thought bugger that for a lark"
Actually IG Farben is a good example of why you should not do business with murderous dictatorships, even if you only care about profit.
http://en.wikipedia.org/wiki/IG_Farben
After the war, the directors were put on trial, and the company had it's assets siezed. Not that I'd expect anything that dramatic to happen to US companies doing business in China, but once the Chinese government changes I'd expect a few fairly devastating lawsuits from people that were forced to work for them.
If I were a shareholder, I'd definitely want them to avoid getting involved in slave labour etc.
I know it's counter intuitive but the freckles are signal, not noise.
The cigarette companies didn't offer a warranty either, and they still got sued. Hell, fast food companies might get sued even though the people buying the food should know it's bad for them, and McDonalds doesn't give you a health warranty.
If mobile phone do turn out to have health problems, companies that sold them probably would get sued on the grounds that they ignored studies like this.
Which is completely unfair in my opinion, because this study isn't conclusive on its own.
Unless it's a Bluetooth hands free kit, then you'll still get the evil radiation ;-)
b er/002023.html
Can't say I believe in this stuff. The RF from a mobile phone is fairly low power, aimed away from your head, and the wrong frequency to be biologically active. Interestingly Bluetooth and WiFi are both the same frequency as a microwave oven, e.g.
http://lists.samba.org/archive/wireless/2002-Octo
Oh noes! Wifi and Bluetooth will cook you!
But unless there is a sudden increase in cataracts/cancer/something nasty with a decent statistical link to one of these technologies, I'm not going to worry to much.
If you have Developer Studio, that installs as a Javascript debugger.
Actually, if we have fusion reactors, you can imagine mining Lunar Helium 3 commercially -
http://www.asi.org/adb/02/09/he3-intro.html
If you're a space flight or fusion geek, you might want to try and convince the government that energy self sufficiency is a National Security thing, so we should do it now regardless of the short term problems with fusion. I mean, no one did a cost benefit analysis on Desert Storm as far as I can see.
Yeah, but most corporate buyers use ancient MS operating systems, e.g. Windows 2000.
Unless these UEFI boxes still allow you boot with the old Bios, you won't be able to install this sort of thing on them, and they won't sell. And if they need to boot 5 year old MS operating systems, they'll boot any untrusted OS.
It has limitations on which parts of the disk it can boot from..
If your PC was built after around the mid 90's, the Bios has Int 13h extensions. That means you pass a 64 bit LBA to the read and write functions, which is enough for a very long time - 137GB* is 28 bits of LBA for example, so you can have drives of 2^36 times 137GB. I.e big.
The OS should test for this at install time, and write a LBA bootsector. This can read anything you can reach with a 64bit lba.
So the current interface is OK essentially forever.
Implementation wise, a Bios released after >137GB drives became available already supports at least 48 bits of the 64 bit LBA. So you should be able to handle disks of 144 petabytes without reflashing.
INT 13 may be primitive, but it's not a limiting factor, and it hasn't been since the mid 90's. Primitive software tends to be relatively easy to make bug free, and advantage that you shouldn't underestimate. It's also an open standard, unlike this UEFI. I can't see a spec on the download page.
* 2^28 is 128 Gigabytes, where a GB is 1024^3. Unfortunately hard disks manufacturers call 1000^3 a GB, so they call this a 137GB drive.
That might not matter
Lexra trapped these, and you could write an emulator in software, but it still got sued. The case was settled out of court as far as I can see.
http://www.linux-mips.org/wiki/Lexra
Great minds think alike.
Even after I read the article, I still think the same too.
Is it reasonable for an ISP to censor webpages they don't agree with during contract negotiations?"
I'd have to go with "No"
Ok, but you'd need to write a _kernel_mode_ trojan, and flash it into the device, in the code that handles the USB protocol. Most mass storage devices have the USB protocol handler in a masked rom - you can change the device ID and so on in a e2prom, but that's fixed length anyway. So you can do it with something like a CypressUSB board where you can hack the protocol, doing it on a cheap USB flash disk is likely impossible. Also, I think the size of data after an overflow will be quite small.
o ntrol
E.g. consider
http://www.beyondlogic.org/usbnutshell/usb4.htm#C
Notice that the device is the one to signal the end of the transfer with a short packet.
Now when the device driver on the host asks reads, it passes a length, so it should be safe. But the problem is probably that most of this happens in hardware.
E.g. imagine I'm a device driver, and I want to read 160 bytes from a usb endpoint with fifo size 64. I ask the Windows USB stack to do it, and it programs the host controller to read 160 bytes. The host controller has to split the transfer into 64 byte chunks, so it will read like this on a good device.
I'm assuming that it knows too stop a transfer if too many bytes are transferred, but it can't stop in the middle of packet, for the purposes of this example. I don't know if this is a problem with any real USB host controllers, it's just an example.
Packet 0 - 64 bytes Total=64
Packet 1 - 64 bytes Total=128
Packet 2 - 32 bytes Total=160
On a bad or malicious device, this happens
Packet 0 - 64 bytes Total=64
Packet 1 - 64 bytes Total=128
Packet 2 - 64 bytes Total=192 ( 32 bytes extra ! )
****Host controller signals an overrun, USB stack issues a bus reset****
The fatal problem is that software only gets control after Packet 2 has been transferred, by which time the buffer has been overrun.
So, if I were designing a malicious device, I'd always send too much data. Somewhere in the USB stack there's probably a place where I'd burst a buffer - the secret in this case is to make sure your buffer has one fifo's worth of unused padding. In fact, that would be a good WHQL test - if the machine with the driver can survive a device that sends too much data. Still at least in the USB case the infrastructure is in place to handle this.
But the same applies to anything where the device controls the transfer length - e.g. bus master DMA . In general, hardware has de facto 'root acces' in this case, as it can always crash the system by writing too much. And most of the time writing drivers this is the sort of hardware bug you spend time working around, so it's not true that "USB drivers are written with very little data validation and security awareness". Security awareness comes naturally if not having it means a blue screen of death.
Also, if you read the article it seems a bit suspicious. No one has released details or told Microsoft, and yet they are already selling a product to protect people against this vulnerabilty.
Ah yes, RAID0. Ideal when a single Deskstar isn't unreliable enough.
Umm no that's not what I meant.
c ryption.asp r ity/Q_21446371.html
I meant Encrypted FS - secure against booting into Knoppix. Data is encrypted on disk, not just locked as the post I was replying to stated.
However, EFS could be cracked in theory if you had a util that could extract the keys from the profile. I don't know if this has been done, because I don't use it and have never had to get access to encrypted files.
Syskey is designed to be _more_ secure - the idea is that you move the keys to a floppy and then lock it in a safe. In which case, you can't get the keys off the hard disk - you need the floppy to get access to the files.
But you can't use syskey to crack an encrypted box because it requires that you can log on to. You can't even reset the password with a hacker tool, because that gets hashed into the encryption key. If you reset the password, the data is essentially gone.
Mind you if you have (local|domain) admin rights and can still boot there are ways around this
http://www.brienposey.com/kb/working_with_ntfs_en
http://www.experts-exchange.com/Security/Win_Secu
So if you were admin, you could repair the machine, making sure you don't do anything that will damage the user's profile, change their password with the NT tools, which won't cause the encryption keys to get screwed and get access that way.
What caused the machines to be borked to the point of unbootability BTW. That's some hard core borking.
Actually the USB device doesn't get root access.
Here's what happens.
You plug in the device, and Windows reads the device class and id. It looks in the registry to see if it has a driver for that class and then the device id in that order. E.g. for a USB mass storage device, it will always find the default windows driver. If it doesn't, the user can provide a driver, but the user needs to have local admin rights to do it.
Now if they have local admin rights, they can install whatever they want anyway, including a root kit.
With a sane network admin, people don't have local admin rights unless they are doing something techie like developing, in which case they handle their own problems without calling the support people. And there's a firewall, so root kits will be somewhat limited in what they can do. You can also fire people with admin rights who install malicious software.
Encrypted NTFS files are encrypted with an DESX or 3DES, with the decryption key in the (encrypted) user profile.
So booting into a different OS wouldn't let you access the unencrypted files, though you could get access to the encrypted data.
Of course, since the key is stored on the hard disk somewhere, it could in principle be extracted.
There's a utility called syskey.exe in XP which can move the keys onto a floppy though. In which case the only way to get the files back without the floppy would be to crack 3DES.