Have a FEW people post this is important and why. When you see that 75 people have already done this in the last 15 minutes, maybe resist the urge to add your voice.
Call whoever sold you the phone. Hint, that wasn't Google.
Yup, this is a big problem with statistical arguments - you have to accept some confidence level.
If everybody does everything right, then we'd probably expect 5% of all research to be outright wrong due to random chance alone (that's what 95% confidence means).
However, the reality is that somebody gets a big set of data, and tests 100 different hypothesis against it. You'd expect 5 of those to be confirmed purely due to random chance, even if there is no real relationship. Five earth-shattering confirmed conclusions is plenty to get published. Lather, rinse, repeat...
Yup. However, I'm sure most of these posters don't know better.
I would place more criticism on news sites that encouraged their readers to go on a bug-staring rampage without any explanation about bug tracker etiquette.
Bottom line is that the spirit of open source is a cooperation between users and developers. If you want to scream at somebody for dropping the ball, call whoever sold you the phone.
Well, my proposal to randomize the exact time that trades are executed was intended to accomplish the purpose of preventing last-nanosecond orders from coming in.
Insider trading will always be a problem that has no technical solution. However, even lower-frequency trades, like once a day, might help equalize access to the markets.
Then, why did the price of gasoline drop $1.50 in a few weeks from record highs when the hedge funds dried up?
I am sure that lots of effort goes into the logistics of oil distribution, etc. That is all effort well-spent.
The part I don't like is when people buy oil futures speculating that prices will rise without any intention to take delivery of the oil. That just results in people bidding up the price.
I'm certainly not the only one suggesting that needless speculation drives up the cost of commodities. Just look at housing prices with the mortgage bubble/etc.
Again, my issue isn't with markets - it is with people buying derivatives purely on speculation, without any interest in actually dealing with the product that is being tracked. Corn growers who want to hedge the value of their crops is fine. Airlines that want to hedge the value of oil is also fine. However, this should be limited to the value of the actual material being traded.
So, based on the posts in the bug it sounds like Google has been actually working on this, but having problems tracking it down.
That being the case, perhaps you should have posted a reproducible scenario or something.
I was just amused to see that as an interested party trying to understand what was going on (and hey, who knows, maybe even spot something that can be patched), I had to wade through 750 me-toos to find the 10 posts that had actual content in them.
The many-eyeballs benefits of open source go away when nobody wants to look at a bug entry...
Well, they provided this nice mechanism - starring the issue. Plus, after the 350th me-too in a one-day period do we really need a 351st?
In any case, I've fixed lots of open-source bugs, and I've been paid exactly zero to do it. I'd hardly say that my free contributions have been holding open-source back.
Now, admittedly Android has commercial sponsorship, but these people should really be complaining to their carriers, not spamming bugs...
Ok, I'll agree that this seems to be an important issue, but the 700 me-toos in a 24 hour period on the issue isn't going to help anybody.
Go ahead and star the issue if you'd like (and enjoy reading the resulting 700 emails you'll get every day from the idiots shouting "this is important). But, there are better ways to get the issue escalated than to spam the bug. This just makes it that much harder for anybody actually working on the problem to fix it. Also, anybody who did care about the issue and who was working on it probably will take their names off the bug as soon as they get into work next week, or at least hit the mute button on the conversation thread in gmail.
If somebody spammed a bug of mine on an open source project like this I'd do two things:
1. Fix the bug. 2. Ban anybody from the bugzilla who posted a me-too.
Me-toos that include helpful step-by-step reproduction scripts, core dumps with symbols, insightful analysis, or whatever are of course perfectly welcome. "This is important!!!" is just whining - yes, it is important, now go find something productive to do...
Yes, but Google's search algorithms help ordinary people find information they need, and they help real business that produce real things to do so more efficiently, which makes the cost of everything you consume a little cheaper.
A better HFT algorithm just ensures that some big banker makes a few hundred million more dollars at the expense of any ordinary person who has a retirement account.
I have nothing against progress. However, most of the financial industry just shuffles numbers around manufacturing money out of nothing, and occasionally turning money back into nothing in astronomical quantities. Did you notice how gas prices plummeted from $4/gallon to about $2.50 in a few weeks after the hedge fund meltdowns? Now, tell me how much value all those funds trading oil futures were creating?
I have nothing wrong with financial instruments that actually create more efficient markets. If an airline needs to buy 50 million gallons of fuel next year I'm fine with them hedging the price of oil to keep their ticket prices stable. My problem is when the market in the actual commodity becomes secondary to playing financial games. The oil market should be about running cars, or environmental controls, or whatever - not about 100 day traders making $40 on the trade of a $50 barrel of oil.
The market does need liquidity, that much I do know.
The market had plenty of liquidity before the invention of HFT. I'm just suggesting limiting liquidity to a few minutes, rather than a few nanoseconds. Will it really hurt the economy if it takes a stock 10 minutes to plunge 50% rather than a few seconds, with only a few big well-connected institutions getting out in time?
I'm all for technology that solves real-world problems. However, HFT is a case of where technology and a lack of regulation has actually created real-world problems. Improving HFT actually makes those problems worse.
Uh, I understand exactly what it is, and who benefits, which would not be the economy at large.
The point in aggregating trades is to entirely negate the advantage of HFT, thus eliminating it from the market. It isn't like there wouldn't still be liquidity - you'll just have to wait 1-2 minutes to have an order filled. The average person making a trade usually has a lag of hours between an event happening and getting to make a trade anyway.
Yeah, I know exactly what it is. My proposal basically is to get rid of it by making it useless. It provides no real benefit to the economy, so nobody will be hurt if it goes away...
Actually, I'd prefer once per day at midnight, with a blackout on company announcements after 5PM. That would go even further towards leveling the playing field.
What value does a bot generate when all it does is capitalize on the tiniest fluctuations in stock price. It isn't like it makes the stock any more efficient - the price would certainly adjust itself. The only difference is that some investment bank can't make a fortune solely based on its ping time.
the cost of enormous amounts of RAM has dropped pretty significantly
Uh, your example was 512GB, and you're comparing $40k for RAM to about $40 for a hard drive. That's around 1000:1!
Sure, RAM is only getting cheaper, but so are hard drives. A few years ago I got 2GB of RAM for about the same price as 320GB of hard drive. So, if anything the relative cost of RAM has gone UP, and not down...
There is another simple solution to optimizing HFT - just aggregate and execute all trades once per minute, with the division between each minute taking place in UTC plus/minus a random offset (a few seconds on average - with 98% of divisions being within 5 seconds either way).
Boom, now there is no need to spend huge amounts of money coming up with lightning-fast implementations that don't actually create real value for ordinary people.
Business ought to be about improving the lives of ordinary people. Sure, sometimes the link isn't direct, and I'm fine with that. However, we're putting far to much emphasis on optimizing what amounts to numbers games that do nothing to produce real things of value for anybody...
Muridae's post is spot-on, but I figured I'd just add a bit more.
Theoretically what you suggest might be possible. In practice, it is probably easier to just develop the film. If somebody REALLY wanted to develop a roll of Ektachrome they can look up the process and reproduce it - it is just chemistry. What is expensive is automating it and doing it consistently and inexpensively. If you are willing to spend a lot of money to have somebody develop it by hand (after careful rehearsal on test film) you could do it.
Note that film does degrade over time - even in a refrigerator. So, I doubt you'll be doing this in 50 years.
As others have pointed out silver halide is sensitive stuff. I doubt you'd do any kind of optical scanning, but who knows, maybe somebody will invent some kind of terahertz imaging that doesn't expose film or whatever. If you have high enough resolution in 3 dimensions you could read all of the film layers, assuming your technique can differentiate exposed and unexposed silver halide. There is no reason that this couldn't happen - they are chemically different (which is how the image is captured in the first place).
Something like atomic force microscopy might be able to do the trick, although it probably would take a ridiculous amount of time.
Bottom line is that there are no reasons why what you suggest couldn't work, but in practice there is little reason that anybody would try to do it that way.
I know that Kodachrome is slide film, and I know that slide film produces positives. I was generalizing, and not really thinking about Kodachrome specifically in my response.
I've also developed black and white film at various points in my life, from 35mm (for fun), to autoradiography films.
Relax - while I didn't invent the C-41 process and wouldn't purport to be the world's greatest expert in emulsions I do actually know something about what I'm posting on...
With modern cameras having increased color depth the gradients are becoming less of an issue. Also, while film is analog that doesn't mean that it can accurately distinguish arbitrarily close shades of color. If you took a photo of two light sources that were only slightly different in intensity at some point you couldn't tell the difference with film.
I think the biggest problem you're going to run into is supply and demand. Is there really enough demand out there for a fancy new film chemistry that people will pay significantly more per roll to get it? If people won't pay more for it, then why develop it in the first place?
At this point digital is basically better than film already, and it will only continue to improve. Sure, your $80 walmart camera won't outperform film, but any serious camera will. And, at $7 to make one copy of 24 exposures (with none of the workflow benefits of digital for screening/editing/etc), it doesn't take a lot of shots before buying a $2000 digital camera makes sense.
At a typical serious holiday like Christmas I probably shoot 200 photos and get at least 20 good keepers out of the bunch. If I just stick them on a webpage my total cost is zero. If I print the keepers I'd pay about $2.50 for them, or a bit more if I want big prints (which will all turn out beautiful). Oh, picking out those 20 just takes a few minutes in Lightroom, and cleaning them up takes maybe a minute per photo unless I want to do something really fancy.
If I did the same with film I'd end up spending about $60 up-front to print 180 lousy or mediocre photos and 20 potential keepers (with no editing). Then I'd fuss with scanning the 20 keepers to clean them up and make them nicer, and then pay the $2.50 and whatever else I was going to spend. Oh, and I churn at least a few days with multiple runs to the film processor. In reality I'd shoot a lot less to reduce waste, and get a few keepers on a single roll (higher percentage, but smaller absolute number).
For a serious photographer I imagine the improvement in workflow using digital would be huge.
Are there really any workflows left where film is the right choice, rather than just the status quo? I know that in the lab we moved to image plates for auto-radiography back in the 90s (several more orders of magnitude dynamic range, no fussing with chemicals, and no need for the darkroom). I guess their disposable nature works for dosimeters, unless somebody has come up with something more clever.
Just shows you how far we've come with digital photography that we actually have/.ers who don't know how film works.
Film before it is developed is light-sensitive. Developing film fixes the image on the negative and makes it no longer light-sensitive. If you scan undeveloped film you'll just get an image of gray, and you'll also expose the film to intense light which means whatever was on it is lost.
Different kinds of film require different kinds of processes to develop them (since the chemistry is different). Color film is particularly fussy about such things. Once the film is developed you get a negative and there are lots of directions you can go from there. Unless you're doing something exotic there is pretty-much only one right way to develop any particular kind of film.
True - they could update the firmware to accept the old key only for signatures that have particular hashes, and supply a list of hashes. If there are 1000 games out there for the PS3 and a hash of the signature is 20 bytes long then you only need 20kb to store the whole table - a trivial amount to include in a firmware blob.
Now, if you can get the keys needed to update the firmware that is a different matter...
HDCP isn't really doing the same thing as Sony's code-signing, and it suffers from the DRM problem where Bob and Eve are the same person.
As you say, Sony's use case is just traditional public-key digital signatures, and should be completely immune to attack barring major advances, or compromise of the signing key. So, they are without excuse.
HDCP accomplishes a different mission. HDCP needs to allow any two random and unrelated pieces of AV equipment to talk to each other without anything in-between intercepting the communication. That means that each device must contain a keypair, and not a single key, which means that private keys are inside every HD TV sold today. If you can extract the keypair from any one of those TVs you can fully impersonate that TV which is all you need to crack the system barring key revocation, since HDCP dictates that any device trust any other device with full-quality streams unless it has a revoked key.
If you crack one TV set you break HDCP somewhat. The manufacturer can of course revoke the key and recall all TVs containing that key at considerable expense, and then re-secure the rest of the system (once the revocation fully propagates, which of course involves a lag).
The next problem with HDCP is that all the device keys are related to a master key (which is how devices can figure out if any particular keypair is a good one or not without having any prior relationship). The nature of that relationship allows the master key to be brute-forced once a sufficient number of device keys are obtained. Over time a sufficient number of device keys were obtained, and thus the master key was obtained. That makes revocation of individual devices no longer an option, and the only solution at this point is to invalidate every HDMI-sporting device out there.
The protection on BluRay had similar issues. Again, this is all DRM and it is theoretically insecure since the threat model is an attacker who has physical possession of the keys, which of course there is no mathematical defense against.
None of this applied to the PS3 - at least not regarding code authentication. Code encryption is a different story - if discs are encrypted then if you extract a private key from any valid console you can decrypt every disc out there, but you can't modify and run them without having the signing key or jailbreaking individual devices.
I'm curious as to how they did it as well. If they didn't provide details I'd be suspicious that the key wasn't simply leaked. Key management is the achilles heel of public key crypto.
The way you tell if the smart card is authentic is via challenge-response. When you create a gmail account you send the server a certificate from your smartcard. When you log in you provide the certificate again, the service sends you a challenge which you give to the smartcard, and the smartcard prompts for a PIN on its internal keyboard, and then after verifying the PIN it computes a response using the private key stored inside that never leaves the card.
Without extracting the key from the physical smartcard (they are designed to make this almost impossible) you can't forge a valid response.
The website doesn't know if a real smartcard was used, but that doesn't matter. The point is that the user got the level of security they asked for.
Now, if it is important to verify an actual identity (unique individual) then you just make sure the certificate is signed by the appropriate issuing government agency. Most likely they would only agree to sign certificates whose keys are protected by secure hardware, and perhaps government-issued hardware at that. Regulation would of course dictate what these IDs can and cannot be used for, as is the case with social security numbers today (perhaps with actual teeth in the regulations).
I agree with your point about virtual hosting. That is also something that needs to be fixed in the protocol.
Why does strong authentication require every client to have a static IP/etc?
I can implement a webapp today that uses client-side SSL certificates for authentication just fine, without the client having a static IP/etc. The only thing that is missing is getting the private key off of the PC and onto a smart card/etc.
There is no reason that such a standard needs to be implemented in a poor way.
Slashdot Mirror
Yup, I'm a fan of OpenID, actually. If only more sites actually supported it...
So, the ways to get this escalated are:
Star the bug.
Have a FEW people post this is important and why. When you see that 75 people have already done this in the last 15 minutes, maybe resist the urge to add your voice.
Call whoever sold you the phone. Hint, that wasn't Google.
Yup, this is a big problem with statistical arguments - you have to accept some confidence level.
If everybody does everything right, then we'd probably expect 5% of all research to be outright wrong due to random chance alone (that's what 95% confidence means).
However, the reality is that somebody gets a big set of data, and tests 100 different hypothesis against it. You'd expect 5 of those to be confirmed purely due to random chance, even if there is no real relationship. Five earth-shattering confirmed conclusions is plenty to get published. Lather, rinse, repeat...
Yup. However, I'm sure most of these posters don't know better.
I would place more criticism on news sites that encouraged their readers to go on a bug-staring rampage without any explanation about bug tracker etiquette.
Bottom line is that the spirit of open source is a cooperation between users and developers. If you want to scream at somebody for dropping the ball, call whoever sold you the phone.
Well, my proposal to randomize the exact time that trades are executed was intended to accomplish the purpose of preventing last-nanosecond orders from coming in.
Insider trading will always be a problem that has no technical solution. However, even lower-frequency trades, like once a day, might help equalize access to the markets.
Then, why did the price of gasoline drop $1.50 in a few weeks from record highs when the hedge funds dried up?
I am sure that lots of effort goes into the logistics of oil distribution, etc. That is all effort well-spent.
The part I don't like is when people buy oil futures speculating that prices will rise without any intention to take delivery of the oil. That just results in people bidding up the price.
I'm certainly not the only one suggesting that needless speculation drives up the cost of commodities. Just look at housing prices with the mortgage bubble/etc.
Again, my issue isn't with markets - it is with people buying derivatives purely on speculation, without any interest in actually dealing with the product that is being tracked. Corn growers who want to hedge the value of their crops is fine. Airlines that want to hedge the value of oil is also fine. However, this should be limited to the value of the actual material being traded.
So, based on the posts in the bug it sounds like Google has been actually working on this, but having problems tracking it down.
That being the case, perhaps you should have posted a reproducible scenario or something.
I was just amused to see that as an interested party trying to understand what was going on (and hey, who knows, maybe even spot something that can be patched), I had to wade through 750 me-toos to find the 10 posts that had actual content in them.
The many-eyeballs benefits of open source go away when nobody wants to look at a bug entry...
Well, they provided this nice mechanism - starring the issue. Plus, after the 350th me-too in a one-day period do we really need a 351st?
In any case, I've fixed lots of open-source bugs, and I've been paid exactly zero to do it. I'd hardly say that my free contributions have been holding open-source back.
Now, admittedly Android has commercial sponsorship, but these people should really be complaining to their carriers, not spamming bugs...
Ok, I'll agree that this seems to be an important issue, but the 700 me-toos in a 24 hour period on the issue isn't going to help anybody.
Go ahead and star the issue if you'd like (and enjoy reading the resulting 700 emails you'll get every day from the idiots shouting "this is important). But, there are better ways to get the issue escalated than to spam the bug. This just makes it that much harder for anybody actually working on the problem to fix it. Also, anybody who did care about the issue and who was working on it probably will take their names off the bug as soon as they get into work next week, or at least hit the mute button on the conversation thread in gmail.
If somebody spammed a bug of mine on an open source project like this I'd do two things:
1. Fix the bug.
2. Ban anybody from the bugzilla who posted a me-too.
Me-toos that include helpful step-by-step reproduction scripts, core dumps with symbols, insightful analysis, or whatever are of course perfectly welcome. "This is important!!!" is just whining - yes, it is important, now go find something productive to do...
Yes, but Google's search algorithms help ordinary people find information they need, and they help real business that produce real things to do so more efficiently, which makes the cost of everything you consume a little cheaper.
A better HFT algorithm just ensures that some big banker makes a few hundred million more dollars at the expense of any ordinary person who has a retirement account.
I have nothing against progress. However, most of the financial industry just shuffles numbers around manufacturing money out of nothing, and occasionally turning money back into nothing in astronomical quantities. Did you notice how gas prices plummeted from $4/gallon to about $2.50 in a few weeks after the hedge fund meltdowns? Now, tell me how much value all those funds trading oil futures were creating?
I have nothing wrong with financial instruments that actually create more efficient markets. If an airline needs to buy 50 million gallons of fuel next year I'm fine with them hedging the price of oil to keep their ticket prices stable. My problem is when the market in the actual commodity becomes secondary to playing financial games. The oil market should be about running cars, or environmental controls, or whatever - not about 100 day traders making $40 on the trade of a $50 barrel of oil.
The market does need liquidity, that much I do know.
The market had plenty of liquidity before the invention of HFT. I'm just suggesting limiting liquidity to a few minutes, rather than a few nanoseconds. Will it really hurt the economy if it takes a stock 10 minutes to plunge 50% rather than a few seconds, with only a few big well-connected institutions getting out in time?
I'm all for technology that solves real-world problems. However, HFT is a case of where technology and a lack of regulation has actually created real-world problems. Improving HFT actually makes those problems worse.
Uh, I understand exactly what it is, and who benefits, which would not be the economy at large.
The point in aggregating trades is to entirely negate the advantage of HFT, thus eliminating it from the market. It isn't like there wouldn't still be liquidity - you'll just have to wait 1-2 minutes to have an order filled. The average person making a trade usually has a lag of hours between an event happening and getting to make a trade anyway.
Yeah, I know exactly what it is. My proposal basically is to get rid of it by making it useless. It provides no real benefit to the economy, so nobody will be hurt if it goes away...
Actually, I'd prefer once per day at midnight, with a blackout on company announcements after 5PM. That would go even further towards leveling the playing field.
What value does a bot generate when all it does is capitalize on the tiniest fluctuations in stock price. It isn't like it makes the stock any more efficient - the price would certainly adjust itself. The only difference is that some investment bank can't make a fortune solely based on its ping time.
the cost of enormous amounts of RAM has dropped pretty significantly
Uh, your example was 512GB, and you're comparing $40k for RAM to about $40 for a hard drive. That's around 1000:1!
Sure, RAM is only getting cheaper, but so are hard drives. A few years ago I got 2GB of RAM for about the same price as 320GB of hard drive. So, if anything the relative cost of RAM has gone UP, and not down...
There is another simple solution to optimizing HFT - just aggregate and execute all trades once per minute, with the division between each minute taking place in UTC plus/minus a random offset (a few seconds on average - with 98% of divisions being within 5 seconds either way).
Boom, now there is no need to spend huge amounts of money coming up with lightning-fast implementations that don't actually create real value for ordinary people.
Business ought to be about improving the lives of ordinary people. Sure, sometimes the link isn't direct, and I'm fine with that. However, we're putting far to much emphasis on optimizing what amounts to numbers games that do nothing to produce real things of value for anybody...
Muridae's post is spot-on, but I figured I'd just add a bit more.
Theoretically what you suggest might be possible. In practice, it is probably easier to just develop the film. If somebody REALLY wanted to develop a roll of Ektachrome they can look up the process and reproduce it - it is just chemistry. What is expensive is automating it and doing it consistently and inexpensively. If you are willing to spend a lot of money to have somebody develop it by hand (after careful rehearsal on test film) you could do it.
Note that film does degrade over time - even in a refrigerator. So, I doubt you'll be doing this in 50 years.
As others have pointed out silver halide is sensitive stuff. I doubt you'd do any kind of optical scanning, but who knows, maybe somebody will invent some kind of terahertz imaging that doesn't expose film or whatever. If you have high enough resolution in 3 dimensions you could read all of the film layers, assuming your technique can differentiate exposed and unexposed silver halide. There is no reason that this couldn't happen - they are chemically different (which is how the image is captured in the first place).
Something like atomic force microscopy might be able to do the trick, although it probably would take a ridiculous amount of time.
Bottom line is that there are no reasons why what you suggest couldn't work, but in practice there is little reason that anybody would try to do it that way.
I know that Kodachrome is slide film, and I know that slide film produces positives. I was generalizing, and not really thinking about Kodachrome specifically in my response.
I've also developed black and white film at various points in my life, from 35mm (for fun), to autoradiography films.
Relax - while I didn't invent the C-41 process and wouldn't purport to be the world's greatest expert in emulsions I do actually know something about what I'm posting on...
With modern cameras having increased color depth the gradients are becoming less of an issue. Also, while film is analog that doesn't mean that it can accurately distinguish arbitrarily close shades of color. If you took a photo of two light sources that were only slightly different in intensity at some point you couldn't tell the difference with film.
I think the biggest problem you're going to run into is supply and demand. Is there really enough demand out there for a fancy new film chemistry that people will pay significantly more per roll to get it? If people won't pay more for it, then why develop it in the first place?
At this point digital is basically better than film already, and it will only continue to improve. Sure, your $80 walmart camera won't outperform film, but any serious camera will. And, at $7 to make one copy of 24 exposures (with none of the workflow benefits of digital for screening/editing/etc), it doesn't take a lot of shots before buying a $2000 digital camera makes sense.
At a typical serious holiday like Christmas I probably shoot 200 photos and get at least 20 good keepers out of the bunch. If I just stick them on a webpage my total cost is zero. If I print the keepers I'd pay about $2.50 for them, or a bit more if I want big prints (which will all turn out beautiful). Oh, picking out those 20 just takes a few minutes in Lightroom, and cleaning them up takes maybe a minute per photo unless I want to do something really fancy.
If I did the same with film I'd end up spending about $60 up-front to print 180 lousy or mediocre photos and 20 potential keepers (with no editing). Then I'd fuss with scanning the 20 keepers to clean them up and make them nicer, and then pay the $2.50 and whatever else I was going to spend. Oh, and I churn at least a few days with multiple runs to the film processor. In reality I'd shoot a lot less to reduce waste, and get a few keepers on a single roll (higher percentage, but smaller absolute number).
For a serious photographer I imagine the improvement in workflow using digital would be huge.
Are there really any workflows left where film is the right choice, rather than just the status quo? I know that in the lab we moved to image plates for auto-radiography back in the 90s (several more orders of magnitude dynamic range, no fussing with chemicals, and no need for the darkroom). I guess their disposable nature works for dosimeters, unless somebody has come up with something more clever.
Just shows you how far we've come with digital photography that we actually have /.ers who don't know how film works.
Film before it is developed is light-sensitive. Developing film fixes the image on the negative and makes it no longer light-sensitive. If you scan undeveloped film you'll just get an image of gray, and you'll also expose the film to intense light which means whatever was on it is lost.
Different kinds of film require different kinds of processes to develop them (since the chemistry is different). Color film is particularly fussy about such things. Once the film is developed you get a negative and there are lots of directions you can go from there. Unless you're doing something exotic there is pretty-much only one right way to develop any particular kind of film.
True - they could update the firmware to accept the old key only for signatures that have particular hashes, and supply a list of hashes. If there are 1000 games out there for the PS3 and a hash of the signature is 20 bytes long then you only need 20kb to store the whole table - a trivial amount to include in a firmware blob.
Now, if you can get the keys needed to update the firmware that is a different matter...
Dunno, but I can make a comment regarding HDCP.
HDCP isn't really doing the same thing as Sony's code-signing, and it suffers from the DRM problem where Bob and Eve are the same person.
As you say, Sony's use case is just traditional public-key digital signatures, and should be completely immune to attack barring major advances, or compromise of the signing key. So, they are without excuse.
HDCP accomplishes a different mission. HDCP needs to allow any two random and unrelated pieces of AV equipment to talk to each other without anything in-between intercepting the communication. That means that each device must contain a keypair, and not a single key, which means that private keys are inside every HD TV sold today. If you can extract the keypair from any one of those TVs you can fully impersonate that TV which is all you need to crack the system barring key revocation, since HDCP dictates that any device trust any other device with full-quality streams unless it has a revoked key.
If you crack one TV set you break HDCP somewhat. The manufacturer can of course revoke the key and recall all TVs containing that key at considerable expense, and then re-secure the rest of the system (once the revocation fully propagates, which of course involves a lag).
The next problem with HDCP is that all the device keys are related to a master key (which is how devices can figure out if any particular keypair is a good one or not without having any prior relationship). The nature of that relationship allows the master key to be brute-forced once a sufficient number of device keys are obtained. Over time a sufficient number of device keys were obtained, and thus the master key was obtained. That makes revocation of individual devices no longer an option, and the only solution at this point is to invalidate every HDMI-sporting device out there.
The protection on BluRay had similar issues. Again, this is all DRM and it is theoretically insecure since the threat model is an attacker who has physical possession of the keys, which of course there is no mathematical defense against.
None of this applied to the PS3 - at least not regarding code authentication. Code encryption is a different story - if discs are encrypted then if you extract a private key from any valid console you can decrypt every disc out there, but you can't modify and run them without having the signing key or jailbreaking individual devices.
I'm curious as to how they did it as well. If they didn't provide details I'd be suspicious that the key wasn't simply leaked. Key management is the achilles heel of public key crypto.
The way you tell if the smart card is authentic is via challenge-response. When you create a gmail account you send the server a certificate from your smartcard. When you log in you provide the certificate again, the service sends you a challenge which you give to the smartcard, and the smartcard prompts for a PIN on its internal keyboard, and then after verifying the PIN it computes a response using the private key stored inside that never leaves the card.
Without extracting the key from the physical smartcard (they are designed to make this almost impossible) you can't forge a valid response.
The website doesn't know if a real smartcard was used, but that doesn't matter. The point is that the user got the level of security they asked for.
Now, if it is important to verify an actual identity (unique individual) then you just make sure the certificate is signed by the appropriate issuing government agency. Most likely they would only agree to sign certificates whose keys are protected by secure hardware, and perhaps government-issued hardware at that. Regulation would of course dictate what these IDs can and cannot be used for, as is the case with social security numbers today (perhaps with actual teeth in the regulations).
I agree with your point about virtual hosting. That is also something that needs to be fixed in the protocol.
Why does strong authentication require every client to have a static IP/etc?
I can implement a webapp today that uses client-side SSL certificates for authentication just fine, without the client having a static IP/etc. The only thing that is missing is getting the private key off of the PC and onto a smart card/etc.
There is no reason that such a standard needs to be implemented in a poor way.
No, that is the rounded down integral number of "billions of dollars". :)
Did you think that I was trying to suggest that the poster I replied to was working for a company that made NO revenue at all?
Virtual desktops tend to be targeted towards larger companies.