This week’s sudden activity was the inclusion of GDPR acceptance to allow email capture on the touch-screen kiosks one of my clients uses in their entertainment products.
This work is done on a legacy system that was designed before the acceptance of the C# Interface was as widespread as it is today. And it’s a complicated system that has been chopped and changed over many years, with many hasty additions and alterations, so it is not straightforward to add new fields to what is a very brittle system. Whilst modern programming concepts are introduced where possible, it is with considerable caution, not to mention peeking-through-fingers apprehension, that any sort of change is made.
For this work, it was not just a case of adding a table of data-protection clauses and a many-to-many table of customers and clauses accepted, but also of adding a data protection clause administration area. And then of allowing 0, 1 or many of those clauses to be accepted, and alter the customer registration route accordingly. In that; accepting 0 clauses would allow a customer to register for the entertainment but not have any personal data collected, or accepting 1 or more of the clauses to make the email field available within the registration sequence.
Deciding what constitutes an email is not a precise science either, with many articles purporting to definitively state which Regex, or other method, will guarantee that a given string is an email. But it seems that many of these methods can be broken by including 2 dots somewhere in the address. This is formally allowed, but probably rarely used, in the account name (left-hand side of an email address from the @) but not allowed on the domain name side. And putting a trailing dot also causes many of these tests to fail.