The cloud synchronization service associated with the useEngineer-app enables joint online meetings to work out the usability of user interfaces in groups. Various tools implement the different methods of usability engineering as an HTML-app: For example, when creating the usage context, card sorting and prototyping, the participation of the users is the basis of every success. The files on the useEngineer server within the European Union are highly encrypted. It is technically not possible for the cloud synchronization service to decrypt them, even in the case of support! The digital sovereignty of the users is, in addition to usability itself, a central concept of useEngineer.
No cookies - own or from third parties - or similar techniques!
Security experts speak of the highest level of data protection: End-to-end encryption, but that also means the reverse: If you forget your locally used passwords, there is no technical way to get a new password from the useEngineer-cloud-synchronization-service on request.
When using the useEngineer app, users take on the role of data sovereignty by assuming responsibility for managing their data. This includes versioning, updates, and the ability to revert to previous versions. This is made possible by an innovative decentralized data management concept. Users can back up the current state of their data locally at any time, in various ways. Each group member is also given the option to back up data. The app allows saving files in different formats, including readable JSON files. The HTML file of the tool can also be used locally, creating a standalone HTML application.
For online collaboration and cloud synchronization, a prepaid account is required. This account enables unlimited moderator access to the tools. This process establishes a hierarchy of security levels, each of which can be protected by different passwords. There are three types of passwords that should be distinguished in the useEngineer app:
The use of these passwords depends on the respective security requirements and application scenarios. All passwords stored on the cloud server are saved as "salted" hash values, meaning they cannot be reverse-engineered to their original form. This enhances data security. The choice of password depends on the desired security level and the target group involved. Group and memory passwords can be transmitted along with the group link or separately. When opening the link or the sent HTML file, the password is requested to decrypt the data.
The moderation password primarily serves to manage and update the synchronization file in the cloud. All cloud data can be overwritten with the actively displayed data, enabling versioning and rollback to previous versions. It is linked to a specific email address. If both are provided when creating the synchronization file, the file gains special attributes. Without the moderation password and with the email address "testing@useengineer.de", the synchronization file is created in test mode.
Creation and modification times of synchronization files are regularly checked. In test mode, a file is deleted if it is older than 20 minutes. The filename and associated access links are only valid for the current session and must be regenerated and exchanged with group members for each new session.
An online session and the group's access link can only last for 20 minutes with an active or valid service account. For this, the moderation password with the associated email address is required when creating. If this was checked successfully, the transferred old
file name is adopted and the last change of the synchronization file is always checked. The file is only deleted if this change was more than 40 minutes ago.
The synchronization file on the useEngineer server is encrypted using Cipher Block Chaining (CBC). For those interested in technology:
For projects with considerable need for protection: If hackers get hold of the synchronization files in any way, each file is cryptologically protected by the procedure. Due to the very small structure of the blocks transmitted during a group session and the structure present therein, it is possible that attack vectors can be found in initially small files based on statistical analyses.
Measures have also been taken against this. The 4th secret, prelude spoofing, makes this more difficult, even with short synchronization files, because it is unclear where the actual data begins. In addition, all transactions by group members are marked with a 16-bit random number specified at the start of the session, so that repetitions in the transactions - i.e. in the encrypted data itself - are minimized. In particular, repetitive standard transactions are also obfuscated using random values.
Additional security can be gained if necessary if a locally secured JSON backup is written back using the moderation password. This not only removes ineffective interactions due to changes - only the last state is retained - but with optimized file length the various small blocks are also removed. The highest level of security is achieved by empty overwriting or deleting the active synchronization file and creating a new synchronization file with a new group link for each group session.
Furthermore, the level of protection naturally depends on the quality of the chosen passwords. The roughly estimated quality is reported back directly when you enter it. An entrophy calculation combined with a pattern analysis is made after each character input. This normalizes 10 different pattern-free characters to a quality of 80%.
So what kind of data is on the useEngineer server? The synchronization file consists only of apparently random UTF-8 characters: many are invisible or non-displayable or Chinese. The control data stored as a list consists of four SHA-512 hash values salted with standardized, complex character strings per file.
The response time when creating a new file is at least two seconds.
© Dr.D.Fischer@use-optimisation.de