This work proposes the development of a web system which helps in locating personal information of third parties, based on the reference information provided by the user, the system opens a request for consultation from a third party data.
1. Introduction
This project creates a scenario for the development of a system that should serve as a real laboratory base for the application of a review according to the Brazilian data protection guidelines. The system will be specified, developed, tested and deployed in a production environment in a way that simulates as closely as possible a real application context. The simulated context basically involves the handling of requests, research and personal data.
In everyday life, keeping informed is always useful to prevent scams, people are constantly looking for the location of data from another one, like a wife to find out if their ex-partner is employed, to even someone who wants to know whose number is calling him every day at a certain time.
The motivation of this project is to create a practical basis for the application of search engines while supporting a laboratory for the practical validation of techniques and recommendations based on GDPL (General Data Protection Law), at the same time providing a tool to keep people with a resource that makes available data of a particular person or telephone, so that you can verify that the information acquired is really valid and existing.
2. Objective
The objective of this project is the development of a tool that helps the lay user to have information about a specific person or telephone number. Basically, the platform does not make a query, but a request to a willing team with resources to provide the desired information, in an interactive way and supported by computational resources.
As it is a tool that involves manipulation of personal information, the results obtained here serve as a laboratory and evidence basis for real and practical application of recommendation and systemic validation according to GDPL recommendations and restrictions (LGPD, 2020)
3. Project
During the structuring of the project, existing sites that have the same proposal were evaluated, so that a new plausible platform and relevant proposal can be created. Among these they, the "TudoSobreTodos.info" (2022) and "SOSBuscaOnline.com.br" (2022).
Among the main features considered in the existing proposals are the possibilities of requesting consultation with practicality, a channel for the customer to communicate with an attendant, for doubts, suggestions, complaints... and a platform that makes the consultation request available by itself, without forwarding the user to an external application for the service request.
After the stage of studying and analyzing existing systems as a means of identifying initial requirements, with the intention of creation of a new platform different from the current ones, focusing especially on the user experience. Being defined after the entire analysis process of the other related platforms:
- Currency – To reduce unnecessary contact and for the user to have greater freedom and flexibility on the site, a “
Coin” will be created, which is a currency for the exclusive use of the platform. - Privacy - To prevent any of the results from being stored in a database, all the results of any requests will be forwarded by email or by an instant messaging system, preventing any information from being stored on the server.
- Security – Preventing people from registering with incorrect information, Zenvia (SMS API) and Mailler will be used to validate the phone number and email provided at the time of registration.
In terms of functional scope, it was defined that the project was structured according to the functionalities (macro) as shown in Figure 1, shared between the actors: user, attendant, manager and admin.
Figure 1 - Use case diagram
Figure 2 presents the activity flow that makes up the system proposal. In this image, it is possible to identify the operation event sequence, from the insertion of basic information for consultation, through the interactive process and finally presenting the results presentation stage.
Figure 2 - Activity diagram for description of the execution process
According to Figure 2, the beginning of the process is stimulated by the User Actor (USER) who registers a request. After registration, the petition remains pending in the user's profile until the user releases it for submission. The next activities of the process are immediately handled by the system, by components responsible for handling the persistence of the request, mainly considering storage and prioritization handling.
The next involved are the manager or admin who are responsible for assigning responsibility and releasing for treatment. These tasks are directly in the system through specific profiles as shown in the diagrams in Figures 1 and 2 (region admin/manager).
After the assignment and release for handling the petition, the attendant assigned to carry it out performs the manual handling supported by external and outsourced tools, always making the alignments with the necessary functionalities to fulfill the request. After carrying out the consultation, if the search has been successfully completed, the attendant makes the referral manually through relevant support tools and then the request is definitively closed. In case of failure in the data search, the request is also definitively closed, but without formally sending the results.
3. Development
3.1. Technical Specification
The application was developed using the following programs and tool:
- VisualCode: For code development (PHP, CSS, JavaScript language, and so on)
- CorelDraw: Create and edit images that will be used
- Github: Project storage, for synchronization between creators
The platform was created from the following programming languages and technologies:
- Mysql: A relational database service, through this tool, each user's information will be stored, as well as their requests
- HTML and CSS: Programming language for the development of the Front-End, it will be from these languages that the page layout will be made
- JavaScript: Programming language that will help in the interaction between the user and the platform
- PHP: Programming language that will make the connection and validation between information passed through the HTML form and that will be sent to the Mysql database
The environment will use APIs to make all services more flexible and reduce the chance of the user having to contact support, as well as making the user have a better experience when using the services, these are:
- MercadoPago: For the user to have greater comfort and confidence with the service provided, when making a top-up of any amount above 10 brazilian coins (reais), automatically as soon as approved, the system identifies and deposits the respective coins in the wallet.
The environment will use APIs to make all services more flexible and reduce the chance of the user having to contact support, as well as making the user have a better experience when using the services, these are:
The main entities in the system are divided into four major groups: petitions (Figure 3), user scoring, payment (Figure 4) and auditing entities (Figure 5). Several of these entities are necessary to provide a minimal basis for a system of handling personal data involving audit, history, control state, process, and life cycle of entities in a way that provides a rich and pertinent basis for an assessment of data protection. data, according to GDPL.
Basics Entities Envolved With Consultation Process Requests (Petitions)
USERS - system users are service request, administrators or attendantsACCOUNTS - concentrate basic user dataQUERIES - are the main entities of the system; it is the manipulation component within the basic process proposed for the project
Figure 3 - Entities envolved with consultation process requests
Reserved Models for Scoring and Payment Control
PACKAGES - define the package options that can be contracted by requesting usersCONTRACTED_PACKAGE - direct relationship between a requesting user and the contracted service packageDEVOLUTION_PACK - container for returning contracted information; is the component used for data transferCREDITS - are the credits accumulated by purchase or by reward of useCREDITS_SOLD - credits contracted to be consumed during consultation requestsPAYMENTS - payment made; imply the release of purchase status once confirmedUSERS_CREDIT - relationship between the consulting user and the credits accumulated in the system
Figure 4 - Entities to account, credits and payments control
Templates for History and Audits
USERS_CREDIT_HISTORIC - user credit historyCONTRACTED_PACK_LOGS - service pack contracted logs; range from the first moments in the system to the most current moment of a user on the platformQUERIES_LOGS - history of queries performedQUERIES_EDIT_LOGS - history of updates in queries performed
Figure 5 - Entities to audits, history and log data
3.2. Results
After completing the project, as shown in Figure 6, the user to use the platform will need to fill in some essential information, these being to prevent fake records from being created in our database:
Figure 6 - Registration Screen
In each field, there is an example of what must be filled in, and in case the new user has been indicated by another, he can use the invitation code, where both received a certain amount as a reward.
Figure 7 demonstrates what the user's home screen will look like, after the user has registered, and confirmed the E-mail and telephone number, on his main screen, he will have some important information, such as the balance in the wallet, number of coupons for consultation, the coupon being a way to help those users who need to make more than one consultation per month, where they can be buying a greater number of consultations, for a lower price.
Figure 7 - User Home Page and Dashboard Panel
After the information on his balance, the user will have his invitation code available, where he can be sending it to his friend, then comes his query history, where demonstrate your last 04 queries, the screen will inform the query code, amount that was paid, the date of the request and the status, which may be between:
- Awaiting Assignment: Every query request will be started as awaiting assignment, where it will be when some employee assigns this request to him.
- Querying: An employee assigned that request, for him to do.
- Canceled – No Refund: Where an appointment is canceled and no refund is made.
- Canceled – Refunded: Where an appointment is canceled and the user is refunded, according to the type of appointment.
- Finished – Sent by Email: The query was performed successfully, and the user received the result by email.
- Finished – Sent by Whatsapp: The query was performed successfully, and the user received the result by whatsapp.
- Finished – Sent by Email/Whatsapp: The query was successfully performed, and the user received the result by email/whatsapp.
Figure 8 shows the Administrative Panel, where the administrative team will have access to the queue of requests, users, then on the query queue screen, we show a little of how the visualization is, where the employee has a vision of essential information , as well as a timer, which is updated when the page refreshes.
Figure 8 - Administrative Panel
The bar will initially be green, if the time for the service to be performed is halfway through, the bar will turn yellow, and finally, if the request is not being performed and the time for the service to be performed is at the end, it will be red.
Finally, Figure 9 shows the visualization of each request, where the employee clicks on the request, he will have access to essential information for the service to be performed.
Figure 9 - Execution Query Console
On this screen, the user who is part of the technical team will have available as much information relevant to the query, in the first field, he will be able to verify the type/data of the query, having a JavaScript function, to make it easier for the technician to copy the information, then, we can observe in the same request data pertinent to that person, such as CPF, Email, Cellular, and soon after we see the information pertinent only to the request, such as the date and time when it was requested, how was the payment method, the status of the request, if it is already or has been answered, after that, we see the timer that informs the time elapsed until the request was opened, and finally, we see who it was assigned to and when it was assigned to a technical team user, and it is worth mentioning that to save any changes, the assignment to a technical member is mandatory.
3.3. Technical and Formal Revision - A GDPL Validation
Because it is a research project applied in a real context, taking as a basis of analysis a corporate need identified from the coexistence and experiences in the different sectors that manipulate data directly linked to a decision process and trust directly related to personal information, civil, public and financial citizens, it was defined that a very relevant validation for the type of project would be the inspection of the prototype oriented to the recommendations and guidelines of the GDPL.
The GDPL or the Brazilian General Data Protection Law, is a law that consists of protecting the personal data of individuals as published "on August 14, 2018" (LGPD, 2022).
This law applies to all Brazilian citizens and all companies in the national territory, where it aims to carry out the processing of data of individuals, that is, all information that is stored physically or electronically that is capable of identifying a person must undergo treatment that ensures freedom, privacy and the free development of the person's personality, if this treatment does not occur, the company or individual receiving the personal data will be subject to disciplinary sanction as established in the Law. In order for these data to be processed, the natural person must give their consent and know the purpose of using their personal data in any situation they are requested.
Personal data are characterized first and last name, CPF, RG, address, telephone and other data that can identify a person with the information provided.
One of the possibilities for validating a system from GDPL regulations (2018) is an analytical validation performed by a specialist that scans the system at two main levels: in a functional layer and another from a lower level check, in the field, modeling and data storage. A more thorough inspection is carried out in the field of data manipulation through algorithms and an information security study based on network infrastructure resources and operating systems.
Considering a more shallow analysis and compatible with the intentions of this project, we have the following observations for an improvement in the treatment of the data that will be stored in this system, below I am listing some GAPs (Table 1) that were identified when we analyzed the database layer and its storage in an external agent:
Table 1 - GAPs and Recommendations according to an GDPL vision for the prototype | ID | GAP | RECOMMENDATION |
| 1 | Absence of encryption of database files
| Use of native tools such as Transparent Data Encryption (TDE) |
| 2 | No encryption of tables containing personal data | Use of table encryption algorithms, example: (Code 1, bellow) |
| 3 | Database access profiles | Creating database access profiles with permissions restricted to tables with personal data |
| 4 | Database backup | Creation of an encrypted backup routine for another environment that is not linked to the same server. |
| 5 | Security system | Configuration of an edge security system to control access to the database, examples: Firewall, WAF, SIEM |
| 6 | User Authentication
| Enabling MFA (Multi-Factor Authnetication) |
| 7 | Password Policy for user entry into the system
| Setting a strong password policy with change at a given time |
| 8 | Access profile within the WEB system | Creation of an access profile for an employee within the system. |
| 9 | Cookie Notice | Setting the Cookie Collection Notice on the Website |
Table 1 presents, on the one hand, the critical points according to a reading of the GDPL guidelines (2022) and, on the other hand, recommendations for their solution or mitigation. The identified GAPs were raised according to a functional, logical and physical analysis of the prototype, implemented and in operation. The recommendations were built from a systems design vision, fostering a proposal for future implementations of evolution or improvement for the project.
Code 1 - Execution Query Console
//
// alter table `CLIENTS`
// modify column</code> EMAIL <code>varbinary</code> (255)
// UPDATE `USER`
// SET CPF = AES_ENCRYPT(cpf,'key-to-encryption')
//
Basically, the formal evaluation process guided by the GDPL recommendations and guidelines was carried out according to the following methodology:
- study and analysis of the official
GDPL material; - practical study of other systems and related validations; then
- a functionally empirical and technical analysis on the developed prototype.
During the functional analysis, scenarios and personas were simulated for all possible actors that, through a list of tasks, allowed analyzes and sensations of transparency of data manipulated by the system.
In the technical validation, mechanisms of data persistence were investigated; recovery; presentation and the appropriate encryption algorithms.
3.4. Source Code
Conclusion
The project allowed greater contact with the development of web platforms using theory, technology, practice and modern tools. This project for its proposal and technologies explored such as modern frameworks for JavaScript, MySql relational database, etc. It offers an environment for the discussion of very important and controversial topics in the technical area.
As a future work, the project allows and stimulates the evolution of the project either from the proposals of the GDPL analysis or from the needs of improvement of the process as a whole, for example, with the development of an improvement in the process of interaction of the system to from notifications and push and instant messaging features.
References
- Zenvia (2022). “Site Oficial e Documentação do Zenvia” [online]. Available at https://zenvia.github.io/zenvia-openapi-spec/v2/#tag/SMSx. Accessed in 2022.
- Mailler (2022). “Repositorio do API de Email” [online]. Available at https://github.com/PHPMailer/PHPMailer. Accessed in 2022.
- MercadoPago (2022). “Site Oficial e Documentação do MercadoPago” [online]. Available at https://www.mercadopago.com.br/developers. Accessed in 2022.
- Fonts de Icones (2022). “Site Oficial de Fonts de Icones da Awesome” [online]. Available at https://fontawesome.com/v4.7.0/icons. Accessed in 2022.
- LGPD (2022). “Lei Geral de Proteção de Dados Pessoais (LGPD), LEI Nº 13.709, DE 14 DE AGOSTO DE 2018” [online]. Available at http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm. Accessed in 2022.
- Menvie (2022). Menvie Official Website and Documentation [online]. Available from: https://menvie.com.br/ Accessed October, 2022.
- Visual Studio Code (2022). “Download Visual Code Studio” [online]. Available at https://code.visualstudio.com/. Accessed in 2022.
- XAMPP (2022). “Download XAMPP” [online]. Available at https://www.apachefriends.org/pt_br/index.html. Accessed in 2022.
- AdminLTE3 (2022). “Template download AdminLTE3” [online]. Available at https://github.com/ColorlibHQ/AdminLTE/releases. Accessed in 2022.
- TudoSobreTodos (2022). “Tudo Sobre Todos” [online]. Available at https://tudosobretodos.info/quemSomos. Accessed in 2022.
- SOSBuscaOnline (2022). “SOS Busca Online - Uma Resposta para sua Busca” [online]. Available at https://sosbuscasonline.com.br/. Accessed in 2022.
History
- 24th October, 2022 - Document creation
- 30th October, 2022 - Textual revision
- 8th November, 2022 - Revision and validation
- 8th November, 2022 - Document submit
- 8th November, 2022 - Fixing the images relative links
- 10th November, 2022 - Authorship bug fixing
