4 ms·

I don't really understand the banks point, given that https://en.wikipedia.org/wiki/UTF-EBCDIC https://en.wikipedia.org/wiki/UTF-EBCDIC exists.

by clort 3y ago

corbezzoli 3y ago
The point is that "nobody ever complained except you" and that programmers cost money, so no change is ever made. Then someone sued and they thought they'd still win this "frivolous litigation" that is "due to a technical limitation that is out of our reach."
- xxs 3y ago
  GDPR is handled by the state - no idea how/where frivolous part comes from. The people can file complaints with the state/agency but not sue companies directly on their own for violations.
dathinab 3y ago
the problem is outside of the bare minimum they had to do for compliance this bank likely didn't do a proper software update in idk. 20-30 years... very trustworthy
- drivingmenuts 3y ago
  If it ain’t broke (in a way that affects the bottom line), don’t put yer hamgrabbers anywhere near it.
  - dathinab 3y ago
    but it is broken, utf8 support need wasn't new when the law suite happened there is also the issue that I would be surprised if that system _didn't_ had tons of security vulnerabilities (which just weren't found because of it's obscurity). Heck, I have heard of enough cases where old banking systems had ton's of well known security issues in their interface they just "defined away" by means like "oh you need to be a bank employee to abuse them so they are not an issue" or "pst, don't speak about it we (supposedly) can't afford an update and they would fire people if they need to do an update".
    - arp242 3y ago
      They were already upgrading their systems when the lawsuit happened. That's why they didn't fix it: "not worth it since we'll be replacing it all".
      - jeroenhd 3y ago
        And ING's Unite be+nl project didn't end up meeting the dates they provided the court, so even if the court had accepted that excuse (it didn't), they still would've needed to alter their systems anyway. In fact, the attempt to unite the Dutch bank with their Belgian counterpart, which would've modernised the system, was cancelled in 2020 after barely making progress after four years, followed by a thousand jobs being cut worldwide. "We're going to replace this anyway" is a pretty bad excuse for a fix that should've been completed ten years ago, and with the replacement clearly not coming any time soon, especially when the you're legally obligated to provide the fix.
drivingmenuts 3y ago
Oh, I get it - modifying the system costs money that the bank is not willing to spend. After all, only one person complained. If it happened her, in the US, fixing the issue would be a very expensive process, probably requiring replacement of the entire system and triggering tons of audits, etc.
lozenge 3y ago
Sure, just store it that way, and make sure the output is converted to UTF8 at every point where a modern system is involved (envelope and letter printing, statement printing, customer website, internal customer support tools, internal anti fraud and audit tools). Also convert input from UTF8 to EBCDIC at every point a user or employee can type into a modern keyboard/OS. Eg searching customers by name. Teach employees on inputting characters. Are we going to allow all unicode characters? Will they be able to find records if the customer doesn't give the diacritics in one context such as phone? Also some routine tasks will be done using a mainframe terminal which doesn't support displaying these characters. More training there as they will just display the UTF-EBCDIC version of the field. Are there connections like tax agencies, credit reporting agencies, other banks, Visa/Mastercard, and what character sets do they support? We always sent them ASCII CSVs via FTP and everybody who understands it no longer works here.
arp242 3y ago
The quoted bit stops too soon; the original goes on to say that in the "near future" they'll be upgrading all their systems, after which it can deal with accents, and a bit further it says that they expect it'll be ready in 2020. That's why they didn't modify the existing system: they didn't feel it was worth it since they're working on replacing the lot. This wasn't accepted as a defence with "it's 2018 and you're still using a system from 1995 wtf?!" so they still had to pay a (small) fine.

I don't really understand the banks point, given that https://en.wikipedia.org/wiki/UTF-EBCDIC https://en.wikipedia.org/wiki/UTF-EBCDIC exists.

by clort 3y ago

I don't really understand the banks point, given that https://en.wikipedia.org/wiki/UTF-EBCDIC https://en.wikipedia.org/wiki/UTF-EBCDIC exists.

corbezzoli 3y ago

The point is that "nobody ever complained except you" and that programmers cost money, so no change is ever made. Then someone sued and they thought they'd still win this "frivolous litigation" that is "due to a technical limitation that is out of our reach."

xxs 3y ago
GDPR is handled by the state - no idea how/where frivolous part comes from. The people can file complaints with the state/agency but not sue companies directly on their own for violations.

dathinab 3y ago

the problem is outside of the bare minimum they had to do for compliance this bank likely didn't do a proper software update in idk. 20-30 years... very trustworthy

drivingmenuts 3y ago
If it ain’t broke (in a way that affects the bottom line), don’t put yer hamgrabbers anywhere near it.
- dathinab 3y ago
  but it is broken, utf8 support need wasn't new when the law suite happened there is also the issue that I would be surprised if that system _didn't_ had tons of security vulnerabilities (which just weren't found because of it's obscurity). Heck, I have heard of enough cases where old banking systems had ton's of well known security issues in their interface they just "defined away" by means like "oh you need to be a bank employee to abuse them so they are not an issue" or "pst, don't speak about it we (supposedly) can't afford an update and they would fire people if they need to do an update".
  - arp242 3y ago
    They were already upgrading their systems when the lawsuit happened. That's why they didn't fix it: "not worth it since we'll be replacing it all".
    - jeroenhd 3y ago
      And ING's Unite be+nl project didn't end up meeting the dates they provided the court, so even if the court had accepted that excuse (it didn't), they still would've needed to alter their systems anyway. In fact, the attempt to unite the Dutch bank with their Belgian counterpart, which would've modernised the system, was cancelled in 2020 after barely making progress after four years, followed by a thousand jobs being cut worldwide. "We're going to replace this anyway" is a pretty bad excuse for a fix that should've been completed ten years ago, and with the replacement clearly not coming any time soon, especially when the you're legally obligated to provide the fix.

drivingmenuts 3y ago

Oh, I get it - modifying the system costs money that the bank is not willing to spend. After all, only one person complained. If it happened her, in the US, fixing the issue would be a very expensive process, probably requiring replacement of the entire system and triggering tons of audits, etc.

lozenge 3y ago

Sure, just store it that way, and make sure the output is converted to UTF8 at every point where a modern system is involved (envelope and letter printing, statement printing, customer website, internal customer support tools, internal anti fraud and audit tools). Also convert input from UTF8 to EBCDIC at every point a user or employee can type into a modern keyboard/OS. Eg searching customers by name. Teach employees on inputting characters. Are we going to allow all unicode characters? Will they be able to find records if the customer doesn't give the diacritics in one context such as phone? Also some routine tasks will be done using a mainframe terminal which doesn't support displaying these characters. More training there as they will just display the UTF-EBCDIC version of the field. Are there connections like tax agencies, credit reporting agencies, other banks, Visa/Mastercard, and what character sets do they support? We always sent them ASCII CSVs via FTP and everybody who understands it no longer works here.

arp242 3y ago

The quoted bit stops too soon; the original goes on to say that in the "near future" they'll be upgrading all their systems, after which it can deal with accents, and a bit further it says that they expect it'll be ready in 2020. That's why they didn't modify the existing system: they didn't feel it was worth it since they're working on replacing the lot. This wasn't accepted as a defence with "it's 2018 and you're still using a system from 1995 wtf?!" so they still had to pay a (small) fine.