| 1.1 Portfolio
48 Education Service | |
|---|
| 11.48 Education Service: | | 1. Acknowledgements to the SL domain and educators for their initiative in the birth of this Bespoke Application Service. | | 2. It is a business requirement to improve productivity with the benefit of an online contact and Customer Relationahip Management (CRM) application. | | 3. A business can get so far with spread sheets, but to be scaleable, productivity must be improved to cope with more contacts in an effective way. | | 4. The current web site has an email address that may be used by people who wish to communicate with the business. It is proposed that this is improved with a "contact us" web page where people can provide more relevant information that is stored in a CRM database. | | 5. It is a business requirement to be able to process the CRM database using a secure online list and form. Filtered sets of contracts may be sent an email message that is relevant to their stated interests. |
| 2. Summary: | | 1. Contact-Us public form on the existing web site. | | 2. Privacy Notice public page on the existing web site to explain how information will be treated. | | 3. CRM private application as a list of contacts and data entry form. | | 4. Email Service to send a personal message to one or more selected contacts. |
| 3. Regulations: | | 1. PECR: Privacy of Electronic Communications Regulations. PECR is concerned with messages sent to people by the email service. | | 2. GDPR: General Data Protection Regulations. GDPR is concerned with the security of Personally Identifiable Information (PII) that is stored in the CRM. | | 3. The bespoke application service is registered with the Information Commissioners Office with data protection registration PZ9322564. This data protection registration covers all bespoke application services provided to people in the UK by the Application Service Provider. | | 4. The bespoke application service includes the services of the Data Protection Officer appointed by the Application Service Provider to undertake regular Data Protection Impact Assessments (DPIA). The Data Protection Impact Assessment is available online and may be shared with the Information Commissioners Office as evidence of the security measures deployed. |
| 4. Contact Us: | | 1. The web site contact us page is a simple data entry form with the field values added to a CRM database. | | 2. The initial data to be captured may include: | | (1) Name as the persons first and family name with optional title and optional suffix. A name is alphabetic with optional space, hyphen and apostrophy - numbers and other symbols may just be ignored. A person may choose to be identified by any string of characters that they wish as up to 64 characters. | | (2) Phone is optional as the persons preferred mobile or telephone number. A phone is numeric with optional space, hyphen and round brackets - letters and other symbols may just be ignored. A person may choose to be telephoned by providing a valid phone number of up to 16 digits. | | (3) Email is optional as the persons preferred email address. An email address is a unique set of letters, numbers and some symbols of up to 64 characters. A person may choose to be emailed by providing a valid email address. | | (4) Postcode is optional as the persons postal address. A postcode is an optional set of letters, numbers and space of up to 8 characters. A person may choose to provide an indication of their physical location so applicable services can be offered. | | (5) Subject is an optional headline as a normal email. A subject is an optional set of letters, numbers and some symbols of up to 128 characters. | | (6) Message is an optional message as a normal email. A message is an optional set of letters, numbers and some symbols of up to 2048 characters. | | (7) Consent is mandatory list to be selected to cause the message to be processed. The contact us form information is not processed until the person consents to that information being processed in accordance with the privacy notice. This is not optional, its the law. | | 3. While the initial contact us form will be simple, in the future this may evolve to capture: | | (1) Course Name as a list of course names. | | (2) Course Date as a list of course dates. | | (3) Course Location as a list of course locations. | | 4. Every contact us message is recorded with a set of extra informtion such as: | | (1) Date as up to 8 characters. | | (2) Time as up to 6 characters. | | (3) IP Address as up to 16 characters. | | (4) Browser as up to 64 characters. | | (5) Device (screen) as up to 64 characters. | | (6) Status list: received, held, replied, cancelled. | | 5. The contact record is the core of a CRM that shall include postal address, interests, course history and many other factors. The primary contact record is assigned a unique primary key that may be replicated and used to index matching records in other tables. | | 6. It is understood that each time a person sends a contact us message, a new contract record will be added to the CRM because the author cannot be told that they have already sent a message - that would be an exploitable data leak. Internal facilities will enable contact records to be merged so a single set of information for each person who is stored in the CRM. |
| 5. Privacy Notice: | | 1. It is a legal obligation to have a privacy notice when Personally Identifiable Information (PII) is to be captured and stored in the CRM. The privacy notice used by the Information Commissioners Office provides a good template for the contents of a Privacy Notice. | | 2. The Privacy Notice is a static set of information presented as a web page. It is a requirement to be able to easilly click to see the Privacy Notice when viewing the Contact Us Form. |
| 6. Customer Relationship Management: (CRM) | | 1. Contact use messages form the core of the CRM database. A lot more optional data may be associated with each person and that can be done using an internal unique person key. | | 2. A root person record may have many children and one of the children is a list of contact us messages - at least one will exist. The root person record may have children such as the full postal address, list of other people, list of courses attended or interested in. | | 3. A spread sheet list of contact messages may be viewed, sorted and filtered. All messages sent in should be processed the same day, but this is not mandated in any way. A simply reply or acknowledgement email message may be quickly returned when an email address has been provided. A phone call may be returned when a phone number has been provided - a popup text box enables contemporary evidence from the phone call to be entered in real-time. |
| 7. Email Service: | | 1. Productivity improvements comes from the final email service. | | 2. A filtered spread sheet list of contact names with a common interest may be selected and used with the email service. | | 3. A common message may be entered and emailed to all the people in the filtered spread sheet list. For security reasons, each person is sent their own personal email - a list of many email addresses is NEVER used. |
| 8. Captcha: | | 1. In theory a "captcha" facility should be part of the contact us form to prevent bots from entering garbage. | | 2. In practice, very "captcha" facility can be fooled by bots and so they tend to serve no purpose. | | 3. The initial edition will not include a "captcha" facilities and experience will show if some method is needed to prevent bots from entering garbage. Because any "captcha" may prevent some people from completing the contact us form, it may be more effective to manually reject messages sent in by bots. | | 4. It is recommended that an email to a person includes a link to the web site page that provides extra information about the subject of the email - a course description. | | 5. Captcha facilities discriminate against people with visual disabilities. |
| 9. Intellectual Property: | | 1. Intellectual property is copyrighted by the author or the company who pays the author. | | 2. Intellectual property of the bespoke application service is transferred to the owner of the bespoke application service when the bespoke application service is accepted into productive use by the owner. | | 3. The Bespoke Application Service includes a Continual Evolutionary Improvement (CEI) service. Each and every Continual Evolutionary Improvement is authored by the owner and the owner holds intellectual property rights to each improvement. | | 4. The role of the Application Service Provider is only to provide the Bespoke Application Service required by the owner. The Bespoke Application Service is not a software system that can be sold to others. The Bespoke Application Service exists solely for the benefit of its owner and must be destroyed when it is no longer needed by its owner. |
| 10. Data Protection Impact Assessment: | | 1. The Data Protection Officer appointed by the Application Service Provider shall review and revise this Data Protection Impact Assessment on a regular basis for the benefit of the Bespoke Application Service owner. | | 2. The Information Security Manager appointed by the Application Service Provider shall deploy all appropriate privacy and security control measures that are identified by the Data Protection Officer. | | 3. The Data Protection Officer has a strategic role and the Information Security Manager has a tactical role. | | 4. The Application Service Provider has decreed an overall mission that it must not be possible for a reportable data breach to happen. This strategic mission is deployed with three ERA methods known as: | | (1) Encryption is mandated at many levels and with many methods to stored data is meaningless and worthless to a criminal. | | (2) Replication is mandated for all encrypted data so stored data can be recovered when any copy is lost. | | (3) Authentication is mandated with a first class Identity and Access Management (IAM) service. | | 5. The Application Service Provider has decreed that privacy-by-design must be built into the basic architecture of the application to ensure that a data breach cannot happen. |
| 11. Pseudonymised Data: | | 1. GDPR identifies pseudonymisation as an effective privacy-by-design method to store Personally Identifiable Information (PII). | | 2. An example is how a persons name is physically stored in the database. Each PII field has its own unique encryption method. | | 3. The persons name is typically a first name and a family name - this is split into two parts and each part is represented by a random token as 8 digits. | | 4. The name part is encrypted using several salted algorithmic methods into a fixed length string of 100 digits. Salted encryption means that each time "John" is encrypted, the resulting 100 digits is very different and cannot be reverse engineered. | | 5. The encrypted token and the encrypted name are stored in an in-memory lookup array that is backed up to disk as a long string of numbers. | | 6. The person record holds two tokens that represent the persons name - this is meaningless and worthless to a criminal. | | 7. Each time the name part "John" is to be stored, it is represented by a unique token so common names do not result as common tokens in the person table. | | 8. The token in the person record and the token in the pseudonymised array are different so it is not practical to match tokens in different tables. | | 9. By design, every token looks like a date and every date looks like a token. A token in one table may be identical to a token in a different table, but they will hae very different meanings. |
| 13. Encryption: | | 1. Every formal encryption method that has ever been devised by the finest minds in the world, has eventually been cracked. The role of quantum computing means that millions of possible solutions can be derived in parallel, so encryption keys need to get more and more complex. | | 2. An alternative is to merge layer after layer of different encryption methods on top of one another in a way that it is not possible to know how many layers of encryption exist. When the correct output of an encryption method is just the input to another layer of encryption, it is not practical to know if any layer of decryption is correct. | | 3. It is recommended to evolve away from complex character codes and explore the benefits of just using numbers in long strings. It is recommended to evolve away from encrypting complete messages and begin to fragment a message into lots of parts that can be scrambled and each part encrypted in many different ways. | | 4. The unit of encryption that cannot be cracked is the integer of up to 10 digits as a token that can mean anything and everything. It may take many integers to represent a long message, but nobody can predict the order of integers that represent a complete message. | | RULES. | | 1. The only type of stored data is an integer (4 bytes) that will represent anything and everything. | | 2. A database is a set of tables containing records where each record contains many integers and nothing else. | | 3. A persons name is split into a prefix and suffix that are represented by two integer tokens. The prefix and suffix are encrypted as a string of numbers and each bucket of 9 digits is represented by an integer token. |
| 13. Block and Bucket Example: | | 1. Take a string of nine blocks numbered 1 to 9 and place a block one at a time into three buckets. Bucket 1 will hold blocks 1-4-7. Bucket 2 will hold blocks 2-5-8. Bucket 3 will hold blocks 3-6-9. | | 2. Take the blocks out of the buckets in the order of bucket 2 as 2-5-8, bucket 3 with the blocks in reverse order as 9-6-3 and bucket 1 as 1-4-7. The nine blocks are now in the order 2-5-8-9-6-3-1-4-7. | | 3. Take a string of nine blocks and place a block one at a time into three buckets. Bucket 1 will hold blocks 2-9-1. Bucket 2 will hold blocks 5-6-4. Bucket 3 will hold blocks 8-3-7. | | 4. Take the blocks out of the buckets in the order of bucket 2 as 5-6-4, bucket 3 with the blocks in reverse order as 7-3-8 and bucket 1 as 2-9-1. The nine blocks are now in the order 5-6-4-7-3-8-2-9-1. | | 5. Take a string of nine blocks and place a block one at a time into three buckets. Bucket 1 will hold blocks 5-7-2. Bucket 2 will hold blocks 6-3-9. Bucket 3 will hold blocks 4-8-1. | | 6. Take the blocks out of the buckets in the order of bucket 2 as 6-3-9, bucket 3 with the blocks in reverse order as 1-8-4 and bucket 1 as 5-7-2. The nine blocks are now in the order 6-3-9-1-8-4-5-7-2. | | 7. With three iterations and three buckets, it becomes hard for a criminal to decrypt the stored data to the original string. With many thousands of blocks and a large number of buckets and a large number of iterations, it is not just hard, it may be impossible to decrypt, even with unlimited computing power. The reason this cannot be decrypted is because the decryption of any layer looks the same as any other layer, so the criminal would never know when the decryption is solved. |
| Evolution: | | 1. The simple contact-us business requirement has evolved into a public survey to capture Personally Identifiable Information (PII). The survey is 20 questions with a yes-no reply using a check box user interface. | | 2. The email reply requirement has evolved into a PECR direct marketing requirement with subscription management. Every message sent to the customer MUST include a simple way for the customer to opt-out and unsubscribe from the communications. The customer has the right to view and change their subscriptions at any time - that means they must be able to sign-in to process their own PII. |
| Factors: | | 1. Each logical table is stored as a primary and history table pair. | | 2. Primary table keys are 6 digits. | | 3. History table keys are 8 digits. | | 4. Integer is the default field type unless specified. | | 5. Pseudonymised token pairs replace each name and email field value. | | 6. Person 123444 is defined as the generic site and the owner. | | 7. Every approved person who can sign in is a person defined in D21. | | 8. Every token and every list value looks like a date. | | 9. Every data item has a unique placeholder such as "D2224" is the address postcode. |
| Database Tables: | | (D21) Person. | | (D22) Postal Address one-to-one dependent on person. | | (D23) Message one-to-many dependent on person. | | (D24) Course one-to-many dependent on person. | | (D25) Security one-to-one dependent on person. | | (ZD31) Pseudonymised encrypted tokens and encrypted values. | | (ZD32) Reference encrypted tokens and encrypted values. |
| Database Fields: | | 3. Root Fields: (22) | | (01) Primary key auto-increment. | | (02) Active as 123. | | (03) Site Key as 123444. | | (04) Person Key as D21.c01. | | (05) Message Key as D23.c01. | | (06) Course Key as D24.c01. | | (07) reserved as integer. | | (08) reserved as integer. | | (09) reserved as integer. | | (10) reserved as integer. | | (11) reserved as integer. | | (12) From User Key as integer. | | (13) To User Key as integer. | | (14) Change Count as integer. | | (15) reserved as integer. | | (16) reserved as integer. | | (17) Last Change User as integer. | | (18) Last Change Date as integer. | | (19) Last Change Time as integer. | | (20) Created User as integer. | | (21) Created Date as integer. | | (22) Created Time as integer. | | + | | 4. Person Fields: (D21) | | (01) Person Key | | (23) Status as list. | | (24) Name as token 1. | | (25) Name as token 2. | | (26) Email as token 1. | | (27) Email as token 2. | | (28) Phone as token 1. | | (29) Phone as token 2. | | (32) Comment as VC64. | | + | | 5. Address Fields: (D22) one-to-one with D21 | | (01) Person Key | | (23) Status as list of address types. | | (24) Postcode as VC8. | | (25) Building as VC32. | | (26) Street as VC32. | | (27) District as VC32. | | (28) Town as VC32. | | (29) County as VC32. | | (30) Country as list. | | (32) Comment as VC64. | | + | | 6. Message Fields: (D23) one-to-many | | (04) Person Key | | (05) Message Key as D23.c01. | | (23) Status as list. | | (24) Subject as VC64. | | (25) Message as VC2048. | | (32) Comment as VC64. | | + | | 7. Course Fields: (D24) one-to-many | | (04) Person Key | | (05) Message Key as D23.c01. | | (23) Status as list. | | (24) Course Name as VC16. | | (25) Course Location as VC16. | | (26) Course Date as integer. | | (32) Comment as VC64. | | + | | 8. Security Fields: (D25) one-to-one with D21 | | (04) Person Key | | (23) Status as list. | | (24) Role as list. | | (25) PIN as integer. | | (26) One-Time PW as integer. | | (27) PW as VC32. | | (28) Formula as VC32. | | (29) Device as VC32. | | (30) Network as VC32. | | (31) Days of Week as list. | | (32) Hours of Day as list. |
| Document Control: | | 1. Document Title: Education Service. | | 2. Reference: 161148. | | 3. Keywords: Education Service. | | 4. Description: Education Service. | | 5. Privacy: Public education service as a benefit to humanity. | | 6. Issued: 23 Jul 2018. | | 7. Edition: 1.2. |
|
|