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:

1. Administration Password: This password protects the entire useEngineer account and follows a unique security concept using SHA3-512 hash values and encryption. Account access is linked to a single email address and this password. Moderators do not need access to this account, allowing for separate management of moderator accesses by another person or group.
2. Moderation Password: Each moderator has an own moderation password. This password enables them to initiate unlimited group work sessions. A paid account with the useEngineer cloud service is necessary for this. The moderation access data is used to set up the online session, create a group password, and send the group link to participants. In test mode, no password is required since no account is needed.
3. Group Password: The group password is used to decrypt the confidential access data contained in the group link. When opening the link, users are prompted to enter this password. It allows users to actively reshape the content of the tool, with all changes being immediately visible to all group members. Everyone can work simultaneously.
4. Storeing Password: The memory password encrypts the active tool data as a whole within the locally stored HTML app itself. This file can be sent via email, and when opened, the active state of the tool at the time of saving is displayed after entering the storeing password. Each group member can also save the tool data locally with their own memory password.

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:

• All data is transmitted and processed as a Unicode character string.
• each string is an encrypted block.
• each block consists of 16-bit block length, 16-bit key type and the encrypted data.
• Protection relies on four secrets known only to the group.
• All secrets are themselves based on cryptologically secure random values.
• Three of the secrets are encrypted in the invitation email in the group link using the salted group password SHA-512 hash:
  1. name of the encrypted file (16 * 16 bit = 256 bit) [crypto random values],
  2. key base (32 * 16 bit = 512 bit) [crypto random values],
  3. Prelude block length (9 bit) [crypto random value],
  4. the preamble (0 - 128 16-bit characters) [crypto random value] is only part of the synchronization file.
• Decryption and encryption
  • Block = Length of transmission string
  • + 16-bit crypto random value
  • + Cipher block chain based on the key base rotated with the random value
  • Result = concatenation of all decrypted blocks

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.