Die wissenschaftliche Schreibweise ist 4e-10m.

Vorsilben:

• Tera
• Giga
• Mega
• Kilo
• Milli
• Mikro
• Nano
• Piko



A write-ahead log or WAL file is used in place of a rollback journal when SQLite is operating in WAL mode. As with the rollback journal, the purpose of the WAL file is to implement atomic commit and rollback. The WAL file is always located in the same directory as the database file and has the same name as the database file except with the 4 characters "-wal" appended. The WAL file is created when the first connection to the database is opened and is normally removed when the last connection to the database closes. However, if the last connection does not shutdown cleanly, the WAL file will remain in the filesystem and will be automatically cleaned up the next time the database is opened.

(Quelle)

When operating in  WAL mode, all SQLite database connections associated with the same database file need to share some memory that is used as an index for the WAL file. In most implementations, this shared memory is implemented by calling mmap() on a file created for this sole purpose: the shared-memory file. The shared-memory file, if it exists, is located in the same directory as the database file and has the same name as the database file except with the 4 characters " -shm" appended. Shared memory files only exist while running in WAL mode.

The shared-memory file contains no persistent content. The only purpose of the shared-memory file is to provide a block of shared memory for use by multiple processes all accessing the same database in WAL mode. If the  VFS is able to provide an alternative method for accessing shared memory, then that alternative method might be used rather than the shared-memory file. For example, if  PRAGMA locking_mode is set to EXCLUSIVE (meaning that only one process is able to access the database file) then the shared memory will be allocated from heap rather than out of the shared-memory file, and the shared-memory file will never be created.

The shared-memory file has the same lifetime as its associated WAL file. The shared-memory file is created when the WAL file is created and is deleted when the WAL file is deleted. During WAL file recovery, the shared memory file is recreated from scratch based on the contents of the WAL file being recovered.

(Quelle)

---

weiß einer [...] wie man diese Dateien öffnen kann?

In der Regel brauchst du diese Dateien nicht zu öffnen. Die einzige Datei, an der du herumhantieren solltest, ist die .sqlite-Datei.

Außerdem sollten diese Dateien nur solange existieren, wie eine Verbindung besteht. Danach müssten sie automatisch gelöscht werden.

Du musst wohl überprüfen, mit welcher Hand geklickt wurde:

if (event.getHand().equals(EquipmentSlot.HAND)) { // Haupthand
    // ...
}

Um die Sicherheit einer Webseite zu analysieren, werden in aller Regel Penetrationtests durchgeführt. https://de.wikipedia.org/wiki/Penetrationstest_(Informatik)

Da du allerdings weder selbst die Webseite hostest, noch den Code selbst schreibst, ist die Sicherheit deiner Website in erster Linie Sache von deinem Dienstleister, also Jimdo. Solche großen Anbieter haben natürlich ein wirtschaftliches Interesse an Sicherheit und du solltest daher gut bedient sein. Selbst kannst du dazu auch nicht wirklich etwas beitragen.

Davon abgesehen, klingt es so als wäre deine Webseite eine einfache Webpräsenz ohne sensible Nutzerdaten oder einen Shop. Daher besteht wohl für niemanden ein Interesse, diese zu "hacken".

Das sind zwar keine Bücher, aber diese Paper sollten auch interessant sein:
https://www.cert.se/2015/11/2015-11-20_Tor_-_the_Onion_Routing_Network.pdf
https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf

Da du den Begriff "das Darknet" verwendet hast, empfehle ich dir auch mal, meine Antwort hier dazu durchzulesen: https://www.gutefrage.net/frage/tor--browser-fuer-ein-darknet#answer-269213212