Not just free-text fields. Any field can be re-purposed on the fly. If the field is big enough and not validated in any way, expect misuse.
Be careful what you wish for when running a hackathon, because one in Australia turned up a data breach in the trove of sample data offered to hackers. And it was probably developers’ fault. The event in question was staged by global travel agency outfit The Flight Centre Group, which in March 2017 staged an event called a “ …
And just what validation does one use to prevent something like a credit card, driver's license or passport number from being entered in a text field?
Okay, credit card numbers are 16 or 15 digits, and satisfy the checksum. Is that with spaces, dashes, or neither?
At some point, the smarter fool will ALWAYS work around such whack-a-mole checks. There is no way to prevent it in code.
Clear training with the fact that this is a fireable offense, backed up in the employee handbook, with regular audits of the field in question, and actually walking someone out of the building when it happens, is the only way to stop this sort of nonsense.
"thought it had cleaned that dataset so that design jammers could see year of birth, postcode, gender and booking information, but no personal information"
I have a UK postcode shared with just two other properties. The year of birth and gender would directly identify me if you knocked all three doors.
They may not be private, but they can be personal.
Since they can quiet easily link to a person they are seldom used in full when providing so called anonymized data. That's why in the UK only the first section (out-code) should be used in exercises like the one being discussed.
Exactly what I was going to say. My parents' postcode is shared by four houses. A friend who moved into a new build briefly had the only occupied property at their postcode (although convincing anyone it actually existed at all was a bit of a struggle, and you still can't find it with Google maps). What kind of idiot thinks address, gender, date of birth and holiday information are somehow not personal data? Personal information doesn't mean every single piece of data can directly identify a specific person.
It's not quite that simple though. Some postcodes in Australia cover quite large geographical areas with lots of people, others cover large areas with a few people, and still others might cover just a few suburbs in Sydney or Melbourne.
Wikipedia - Postcodes in Australia gives a few examples of extremes.
Given those sorts of examples, most Australians probably won't think of a postcode as being able to directly identify people.
Why not? Seems a PI breach was found in quite a safe environment, they then reacted sensibly and quickly.
Would they rather the issue was found by some balckhats later, then compromised for n-years before they found out?
Feels like the same ol' issue well known to test teams that the dev teams don't like to be told of bugs. Before release. Before anyone else finds out. Sigh.
Why didn't they generate some, or are they dummies?
FWIW, worked on a contract for a low cost airline in the UK and we were only ever given fake data. Names like 'Hugh Jarse', 'Ivor Biggin', 'Phil McAvity' etc reminded us the data was not real and made for some interesting demos!
Æ A-12 springs to mind.
Surprised Bobby Drop Tables hasn't been mentioned yet.
Not sure if I am repeating myself here, but I had occasion to apply for a business PayPal account for an organisation that was founded in 1899. The on-line form told me that was totally unacceptable.
Then there are validation problems with PO Box postcodes which don't exist on a map. Had a lot of fun and games with that over the years. Google showed my location at some random location nowhere near me.
Nope, nope, nope. You're doing it wrong.
If you're needing a few thousand records to ensure your code isn't crazy slow, that's one thing. But if you are testing validation routines and business logic, you MUST fashion your test data to hit EVERY corner that live data might well never see.
Real life it too boring--until suddenly it's too exciting. Tests must be ready for the exciting bits.
Could someone explain what that means in this particular context, please?
I am well familiar with the concept of hackathon in free / open source software.
A few months ago, however, I received some spam in my company email "inviting" us to participate in a "hackathon" the premise of which, as far as I could ascertain, appeared to be that we would work for free to solve someone else's problem and get a handshake and an ice cream or some such.
Is this the sort of thing we're talking about or is there something that I fail to understand? Serious question.
The original idea of a hackathon was for the teams inside a company to take some time "off" from working on tickets and instead work on creating prototypes for some ideas that might have been rattling around in the back of their heads for the last few months, but were too big to explore without a ticket driving them.
Some marketing genius heard the idea and said, "what if we invite people to do that with our product"? It would only make sense for a company to send people to something like that if they were already committed to the platform, and wanted their people to cross-polinate ideas with other organizations while letting them feel like they were kinda-sort not working.
There's already plenty of abuse of free text. A recent Tales from Tech Support on reddit involved a hotel using it for credit card info, with the software OEM putting measures in place to trap such stuff, up to and including taking all suspicious numbers in free text and running them through the validator. Hotel responded by breaking the numbers across lines with asterisks in between. No doubt the OEM will respond, and the race will go on.