Well, of course I was exaggerating when I said "no one." But it's interesting to hear your view.:) I didn't realize newegg provided it.
As for the "address" info - a very well-written system put in front of the credit card processing networks will do a real postal database lookup on an address. That's nice. It's also exceedingly rare. What you normally get for address verification is what the credit card processing networks themselves provide: AVS, the Address Verification Service.
A few interesting notes on AVS:
1) It only validates the digits in the street address and zip code, nothing else. So 123 Fake Street and 123 Oak Street are exactly the same in it's eyes. 2) It never rejects a transaction. Even if the address is wrong, it's approved. It's up to the merchant to check the response from the credit card processing network that says "the address was right" or "the address was wrong" or a dozen values of "the address was kinda' right" and then void the transaction if the response is unacceptable to them. VbV and MC SecureCode also give additional discount rates. I think upwards of 25-50 basis points.
We setup a special authorization transaction type for AVS, basically AVS+Auth. AVS was tried first, and only if succeeded would we follow up with an authorization request. And since AVS only checks can be completed for a marginal amount (less than 2 cents), was our first line of fraud detection for the merchant. Ugh, I still remember the various ISO 8583 single character return codes for AVS.
There are better systems, just ask our Europeans counterparts. It's near impossible to buy anything in the UK (and I assume other EU countries) where the merchant does not have chip/PIN capability. Chip cards significantly reduce the risk to the merchant, and thereby reduce the discount rate paid, and provides the merchant with more chargeback rights.
Granted, if the merchant puts out a Visa or MC logo, they still have to honor swiped transactions (not withstanding that one Brick Lane curry house that kept saying no-no-no-chip only -- but I digress), but will do everything in their power (and the merchant agreement) to dissuade swiped transactions.
Anyone who's had to work with Mastercard Visa, AMEX, Discover, JCB/Diners, and the rest know how bad it can be. But remember, these are just the associations. Look to the members who make up these organizations (or sit on the board of the publicly traded ones) and ask them why they haven't increased security. That's you BoA, Chase, Citi, and the rest.
But then again, one step down the food chain (and off to the side) are the acquirers. If they and the the ISO's under them would provide merchants (their clientele) with chip/PIN solutions, that would go a long way to help the merchants out. Supporting such solutions, on razor thin margins (measured in single basis points in the most competitive markets) is always low on the list (along with decent merchant reporting).
But, then again (2), the issuers would have to have products that support Chip/PIN. The only one I ever see, AMEX Blue, may be a good card, but I bet it's still used 98% of the time as a regular old track 2 swiped transaction. I'm interested in any large merchant that has card readers capable of chip transactions.
So, you have the unholy triumvirate: banks and issuers that give out cards; ISO's / acquirers that accept card and settle for the merchant; and the associations that sets the rules for card acceptance, fraud processes, and such. If I was Visa, I'd issue a mandate to, err, issuers, that as of date x, all cards must be chip capable (with world-wide standards). At date x+n, acquirers, ISO's, and merchants must be capable of accepting Chip/PIN cards or face fines.
Anyone who has had to deal withe craziness of PCI and it's predecessors knows the frustration, fear, and pain of not meeting association deadlines.
And while I'm on it, what is the adoption rate of Verified by Visa or the other SET-based solutions? These offer reduction is discount rates too, if implemented.
Sorry for the rant, but having a waiter tell me to go down to a cash machine because by US-issued credit card isn't chip capable has got me a little feisty.
The only one that had inflammatory hand wringing was the Mp3 player that Sound emitted from the line is then interpreted using a modem line tap, or passed through a Ukrainian computer software program which is illegal to purchase.
And yes, there is crypto, at least for US ATM networks, between the ATM and end unit HSM.
This isn't a comment regarding the original article, just this particular story.
There is really no benefit that I've witnessed from a client perspective in not allowing me to use my own machine and tools.
Now, the quoted statement of having me use my own machine coupled with the limitation of not having my tools available and also not being able to use the resources available through my company's network for the client's benefit seems like a worse situation for a client than any of the previous ones.
No matter from which angle I try comparing the three typical scenarios with using ACE for the suggested purpose, I fail to see the bottom-line benefits for a company relying on consultants / contractors.
Banks. Financial Institutions. Today the risk folks run the show. A lack of demonstrable controls, even if over the top, can impact the bottom line. SOX, 404, BASEL II, SAS 70, ISO17799, etc.
Some of the more stringent clients I work for have gone a step further, and something that ACE may address. All developers are moving to VMware guests on a locked down VLAN. They have nice big monitors and a standard corporate image on their desk, but all development work is through RDP. The premise being that code can flow into the dev environment, but only certain people can promote code out of dev to the test, QA, and UAT.
Some organizations will take the productivity hit in order to assure (or enhance) the control of their development and operational environment. I think it really comes down to the organization to make the decision.
And VMware is listening to some, as ACE does address concerns I've seen. I just hopes it's more stable than VC 1.x or 2.0.....
What most of the MS Money and Quickens do is hide double entry accounting. For general tracking of *an* account, a spreadsheet is functional.
I like the OFX integration of Quicken/Money/GNUcash. Well except for the recent MBNA purchase by Bank of America.
Rant: So I can no longer download transactions for my MBNA Visa bugged card because I don't have any other accounts with BoA? And, the transition isn't going so well either. I can manually download transactions, but historical only (sayeth the CSR).
MBNA has a crapload of branded MasterCard/Visa products, and the only one that I know of that has no foreign transaction fee (AAA Visa).
Alas, the ability to offload the import of transactions into my money management software is more important that a 1% FX fee. Simmons Trust, here I come.
"A chain of Florida convenience stores has begun accepting fingerprints as payment, using a biometric system called Pay By Touch. The company is a Bay-area startup backed by $130 million in VC cash and the acquisition of BioPay, a Virginia-based biometrics firm that's already done $7 billion in European transactions...
Okay, we just need an Australian court to decide the distribution of remaining assets to Japanese investors on the sellers in Nigerian government officials to make this truly a world-wide story.
After getting burned back in the late 80s / early 90s with the OSI protocol mandates, I'm leery of anything the US government mandates. Then again, look how well Ada turned out too.
I'm torn on the IPv6 situation. I hate the NAT issues we run into on every project that requires site to site connectivity (we're using 172.16/16.... Oh neat, so are we!) and the NAT hoops you have to jump through. But then again, it's hard to work with "network engineers" that get lost once you start moving off of octet boundries for netmasks.
If there was a decent ISP that provided both IPv4 and IPv6 connectivity with little to no overhead, I'd seriously start looking and doing pilot projects. Until that happens or the IPv6 killer app comes along, I don't see much movement from IPv4, which is a testament to the flexibilty and scaleability of the protocol stack. I really am in awe at what IPv4 has been able to do....
I'm sorry mpapet, but I don't see the personal insults. You appear to come off attacking Vista without detailing any knowledge of actually using the product.
What do you expect when using terms such as "Longwait"????
Commitment to the shares required various steps which were clearly stated that if you sign up, you are responsible for the shares no matter which way they went (up or down). I think Vonage, or the institutions that performed the IPO should go after those that committed to the shares.
As part of the process they gave an estimate for the float price and cautioned that you should have X funds ready to send. I guess the real question is was there enough information during the signup process to authenticate the person and informing them of the rules of the IPO. I would think so, but then again, IANAL.
I looked into the IPO as I qualified and actually committed to a certain amount of shares. However, after speaking with investor friends, they recommended staying away from the IPO for various reasons. I went back to the site and retracted my offer. So I'm not on the hook for these shares.
They use the information for chargebacks, refunds, reconciliation, auto-renewal, etc..., etc...
Last time I read the VISA and MC guidelines, the only real requirement was that you are never supposed to store the VVC code for longer than you need to get the authorization. Everything else is fair game to store, subject to various security guidelines.
If you are still involved with card processing, you should read up on the latest guidelines. Basically, don't store the PAN or exipiration date unencrypted. And NEVER store the card verification code (CVV2, CVC2, or Amex's CID), track data, or PIN for debit transactions. It should be transmitted to the processor or authorizer and then deleted from memory.
This has been in effect for a couple years now, but only recently (post Card Systems) have the associations started to really crack down. Processors and authorization entities were the first to comply with the more stringent guidelines. Now that they are, for the most part CISP complaint, the next in the chain are merchants.
POS software should include authentication and logging, at minimum, pertaining to lookups of cardholder info. Even tighter controls on cardholder data access should be required.
Post-transaction events such as chargebacks and returns do require access to cardholder details, at least the PAN.
Sear's may have an auto capture for authorized transactions, but just because an auth went through does not mean it will be automatically captured at the end of the day. It's not the card associations that perform the capture, but the merchant or processor.
It's quite common for a processor to offer a single pass transaction type (auth, and if approved automatically capture and settle the transaction), but two pass transactions are used by savvy merchants to reduce chargeback risks.
But back to your GP post, if someone offers a pre-order and stipulates that you'll be charged in advance, that's valid by most association rules.
Well, you don't need a card per se, but it is probably better to have the timing on a Digium card vs. using zapdummy.
I have my home * server with an FXO card and then use IAX to talk to my co-lo server (zapdummy). It's a good box to then tie to VoIP providers such as NuFone and Voicepulse.
I'm setting up a 50-odd user environment right now with the kicker being four different countries. Just try to get an Avaya or Nortel partner to quote project management and integration costs for two countries.
Blessed be the markster and the OSS application *.
Gameplay is good (PGR3, CoD2, Kameo), and partly due to the eye candy. This is more true for Call of Duty than the other games IMO, but even the game menus being clean and sharp is pleasing too. It's also nice to go to then Live Marektplace and download 720p trailers and music videos too.
And the quality of the MCE content is quite nice (SD right now since I'm still up in the air over the HD solution.
It's the total integration of the 360 that makes it a pleasure to use. Drop on an iPod and have access to all non-DRM songs with only a single downlaod (iPod optional support for AAC). Access to photos and music on PC's and video content via MCE 2005.
The Live aspect is also quite nice with the common look and feel across all games.
So I can understand that there are few "next-gen" games out, just like any other console launch. But I'd rather work through the games that are there over the next few months while new "next-gen" games trickle out. Looking forward to Burnout Revenge, just wish I could copy over my Xbox profile to it!!!
Well, if it's social engineering, it's working well for MS, dont'cha think? Should increase the buzz and gain MS some marketshare (until the PS3 comes out).
My 360 shipped Friday (the Coscto bundle) and is due to arrive on the 28th (shipping from infamous Ontario, CA). Looking forward to using it as a MCE extender and Christmas gift for the kids.
Well, you could always keep your passport locked in the hotel safe.
Of course, the supposed terrorist could always check:
a) Does the individual wear white tennis shoes (black socks and shorts optional)? b) Speak in a loud and/or abrasive manner? c) Stands to the left on an escalator (or any other cultural misqueue)
Being an US citizen and traveling abroad quite often to Europe, it's not too hard picking out my compatriots.
The same can be said for European's in the US. European males -- LOSE THE MAN-CAPRI'S PLEASE!:)
I see you mention Mac Mini noise, but others, even on the one page you reference, state exactly the opposite. Friends with Mini's (and love them) say the same thing. Quietest machine they have.
If there was better PVR software for the Mini, I'd end up getting one instead a separate MythTV front-back end....
CISP (Visa) has been gently put in place over the last few years. SDP (MasterCard) has been a more formal process and based upon tiers. Do a large gross volume annually or are considered an acquirer? You needed to be compliant last June 30th.
The problem was that the CISP and SDP "best practices" never jived up. Case in point:
Visa - You need to protect cardholder data. Encryption was recommended but compensating controls were sufficient.
MasterCard - Strong encryption of all persistant cardholder data. No ifs, ands, or buts. Go ask First Data, Nat West (err Royal Bank of Scotland) or any of the other large (as in trillions of dollars processed per year) if every card number is encrypted. Answer - zero. In fact, certain large processing entities has special dispensations from the associations.
Along comes PCI (URLs in previous posts) that homogenizes the various best practices and brings on board American Express and Discover too. This is good news in that some of the absurd "rules" (Visa - 30 day password expiry) have been changed to more practical and achievable goals. Oh, and the stupid rule of only displaying the last 4 digits of the card. The first 6 digits are needed to figure out who the issuer is so you can go back and smack them over the head when a transaction fails for some strange ISO response code.
This does go into effect on July 1st of this year along with the ongoing requirements by V, MC, D, and AX.
But back to the point. We absolutely need better controls and protection than a MOD-10 checked 13, 16, or 19 digit number (easily generated), expiration date (date/year hopping pretty standard fraud seen, especially since a valid card number is pretty much guarateed to get a hit within 30 tries - (12*5)/2 ). The CVV2/CVC2/CID checks are good, but again comes down the association mandate "thou shalt not store *ever* CVV or track data". Want to know how many log files, trace files, and such this data is stored in during development? Post implementation audits see this data being stored accidentily all the time. And before someone brings up good software design and security requirements to eliminate such risks, work 6 months in the payments field. It will scare the hell out of you.
To meet this years requirements of encrypted data: use a SAN and central storage solution for systems that process data and then add a hardware level (block) encryption unit such as Decru sells. Do the same for tape backup and the majority of CISP/AIS/SDP/PCI technical requirements will be met.
I'll lay $50 on the table that next year fully logged access and the beginnings of PKI or some other strong key management solution will be necessary. Maybe some of the "PCI certified" auditors would care to chime in on what they are seeing?
Anyway, don't be too afraid. Annoyed and concerned at the hours you would need to spend in the case of fraud or identity theft maybe. But the issuer will pick up the tab as long as it's not some stupid mistake on the cardholder.
I'd never use my debit card except in emergency situations though.....
The ACR bit irks me too. But what I hear is that the lack of D2X support is that Nikon (again) changed (again) the NEF format. Over at Nikonians someone mentioned that the new NEF may be encrypted. More than likely just changed enough to cause Adobe and other capture vendors headaches.
Slashdot Mirror
I'm assuming you can run KDE *slowly* through an X11 server (Apple's for OS X) or the various ones available for Windows (eXceed, cygwin, etc).
Where are Windows and OS X versions??? I'd love to try it out as I'm always looking for a new music, podcast, and video management tools.
As for the "address" info - a very well-written system put in front of the credit card processing networks will do a real postal database lookup on an address. That's nice. It's also exceedingly rare. What you normally get for address verification is what the credit card processing networks themselves provide: AVS, the Address Verification Service.
A few interesting notes on AVS:
1) It only validates the digits in the street address and zip code, nothing else. So 123 Fake Street and 123 Oak Street are exactly the same in it's eyes.
2) It never rejects a transaction. Even if the address is wrong, it's approved. It's up to the merchant to check the response from the credit card processing network that says "the address was right" or "the address was wrong" or a dozen values of "the address was kinda' right" and then void the transaction if the response is unacceptable to them. VbV and MC SecureCode also give additional discount rates. I think upwards of 25-50 basis points.
We setup a special authorization transaction type for AVS, basically AVS+Auth. AVS was tried first, and only if succeeded would we follow up with an authorization request. And since AVS only checks can be completed for a marginal amount (less than 2 cents), was our first line of fraud detection for the merchant. Ugh, I still remember the various ISO 8583 single character return codes for AVS.
I have to get out of financial services.....
There are better systems, just ask our Europeans counterparts. It's near impossible to buy anything in the UK (and I assume other EU countries) where the merchant does not have chip/PIN capability. Chip cards significantly reduce the risk to the merchant, and thereby reduce the discount rate paid, and provides the merchant with more chargeback rights.
Granted, if the merchant puts out a Visa or MC logo, they still have to honor swiped transactions (not withstanding that one Brick Lane curry house that kept saying no-no-no-chip only -- but I digress), but will do everything in their power (and the merchant agreement) to dissuade swiped transactions.
Anyone who's had to work with Mastercard Visa, AMEX, Discover, JCB/Diners, and the rest know how bad it can be. But remember, these are just the associations. Look to the members who make up these organizations (or sit on the board of the publicly traded ones) and ask them why they haven't increased security. That's you BoA, Chase, Citi, and the rest.
But then again, one step down the food chain (and off to the side) are the acquirers. If they and the the ISO's under them would provide merchants (their clientele) with chip/PIN solutions, that would go a long way to help the merchants out. Supporting such solutions, on razor thin margins (measured in single basis points in the most competitive markets) is always low on the list (along with decent merchant reporting).
But, then again (2), the issuers would have to have products that support Chip/PIN. The only one I ever see, AMEX Blue, may be a good card, but I bet it's still used 98% of the time as a regular old track 2 swiped transaction. I'm interested in any large merchant that has card readers capable of chip transactions.
So, you have the unholy triumvirate: banks and issuers that give out cards; ISO's / acquirers that accept card and settle for the merchant; and the associations that sets the rules for card acceptance, fraud processes, and such. If I was Visa, I'd issue a mandate to, err, issuers, that as of date x, all cards must be chip capable (with world-wide standards). At date x+n, acquirers, ISO's, and merchants must be capable of accepting Chip/PIN cards or face fines.
Anyone who has had to deal withe craziness of PCI and it's predecessors knows the frustration, fear, and pain of not meeting association deadlines.
And while I'm on it, what is the adoption rate of Verified by Visa or the other SET-based solutions? These offer reduction is discount rates too, if implemented.
Sorry for the rant, but having a waiter tell me to go down to a cash machine because by US-issued credit card isn't chip capable has got me a little feisty.
What story are you referring to?
The only one that had inflammatory hand wringing was the Mp3 player that Sound emitted from the line is then interpreted using a modem line tap, or passed through a Ukrainian computer software program which is illegal to purchase.
And yes, there is crypto, at least for US ATM networks, between the ATM and end unit HSM.
This isn't a comment regarding the original article, just this particular story.
So the only email definitions come from the RFC's?
There is really no benefit that I've witnessed from a client perspective in not allowing me to use my own machine and tools.
Now, the quoted statement of having me use my own machine coupled with the limitation of not having my tools available and also not being able to use the resources available through my company's network for the client's benefit seems like a worse situation for a client than any of the previous ones.
No matter from which angle I try comparing the three typical scenarios with using ACE for the suggested purpose, I fail to see the bottom-line benefits for a company relying on consultants / contractors.
Banks. Financial Institutions. Today the risk folks run the show. A lack of demonstrable controls, even if over the top, can impact the bottom line. SOX, 404, BASEL II, SAS 70, ISO17799, etc.
Some of the more stringent clients I work for have gone a step further, and something that ACE may address. All developers are moving to VMware guests on a locked down VLAN. They have nice big monitors and a standard corporate image on their desk, but all development work is through RDP. The premise being that code can flow into the dev environment, but only certain people can promote code out of dev to the test, QA, and UAT.
Some organizations will take the productivity hit in order to assure (or enhance) the control of their development and operational environment. I think it really comes down to the organization to make the decision.
And VMware is listening to some, as ACE does address concerns I've seen. I just hopes it's more stable than VC 1.x or 2.0.....
What most of the MS Money and Quickens do is hide double entry accounting. For general tracking of *an* account, a spreadsheet is functional.
I like the OFX integration of Quicken/Money/GNUcash. Well except for the recent MBNA purchase by Bank of America.
Rant: So I can no longer download transactions for my MBNA Visa bugged card because I don't have any other accounts with BoA? And, the transition isn't going so well either. I can manually download transactions, but historical only (sayeth the CSR).
MBNA has a crapload of branded MasterCard/Visa products, and the only one that I know of that has no foreign transaction fee (AAA Visa).
Alas, the ability to offload the import of transactions into my money management software is more important that a 1% FX fee. Simmons Trust, here I come.
"A chain of Florida convenience stores has begun accepting fingerprints as payment, using a biometric system called Pay By Touch. The company is a Bay-area startup backed by $130 million in VC cash and the acquisition of BioPay, a Virginia-based biometrics firm that's already done $7 billion in European transactions...
Okay, we just need an Australian court to decide the distribution of remaining assets to Japanese investors on the sellers in Nigerian government officials to make this truly a world-wide story.
After getting burned back in the late 80s / early 90s with the OSI protocol mandates, I'm leery of anything the US government mandates. Then again, look how well Ada turned out too.
I'm torn on the IPv6 situation. I hate the NAT issues we run into on every project that requires site to site connectivity (we're using 172.16/16.... Oh neat, so are we!) and the NAT hoops you have to jump through. But then again, it's hard to work with "network engineers" that get lost once you start moving off of octet boundries for netmasks.
If there was a decent ISP that provided both IPv4 and IPv6 connectivity with little to no overhead, I'd seriously start looking and doing pilot projects. Until that happens or the IPv6 killer app comes along, I don't see much movement from IPv4, which is a testament to the flexibilty and scaleability of the protocol stack. I really am in awe at what IPv4 has been able to do....
Mac OS X / Linux - Mature Production OS
Windows Visa - Beta 2, not even CTP yet....
Maybe they are using the beta to determine the appropriate balance of user prompting that doesn't piss the users off or desensitize them too much?
sudo does work fine except I find the priviledge escalation from user to root to be a little too, how should I say it, extreme?
I'm sorry mpapet, but I don't see the personal insults. You appear to come off attacking Vista without detailing any knowledge of actually using the product.
What do you expect when using terms such as "Longwait"????
Commitment to the shares required various steps which were clearly stated that if you sign up, you are responsible for the shares no matter which way they went (up or down). I think Vonage, or the institutions that performed the IPO should go after those that committed to the shares.
As part of the process they gave an estimate for the float price and cautioned that you should have X funds ready to send. I guess the real question is was there enough information during the signup process to authenticate the person and informing them of the rules of the IPO. I would think so, but then again, IANAL.
I looked into the IPO as I qualified and actually committed to a certain amount of shares. However, after speaking with investor friends, they recommended staying away from the IPO for various reasons. I went back to the site and retracted my offer. So I'm not on the hook for these shares.
They use the information for chargebacks, refunds, reconciliation, auto-renewal, etc..., etc...
Last time I read the VISA and MC guidelines, the only real requirement was that you are never supposed to store the VVC code for longer than you need to get the authorization. Everything else is fair game to store, subject to various security guidelines.
If you are still involved with card processing, you should read up on the latest guidelines. Basically, don't store the PAN or exipiration date unencrypted. And NEVER store the card verification code (CVV2, CVC2, or Amex's CID), track data, or PIN for debit transactions. It should be transmitted to the processor or authorizer and then deleted from memory.
This has been in effect for a couple years now, but only recently (post Card Systems) have the associations started to really crack down. Processors and authorization entities were the first to comply with the more stringent guidelines. Now that they are, for the most part CISP complaint, the next in the chain are merchants.
POS software should include authentication and logging, at minimum, pertaining to lookups of cardholder info. Even tighter controls on cardholder data access should be required.
Post-transaction events such as chargebacks and returns do require access to cardholder details, at least the PAN.
Sear's may have an auto capture for authorized transactions, but just because an auth went through does not mean it will be automatically captured at the end of the day. It's not the card associations that perform the capture, but the merchant or processor.
It's quite common for a processor to offer a single pass transaction type (auth, and if approved automatically capture and settle the transaction), but two pass transactions are used by savvy merchants to reduce chargeback risks.
But back to your GP post, if someone offers a pre-order and stipulates that you'll be charged in advance, that's valid by most association rules.
Well, you don't need a card per se, but it is probably better to have the timing on a Digium card vs. using zapdummy.
I have my home * server with an FXO card and then use IAX to talk to my co-lo server (zapdummy). It's a good box to then tie to VoIP providers such as NuFone and Voicepulse.
I'm setting up a 50-odd user environment right now with the kicker being four different countries. Just try to get an Avaya or Nortel partner to quote project management and integration costs for two countries.
Blessed be the markster and the OSS application *.
Gameplay is good (PGR3, CoD2, Kameo), and partly due to the eye candy. This is more true for Call of Duty than the other games IMO, but even the game menus being clean and sharp is pleasing too. It's also nice to go to then Live Marektplace and download 720p trailers and music videos too.
And the quality of the MCE content is quite nice (SD right now since I'm still up in the air over the HD solution.
It's the total integration of the 360 that makes it a pleasure to use. Drop on an iPod and have access to all non-DRM songs with only a single downlaod (iPod optional support for AAC). Access to photos and music on PC's and video content via MCE 2005.
The Live aspect is also quite nice with the common look and feel across all games.
So I can understand that there are few "next-gen" games out, just like any other console launch. But I'd rather work through the games that are there over the next few months while new "next-gen" games trickle out. Looking forward to Burnout Revenge, just wish I could copy over my Xbox profile to it!!!
Well, if it's social engineering, it's working well for MS, dont'cha think? Should increase the buzz and gain MS some marketshare (until the PS3 comes out).
My 360 shipped Friday (the Coscto bundle) and is due to arrive on the 28th (shipping from infamous Ontario, CA). Looking forward to using it as a MCE extender and Christmas gift for the kids.
Well, you could always keep your passport locked in the hotel safe.
:)
Of course, the supposed terrorist could always check:
a) Does the individual wear white tennis shoes (black socks and shorts optional)?
b) Speak in a loud and/or abrasive manner?
c) Stands to the left on an escalator (or any other cultural misqueue)
Being an US citizen and traveling abroad quite often to Europe, it's not too hard picking out my compatriots.
The same can be said for European's in the US. European males -- LOSE THE MAN-CAPRI'S PLEASE!
I see you mention Mac Mini noise, but others, even on the one page you reference, state exactly the opposite. Friends with Mini's (and love them) say the same thing. Quietest machine they have.
If there was better PVR software for the Mini, I'd end up getting one instead a separate MythTV front-back end....
Do you know what I'd like in Office 2003? To have the frickin' menu bars not move around. It's like trying to herd cats dealing with menu bars.
Oh, and when Word is used as the editor for Outlook, the menu bar selection gets changed to things such as "e-mail". Grrrrr.
The good news is that this horrible behavior is consistant throughout the Office suite, including Project '03 and Visio '03 too.
CISP (Visa) has been gently put in place over the last few years. SDP (MasterCard) has been a more formal process and based upon tiers. Do a large gross volume annually or are considered an acquirer? You needed to be compliant last June 30th.
The problem was that the CISP and SDP "best practices" never jived up. Case in point:
Visa - You need to protect cardholder data. Encryption was recommended but compensating controls were sufficient.
MasterCard - Strong encryption of all persistant cardholder data. No ifs, ands, or buts. Go ask First Data, Nat West (err Royal Bank of Scotland) or any of the other large (as in trillions of dollars processed per year) if every card number is encrypted. Answer - zero. In fact, certain large processing entities has special dispensations from the associations.
Along comes PCI (URLs in previous posts) that homogenizes the various best practices and brings on board American Express and Discover too. This is good news in that some of the absurd "rules" (Visa - 30 day password expiry) have been changed to more practical and achievable goals. Oh, and the stupid rule of only displaying the last 4 digits of the card. The first 6 digits are needed to figure out who the issuer is so you can go back and smack them over the head when a transaction fails for some strange ISO response code.
This does go into effect on July 1st of this year along with the ongoing requirements by V, MC, D, and AX.
But back to the point. We absolutely need better controls and protection than a MOD-10 checked 13, 16, or 19 digit number (easily generated), expiration date (date/year hopping pretty standard fraud seen, especially since a valid card number is pretty much guarateed to get a hit within 30 tries - (12*5)/2 ). The CVV2/CVC2/CID checks are good, but again comes down the association mandate "thou shalt not store *ever* CVV or track data". Want to know how many log files, trace files, and such this data is stored in during development? Post implementation audits see this data being stored accidentily all the time. And before someone brings up good software design and security requirements to eliminate such risks, work 6 months in the payments field. It will scare the hell out of you.
To meet this years requirements of encrypted data: use a SAN and central storage solution for systems that process data and then add a hardware level (block) encryption unit such as Decru sells. Do the same for tape backup and the majority of CISP/AIS/SDP/PCI technical requirements will be met.
I'll lay $50 on the table that next year fully logged access and the beginnings of PKI or some other strong key management solution will be necessary. Maybe some of the "PCI certified" auditors would care to chime in on what they are seeing?
Anyway, don't be too afraid. Annoyed and concerned at the hours you would need to spend in the case of fraud or identity theft maybe. But the issuer will pick up the tab as long as it's not some stupid mistake on the cardholder.
I'd never use my debit card except in emergency situations though.....
You mean $129 every 18 months or so. Well worth every penny, at least every other upgrade.
The ACR bit irks me too. But what I hear is that the lack of D2X support is that Nikon (again) changed (again) the NEF format. Over at Nikonians someone mentioned that the new NEF may be encrypted. More than likely just changed enough to cause Adobe and other capture vendors headaches.
Having a D70, that ain't a problem for me....
Try asterisk@home for a good distro that should do most of the easy stuff "out of the box".