A few TCP packets, compared to uncompressed TIFF files? I rather do think so.
That's like saying "what do you mean you didn't notice fifty kilos of material missing???!?!?!!?" when you're talking about hauling away the debris after demolishing a sky-scraper.
I've been following the issue. Google didn't collect traffic if it was encrypted in any way.
I mean, I think you knew that and were being snide at the morons who think this is an invasion of privacy. I'm just clearing it up for those readers who aren't up to date.
This is crap. You're obscuring the issue completely. Try this analogy instead:
If you were standing naked on your front lawn with no fence or anything, and I'm walking down the road taking a video, is that ok? And of course, it's you're fault for standing out naked where everyone can see you. Google didn't have to peer in from the top of your tree: You were broadcasting this stuff to everyone anyway.
This is beyond ridiculous. It's no different to standing on your front lawn naked for everyone to see, and then being upset when the streetview van snaps you naked. I can't see why people have any expectation of privacy for unencrypted public-broadcast wireless traffic. The creepy guy across the road is probably logging it all anyway, right?
Everyone is yelling things like "it's clearly violating privacy and European laws", but I want to know how, and which laws. I'm just not buying it.
Another big problem is relating to their Anti-Money-Laundering/Counter-Terrorism-Financing (AML/CTF) policies. Basically, the more unusual a client is, the more carefully you have to watch them. If someone walks in with a reference from his employer, opens a standard account, has a driver's licence but no passport (because he's never left the country), makes a typical wage which shows up in his account weekly, and withdraws about a quarter of his income as cash and spends the rest on his card and paying his home loan and bills, you really don't have to watch him very hard. His behaviour is very well understood, and automated systems can flag unusual activity in real-time. He's very cheap to manage and he seldom does anything unexpected. To a lesser extent, the same goes for a Fortune 100 company: their banking patterns are much more complex, but the banks have learned to understand them because of how much money is involved.
On the other hand, if you're a consumer and you walk in wanting API access, the bank doesn't understand you at all. They know you're both technically and financially savvy, which is a point against you from a risk-based point of view. They don't know why you want API access, and they have to pay one of their expensive analysts to work out if it's above-board. They're fairly comfortable with their API as a secure platform (or maybe they aren't!) but they're worried that you will find something they haven't; and being "just some guy", if you do find a problem with it, they're worried about you jumping on a yacht with a bunch of their money and disappearing.
From their perspective, they will have to spend a lot of money becoming more aware of the sorts of usage patterns they would see from "some guy who wants API access", and they'll have to spend more money on their security as well. And you're still a bigger risk than if they just didn't bother and made you use the website like everyone else.
I'm not saying I like it, but I've worked in software engineering in the banking world, and I have some idea what the reasoning behind it all is.
My advice would be to find someone who already has access to the sort of API you need and suggest a joint venture or partnership with them. Good targets are payroll companies, invoicing and billing houses (the sort you sign up for if you're some handyman who wants to let his clients pay via web or phone banking), investment managers, and stored value card providers. The final option is a good target, because they're a fairly new industry and more likely to still be fairly entrepreneurial. Some stored value providers even maintain their own back end, and may be in a position to give you what you need through their own internal API without relying on a bank at all.
And it's been tested in court, which is what I really meant: I'm not sure what the correct term would be. I don't recall the parties, but I followed the case with interest in the late 80s or early 90s.
In Australia, there's a legal precedent saying that code written by an employee is owned by the employer, even if the employment contract doesn't mention it.
IANAL either, but my dad went through this (we're both software developers). (In Australia, at least, and barring contractual agreements to the contrary...) if you're working as a contractor, you own the code you write, but your client is entitled to exploit it for the purposes envisaged by the contract or agreement. If you're employed as... well, an employee (which I assume is the case here), they own everything you write in the capacity in which they're paying you. You have no control, they own the copyright.
That is entirely separate to what they can DO with the code once written, but that's between them and the licences on the code they're developing on top of. If you're an employee, it's also not your problem if they can't do what they intended to with it: the company made the decision to hire you, the company went down the path they did (even if you were the one deciding to).
This is exactly the opposite of reality. In reality you don't get promoted by cleaning up after people. If you are ready and willing to always clean up after people, especially your boss, then your boss will want to keep you right where you are to keep cleaning up after them.
This assumes you're going to be working for the same boss long-term, which means he's going to be where he is long-term. Anyone who ends up in this situation needs to look for a way out, and that comes (chiefly) out of cross-team projects, and having people on other teams wanting you on theirs. Get an upwardly-mobile boss in an upwardly-mobile chain if you want to go somewhere.
Also, I would certainly never advocate rescuing someone and letting them have the credit. Generally, by the time someone you argued with over how to do it in the first place is ready to admit defeat and let you fix it, things are a right mess, and people higher up in your organization are paying attention. They need to see you sorting things out, or, like you said, it's not worth the effort.
On the other hand I realize that all my success in life has come from my determination and not some silly rules as to how one should act at all times.
I couldn't agree more. I don't so much have "a system" as I have "the things which worked in the past", and it's probably the case that what works for one person will be totally useless in the hands of another.
For those that don't know, "acting like a know-it-all" is just something that less knowledgeable people like to say about us more knowledgeable people, as if they are taking some moral high ground by being less knowledgeable.
I guess it's redundant by now, because you've been called out by half the other replys, but I wanted to point out the genius of setting anyone who disagrees with you up for going called one of those "less knowledgeable people" who like to call "more knowledgeable people [like you]" a know-it-all. Which is, of course, exactly how you sound: a know-it-all (which, despite your protestations that it's really a badge of honor to be called one, is almost universally considered a derogatory term). It is, of course, not about a less knowledgeable moral high ground, but about the fact that the know-it-all has their own little patch of high ground they're sitting on, failing dismally to communicate with anyone they see as 'less smart' (despite often being wrong about that).
That being said, when you are first starting out, and really anytime you are talking to someone higher in your chain of command, Just point out what you know and let others make the wrong decision. Don't ever clean up after someone else when you already told them what was the right way to do something, let people deal with their own messes.
This is a great approach if you want to obsolete yourself into a corner. People will learn that you're not someone they should take problems to, and you'll find yourself in a little corner where you can do the minimum, never talk to anyone else, and never make any progress in your career. Which is, of course, perhaps exactly what you wanted.
A better approach is to point out what you know, try to help make decisions, but back down and prepare a disaster recovery plan if you're just not going to win. Then, when everything falls apart, you get to be not the guy who just says "told you so" and doesn't contribute, but the guy who steps in and sorts it all out, quickly and without fuss. You'll gain a reputation for being easy to deal with and getting effective results even in the face of disaster, and you will actually get somewhere in your career.
Ah, but you agreed with what I said, despite leading with a 'No'. The GP said things like "Don't mention anyone else's culpability", which is what I objected to. I said "When a colleague has royally screwed up... avoid pointing the finger", and then "if your manager approaches you directly looking for fault, be honest. Don't cover for the guy: that's his manager's job, not yours." (Unless, of course, you are his manager, but the original question was from a graduate who won't be in that position for quite some time).
The GP was advocating secrecy and misleading the people you report to (and assuming the people who need to know will somehow have time to hang around with the team, analyse the gossip, and work out "how much you were actually involved in both successes and failures", in spite of the fact that you're... well, lying to them about it).
I'm gonna assume you want to build a career, develop a great reputation, be able to change jobs easily (because you're references are all amazing), and make lots of money.
Dress well. It sounds trite (and engineers always like to think people will see past that), but the fairest manager ever will think twice about promoting you up a level if he's worried your appearance will make his choice look embarrassing to people who don't know your ability.
Communicate well and keep records. Use the phone sometimes (engineers often like to avoid actually talking to people), because it leaves a more personal impression, but always follow up with an email.
Be good value. Your boss needs to know that he's getting plenty out of having you on salary. If you're asked to build a solution to a problem, don't leave it half-done or buggy. Don't save whoever uses it a half-hour where you could save them an hour (unless it will take you substantially longer than you're supposed to spend).
Be pro-active. Think of things you can do to make things run more efficiently, and get your boss's permission to spend time on them. Follow them through. You want people to be saying "I used that tool Tim built last week and it saved me hours!"
When your annual review rolls around, have a decent list of things you've done to add value. Point them out. Your annual (or quarterly, or whatever) review is when you're supposed to brag about your accomplishments.
Be honest with your manager, fair to your co-workers, keep things said in confidence in confidence, and try to avoid blaming others when things go wrong (unless you're asked directly, and then: BE FAIR).
Know when to admit defeat. Engineers, in particular, want to always do things "The Right Way", and we have trouble understanding why we get over-ruled and told to do it "The Other Way". Remember that correct engineering isn't the only pressure (there are things like Time, Budget, Personality Clashes, CEO's Nephew Who Needs To Be Kept Happy, and even less sensible stuff), and some of the people you work with might be better at balancing the irrational-but-necessary than you. Get your rational objections on the record, and just do what you're told. Be ready with a way to save the day when everything goes to crap.
Finally, get on with people. Don't be a push-over or anything, but go out with your co-workers for coffee (not so much you seem like a slacker who's always off getting coffee). If there are Friday Arvo Beers at the pub, go to them, and talk with different people. Greet the receptionist in the morning. You don't want to be everyone's best mate (you'll just look like a suck-up), but try to leave a basically-positive impression on as many people as possible.
Here is the secret to advancing in virtually any endeavor you pursue, with the possible exception of politics: always take the blame, never accept the credit. If something goes wrong and you had the slightest smidgen of responsibility for it, step up and say you messed up. Don't mention anyone else's culpability. Bring up solutions for how to fix it. But if something goes well, credit the whole team, even if you did 99% of the work. When describing a success, get used to using the word "we." Believe me, people will figure out how much you were actually involved in both successes and failures.
This is a great way to have your co-workers think you're such a great guy as they walk all over you. In addition, management likes to have the whole story, and if you're seen as covering things up (even if it's covering for your co-workers), you will appear untrustworthy to the people trying to run your department. A successful company has good visibility of responsibility and performance across all its employees, and getting in the way of it is getting in the way of success.
I would suggest people never take credit where they don't deserve it (it looks so bad when you're caught out), but make sure you contribute solidly and be proud of your achievements. When a colleague has royally screwed up, be pro-active in sorting out the screw-up and don't be afraid to take credit for saving the day, but avoid pointing the finger. Focus on making it a 'pull together and fix it, who cares whose fault it is' effort, but if your manager approaches you directly looking for fault, be honest. Don't cover for the guy: that's his manager's job, not yours.Your manager needs to know what happened.
I'm speaking from experience: I sat in a company for nearly four years trying to be humble about what I did. I watched morons walk in, avoid screwing up too badly, take a bunch of credit for things they didn't really do themselves, and keep getting promoted ahead of me. I moved companies and started keeping my manager in the loop about what I thought I was accomplishing, being honest (in private) to my manager about problems I saw in the department, and generally trusting that honesty was a better policy than trying to make sure I was all good-guy with everyone, and life has been much better ever since. I've moved again since, but my manager now sees me as the guy in the group he can go to and get honesty about problems the team is keeping silent about, and my co-workers see me as someone they can approach to help them sort out problems they're having with management.
That's not to say you should blab to management about things told to you in confidence: I'm only talking about things everyone knows but won't 'blab' about. I think the most important thing you can do to not piss people off is keep what you're told in confidence, in confidence.
I suppose the ultimate counter-point is that a PoS without an internet connection cannot deliver enough functionality to be attractive to a merchant to use. Merchants want to be able to opt in to new PoS value-added services for no cost (any more than "install the software and select some options" will never sell). PoS machines are usually on a LAN behind a NAT/firewall, like I said, so they're still behind some basic security; they still usually have full out-going 'net access.
As well as that, PoS machines generally don't have access to payment details. The financial transaction will usually go through a separate payment device provided by the bank (that little terminal they swipe your card through), and the best sniffer on earth can't access data which just isn't there. These payment devices are, increasingly, connecting to the banks via the internet as well! The device is much better secured than the PoS PC would be, though, and the encryption uses a rolling-key approach which is much stronger than standard SSL. So you see, lots and lots of attention has already been paid to a sensible multi-layered security model which includes internet access.
The problem with TJX was that several layers failed: the private LAN they were using wasn't really private; the PoS systems were also processing the payments (some other larger retailers still do this, but it isn't the prevalent model); the payment system in use was nowhere near PCI compliant. Breaches don't happen simply because PoS systems have internet connections: they happen because a range of different levels of security fail. "No internet access" would add a layer of protection much weaker than most of the existing layers, while being a major impediment to functionality.
Which is why PoS systems have, and will continue to have, internet connections.
I don't see what the problem is. The TJX data breach WAS on a private lan (albeit one someone had plugged a wireless router into). I can't think of any major PoS breaches which occurred over the internet. The simple fact is, there are easier ways to steal. Are you gonna come up with complicated exploits and try to crack encryption or steal keys, or are you just gonna get a minimum wage checkout job and shove a USB key into the boss's computer?
Anyway, as the service vendor, we're not interested in fixing the security problems of our clients. We're interested in providing a secure service. We expect our clients to secure their PoS machines, using firewalls and by buying actually secure PoS systems, but we can't force them. MasterCard takes care of that for us, and we're not going to convince them we know better than MasterCard.
My point is that they need an internet connection.
I guess you've never worked in this space. When there's one provider serving PoS machines across thousands of sites, with everything from single-register florists up to supermarket and fuel chains, you need a cost-effective way of connecting tons of different sites.
Add to that the fact that a single PoS installation may be using live services from four or five different providers, and the best solution by far is to use the internet.
Perhaps you should go spend five or six years working in retail payment software before you decide how dumb we all are.
Spend some time working out how much this cost, and then show them how cheap it would be to avoid. A cost-effective way is to have juniors or admin staff crash-dummy the updates, and it doesn't cost too much in lost productivity if their machines bomb. Roll updates out to everyone else a day or so later.
You can get a good hardware spread by sending one machine from each new batch into the testing pool.
If the penalty does run that high, it was a good trade-off to do penalty clauses instead of your own QA. Lots of job roles these days do grind to a halt, though: the company I work for at the moment grinds to a total halt without computers (we're doing weather modeling, and slide rules just don't cut it anymore).
Your point is correct, but it's rare to do the CBA and come out with "don't bother testing anything", at least for any moderately-sized business. Numbers like 1,000 PCs have been thrown around. Let's assume:
The cost per hour of downtime is $10,000 + $140,000 + $100,000 = $250,000. For one hour. Imagine it takes half a day. You get to add in lost IT productivity, opportunity cost, and reputational loss as you fail to deliver to your clients. One incident can cost millions. A testing-in-production policy (where a few guinea pigs get all updates a day or so early) is incredibly cheap to run.
Physical security: solid case, no USB/floppy/whatever. That should do the trick. Staff normally does not start meddling with hardware - if they start doing that, you will have bigger problems on your hands than just a virus risk.
Yep. You've hired GEEKS. Employers should be screening for this stuff.
Lots of modern PoS systems do all sorts of live processing. Loyalty. Marketing. They're all run by third-party systems, and they're often live. That's why the PoS computer has an internet connection.
Slashdot Mirror
A few TCP packets, compared to uncompressed TIFF files? I rather do think so.
That's like saying "what do you mean you didn't notice fifty kilos of material missing???!?!?!!?" when you're talking about hauling away the debris after demolishing a sky-scraper.
I've been following the issue. Google didn't collect traffic if it was encrypted in any way.
I mean, I think you knew that and were being snide at the morons who think this is an invasion of privacy. I'm just clearing it up for those readers who aren't up to date.
This is crap. You're obscuring the issue completely. Try this analogy instead:
If you were standing naked on your front lawn with no fence or anything, and I'm walking down the road taking a video, is that ok? And of course, it's you're fault for standing out naked where everyone can see you. Google didn't have to peer in from the top of your tree: You were broadcasting this stuff to everyone anyway.
This is beyond ridiculous. It's no different to standing on your front lawn naked for everyone to see, and then being upset when the streetview van snaps you naked. I can't see why people have any expectation of privacy for unencrypted public-broadcast wireless traffic. The creepy guy across the road is probably logging it all anyway, right?
Everyone is yelling things like "it's clearly violating privacy and European laws", but I want to know how, and which laws. I'm just not buying it.
Another big problem is relating to their Anti-Money-Laundering/Counter-Terrorism-Financing (AML/CTF) policies. Basically, the more unusual a client is, the more carefully you have to watch them. If someone walks in with a reference from his employer, opens a standard account, has a driver's licence but no passport (because he's never left the country), makes a typical wage which shows up in his account weekly, and withdraws about a quarter of his income as cash and spends the rest on his card and paying his home loan and bills, you really don't have to watch him very hard. His behaviour is very well understood, and automated systems can flag unusual activity in real-time. He's very cheap to manage and he seldom does anything unexpected. To a lesser extent, the same goes for a Fortune 100 company: their banking patterns are much more complex, but the banks have learned to understand them because of how much money is involved.
On the other hand, if you're a consumer and you walk in wanting API access, the bank doesn't understand you at all. They know you're both technically and financially savvy, which is a point against you from a risk-based point of view. They don't know why you want API access, and they have to pay one of their expensive analysts to work out if it's above-board. They're fairly comfortable with their API as a secure platform (or maybe they aren't!) but they're worried that you will find something they haven't; and being "just some guy", if you do find a problem with it, they're worried about you jumping on a yacht with a bunch of their money and disappearing.
From their perspective, they will have to spend a lot of money becoming more aware of the sorts of usage patterns they would see from "some guy who wants API access", and they'll have to spend more money on their security as well. And you're still a bigger risk than if they just didn't bother and made you use the website like everyone else.
I'm not saying I like it, but I've worked in software engineering in the banking world, and I have some idea what the reasoning behind it all is.
My advice would be to find someone who already has access to the sort of API you need and suggest a joint venture or partnership with them. Good targets are payroll companies, invoicing and billing houses (the sort you sign up for if you're some handyman who wants to let his clients pay via web or phone banking), investment managers, and stored value card providers. The final option is a good target, because they're a fairly new industry and more likely to still be fairly entrepreneurial. Some stored value providers even maintain their own back end, and may be in a position to give you what you need through their own internal API without relying on a bank at all.
And it's been tested in court, which is what I really meant: I'm not sure what the correct term would be. I don't recall the parties, but I followed the case with interest in the late 80s or early 90s.
In Australia, there's a legal precedent saying that code written by an employee is owned by the employer, even if the employment contract doesn't mention it.
IANAL either, but my dad went through this (we're both software developers). (In Australia, at least, and barring contractual agreements to the contrary...) if you're working as a contractor, you own the code you write, but your client is entitled to exploit it for the purposes envisaged by the contract or agreement. If you're employed as ... well, an employee (which I assume is the case here), they own everything you write in the capacity in which they're paying you. You have no control, they own the copyright.
That is entirely separate to what they can DO with the code once written, but that's between them and the licences on the code they're developing on top of. If you're an employee, it's also not your problem if they can't do what they intended to with it: the company made the decision to hire you, the company went down the path they did (even if you were the one deciding to).
This is exactly the opposite of reality. In reality you don't get promoted by cleaning up after people. If you are ready and willing to always clean up after people, especially your boss, then your boss will want to keep you right where you are to keep cleaning up after them.
This assumes you're going to be working for the same boss long-term, which means he's going to be where he is long-term. Anyone who ends up in this situation needs to look for a way out, and that comes (chiefly) out of cross-team projects, and having people on other teams wanting you on theirs. Get an upwardly-mobile boss in an upwardly-mobile chain if you want to go somewhere.
Also, I would certainly never advocate rescuing someone and letting them have the credit. Generally, by the time someone you argued with over how to do it in the first place is ready to admit defeat and let you fix it, things are a right mess, and people higher up in your organization are paying attention. They need to see you sorting things out, or, like you said, it's not worth the effort.
On the other hand I realize that all my success in life has come from my determination and not some silly rules as to how one should act at all times.
I couldn't agree more. I don't so much have "a system" as I have "the things which worked in the past", and it's probably the case that what works for one person will be totally useless in the hands of another.
For those that don't know, "acting like a know-it-all" is just something that less knowledgeable people like to say about us more knowledgeable people, as if they are taking some moral high ground by being less knowledgeable.
I guess it's redundant by now, because you've been called out by half the other replys, but I wanted to point out the genius of setting anyone who disagrees with you up for going called one of those "less knowledgeable people" who like to call "more knowledgeable people [like you]" a know-it-all. Which is, of course, exactly how you sound: a know-it-all (which, despite your protestations that it's really a badge of honor to be called one, is almost universally considered a derogatory term). It is, of course, not about a less knowledgeable moral high ground, but about the fact that the know-it-all has their own little patch of high ground they're sitting on, failing dismally to communicate with anyone they see as 'less smart' (despite often being wrong about that).
That being said, when you are first starting out, and really anytime you are talking to someone higher in your chain of command, Just point out what you know and let others make the wrong decision. Don't ever clean up after someone else when you already told them what was the right way to do something, let people deal with their own messes.
This is a great approach if you want to obsolete yourself into a corner. People will learn that you're not someone they should take problems to, and you'll find yourself in a little corner where you can do the minimum, never talk to anyone else, and never make any progress in your career. Which is, of course, perhaps exactly what you wanted.
A better approach is to point out what you know, try to help make decisions, but back down and prepare a disaster recovery plan if you're just not going to win. Then, when everything falls apart, you get to be not the guy who just says "told you so" and doesn't contribute, but the guy who steps in and sorts it all out, quickly and without fuss. You'll gain a reputation for being easy to deal with and getting effective results even in the face of disaster, and you will actually get somewhere in your career.
Ah, but you agreed with what I said, despite leading with a 'No'. The GP said things like "Don't mention anyone else's culpability", which is what I objected to. I said "When a colleague has royally screwed up ... avoid pointing the finger", and then "if your manager approaches you directly looking for fault, be honest. Don't cover for the guy: that's his manager's job, not yours." (Unless, of course, you are his manager, but the original question was from a graduate who won't be in that position for quite some time).
The GP was advocating secrecy and misleading the people you report to (and assuming the people who need to know will somehow have time to hang around with the team, analyse the gossip, and work out "how much you were actually involved in both successes and failures", in spite of the fact that you're ... well, lying to them about it).
I'm gonna assume you want to build a career, develop a great reputation, be able to change jobs easily (because you're references are all amazing), and make lots of money.
Here is the secret to advancing in virtually any endeavor you pursue, with the possible exception of politics: always take the blame, never accept the credit. If something goes wrong and you had the slightest smidgen of responsibility for it, step up and say you messed up. Don't mention anyone else's culpability. Bring up solutions for how to fix it. But if something goes well, credit the whole team, even if you did 99% of the work. When describing a success, get used to using the word "we." Believe me, people will figure out how much you were actually involved in both successes and failures.
This is a great way to have your co-workers think you're such a great guy as they walk all over you. In addition, management likes to have the whole story, and if you're seen as covering things up (even if it's covering for your co-workers), you will appear untrustworthy to the people trying to run your department. A successful company has good visibility of responsibility and performance across all its employees, and getting in the way of it is getting in the way of success.
I would suggest people never take credit where they don't deserve it (it looks so bad when you're caught out), but make sure you contribute solidly and be proud of your achievements. When a colleague has royally screwed up, be pro-active in sorting out the screw-up and don't be afraid to take credit for saving the day, but avoid pointing the finger. Focus on making it a 'pull together and fix it, who cares whose fault it is' effort, but if your manager approaches you directly looking for fault, be honest. Don't cover for the guy: that's his manager's job, not yours.Your manager needs to know what happened.
I'm speaking from experience: I sat in a company for nearly four years trying to be humble about what I did. I watched morons walk in, avoid screwing up too badly, take a bunch of credit for things they didn't really do themselves, and keep getting promoted ahead of me. I moved companies and started keeping my manager in the loop about what I thought I was accomplishing, being honest (in private) to my manager about problems I saw in the department, and generally trusting that honesty was a better policy than trying to make sure I was all good-guy with everyone, and life has been much better ever since. I've moved again since, but my manager now sees me as the guy in the group he can go to and get honesty about problems the team is keeping silent about, and my co-workers see me as someone they can approach to help them sort out problems they're having with management.
That's not to say you should blab to management about things told to you in confidence: I'm only talking about things everyone knows but won't 'blab' about. I think the most important thing you can do to not piss people off is keep what you're told in confidence, in confidence.
You can't unlock the door from the passenger side?
That was the gist of the comment, yes.
There was no need for the overclarification
And again. This is slashdot
And again. This is slashdot
I suppose the ultimate counter-point is that a PoS without an internet connection cannot deliver enough functionality to be attractive to a merchant to use. Merchants want to be able to opt in to new PoS value-added services for no cost (any more than "install the software and select some options" will never sell). PoS machines are usually on a LAN behind a NAT/firewall, like I said, so they're still behind some basic security; they still usually have full out-going 'net access.
As well as that, PoS machines generally don't have access to payment details. The financial transaction will usually go through a separate payment device provided by the bank (that little terminal they swipe your card through), and the best sniffer on earth can't access data which just isn't there. These payment devices are, increasingly, connecting to the banks via the internet as well! The device is much better secured than the PoS PC would be, though, and the encryption uses a rolling-key approach which is much stronger than standard SSL. So you see, lots and lots of attention has already been paid to a sensible multi-layered security model which includes internet access.
The problem with TJX was that several layers failed: the private LAN they were using wasn't really private; the PoS systems were also processing the payments (some other larger retailers still do this, but it isn't the prevalent model); the payment system in use was nowhere near PCI compliant. Breaches don't happen simply because PoS systems have internet connections: they happen because a range of different levels of security fail. "No internet access" would add a layer of protection much weaker than most of the existing layers, while being a major impediment to functionality.
Which is why PoS systems have, and will continue to have, internet connections.
I don't see what the problem is. The TJX data breach WAS on a private lan (albeit one someone had plugged a wireless router into). I can't think of any major PoS breaches which occurred over the internet. The simple fact is, there are easier ways to steal. Are you gonna come up with complicated exploits and try to crack encryption or steal keys, or are you just gonna get a minimum wage checkout job and shove a USB key into the boss's computer?
Anyway, as the service vendor, we're not interested in fixing the security problems of our clients. We're interested in providing a secure service. We expect our clients to secure their PoS machines, using firewalls and by buying actually secure PoS systems, but we can't force them. MasterCard takes care of that for us, and we're not going to convince them we know better than MasterCard.
My point is that they need an internet connection.
I guess you've never worked in this space. When there's one provider serving PoS machines across thousands of sites, with everything from single-register florists up to supermarket and fuel chains, you need a cost-effective way of connecting tons of different sites.
Add to that the fact that a single PoS installation may be using live services from four or five different providers, and the best solution by far is to use the internet.
Perhaps you should go spend five or six years working in retail payment software before you decide how dumb we all are.
Spend some time working out how much this cost, and then show them how cheap it would be to avoid. A cost-effective way is to have juniors or admin staff crash-dummy the updates, and it doesn't cost too much in lost productivity if their machines bomb. Roll updates out to everyone else a day or so later.
You can get a good hardware spread by sending one machine from each new batch into the testing pool.
If the penalty does run that high, it was a good trade-off to do penalty clauses instead of your own QA. Lots of job roles these days do grind to a halt, though: the company I work for at the moment grinds to a total halt without computers (we're doing weather modeling, and slide rules just don't cut it anymore).
Your point is correct, but it's rare to do the CBA and come out with "don't bother testing anything", at least for any moderately-sized business. Numbers like 1,000 PCs have been thrown around. Let's assume:
200xAdmin machines - productivity $50/hr. 700xProfessional worker machines - productivity $200/hr. 100xInfrastructure machines - affects multiple users, cost of downtime $1,000hr.
The cost per hour of downtime is $10,000 + $140,000 + $100,000 = $250,000. For one hour. Imagine it takes half a day. You get to add in lost IT productivity, opportunity cost, and reputational loss as you fail to deliver to your clients. One incident can cost millions. A testing-in-production policy (where a few guinea pigs get all updates a day or so early) is incredibly cheap to run.
...if we would have been impacted by the bug we would have been screwed....
This is your clue that you should be spending money QAing virus definitions. Everyone else does. Well, nearly everyone else. The rest end up on /..
Physical security: solid case, no USB/floppy/whatever. That should do the trick. Staff normally does not start meddling with hardware - if they start doing that, you will have bigger problems on your hands than just a virus risk.
Yep. You've hired GEEKS. Employers should be screening for this stuff.
Lots of modern PoS systems do all sorts of live processing. Loyalty. Marketing. They're all run by third-party systems, and they're often live. That's why the PoS computer has an internet connection.
You're living in the dark ages. Lots of modern PoS addons require internet access. Loyalty is a high-profile example at the moment.