Let's walk backwards from the worst case to the realistic case.
1a. The absolute worst case, someone takes a memory dump of your VPS, well you are screwed if something fishy is going on they will find about it.
1b. Someone mounts the .qcow2 image and inspects your VPS like if its a docker image without leaving any trace, also in this case, you are screwed.
So we can already say, this project is not to defend you once you become a target, that's already too late.
Now let's see what can be actually done.
Someone takes a file system dump, yes we can work with this.
An automated script looks around the file system for something fishy, yes this is literally the use case.
But how to achieve this?
First we need to decide what an actor wants to detect in our media server:
- media files: if you do not have authorization to host them, this is the absolute worst. So how to tackle this?
First step: The project encrypts them, each media file is always persisted encrypted, the encryption key is a combination of a general encryption key, and a random value stored in the database. If you have both of them you can decrypt the file, if even only one is missing they cannot be decrypted.
At this point it becomes important what level of safety we want...
Do you want to stop automated scripts? The database can live in the VPS, unless a script is targeting exactly this project they will not be able to know that file X needs to be decrypted with Y
Do you want to be "safe" in case of a file system snapshot? The database then must be external to the VPS
Second step: The length of the media file is a giveaway, let's add some random padding to it.
- torrent info hashes, names, magnets, blobs, etc... This are in the gray zone, but a script could still treat the presence of a specific torrent infohash in your system as something to flag you for. We store them encrypted in the database, if you separate the database from the VPS then you have the decryption key in the VPS and the encrypted infohash in the database, a snapshot of the DB alone is not enough. Both VPS and DB are needed at the same time.
Yes, I'm aware this is not enough to stop a determined sysop, but this is not the purpose of it, the purpose is to never reach the point where they inspect you.
If this peculiarity of the project intrigues you, you can find out more about it at: https://github.com/maury91/miauflix
I do also have another feature I'm quite proud of, ahead-of-time downloads. I think the process of imdb_id -> torrent hash -> torrent file -> loading seeds -> download initial parts to be too long ( time wise ), so I worked for it to happen before you click "watch":
- catalog data ( TMDB/Trakt ) is constantly synched in backgrounds queues - sources are searched by priority in background queues - torrent health ( seeders/leachers ) are kept up-to-date periodically in background queues - torrent metadata is download in background queues and in case of mismatching data the torrent is deleted (a torrent containing movie_name.exe is marked as fake) - the initial sectors needed to stream a file are download when you enter the details page, if you don't click on "watch" like flash but you spend a little bit of time reading the description ( or in future watching the trailer ), everything will be warm and streaming can start immediately
I don't know if someone ever used it, but I contributed to webtorrent because when I was reloading a torrent it would make the server hang: https://github.com/webtorrent/webtorrent/pull/2878 [I was a little bit burn out at the time of this PR]