Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)LI
Posts
1
Comments
353
Joined
2 yr. ago

  • You probably didn't understand me. I'm saying that a company can just arbitrarily decide (like you did) that the server is the "end" recipient (which I disagree with). That can be done for chat messages too.

    You send the message "E2EE" to the server, to be stored there (like a file, unencrypted), so that the recipient(s) can - sometime in the future - fetch the message, which would be encrypted again, only during transport. This fully fits your definition for the cloud storage example.

    By changing the recipient "end", we can arbitrarily decode the message then.

    I would argue that the cloud provider is not the recipient of files uploaded there. In the same way a chat message meant for someone else is not meant for the server to read, even if it happens to be stored there.

  • Just like Netflix who purposefully scrambles the start screen to get you to watch something else rather than your favourites. They want you to not realize you have already seen all the good stuff already and unsubscribe.

  • You could probably configure your system monitor to show available memory - that is memory available given that cache can be dropped - rather than free memory that should always be as close to zero as possible.