Re: And yet CA banks adopted chip-cards long before the US
That has nothing to do with it.
The US already had a large infrastructure in place and they looked at the cost of moving to chip and pin versus the losses (theft) that they had at the time. The cost of moving was higher. So they didn't move.
When there was more data theft and fraud such that the cost of moving was cheaper, the US moved.
That's pretty much the gist of it.
The various PHBs have not figured out (probably never will) that most of an organization's IT functions should remain in house, done by direct, permanent, employees. This is the only scenario that allows for the most control of the information, data, and code. This is especially critical for privacy issues. The third party company may or may not have all the proper controls required by various national data privacy laws. Medical data laws are similar but not identical to financial data laws. I am reasonably familiar with one (HIPPA) and only have a vague awareness of financial but I work in the medical industry.
Employees of the third party company first loyalty is the company paying them not the client, as it should be.
Re: Real Problem
It may be hip, or even hippy, but what the heck is it?
Maybe you are familiar with that acronym HIPPA - whatever it is, but certainly not with the Health Insurance Portability and Accountability Act 1996 (aka HIPAA)... So much for claims of exertise by familiarity...
@Yank Re: Real Problem
I am familiar with HIPPA and several different countries banking laws.
Its interesting to point out that none of the files shown on the screen shot included code, but were presentations made to different clients.
So while no data was compromised, (No shock there.) there was client specific information. The presentations are work products and should be owned by the client where TATA doesn't have the right to reuse them. (Note: This could be added to the contract, IBM does this all the time with their Type III contracts.)
I have a friend who tossed Mu Sigma from the account because he couldn't trust them to not reuse proprietary algorithms at other clients. The whole point is that many Enterprises are starting to learn that moving offshore may not be the best news. However... it will take many years to right this. Note that if there is another disruptive technology.. it could increase the speed of moving away from offshoring.
Of course if there is a case for a massive lawsuit against a company because there was a massive error done by the offshore team.. It could happen faster.
I am reminded of a software development group that I worked with the USA - they were shut down and outsourced to India - the indian people assured that they were up to the task (this was O/S level and Device driver stuff). There are a few online forums for that platform - all of a sudden, they start getting new members with Half Indian names (like Charles kutrapali), and are asking the most basic questions, as well as some very specific ones. An Associate had a major bug report outstanding and one of the questions was the same as appeared from the new Indian Forum member - So, his query was responded to in very specific language, and lo-and-behold - that was almost word for word, what my Associate received as information on his bug fix. That group is now back in the hands of a US Team of SW Engineers.
Re: Half Indian names
"Have noticed the same thing when searching MS for help. Canned answers are totally useless."
Agree, MS Help is useless. MS hired tech writers to compose Help files for the software. However, since the software and its associated help files get released simultaneously, the tech writers are working from software specs, not from final version software, nor would it be efficient to let mere writers ask questions of the software producers. See where this is going? This disaster is compounded by other factors. Of course, once you have a help entry established for a question, bean counters say it's hardly economical to hire another team to do the same work again. That's why Help for 21st century Windows can look like it was written (in ignorance) for Windows 95. Not a candy mint? Please consult your system administrator.
PS I have never worked for MS. The above is from inference.
Re: Half Indian names
> ... nor would it be efficient to let mere writers ask questions of the software producers.
Efficiency be damned. Make sure the writers can ask the dev's, and get a useful result, otherwise the written docs will be shit. Leading to unnecessary support expenses, bad reputation, etc.
Keeping software devs away from the doc production is rarely a good idea.
That happened to someone on a Solaris / Sun Microsystems / Oracle forum I read and post at a few years ago.
Forum member's job, and actual whole department was outsourced to India. He was looking for work and had more time to spend on the forums and suddenly new members joined. They first started out with Solaris basics and then it moved onto more detailed questions and finally the new members quoted directly from the documentation our older member wrote himself (that was proprietary) and he realized he had been helping the people who replaced him.
So, he had a bit of fun with them "answering their questions the best he could".
I am not a proper programmer. Any code I provide, real programmers will think: "Is that some sort of awkward pseudo code?" Anyway, I scanned the linked article down to the red ink before going to bed. In the sweet befuddlement of waking up the next day I was dreaming of
Hester History. Deep Hestory. I remembered from the days when you had to fit the OS, the program(me) code, and the program's own space into 64K RAM, that you'd never have a list of resources all starting with "https://www.somebank.ca/...". No, you'd define the quoted part as $BaseAddr and make up each resource name as $BaseAddr & "whatever" on the fly, this economizing (ResourceListLength% - 1) * (BaseAddrLengthInBytes%) bytes of precious RAM. Well, almost. Less pretentious than "asymptotically". The year was 1979.
I also remembered the Deep Hester of 194? (before my time, honest) when they were able to decode the Enigma messages but not in the 24-hour expiry of each Enigma code--until somebody (and I like to think it was one of the chess players because this is the kind of thing that a chess player should notice, rather than one of the math geniuses who get the lion's share of the credit) noticed that one military clerk liked to begin each message with "Hail Hester" (Godwin forfend what he really wrote) and using that repeated pattern they were able to decode the messages in less than 24 hours and bingo, Coventry was saved from total destruction. Oops.
So using $BaseAddr not only makes the compiled code slimmer, it also eliminates the repeated-handle fulcrum into de-obfuscating the code-that-you-want-to-hide. Returning to the linked article, I noticed that the author Coulls made that same points, inter alia, though in very different words. Whether this actually makes a tinker's cuss of difference to cybersecurity I know not, but one gets a warm fuzzy feeling to use Hestory to pretend to delve into some of the Great Problems facing Mankind in these Troubled Times.</billhocks>
It has proven that offshoring hell of issues like quality, commitments and availability of dependent resources however the management in the big companies don't give a sh!t. This also has severely impacted local job market with less number of jobs and decreasing pay rates.
Very little to do with Canadian culture
What I learned from this article, it that off-shore development firms like the one from India that is mentioned, is where you will find the lax security and cultural differences.
There is no surprise at all about that statement.
If there is any cultural difference between Canada and US, it would be all the socialist/communist laws in Canada that make developing our own code a cost prohibitive activity.