I see people in management make regular stupid decisions, usually based on their views without listening to more qualified expertise.
I don't know what happened internal to Sony, but it seemed like hubris in the theory that 'PS1 and PS2 dominated, therefore we can do whatever the hell with PS3 we want and people will just automatically buy it, let's make it really expensive and try to have it float our HD optical media format.'
In more personal hubris where I work, I see very very good technical input on the qualities and shortcomings of various products ignored by execs. Going out the door a particular software was needed, and the technical team evaluated the solution liked by management (third party software that lacked functionality and would be very costly) or what another division within the company had developed, which was much more comprehensive and advanced, and, we thought, business execs would like that we could honestly recommend the cheaper way to go that preserves the most profit for the company and make things happy. However, the third party had salespeople, took execs out to dinner and sweet talked them to go out with the shitty product. It seems that personally winning over an executive frequently trumps concrete information on a product.
Also, they have been trying *so* hard to move into less technical stuff. They want to do business consulting so they just get to focus on the bullshittery of executive and management without dealing with anything non-bullshittery. It's probably orgasmically exciting to them to think about the prospect of many people *paying* to be bossed around by them, and of course logical, they are *such* great leaders people *should* pay for the privilege. Evidently, despite great efforts to do so, there isn't much uptake on other companies who think they are too stupid to do basic management, imagine that. In the face of a successful segment of the business and the flopping business consulting, they repeatedly screwed over the people doing real work to try to get that miserable stuff up. I haven't heard much lately about it, so I'm getting the impression that someone got the message that the business consulting market is either not that big, or that no one is interesting in paying to listen to these executives say how they think a business should be run.
Now execs/managers aren't the only ones to suffer from hubris. Probably everyone in their role can thoroughly screw up due to hubris, but it seems that executives are less likely to be shitcanned for stupid stuff, and up the chain the 'punishment' for fucking up to the point of being ousted means a multi-million dollar payoff. That combined with the natural implications of being a leader within a company means a single exec's hubris can do so much more damage with very little accountability, and that makes it all the worse.
Realtime high definition encoders A further amendment. Though what you say is probably true about commercially provided DVR, and for anything in the ballpark of price for live tv watching, for recordings transcoding after the fact is not necessarily a real-time task.
My myth box, for example, transcodes the OTA MPEG-2 stream to save space after the recording is done. 90% of the time, when I watch a program it has happened to have completed transcoding.
You have to a) realize what packages must be pinned and b) forgo any potentially badly needed updates for that package until you are thoroughly fucked and you realize you have a problem. The good thing about having a trusted update source that won't pull in upstream blindly is that you *don't* have to worry and you *don't* end up on forums looking for the reason why X went south and what release Y ends up addressing your problem, at which point you *then* have to do the update you were fearing in the beginning.
Pinning versions is *not* a solution. Just accept that Gentoo is *not* appropriate for the discussed environment because it caters to a different group than that. It does what it aims to do well and shoehorning it everywhere because you like it on your personal systems is simply not good.
Every backported fix I have ever seen either doesn't need to change hardly at all or changes in very well-thought out ways to be applicable to the old version. I've even seen fixes that take the 2.4 2.6 (yes it flows both ways) path. They are radically different in some ways, but not so different as to make code completely irrelevant.
I've ran many distributions and supported them in large deployments, and did similar for Gentoo in small small deployments (workstations and a rare server). Gentoo's approach by *far* leads to the most babysitting of updates and the most downtime (and most of it unanticipated) post-upgrade. revdep-rebuild was created to deal with the obvious linking implications of ABI-breaking library upgrades, but you have to examine and contemplate a pending update list to predict how things are likely to break, and then deal with the breakage. If you aren't careful, you suddenly end up with a new major version of your DB server and have to deal with that, or an Apache update that requires you rebuild your plugins. Though more often by design than by accident, nearly blindly following upstream causes more headaches than not.
What you get out of Gentoo is that 99% of the time, you have the latest features package X has to offer. For production environments, this is almost never important across the board, and rarely is it important even for a particular package. This has its place, but not on production servers. On production servers, you shouldn't need to devote a large time to updates *and* suffer such downtime as a consequence, and you should *always* know without much of a thought if you are about to do a major upgrade with implications or a minor update that is not likely to cause major issues.
And this shouldn't be considered offensive by Gentoo proponents. The fact is, on production servers, you need to run distributions that have legacy baked into their methodology and that do not have a conflict of interest or obvious impediment to such an effort.
Gentoo's aim *clearly* is keep up to date with upstream constantly, plus add some patches for pending bugs, and the end user is smart enough and willing to put up with the inevitable pains in the ass that result from such an effort to always be cutting/bleeding edge (yes, Gentoo occasionally lags on a package depending on maintainer/build difficulties, but the goal is clear). The only periodic release you could remotely keep pace by is LiveCD releases, but the reality is that any given day may be significantly different in functionality/ABI compatibility than the previous and/or next. That is a fine segment of the population to target who will not be satisfied by anything that would be 'production appropriate', and Gentoo can't cater to both those and long-term production environments. I've been saying the same thing about Fedora Core (to a somewhat lesser, but still important extent), and the whole breakdown over 'Legacy' really proves that trying to maintain a cutting-edge distribution that releases frequently makes it nearly impossible to satisfy the needs of those not on the cutting edge. Add to that Fedora Core has a fair amount of RH directing the path of FC and you have a conflict of interest. OpenSuSE I can't directly speak to, but with being driven by the same company as SLES, I suspect OpenSuSE's situation is in line with FC.
As far as free 'production' appropriate distributions, so far the only "proven" ones are RHEL repackagings (CentOS high on the list, they deviate the least, others based on RHEL deviate more to differentiate themselves, and depending on that deviation things could get troublesome) and Debian. Now Ubuntu with Dapper has a stated goal of maintaining a release for years, so the stated goal aligns with this need. Add to this that ultimately Canonical is a commercial entity with a vested interest in Ubuntu LTS being embraced by their customers, and it seems likely Dapper will belong on this list. However, not enough time has passed to know yet.
Now if I could just find another Wii-mote... Funny that, went randomly to a best buy on Friday afternoon, and there were half a dozen wii-motes and nunchuks on the shelf. No Wiis, but controllers were plentiful.
My strategy is simpler: wait until I don't have to work for it. It will happen, and I have plenty to do in the meantime...
Just different application. For example, if your application needs hashes, use two hashes. One hash of a byte-sized fixed field that gives you the 'hints' you desire, and because it is a fixed byte-size, it reduces the problemspace, and another hash that is considered in the context of the fixed field hints. The hashing algorithm need not change to do what you want.
Even if Solaris gives other developers two options, GPL *or* their more BSD-ish license, things only flow to linux. Unless sun stops their own license, they can't take linux code and give people the option of not doing the GPL..
Is to have a common component shared among many documents without replication.
Class paths is java are the perfect example to say how it *should* work. Java CLASSPATHs in every application/installation I have seen are site-local, all paths accessible without going over the internet to another site to get classes.
To be similar, an RSS site should copy this DTD to their local server, or to a server with which they have a concrete understanding of the relationship. Either a commercial agreement with a peer or at least using a server from an organization who explicitly defines the purpose of hosting to be a common place to promote it as a standard.
Did netscape promise itself to be an organization sharing that DTD explicitly, or did site developers get in the practice because 'it just always was there'?
VHS vs Beta probably wasn't decided by porn, but even assuming it was, it is a different world now.
Before VHS, moving porn was essentially restricted to live shows and seedy theatres, both of which required sacrificing privacy both while watching and in the act of getting there and back. With home video playback, it became possible to be fairly discrete and... enjoy the show however you may wish. Obtaining the tapes could potentially be embarasssing. Once purchased, to be discrete hiding the tapes was required from time to time, but things were generally fairly private.
DVD rolls around, and any influence porn may have at this point is moot, there is no competitor to measure success or failure of DVD against.
Now we come to the question of BD vs HD-DVD with respect to porn. If porn is the deciding factor, the internet wins. With the prevalence of broadband, computer displays that are generally higher quality than TVs and sufficient for short distance viewing, and the fact it is the ultimate way to get content free and really discretely. It's no surprise that the first widely discussed HD porn was in a format only viewable mostly on computers. Filling the gap beyond broadband, cable and satellite providers provide adult pay-per-view, which is also more discrete than having to get a video.
I'd be interested to see how DVD sales have been in this era. And I know I stress discreteness and private viewing where there is a population that isn't so concerned with it, but the vast majority want to not advertise it, and thus leap on online acquisition of material.
Who are you talking about and what are you asking?
This article is about a HD set, and I have no problems plugging my DVI into my set's HDMI port and getting the modelines and having Xorg do things automagically. I watch HD content delivered over the air no problems.
One thing that doesn't guard against is the merchant lying to the customer (i.e. the device says 'we are charging you $1.50', while the merchant actually asks for $2.50 from the bank (enough to be unfair, probably not enough for a person to remember it being wrong). The chances any company would risk such a stunt are slim, but if the banks wanted to go a lot further toward not having many fraud claims to manually deal with, the more convoluted scheme could work...
True though, that the described approach would make PINs useless one moment to the next, and take care of the bulk of the problem.. (merchants keeping your account info, and someone else, an employee of the merchant, or the merchant themselves abusing that saved knowledge at a later date... I suspect the amount of fraud done at the time of a legitimate purchase (overcharging) is admittedly very low, and even in such cases not done to the point of critically endangering your account balance.
I have never seen this, but a question I'm left with is if a phishing site is well crafted, what would prevent them from taking the info you entered, re-entering the data into BOA's site, getting the 'goofy picture' image, and displaying it on their page?
While your idea seems very well thought out, it still wouldn't gaurantee it couldn't be a dummy terminal that's designed to collect swipe data and pin codes. The idea was that all input and display was on the device the customer always carried *with* them. They never touch a button or trust anything displayed by the merchant's equipment. The POS half would be a plug with basic data I/O lines and power. The device is expected not to be tampered with because the customer always has it. In order for it to be compromised as described it would have to be physically stolen and swapped. Even then, it would be unable to complete a transaction. I.e. you plug it in and you enter your passphrase, it won't have the key so it will fail. Presumably at that point you call in a problem so the window of opportunity for them to use the passphrase to exploit the stolen device would be small. The person doing the swap would additionally either have to be working with the very next merchant you try to buy from to intercept it in the middle, or tail you constantly until you do a transaction if they put a wireless transmitter in it. Of course, if they do tail you and instrument everything just so, I suppose it could broadcast the key and the equipment that has the flash part from your valid device could decode and relay it back... I suppose also that if they managed to steal it long enough to bug the keypad it could be more transparent.... But still, orders of magnitude more secure than things today.
Your idea of having the equipment show you info to prove it is talking to your financial institution doesn't mean it is a meaningfully more trustworthy man in the middle than otherwise. If the merchant put a bug between the keypad and the rest of the circuitry internal to the otherwise 'trusted' device, still game over.
The reason why I use the phrase 'financial institution' would be that this concept is generically applicable to both credit and debit. There is nothing magical about the account type that means something technically different for a private/public key scheme with pass phrase/code protecting the private key.
It is sad when we have more security behind a random throwaway ssh account than our financial stuff.
That the whole point of this is to demonstrate that if you use the merchant's hardware to enter any personal data, it is *impossible* to be tamper-proof or tamper-evident for sure.
My vision has always been a smart device with a crypto engine, that provides it's own display and entry. It would plug into POS equipment, and tell the POS equipment at first, only enough to identify itself and tell the POS which financial institution to contact.
The financial institution would receive from the merchant the account holders ID number and some info about the transaction (i.e. the amount, maybe an interval if a service, maybe a tolerance if a repeating service charge). The financial institute would look up the customer's public encryption key, and use it to encrypt all that data together with a challenge string, and send that back to merchant.
Merchant relays the encrypted package to the customer smart device. The device then (maybe using a passphrase to decode private key like a pin, but not linked to anything outside the device) uses the private key to decode the data, and display to user what the financial institution thinks the merchant is asking for with a confirmation. If user confirms details, the decrypted challenge is sent to POS and the merchant relays it to Financial institute.
Financial institute upon receipt of a correctly decoded challenge, authorizes the transaction, and gives the merchant an affirmative response with an authorization code that is *only* valid for that specific transaction.
Here, the financial institute *only* has the customer private key, so ripping off that database won't give anyone access to the account. The merchant knows they are getting the money, but isn't left with anything they *could* use to get more money than the customer authorizes directly. The only place that has the private key is the customers smart card, which should *never* allow it to be transferred out (probably should be generated by the card and only the public part uploaded when issued). If using a passphrase for storage of the private key, it even has resistance to physical theft.
For bonus points (actually, I would pretty much demand it), have it somehow able to plug into usb ports for online transactions. Of course, online, the customer and financial institute can talk directly, simplifying some of it, but the model need not be changed much for online stuff). Again, the PC would never get the private key, so you would have to use the device.
I would *pay* an upfront charge to help cover the cost of the device in exchange for such security. If it's half-assed and uses merchant display/entry, or shares the private key *ever* theoretically, I wouldn't.
The only lock that *probably* exists is that Sony probably contractually has nVidia bound to 'not do such a thing', and the open source world.... well, we see how far nVidia drivers haven't gotten in the open source drivers (thanks to nVidia closed specs).
One, the act may have technically occurred in 2006, but has yet to leave a mark.
Two, the stuff released so far is not interesting, the stuff released so far is simply "if you get the key, you can use this to decrypt", which is just a straight implementation of the public spec....
Slashdot Mirror
I see people in management make regular stupid decisions, usually based on their views without listening to more qualified expertise.
I don't know what happened internal to Sony, but it seemed like hubris in the theory that 'PS1 and PS2 dominated, therefore we can do whatever the hell with PS3 we want and people will just automatically buy it, let's make it really expensive and try to have it float our HD optical media format.'
In more personal hubris where I work, I see very very good technical input on the qualities and shortcomings of various products ignored by execs. Going out the door a particular software was needed, and the technical team evaluated the solution liked by management (third party software that lacked functionality and would be very costly) or what another division within the company had developed, which was much more comprehensive and advanced, and, we thought, business execs would like that we could honestly recommend the cheaper way to go that preserves the most profit for the company and make things happy. However, the third party had salespeople, took execs out to dinner and sweet talked them to go out with the shitty product. It seems that personally winning over an executive frequently trumps concrete information on a product.
Also, they have been trying *so* hard to move into less technical stuff. They want to do business consulting so they just get to focus on the bullshittery of executive and management without dealing with anything non-bullshittery. It's probably orgasmically exciting to them to think about the prospect of many people *paying* to be bossed around by them, and of course logical, they are *such* great leaders people *should* pay for the privilege. Evidently, despite great efforts to do so, there isn't much uptake on other companies who think they are too stupid to do basic management, imagine that. In the face of a successful segment of the business and the flopping business consulting, they repeatedly screwed over the people doing real work to try to get that miserable stuff up. I haven't heard much lately about it, so I'm getting the impression that someone got the message that the business consulting market is either not that big, or that no one is interesting in paying to listen to these executives say how they think a business should be run.
Now execs/managers aren't the only ones to suffer from hubris. Probably everyone in their role can thoroughly screw up due to hubris, but it seems that executives are less likely to be shitcanned for stupid stuff, and up the chain the 'punishment' for fucking up to the point of being ousted means a multi-million dollar payoff. That combined with the natural implications of being a leader within a company means a single exec's hubris can do so much more damage with very little accountability, and that makes it all the worse.
My myth box, for example, transcodes the OTA MPEG-2 stream to save space after the recording is done. 90% of the time, when I watch a program it has happened to have completed transcoding.
You have to a) realize what packages must be pinned and b) forgo any potentially badly needed updates for that package until you are thoroughly fucked and you realize you have a problem. The good thing about having a trusted update source that won't pull in upstream blindly is that you *don't* have to worry and you *don't* end up on forums looking for the reason why X went south and what release Y ends up addressing your problem, at which point you *then* have to do the update you were fearing in the beginning.
Pinning versions is *not* a solution. Just accept that Gentoo is *not* appropriate for the discussed environment because it caters to a different group than that. It does what it aims to do well and shoehorning it everywhere because you like it on your personal systems is simply not good.
Every backported fix I have ever seen either doesn't need to change hardly at all or changes in very well-thought out ways to be applicable to the old version. I've even seen fixes that take the 2.4 2.6 (yes it flows both ways) path. They are radically different in some ways, but not so different as to make code completely irrelevant.
I've ran many distributions and supported them in large deployments, and did similar for Gentoo in small small deployments (workstations and a rare server). Gentoo's approach by *far* leads to the most babysitting of updates and the most downtime (and most of it unanticipated) post-upgrade. revdep-rebuild was created to deal with the obvious linking implications of ABI-breaking library upgrades, but you have to examine and contemplate a pending update list to predict how things are likely to break, and then deal with the breakage. If you aren't careful, you suddenly end up with a new major version of your DB server and have to deal with that, or an Apache update that requires you rebuild your plugins. Though more often by design than by accident, nearly blindly following upstream causes more headaches than not.
What you get out of Gentoo is that 99% of the time, you have the latest features package X has to offer. For production environments, this is almost never important across the board, and rarely is it important even for a particular package. This has its place, but not on production servers. On production servers, you shouldn't need to devote a large time to updates *and* suffer such downtime as a consequence, and you should *always* know without much of a thought if you are about to do a major upgrade with implications or a minor update that is not likely to cause major issues.
And this shouldn't be considered offensive by Gentoo proponents. The fact is, on production servers, you need to run distributions that have legacy baked into their methodology and that do not have a conflict of interest or obvious impediment to such an effort.
Gentoo's aim *clearly* is keep up to date with upstream constantly, plus add some patches for pending bugs, and the end user is smart enough and willing to put up with the inevitable pains in the ass that result from such an effort to always be cutting/bleeding edge (yes, Gentoo occasionally lags on a package depending on maintainer/build difficulties, but the goal is clear). The only periodic release you could remotely keep pace by is LiveCD releases, but the reality is that any given day may be significantly different in functionality/ABI compatibility than the previous and/or next. That is a fine segment of the population to target who will not be satisfied by anything that would be 'production appropriate', and Gentoo can't cater to both those and long-term production environments. I've been saying the same thing about Fedora Core (to a somewhat lesser, but still important extent), and the whole breakdown over 'Legacy' really proves that trying to maintain a cutting-edge distribution that releases frequently makes it nearly impossible to satisfy the needs of those not on the cutting edge. Add to that Fedora Core has a fair amount of RH directing the path of FC and you have a conflict of interest. OpenSuSE I can't directly speak to, but with being driven by the same company as SLES, I suspect OpenSuSE's situation is in line with FC.
As far as free 'production' appropriate distributions, so far the only "proven" ones are RHEL repackagings (CentOS high on the list, they deviate the least, others based on RHEL deviate more to differentiate themselves, and depending on that deviation things could get troublesome) and Debian. Now Ubuntu with Dapper has a stated goal of maintaining a release for years, so the stated goal aligns with this need. Add to this that ultimately Canonical is a commercial entity with a vested interest in Ubuntu LTS being embraced by their customers, and it seems likely Dapper will belong on this list. However, not enough time has passed to know yet.
My strategy is simpler: wait until I don't have to work for it. It will happen, and I have plenty to do in the meantime...
Just different application. For example, if your application needs hashes, use two hashes. One hash of a byte-sized fixed field that gives you the 'hints' you desire, and because it is a fixed byte-size, it reduces the problemspace, and another hash that is considered in the context of the fixed field hints. The hashing algorithm need not change to do what you want.
But nVidia bought 3dfx, not ati...
About Probe model 2418-B...
Even if Solaris gives other developers two options, GPL *or* their more BSD-ish license, things only flow to linux. Unless sun stops their own license, they can't take linux code and give people the option of not doing the GPL..
http://www.reighn.com.nyud.net:8080/theaterphoto.h tml
An SCIII from Toys for Bob (or whatever they would name it) is high on my list, even after all these years...
Is to have a common component shared among many documents without replication.
Class paths is java are the perfect example to say how it *should* work. Java CLASSPATHs in every application/installation I have seen are site-local, all paths accessible without going over the internet to another site to get classes.
To be similar, an RSS site should copy this DTD to their local server, or to a server with which they have a concrete understanding of the relationship. Either a commercial agreement with a peer or at least using a server from an organization who explicitly defines the purpose of hosting to be a common place to promote it as a standard.
Did netscape promise itself to be an organization sharing that DTD explicitly, or did site developers get in the practice because 'it just always was there'?
VHS vs Beta probably wasn't decided by porn, but even assuming it was, it is a different world now.
Before VHS, moving porn was essentially restricted to live shows and seedy theatres, both of which required sacrificing privacy both while watching and in the act of getting there and back. With home video playback, it became possible to be fairly discrete and... enjoy the show however you may wish. Obtaining the tapes could potentially be embarasssing. Once purchased, to be discrete hiding the tapes was required from time to time, but things were generally fairly private.
DVD rolls around, and any influence porn may have at this point is moot, there is no competitor to measure success or failure of DVD against.
Now we come to the question of BD vs HD-DVD with respect to porn. If porn is the deciding factor, the internet wins. With the prevalence of broadband, computer displays that are generally higher quality than TVs and sufficient for short distance viewing, and the fact it is the ultimate way to get content free and really discretely. It's no surprise that the first widely discussed HD porn was in a format only viewable mostly on computers. Filling the gap beyond broadband, cable and satellite providers provide adult pay-per-view, which is also more discrete than having to get a video.
I'd be interested to see how DVD sales have been in this era. And I know I stress discreteness and private viewing where there is a population that isn't so concerned with it, but the vast majority want to not advertise it, and thus leap on online acquisition of material.
Who are you talking about and what are you asking?
This article is about a HD set, and I have no problems plugging my DVI into my set's HDMI port and getting the modelines and having Xorg do things automagically. I watch HD content delivered over the air no problems.
One thing that doesn't guard against is the merchant lying to the customer (i.e. the device says 'we are charging you $1.50', while the merchant actually asks for $2.50 from the bank (enough to be unfair, probably not enough for a person to remember it being wrong). The chances any company would risk such a stunt are slim, but if the banks wanted to go a lot further toward not having many fraud claims to manually deal with, the more convoluted scheme could work...
True though, that the described approach would make PINs useless one moment to the next, and take care of the bulk of the problem.. (merchants keeping your account info, and someone else, an employee of the merchant, or the merchant themselves abusing that saved knowledge at a later date... I suspect the amount of fraud done at the time of a legitimate purchase (overcharging) is admittedly very low, and even in such cases not done to the point of critically endangering your account balance.
Get banks to actually do this.... and give a share of each one sold to an account holder to my bank account.
I have never seen this, but a question I'm left with is if a phishing site is well crafted, what would prevent them from taking the info you entered, re-entering the data into BOA's site, getting the 'goofy picture' image, and displaying it on their page?
Your idea of having the equipment show you info to prove it is talking to your financial institution doesn't mean it is a meaningfully more trustworthy man in the middle than otherwise. If the merchant put a bug between the keypad and the rest of the circuitry internal to the otherwise 'trusted' device, still game over.
The reason why I use the phrase 'financial institution' would be that this concept is generically applicable to both credit and debit. There is nothing magical about the account type that means something technically different for a private/public key scheme with pass phrase/code protecting the private key.
It is sad when we have more security behind a random throwaway ssh account than our financial stuff.
That the whole point of this is to demonstrate that if you use the merchant's hardware to enter any personal data, it is *impossible* to be tamper-proof or tamper-evident for sure.
My vision has always been a smart device with a crypto engine, that provides it's own display and entry. It would plug into POS equipment, and tell the POS equipment at first, only enough to identify itself and tell the POS which financial institution to contact.
The financial institution would receive from the merchant the account holders ID number and some info about the transaction (i.e. the amount, maybe an interval if a service, maybe a tolerance if a repeating service charge). The financial institute would look up the customer's public encryption key, and use it to encrypt all that data together with a challenge string, and send that back to merchant.
Merchant relays the encrypted package to the customer smart device. The device then (maybe using a passphrase to decode private key like a pin, but not linked to anything outside the device) uses the private key to decode the data, and display to user what the financial institution thinks the merchant is asking for with a confirmation. If user confirms details, the decrypted challenge is sent to POS and the merchant relays it to Financial institute.
Financial institute upon receipt of a correctly decoded challenge, authorizes the transaction, and gives the merchant an affirmative response with an authorization code that is *only* valid for that specific transaction.
Here, the financial institute *only* has the customer private key, so ripping off that database won't give anyone access to the account. The merchant knows they are getting the money, but isn't left with anything they *could* use to get more money than the customer authorizes directly. The only place that has the private key is the customers smart card, which should *never* allow it to be transferred out (probably should be generated by the card and only the public part uploaded when issued). If using a passphrase for storage of the private key, it even has resistance to physical theft.
For bonus points (actually, I would pretty much demand it), have it somehow able to plug into usb ports for online transactions. Of course, online, the customer and financial institute can talk directly, simplifying some of it, but the model need not be changed much for online stuff). Again, the PC would never get the private key, so you would have to use the device.
I would *pay* an upfront charge to help cover the cost of the device in exchange for such security. If it's half-assed and uses merchant display/entry, or shares the private key *ever* theoretically, I wouldn't.
Was last years resolution too (if I would have waited, maybe my 2007 resolution would have been 1920x1080...
The only lock that *probably* exists is that Sony probably contractually has nVidia bound to 'not do such a thing', and the open source world.... well, we see how far nVidia drivers haven't gotten in the open source drivers (thanks to nVidia closed specs).
One, the act may have technically occurred in 2006, but has yet to leave a mark.
Two, the stuff released so far is not interesting, the stuff released so far is simply "if you get the key, you can use this to decrypt", which is just a straight implementation of the public spec....