A) Active development and support? Same for Tk: Ever been on comp.lang.tcl or http://wiki.tcl.tk give it a try. There are too many people to count there, most of them very helpful. Plenty of active developers both using *and* creating the language and Tk.
B) What's wrong with extern "C" {}? Or just use a (god forbid) Tcl script to build the UI with a few lines? Forgive my ignorance, but there are dozens of Tk bindings to other languages than Tcl, how many does wxWindows have?
C) Ah, yes, the looks. That is a bit of a sore point, yes. On windows it usually looks just like windows, though and on unix you just copy paste about 100 LOC to make it look more modern. Mind you, the way Tk works, you only need to copy-paste, no need to edit.
Re:Beta will expire on 6th Dec. 2002
on
PGP 8.0 Beta Released
·
· Score: 2, Informative
Yes: MAKE A BACKUP OF YOUR KEYS! This beta version does not have 'special encryption thingies so you cannot use it with any other version'. That would be quite pointless because they make a lot of effort making it interoperate with other PGP versions.
I am just curious, but have you *ever* sent encrypted mail? On a regular basis?
Not quite. If you just make backups of your keys, uninstall the beta and install another PGP version, even 7.0 freeware will do, you can go on using your data, keys rings and everything else. It is just the beta program will not work anymore. If you forgot to backup your keys, just turn back your clock a bit and it will work again.
Just to put a couple of items straight, after the Beta expires, your data WILL NOT BE LOST. That is, if you do what you should do and backup your keys. It is only the beta program that will not work anymore. PGP keys can be freely interchanged between versions, heck, even accross platforms if you are a bit careful.
That is precisely what is meant by 'plan accordingly', it could have been worded more carefully though. This beta in not meant for the people who are freaking out in this discussion and say 'watch out, it's a lock in', 'they are trying to screw you!'. As with any beta, people experienced with the product are the prefered beta testers, and they have received the beta, which incidentally has been out since last Thursday, pretty well. There were some glitches upgrading from previous versions, but by what I hear it's pretty good.
For those still interested, I recommend you grab copy and pound on it. After the beta expires you can decide to buy it if you like it or move your keys over to GnuPG and still have access to all your data and friends.
According to this publication:
Why the Copyright Directive is Unimportant, and Possibly Invalid, dated 2000-something, the directive is not a clear (surpise, surprise) directive *at all*. It basically fails to do what they intended it to do: harmonize copyright law (which is basically a good thing).
I like the final statement he makes:
The European Court's decision raises the intriguing prospect of one or more disgruntled Member States challenging the validity of the Copyright Directive. Wouldn't that be the perfect way of getting rid of this monstrosity? I hereby offer my services to any Member State pro bono.
I would love to take him up on that, except I'm not a member state, just a citizen.
Yes, and ping times aren't the most important factor. Admittedly the Medical Faculty might not be the most important bandwidth-hog, but I recall that they're always talking about 'remote medicine'. Well, here I am sitting on my SURFNet connection, @10Mbps to my desktop, from a 100Mbit switch (GBit backplane), with a 38MBit link to the main Rotterdam SURFNet connection.
Not that I ever have speed problems here, but still, I bit more spreading of the bandwidth might be nice. They're upgrading the network here, so I should have 100Mbps to my desktop soon, with cables rated at 1Gbit.
Well, not a lot of people/companies anyway.
Half the time I try to download an application/plugin I get the message 'this code was not signed'. This happens so often that the average user will simply click 'run anyway'.
This will only affect companies that have actually taken the time to set the system security policy to 'never run unsigned software'. Which nobody on this planet has done, because all the really useful software has not been signed. *sigh*
Code signing is rather useless anyway, it's a good concept. However, the certificate issuers only certify that a company writes software (which you knew anyway, you just downloaded a piece of their work), they do *explicitly* not certify 'this is software written by a company that will not copy all files from your harddrive and publish them on IRC'.
In it's current implementation it makes software somewhat tamper proof. Which is nice...
The point of the discovery is that you can send a message, possibly without revealing your exact location. This is not cryptography. There is probably not a lot of (public) research on this subject - it may be very possible to locate a ship regardless. If it is hard to locate a sender this way, the interesting thing seems to be the distance over which this works.
Even if distances don't go much beyond 10 kilometers, you can still create a buouy that a sub launches, and uses as a message relay. Or launch a few while enroute and leave a relay network behind.
Now, if and when this becomes a real world application *nobody* will be sending uncompressed, non-encrypted information over the link. The regular public and symmetric cryptography has a very calculatable 'risk' of decryption in it.
Btw, Like so many others said: the Internet idea is totally bonkers. That won't work.
This gives you hardly any security at all. Your message is NOT encrypting by anything but 'their' key. And I doubt that the emails are encrypted at all on their servers. Besides, yahoo could encrypt them with their public key, if they wanted to.
This scheme is very good for protecting your mails from coworkers scanning tools - as would POP over SSL. On the other hand, almost every mail sent to that server is bound to be 'interesting'. If you don't encrypt by default, to the recipient, you'll only be sending sensitive information that way.
A good first step towards protecting emails around the world would be SMTP delivery through SSL (or SSH or IPSec or...), that way intermediate hosts cannot sniff effectively anymore. The next good thing would be SSL connections to POP/IMAP services.
That would definitely annoy most government listening services. The only Bad-Thing about SSL is the server certificates, which everybody whould then need to have. If we drop server authentication, we run the risk of man-in-middle attacks by governments. Which would be very costly indeed, because of the CPUs needed to do that.
I've seen some comments on working in the boss' time on OS projects, I don't think that's what this agreement is for. It covers that, yes 'you can work on an open source project similar to a project you work on for your business.' This clearly is useful.
My company, like any other likes it's intelectual property and would not want it be thrown out on the street. But when I asked my boss's position on me working on similar projects (which I don't do at the moment) in an Open Source environment, his reaction to this was that it would probably be useful for my personal skills and insights. "go right ahead" is what he said.
Now, this maybe because I work for a small company, I dunno.
Well, five actually. And they're all payed. You actually get, on average, 8% of your annual salary extra every may (or when you leave).
I now have 25 days for vacationing. They won't let me go for five weeks on end, three weeks max. And maybe in my next round of negotiations I'll barter for 30 days.
Things are a bit different here in the Netherlands. We all have very good health care (people still whine, of course). We don't earn as much as you guys do, mostly due to taxation. A lot of people see this as bad, but we have quite a few benefits that other countries don't have.
My company pays half of my lunch, they would pay it all if the IRS would allow it. We have free cola/fanta/whatever. Stock options are a bit hard for a pre-IPO company.
So your answer might be come work in the Netherlands.
Blatant plug Seriously, any one who wants to work for us should contact me at p.scheffers@bhold.net we're small and have a lot of fun with watching DVDs on big screens (boy those video-beamers are *great*)
Although the absence of a good set of crypto is bad to begin with, the designers made matters worse still by using a PIN code system. To establish an adhoc connection, you can use PIN codes on both sides to establish a new link. This will probably work fine if you are connecting two PDAs with each other, and neither of those devices will normaly accept new connections.
However, this will probably be RARE, to say the least. A lot of devices, like the Blue Tooth ear phone/mic for your mobile will have a hard to modify (from a user point of view) fixed pin.
By default a lot of devices will be shipped with pin codes of 0000 or 1234 or whatever. Most users will not change that PIN, or when they do choose something like 1111...
In an automated world, 10000 tries (5000 on average) is not much. It won't take long before someone writes a Palm-Blue Tooth scanner.
Even if some people are a bit more sensible and change their PINs to 8 digits (or even the maximum of 16) this will leave a LOT of mostly unprotected devices. Just imagin, walking past someone's house, and you will be able to start the Blue-Tooth coffee machine... Or better still, you see someone with the ear-mic thingie, you'll be able to whisper in his ear:)
They simply need to transfer the functionality of one platform to another.
The problem will also be determining what the functionality is in the first place, which is definitely not trivial.
And there is the bit about keeping your old data. If you implement the same functionality, which should be easier than porting, your new data model is probably gonna be incompatible with the old - forcing you to either throw the old stuff out or keeping a 'legacy' version [which will require maintenance]...
If Microsoft *acquired* these websites and tried to port them to NT/W2K/SQL/whatever and they fail, might that just mean that porting them MAY not be economical? I can imagin that a certain marketing division wants to how much effort it would take to port, they draw a conclusion after two months that it's not economical.
some other exec decides 'Lets just be quiet about it not being run on MS software and make money along the way.'
There are probably lots of projects that start as VB/NT which would be equally hard to port. Most of the time, it's probably just not worth it. Documentation is probably sparse at best for these projects, a complete rewrite would require you to reverse engineer a (probably) complex project, which is hard. The next problem would be that the guys who know most about the system probably don't (want to) speak VB/ASP, leaving the building of the project in the hands of people who haven't done it before.
Ego-satisfaction is not always enough cause to burn money.
What surprises me most about all this is they are filing for a patent on nothing more than a map. A real world analogy would be the map of a town or a schematic drawing of a tree. Okay, you can get a copyright on a map, saying 'I did the survey, you can copy it but you'll have to pay'. But you might just as well go out there and do a survey of your own.
As genome sequencing becomes faster and faster, there will probably be more maps real soon now. The wellcome trust say so themselves. All this patenting business will be moot then. If you can show that you obtained the map on your own, which should be quite easy, I can't imagine how patent can hold up in court.
In the mean time, the cheapest way to get a specific sequence may be buying a copy of the map from someone. So what? If it was corporatly funded research this has been the norm for quite a while. If it was publicly funded research - it should be public.
I like the 'I'm feeling lucky' button. Not that it's extremely useful. 'Luckies' like 'slashdot', 'slash dot', 'linux', 'great operating system' and 'free operating system' all bring you to the right place, however:)
Still, there is only a maximum of twelve copies of each gene. I agree that maybe with a very good programme you may be able to keep them viable, but you'd still be working a long time to breed out the traits you don't want. I still don't see that you can keep a population healthy, without changing them from Tasmanian Tigers into something else. And then indeed there are the social problems.
Okay, I agree that actually creating an animal from DNA salvaged from a dead-animal-in-a-jar is quite a feat, that will indeed do much for research in fertility and might well help preserve existing species. However, the Tasmanian Tiger will probably not be helped much, with only six DNA samples, the genepool is small to say the least. The first and second generations may do well, although chances are that there are already too many errors in the existing DNA. The DNA in the Jar does not preserve very well, as it is still subject to background radiation that will do damage. All the information is probably still in there, as there are enough cells that all have a piece of correct DNA. To my knowledge there is no technique to combine all 'good' pieces and filter out the bad other than sequencing ALL of it several times. Then you can compare the sequences and try to synthesize the DNA. Which turns you back to yesterdays problem with the 'artificial bacterium', but then multiplied 10,000 times. Not to mention that at present we cannot even sequence one human in less than ten years, with several thousand of laboratories working together. But okay, lets assume they have done it. When you breed them, you will have to inbreed them after the third generation, which is NOT a good idea with such a small genepool. Even lab mice, in which most bad traits have been out-bred long ago, don't respond well to that kind of inbreeding. The technology might be useful, but not for resurecting long-dead animals, except if you're willing to keep doing it over and over again. At best you may be able to crossbreed it with a close relative again, but then it wouldn't be a tasmanian tiger anymore...
As I pointed out, for now there are much, much simpler ways to achieve deadly things. 2nd year university students are doing it today. It's just like cutting and pasting. Okay, it takes some work to get it right, but bacteria in a dish multiply FAST. You only need to find one that works and then you're set to do the damage. Remember that you don not need to create a whole new bug to do the damage. The highly successful e.coli (apearing in a bowel near you) can be augmented with two or three new genes (copied from a harmful species) and it'll do just the same thing as a fully enginered bug. As for the line crossing, do you know what line is being crossed right now?
Well... From the looks of it, he isn't creating new life (or trying to). It's probably fair to consider that LineOne may have misquoted him. He does not intend to create new genes, he just wants to select an existing set of genes, that have been evolving for some time now. The real news comes from him wanting to synthesize the DNA that contain these genes and then inserting it into an existing bacterium. This is the bacterial equivalence of a brain transplant. His problem is that although bacterial DNA isn't long in the human/eukariotic sense, but it is still Very long.
And as for the matter of 'ooohhh, this might be dangerous': don't forget that we have been able, for quite a few years now, to insert foreign genes into bacteria to create a lot of wonderful things. (hormones: insulin, birth control, etc...) And of course the not so wonderful things.
His research, or lets be fair, his teams' research might lead to a speedup of experiments in the near future and maybe even the creation of actual new genes. But for now let's not too shocked.
The signatures in this case are merely meant as an identification. Meaning it just says 'it is truly me'. I agree with you that it does not solve the problem of the amount of money you transfer. That would mean you need to create a trusted path. What you might do is:
Step 1: The merchant wants to do a transaction with you. It tells a local web browser plug in (or whatever), please contact Amex, with my transaction ID and authorise US$50. Step 2: The local machine/plug in contacts the Amex server (using ssl?!?), with the transaction ID, 'please authorise US$50 for merchant ID#xxx. Step 3: Amex sends you a random number, that the chip on the credit card has to sign. You send that back.
Now it can go two ways: A: Step 4: Amex sends you an digitaly-signed (this would then be an secure channel) payment authorisation. Step 5: You send this package over to the merchant. Step 6: The merchant verifies with its own 'secure' way that the authorisation is valid.
or B: step 4: Amex contacts the merchant with the authorisation over a secure channel. step 5: Merchant 'pushes' over the open HTTP connection the end result.
I don't think the guys over at CNET mean 'swipe' as in magentic strip, but more like 'insert your chipcard'.
Chip cards are far more usefull, as the embedded chip might be able to do (3)DES, Public-key-signatures or more advanced stuff.
For example, the american express computer might issue a number that then gets encrypted/signed by the card, send back the result et-voila, Amex now knows for sure it's your personal card.
Slashdot Mirror
I'll take the f****bait:
A) Active development and support? Same for Tk: Ever been on comp.lang.tcl or http://wiki.tcl.tk give it a try. There are too many people to count there, most of them very helpful. Plenty of active developers both using *and* creating the language and Tk.
B) What's wrong with extern "C" {}? Or just use a (god forbid) Tcl script to build the UI with a few lines? Forgive my ignorance, but there are dozens of Tk bindings to other languages than Tcl, how many does wxWindows have?
C) Ah, yes, the looks. That is a bit of a sore point, yes. On windows it usually looks just like windows, though and on unix you just copy paste about 100 LOC to make it look more modern. Mind you, the way Tk works, you only need to copy-paste, no need to edit.
Yes: MAKE A BACKUP OF YOUR KEYS! This beta version does not have 'special encryption thingies so you cannot use it with any other version'. That would be quite pointless because they make a lot of effort making it interoperate with other PGP versions.
I am just curious, but have you *ever* sent encrypted mail? On a regular basis?
Not quite. If you just make backups of your keys, uninstall the beta and install another PGP version, even 7.0 freeware will do, you can go on using your data, keys rings and everything else. It is just the beta program will not work anymore. If you forgot to backup your keys, just turn back your clock a bit and it will work again.
It is not a lock-in ploy, just a beta.
That is precisely what is meant by 'plan accordingly', it could have been worded more carefully though. This beta in not meant for the people who are freaking out in this discussion and say 'watch out, it's a lock in', 'they are trying to screw you!'. As with any beta, people experienced with the product are the prefered beta testers, and they have received the beta, which incidentally has been out since last Thursday, pretty well. There were some glitches upgrading from previous versions, but by what I hear it's pretty good.
For those still interested, I recommend you grab copy and pound on it. After the beta expires you can decide to buy it if you like it or move your keys over to GnuPG and still have access to all your data and friends.
I like the final statement he makes:
I would love to take him up on that, except I'm not a member state, just a citizen.So, with my RF equipment, I walk into the store, making sure I get to within a couple of meters of every product in the store.
When I (innocently, mind you), walk through the checkout I hapily respond with all product codes I recorded.
</imagin>
Yes, and ping times aren't the most important factor. Admittedly the Medical Faculty might not be the most important bandwidth-hog, but I recall that they're always talking about 'remote medicine'. Well, here I am sitting on my SURFNet connection, @10Mbps to my desktop, from a 100Mbit switch (GBit backplane), with a 38MBit link to the main Rotterdam SURFNet connection.
Not that I ever have speed problems here, but still, I bit more spreading of the bandwidth might be nice. They're upgrading the network here, so I should have 100Mbps to my desktop soon, with cables rated at 1Gbit.
Well, not a lot of people/companies anyway.
Half the time I try to download an application/plugin I get the message 'this code was not signed'. This happens so often that the average user will simply click 'run anyway'.
This will only affect companies that have actually taken the time to set the system security policy to 'never run unsigned software'. Which nobody on this planet has done, because all the really useful software has not been signed. *sigh*
Code signing is rather useless anyway, it's a good concept. However, the certificate issuers only certify that a company writes software (which you knew anyway, you just downloaded a piece of their work), they do *explicitly* not certify 'this is software written by a company that will not copy all files from your harddrive and publish them on IRC'.
In it's current implementation it makes software somewhat tamper proof. Which is nice...
The point of the discovery is that you can send a message, possibly without revealing your exact location. This is not cryptography. There is probably not a lot of (public) research on this subject - it may be very possible to locate a ship regardless. If it is hard to locate a sender this way, the interesting thing seems to be the distance over which this works.
Even if distances don't go much beyond 10 kilometers, you can still create a buouy that a sub launches, and uses as a message relay. Or launch a few while enroute and leave a relay network behind.
Now, if and when this becomes a real world application *nobody* will be sending uncompressed, non-encrypted information over the link. The regular public and symmetric cryptography has a very calculatable 'risk' of decryption in it.
Btw, Like so many others said: the Internet idea is totally bonkers. That won't work.
To do it with a regular expression.
This gives you hardly any security at all. Your message is NOT encrypting by anything but 'their' key. And I doubt that the emails are encrypted at all on their servers. Besides, yahoo could encrypt them with their public key, if they wanted to.
This scheme is very good for protecting your mails from coworkers scanning tools - as would POP over SSL. On the other hand, almost every mail sent to that server is bound to be 'interesting'. If you don't encrypt by default, to the recipient, you'll only be sending sensitive information that way.
A good first step towards protecting emails around the world would be SMTP delivery through SSL (or SSH or IPSec or...), that way intermediate hosts cannot sniff effectively anymore. The next good thing would be SSL connections to POP/IMAP services.
That would definitely annoy most government listening services. The only Bad-Thing about SSL is the server certificates, which everybody whould then need to have. If we drop server authentication, we run the risk of man-in-middle attacks by governments. Which would be very costly indeed, because of the CPUs needed to do that.
Just my 0.02 EUR
I've seen some comments on working in the boss' time on OS projects, I don't think that's what this agreement is for. It covers that, yes 'you can work on an open source project similar to a project you work on for your business.' This clearly is useful.
My company, like any other likes it's intelectual property and would not want it be thrown out on the street. But when I asked my boss's position on me working on similar projects (which I don't do at the moment) in an Open Source environment, his reaction to this was that it would probably be useful for my personal skills and insights. "go right ahead" is what he said.
Now, this maybe because I work for a small company, I dunno.
Well, five actually. And they're all payed. You actually get, on average, 8% of your annual salary extra every may (or when you leave).
I now have 25 days for vacationing. They won't let me go for five weeks on end, three weeks max. And maybe in my next round of negotiations I'll barter for 30 days.
Things are a bit different here in the Netherlands. We all have very good health care (people still whine, of course). We don't earn as much as you guys do, mostly due to taxation. A lot of people see this as bad, but we have quite a few benefits that other countries don't have.
My company pays half of my lunch, they would pay it all if the IRS would allow it. We have free cola/fanta/whatever. Stock options are a bit hard for a pre-IPO company.
So your answer might be come work in the Netherlands.
Blatant plug
Seriously, any one who wants to work for us should contact me at p.scheffers@bhold.net we're small and have a lot of fun with watching DVDs on big screens (boy those video-beamers are *great*)
Although the absence of a good set of crypto is bad to begin with, the designers made matters worse still by using a PIN code system. To establish an adhoc connection, you can use PIN codes on both sides to establish a new link. This will probably work fine if you are connecting two PDAs with each other, and neither of those devices will normaly accept new connections.
:)
However, this will probably be RARE, to say the least. A lot of devices, like the Blue Tooth ear phone/mic for your mobile will have a hard to modify (from a user point of view) fixed pin.
By default a lot of devices will be shipped with pin codes of 0000 or 1234 or whatever. Most users will not change that PIN, or when they do choose something like 1111...
In an automated world, 10000 tries (5000 on average) is not much. It won't take long before someone writes a Palm-Blue Tooth scanner.
Even if some people are a bit more sensible and change their PINs to 8 digits (or even the maximum of 16) this will leave a LOT of mostly unprotected devices. Just imagin, walking past someone's house, and you will be able to start the Blue-Tooth coffee machine... Or better still, you see someone with the ear-mic thingie, you'll be able to whisper in his ear
They simply need to transfer the functionality of one platform to another.
The problem will also be determining what the functionality is in the first place, which is definitely not trivial.
And there is the bit about keeping your old data. If you implement the same functionality, which should be easier than porting, your new data model is probably gonna be incompatible with the old - forcing you to either throw the old stuff out or keeping a 'legacy' version [which will require maintenance]...
If Microsoft *acquired* these websites and tried to port them to NT/W2K/SQL/whatever and they fail, might that just mean that porting them MAY not be economical? I can imagin that a certain marketing division wants to how much effort it would take to port, they draw a conclusion after two months that it's not economical.
some other exec decides 'Lets just be quiet about it not being run on MS software and make money along the way.'
There are probably lots of projects that start as VB/NT which would be equally hard to port. Most of the time, it's probably just not worth it. Documentation is probably sparse at best for these projects, a complete rewrite would require you to reverse engineer a (probably) complex project, which is hard. The next problem would be that the guys who know most about the system probably don't (want to) speak VB/ASP, leaving the building of the project in the hands of people who haven't done it before.
Ego-satisfaction is not always enough cause to burn money.
If you go to www.doc.gov you'll see the link to the page. Furthermore, this host (204.193.246.62) is in the same subnet as www.doc.gov(204.193.246.9).
That would be a very unlikely hack.
Also where is the 'FREE KEVIN!'?
What surprises me most about all this is they are filing for a patent on nothing more than a map. A real world analogy would be the map of a town or a schematic drawing of a tree. Okay, you can get a copyright on a map, saying 'I did the survey, you can copy it but you'll have to pay'. But you might just as well go out there and do a survey of your own.
As genome sequencing becomes faster and faster, there will probably be more maps real soon now. The wellcome trust say so themselves. All this patenting business will be moot then. If you can show that you obtained the map on your own, which should be quite easy, I can't imagine how patent can hold up in court.
In the mean time, the cheapest way to get a specific sequence may be buying a copy of the map from someone. So what? If it was corporatly funded research this has been the norm for quite a while.
If it was publicly funded research - it should be public.
I like the 'I'm feeling lucky' button. :)
Not that it's extremely useful.
'Luckies' like 'slashdot', 'slash dot', 'linux', 'great operating system' and 'free operating system' all bring you to the right place, however
Still, there is only a maximum of twelve copies of each gene. I agree that maybe with a very good programme you may be able to keep them viable, but you'd still be working a long time to breed out the traits you don't want. I still don't see that you can keep a population healthy, without changing them from Tasmanian Tigers into something else.
And then indeed there are the social problems.
Okay, I agree that actually creating an animal from DNA salvaged from a dead-animal-in-a-jar is quite a feat, that will indeed do much for research in fertility and might well help preserve existing species. However, the Tasmanian Tiger will probably not be helped much, with only six DNA samples, the genepool is small to say the least. The first and second generations may do well, although chances are that there are already too many errors in the existing DNA. The DNA in the Jar does not preserve very well, as it is still subject to background radiation that will do damage.
All the information is probably still in there, as there are enough cells that all have a piece of correct DNA. To my knowledge there is no technique to combine all 'good' pieces and filter out the bad other than sequencing ALL of it several times. Then you can compare the sequences and try to synthesize the DNA. Which turns you back to yesterdays problem with the 'artificial bacterium', but then multiplied 10,000 times. Not to mention that at present we cannot even sequence one human in less than ten years, with several thousand of laboratories working together.
But okay, lets assume they have done it. When you breed them, you will have to inbreed them after the third generation, which is NOT a good idea with such a small genepool. Even lab mice, in which most bad traits have been out-bred long ago, don't respond well to that kind of inbreeding.
The technology might be useful, but not for resurecting long-dead animals, except if you're willing to keep doing it over and over again. At best you may be able to crossbreed it with a close relative again, but then it wouldn't be a tasmanian tiger anymore...
As I pointed out, for now there are much, much simpler ways to achieve deadly things. 2nd year university students are doing it today. It's just like cutting and pasting. Okay, it takes some work to get it right, but bacteria in a dish multiply FAST. You only need to find one that works and then you're set to do the damage.
Remember that you don not need to create a whole new bug to do the damage. The highly successful e.coli (apearing in a bowel near you) can be augmented with two or three new genes (copied from a harmful species) and it'll do just the same thing as a fully enginered bug.
As for the line crossing, do you know what line is being crossed right now?
Well... From the looks of it, he isn't creating new life (or trying to). It's probably fair to consider that LineOne may have misquoted him.
He does not intend to create new genes, he just wants to select an existing set of genes, that have been evolving for some time now.
The real news comes from him wanting to synthesize the DNA that contain these genes and then inserting it into an existing bacterium. This is the bacterial equivalence of a brain transplant.
His problem is that although bacterial DNA isn't long in the human/eukariotic sense, but it is still Very long.
And as for the matter of 'ooohhh, this might be dangerous': don't forget that we have been able, for quite a few years now, to insert foreign genes into bacteria to create a lot of wonderful things. (hormones: insulin, birth control, etc...) And of course the not so wonderful things.
His research, or lets be fair, his teams' research might lead to a speedup of experiments in the near future and maybe even the creation of actual new genes. But for now let's not too shocked.
The signatures in this case are merely meant as an identification. Meaning it just says 'it is truly me'. I agree with you that it does not solve the problem of the amount of money you transfer.
That would mean you need to create a trusted path. What you might do is:
Step 1:
The merchant wants to do a transaction with you. It tells a local web browser plug in (or whatever), please contact Amex, with my transaction ID and authorise US$50.
Step 2:
The local machine/plug in contacts the Amex server (using ssl?!?), with the transaction ID, 'please authorise US$50 for merchant ID#xxx.
Step 3:
Amex sends you a random number, that the chip on the credit card has to sign. You send that back.
Now it can go two ways:
A:
Step 4:
Amex sends you an digitaly-signed (this would then be an secure channel) payment authorisation.
Step 5:
You send this package over to the merchant.
Step 6:
The merchant verifies with its own 'secure' way that the authorisation is valid.
or B:
step 4:
Amex contacts the merchant with the authorisation over a secure channel.
step 5:
Merchant 'pushes' over the open HTTP connection the end result.
Final step:
Purchase has been completed.
I don't think the guys over at CNET mean 'swipe' as in magentic strip, but more like 'insert your chipcard'.
Chip cards are far more usefull, as the embedded chip might be able to do (3)DES, Public-key-signatures or more advanced stuff.
For example, the american express computer might issue a number that then gets encrypted/signed by the card, send back the result et-voila, Amex now knows for sure it's your personal card.