That's pretty much how the Calypso system works. I can't go into details because the specification is proprietary, but unlike Mifare Classic cards, they use only standard algorithms like 3DES and well-known signature algorithms. You can actually implement this system in an off-the-shelf Java Card (and it it fast enough!)
Now I understand perfectly that using standard algorithms does not mean that the overall system is secure, but at least it has a chance. The cryptographic algorithms used by Mifare cards meant that the system was insecure from the start. But, guess what? The Calypso cards are more expensive that the Mifare cards (because they have to be more capable than Mifare cards) so most cities pick the Mifare system.
No offense but Usability has nothing to do with most of these points.
First, many of them deal with "Ease of installation." While it is an important concern, most users don't have to deal with this problem. For them, the application is either already installed or just a click away in a package manager.
Second, the presence of examples, or whether all the options of the options of the application are available in the GUI are not good measures: it is possible to build an "unusable" application that fulfills both points.
So the only interesting point is to let people vote about the quality of the examples and options. This is a hotly debated idea. Personally, I think that the only real solution is to find someone with the skills (and clout!) to address the problems and to let her/him choose an improvement process tailored to the issues at hand.
As someone who had the dubious task of integrating the Paypal payment mechanism into a custom checkout process, I welcome this new "Checkout by Amazon" with open arms.
How can I possibly know that? Well, if the submitter knew anything about value transfer cards, he would know that cards that store value require microseconds to transfer the value. Those microseconds translate into the rider having to -stop and wait- in order to transfer value. Which all mass transit riders know would be an absolute mess. So, the card carries, at most, a disguised unique ID with all the value transfer happening on some backend.
This is incorrect. The Oyster card is a Mifare card, i.e. it stores record and protects them through a secure session algorithm. This means that the value of an Oyster card is actually stored in the card. When the card is presented to a gate, the gate actually authenticate the card and its content. The value is probably also stored in a server somewhere, but that's probably only used for fraud detection.
Now, Mifare cards are pretty old hat and their cryptographic algorithms are weak. But better "fare collection systems" do exist. For example, the Calypso system (used in Paris, Brussels and a number of other cities) is based on DES (with 3DES available in the last spec) and ISO9797. And by the way, a Calypso application running in a Java Card is actually fast enough to replace old, proprietary cards like Mifare cards. Speed is not an issue anymore.
I've found the case study to be pretty interesting. I also think that the answer from Eric Levin from Techno Source (an electronic toy maker) was perfectly in line with their current way of thinking and therefore disappointing. From my point of view, this middle path is just business as usual for electronic manufacturers: this is the standard business models for third-party accessories, from the iPod to the Wii. However, it should be noted that the middle path he was suggesting included a "certification" step: every piece of software or hardware would have to be vetted by KMS, so KMS is protected.
My solution: establish yourself as the gatekeeper of the "standards" while still working with other companies or individuals to extend them. Something like MIDI or the JCP. But the most important is to keep working on great products of your own. Dear Sun, you wrote the J2EE spec, where is your production-ready J2EE implementation?
The mechanism you've just described is used by the Bull Trusway PPS key. There is still a few differences. First, there is a single wheel so you have to enter the PIN code digit by digit. Second, it does not use a battery: you have to plug it in first. However the data is accessible only if the PIN is entered correctly.
The only drawback is that it is not really something you can buy "off the shelf."
Maybe because they are in a different timezone? Maybe because sometimes logging in a channel is just a way to signal your presence and that no one is chatting on this specific room anymore? Nowadays, IRC is mostly a social forum and each well-established room as its own, sometimes peculiar, rules.
QR codes is a well-known technology that worked very well in Japan. However, the rest of the world will probably never hear about them since another technology is about to place its place: RFID tags and NFC phones. NFC is a much better technology since you do have to position the camera just above the tag to read it. Also, NFC phones and RFID tags communicate with a bidirectionnal connection while QR codes are unidirectional only. There is no doubt that NFC phones are going to replace tickets and credit cards in many cases (but not all of course).
So it's really too late to try to bring this kind of technology in the Americas or in Europe. Even in Asia QR codes are only used in Japan.
Once I visited a military base that hosted large fields of well-known cereals and stuff. I was told those fields were used to calibrate spy satellites, since the size and "color" of those fields are perfectly known. I guess they use those flat areas as well.
I've been using Eclipse for thousands of hours, all the way back to Eclipse 2.0. I've never seen Eclipse corrupt its workspace. However, I've seen lots of badly-written plugins that do manage to mangle their own configuration files.
Are you sure that your issues at coming from Eclipse?
The author does not know about it so he says nothing. I've used it and I can say that it's pretty good. The only problem is the IDE, which is really an embarrassment, but you don't have to use it. You can access the "restricted" APIs (making a phone call, accessing the agenda...) by signing the application, which is a simple process that requires a $100 one-time payment.
If you know Java, the Blackberry platform is the simplest and most powerful platform you will find.
I'm not sure that this is such a good idea. Time and again, operators have made clear the fact that when a mobile phone manufacturer tries to package this kind of application with their phones, the application will be "evaluated" against the operator own offering. In this case, it means that the operator will remove the original mapping application and will install its own instead, The common justification is that it allows the operator to standardize on a single application across a wide range of devices. Of course the real reason is that operators don't want mobile phone manufacturers to get into services.
So Nokia may find that they cannot distribute their own application. Of course, Nokia is a very well-run company, so I guess that they foresee some benefits in this move. However, like any large company, they can make some pretty bad moves at times (N-Gage...)
Now, here is a funny thing: an exploitable buffer overflow was recently found in the native library handling images in Sun's JVM. This is one of the most significant security bug found in this JVM for the past few years.
Programs in Java are more secure than programs in native code, but only as long as they don't rely on native libraries...
Hint: most cell phones run their software almost exclusively on a JVM. Hum, no. Many cell phones can run Midlets, but the main firmware (user interface, call handling, SMS, picture processor...) is programmed in native code. On Symbian and Windows Mobile cell phones, you can actually install additional native appliations. Midlets are only used for user-downloaded applications programmed in Java, which is a really small market. Blackberries are the only cell phones that run every program in Java, including the user interface, but even them rely on significant portions of native code.
I don't know if you're serious or if you're only trying to be funny, but for the record, in general, chips are not photosensible. I know of two exceptions. Some EEPROM chips (a pre-Flash storage technology) can be erased by UV light. Highly secure chips sport light sensors in order to detect that their cover has been removed or if someone is trying to disrupt their behavior using a flash or laser attack.
Also, taking a picture of the chip is only useful if you want to reconstruct the actual layout of the chip, which is of limited use for various reasons.
You're not the first one to propose this scheme. One issue is that there is no way to prevent a trojan from impersonating the user. The solution is to add a pinpad and a screen to the card reader, and to ask the user to authorize each transaction by typing his PIN on the pinpad. The screen is used to display a small message that describe the transaction. This reader would be much easier to secure than a Windows PC.
Basically, this scheme is implemented by FINREAD, and banks are not interested, probably because deploying card readers is more expensive than simply reimbursing customers tricked by phishers.
Funny story, somebody started a campaign to take down the Christmas lights because they were red and white, and thought they were a big Coke advertisement. Never mind that red and white are traditional Christmas colours. Well, Coca-Cola did have a part in standardizing the image of Santa Claus as a jolly fat guy dress in red in white..
One little detail has me curious: TGVs, though electric, still use locomotives to push and/or pull the train, a design feature that's been around since the first steam trains in 1833. I seem to recall "futurists" like Arthur Clarke claiming that the train of the future would use lots of small motors connected to each wheel instead of one big one in a locomotive. Actually, this train uses two AGVTM ("high speed trainset with distributed propulsion") in addition to front and back locomotives. Just google "AGVTM".
Actually, this is even worse. I'm in France but I used to order from Amazon.co.uk (and Amazon.com) because in many cases, books (and other stuff) weren't available or were more expensive on Amazon.fr, even with the higher shipping fee for international orders. No travelling required, just a longer delivery time.
But I don't do it anymore. Why ? Because 1) the Amazon.fr website now has a large (and I really mean large) collection of books in English and 2) the prices are now pretty much identical (or even cheaper given the fact that Amazon.fr ships everything for free in France).
Get over it Apple. Even the movie studio (the movie studios, for God's sake!) manage to release their movies on the same day all over the world.
This difference in startup times between Azureus and Eclipse is surprising. Both are based on the same framework (RCP) and I will argue that Eclipse is "bigger" than Azureus. On my box, the startup times are similar. How many torrents are you trying to download? Also, are you sure that Azureus is started in a recent JVM (like 1.6) instead of some ancient 1.4?
Anyway, in Java, each process runs in a different JVM, so there is absolutely no sharing between processes. This is a long-standing issue and Sun is clearly not interested in implementing run-time sharing. However, startup time in 1.5 and 1.6 are much better than in 1.3 and 1.4 (and it's not only because computers are faster these days). Memory use is still an issue.
Project files (.classpath and.project) in Eclipse are shareable, with a few caveats. If you want to share them across developers, you need to enforce some stricts rules and sometimes it's not worth the shot. Also, do not checkout projects in.workspace.
I second that. Ape is a bitch to work with compared with FLAC. There is no official spec, no official Linux version... Furthermore, unlike FLAC, Ape is probably not patent-free. This means that many players support FLAC, while none support APE. The only nice thing about Ape is that since it is lossless, you can convert it back to PCM WAV and reencode in FLAC without any loss in quality. Nuff' said.
So rght now FLAC is the way to go for lossless archives. And if a better codec comes round, you can always reconvert everything to this new format.
A few months ago, I bought a nice mountain bike from a well-known vendor. Right from the start I had issues with the front crank. So I went online and founds hundreds of people having exactly the same problem on the very same model. It gave me a much stronger case to get the shop to replace the problematic part by another brand: they could not claim that it was my fault. So yeah, online consumer activist is good, but you already knew that, right ?
Perhaps I am in error, but I doubt the standard itself has ever been cracked
Early versions of some encryption "algorithms" were "cracked" and soon replaced by updated versions. BTW, those encryption algorithms are proprietary and not officially part of the specification: only the encryption protocols are. The new algorithms used for 3G are based on standard algorithms (AES, SHA-1) and were designed through an open process.
unless via law enforcement with the complicity of the companies involved.
"Lawful Interception" is actually defined in the spec (which is composed of thousands of very tersely prosed Word documents). Beside this issue, some networks disable encryption from time to time for various reasons (network issues, terrorists...). At this point every Joe Six-Pack with a digital scanner can listen to conversations.
And finally, GSM has nothing to do with DRM. The goal of DRM is to restrict the use of piece of media to some arbitrary conditions. Encryption in the GSM network is used to protect the customer against eavesdropping and the telcos against phone cloning.
Slashdot Mirror
That's pretty much how the Calypso system works. I can't go into details because the specification is proprietary, but unlike Mifare Classic cards, they use only standard algorithms like 3DES and well-known signature algorithms. You can actually implement this system in an off-the-shelf Java Card (and it it fast enough!)
Now I understand perfectly that using standard algorithms does not mean that the overall system is secure, but at least it has a chance. The cryptographic algorithms used by Mifare cards meant that the system was insecure from the start. But, guess what? The Calypso cards are more expensive that the Mifare cards (because they have to be more capable than Mifare cards) so most cities pick the Mifare system.
No offense but Usability has nothing to do with most of these points.
First, many of them deal with "Ease of installation." While it is an important concern, most users don't have to deal with this problem. For them, the application is either already installed or just a click away in a package manager.
Second, the presence of examples, or whether all the options of the options of the application are available in the GUI are not good measures: it is possible to build an "unusable" application that fulfills both points.
So the only interesting point is to let people vote about the quality of the examples and options. This is a hotly debated idea. Personally, I think that the only real solution is to find someone with the skills (and clout!) to address the problems and to let her/him choose an improvement process tailored to the issues at hand.
Are you in the US?
As someone who had the dubious task of integrating the Paypal payment mechanism into a custom checkout process, I welcome this new "Checkout by Amazon" with open arms.
How can I possibly know that? Well, if the submitter knew anything about value transfer cards, he would know that cards that store value require microseconds to transfer the value. Those microseconds translate into the rider having to -stop and wait- in order to transfer value. Which all mass transit riders know would be an absolute mess. So, the card carries, at most, a disguised unique ID with all the value transfer happening on some backend.
This is incorrect. The Oyster card is a Mifare card, i.e. it stores record and protects them through a secure session algorithm. This means that the value of an Oyster card is actually stored in the card. When the card is presented to a gate, the gate actually authenticate the card and its content. The value is probably also stored in a server somewhere, but that's probably only used for fraud detection.
Now, Mifare cards are pretty old hat and their cryptographic algorithms are weak. But better "fare collection systems" do exist. For example, the Calypso system (used in Paris, Brussels and a number of other cities) is based on DES (with 3DES available in the last spec) and ISO9797. And by the way, a Calypso application running in a Java Card is actually fast enough to replace old, proprietary cards like Mifare cards. Speed is not an issue anymore.
I've found the case study to be pretty interesting. I also think that the answer from Eric Levin from Techno Source (an electronic toy maker) was perfectly in line with their current way of thinking and therefore disappointing. From my point of view, this middle path is just business as usual for electronic manufacturers: this is the standard business models for third-party accessories, from the iPod to the Wii. However, it should be noted that the middle path he was suggesting included a "certification" step: every piece of software or hardware would have to be vetted by KMS, so KMS is protected.
My solution: establish yourself as the gatekeeper of the "standards" while still working with other companies or individuals to extend them. Something like MIDI or the JCP. But the most important is to keep working on great products of your own. Dear Sun, you wrote the J2EE spec, where is your production-ready J2EE implementation?
The mechanism you've just described is used by the Bull Trusway PPS key. There is still a few differences. First, there is a single wheel so you have to enter the PIN code digit by digit. Second, it does not use a battery: you have to plug it in first. However the data is accessible only if the PIN is entered correctly.
The only drawback is that it is not really something you can buy "off the shelf."
Maybe because they are in a different timezone? Maybe because sometimes logging in a channel is just a way to signal your presence and that no one is chatting on this specific room anymore?
Nowadays, IRC is mostly a social forum and each well-established room as its own, sometimes peculiar, rules.
QR codes is a well-known technology that worked very well in Japan. However, the rest of the world will probably never hear about them since another technology is about to place its place: RFID tags and NFC phones. NFC is a much better technology since you do have to position the camera just above the tag to read it. Also, NFC phones and RFID tags communicate with a bidirectionnal connection while QR codes are unidirectional only. There is no doubt that NFC phones are going to replace tickets and credit cards in many cases (but not all of course).
So it's really too late to try to bring this kind of technology in the Americas or in Europe. Even in Asia QR codes are only used in Japan.
Once I visited a military base that hosted large fields of well-known cereals and stuff. I was told those fields were used to calibrate spy satellites, since the size and "color" of those fields are perfectly known. I guess they use those flat areas as well.
I've been using Eclipse for thousands of hours, all the way back to Eclipse 2.0. I've never seen Eclipse corrupt its workspace. However, I've seen lots of badly-written plugins that do manage to mangle their own configuration files.
Are you sure that your issues at coming from Eclipse?
The author does not know about it so he says nothing. I've used it and I can say that it's pretty good. The only problem is the IDE, which is really an embarrassment, but you don't have to use it. You can access the "restricted" APIs (making a phone call, accessing the agenda...) by signing the application, which is a simple process that requires a $100 one-time payment.
If you know Java, the Blackberry platform is the simplest and most powerful platform you will find.
I'm not sure that this is such a good idea. Time and again, operators have made clear the fact that when a mobile phone manufacturer tries to package this kind of application with their phones, the application will be "evaluated" against the operator own offering. In this case, it means that the operator will remove the original mapping application and will install its own instead, The common justification is that it allows the operator to standardize on a single application across a wide range of devices. Of course the real reason is that operators don't want mobile phone manufacturers to get into services.
So Nokia may find that they cannot distribute their own application. Of course, Nokia is a very well-run company, so I guess that they foresee some benefits in this move. However, like any large company, they can make some pretty bad moves at times (N-Gage...)
Now, here is a funny thing: an exploitable buffer overflow was recently found in the native library handling images in Sun's JVM. This is one of the most significant security bug found in this JVM for the past few years.
...
Programs in Java are more secure than programs in native code, but only as long as they don't rely on native libraries
I don't know if you're serious or if you're only trying to be funny, but for the record, in general, chips are not photosensible. I know of two exceptions. Some EEPROM chips (a pre-Flash storage technology) can be erased by UV light. Highly secure chips sport light sensors in order to detect that their cover has been removed or if someone is trying to disrupt their behavior using a flash or laser attack.
Also, taking a picture of the chip is only useful if you want to reconstruct the actual layout of the chip, which is of limited use for various reasons.
You're not the first one to propose this scheme. One issue is that there is no way to prevent a trojan from impersonating the user. The solution is to add a pinpad and a screen to the card reader, and to ask the user to authorize each transaction by typing his PIN on the pinpad. The screen is used to display a small message that describe the transaction. This reader would be much easier to secure than a Windows PC.
Basically, this scheme is implemented by FINREAD, and banks are not interested, probably because deploying card readers is more expensive than simply reimbursing customers tricked by phishers.
Actually, this is even worse. I'm in France but I used to order from Amazon.co.uk (and Amazon.com) because in many cases, books (and other stuff) weren't available or were more expensive on Amazon.fr, even with the higher shipping fee for international orders. No travelling required, just a longer delivery time.
But I don't do it anymore. Why ? Because 1) the Amazon.fr website now has a large (and I really mean large) collection of books in English and 2) the prices are now pretty much identical (or even cheaper given the fact that Amazon.fr ships everything for free in France).
Get over it Apple. Even the movie studio (the movie studios, for God's sake!) manage to release their movies on the same day all over the world.
This difference in startup times between Azureus and Eclipse is surprising. Both are based on the same framework (RCP) and I will argue that Eclipse is "bigger" than Azureus. On my box, the startup times are similar. How many torrents are you trying to download? Also, are you sure that Azureus is started in a recent JVM (like 1.6) instead of some ancient 1.4?
Anyway, in Java, each process runs in a different JVM, so there is absolutely no sharing between processes. This is a long-standing issue and Sun is clearly not interested in implementing run-time sharing. However, startup time in 1.5 and 1.6 are much better than in 1.3 and 1.4 (and it's not only because computers are faster these days). Memory use is still an issue.
Project files (.classpath and .project) in Eclipse are shareable, with a few caveats. If you want to share them across developers, you need to enforce some stricts rules and sometimes it's not worth the shot. Also, do not checkout projects in .workspace.
I second that. Ape is a bitch to work with compared with FLAC. There is no official spec, no official Linux version... Furthermore, unlike FLAC, Ape is probably not patent-free. This means that many players support FLAC, while none support APE. The only nice thing about Ape is that since it is lossless, you can convert it back to PCM WAV and reencode in FLAC without any loss in quality. Nuff' said.
So rght now FLAC is the way to go for lossless archives. And if a better codec comes round, you can always reconvert everything to this new format.
A few months ago, I bought a nice mountain bike from a well-known vendor. Right from the start I had issues with the front crank. So I went online and founds hundreds of people having exactly the same problem on the very same model. It gave me a much stronger case to get the shop to replace the problematic part by another brand: they could not claim that it was my fault. So yeah, online consumer activist is good, but you already knew that, right ?
Early versions of some encryption "algorithms" were "cracked" and soon replaced by updated versions. BTW, those encryption algorithms are proprietary and not officially part of the specification: only the encryption protocols are. The new algorithms used for 3G are based on standard algorithms (AES, SHA-1) and were designed through an open process.
"Lawful Interception" is actually defined in the spec (which is composed of thousands of very tersely prosed Word documents). Beside this issue, some networks disable encryption from time to time for various reasons (network issues, terrorists
And finally, GSM has nothing to do with DRM. The goal of DRM is to restrict the use of piece of media to some arbitrary conditions. Encryption in the GSM network is used to protect the customer against eavesdropping and the telcos against phone cloning.