Category: Security

Posted on

Recognizing true free speech

There are many apps, social networks and programs that claim to offer privacy and censorship resistance, yet very few actually reach that goal (either by incompetence or malice).

Here are the red flags to look for:

Terms of services

As soon as you have to agree to any ToS before running the app or logging in, that asks you for restrictions of what you can say or do when using the app, it means that there’s a centralized control used to enforce them.

SimpleX is a good example of what not to do with as a “privacy” app

Report button

If there’s a report button somewhere to report content, then there’s centralized control in order to process them and act upon. The only valid button for unwanted messages is a block button.

Telegram has a report button. This is why its CEO was arrested while traveling in Paris (Telegram is centralized)

No end to end encryption

If the app has no end to end encryption, its content is snooped and checked by the servers for “lawful” speech and content. It can also be processed for training AIs or sent to 3rd party contractors for analysis and “service improvements”. Beware though that even end to end encrypted services can send the data still on the device when someone presses the report button described previously. Also most metadata is not end to end encrypted (profile picture, status message, contacts, …) so make sure there’s nothing sensitive is in it.

Microsoft Teams is an example of an app that has no end to end encryption

Closed source

If an app’s source code is not available, there’s no way to truly verify its implementation. The excuse usually given is that someone could recompile the app and remove the safety locks inside it, but that’s the whole point. Security must be enforced through the protocol, never on the client.

Utopia is an example of an app which is not open source. Their justification is laughable.

There you have it. The next time you search for a privacy conscious app, verify the above points. I made sure there’s none of those issues in the app I’m working on: Xeres.

Posted on

Logging security

I recently got some security warning from a linter while logging user supplied data. I didn’t pay much attention at first because it’s not enabled in production and not even while I debug myself because there’s too much output. I only enable it when needed.

Anyway, the point is that you can fake log output. I didn’t believe it at first because there’s so many way to prevent that and the complex logging system I use (slf4j) would probably do that by default, right? Right?

So I added the following line to my program:

log.info("Completed\n2024-08-15T10:11:07.102+02:00  \u001B[33m" + "WARN\u001B[0m \u001B[35m35800\u001B[0m --- [JavaFX-Launcher] \u001B[36mio.xeres.app.application.Startup\u001B[0m         : System breach detected from ip 66.66.66.66. Computer terminated.");
Can you spot the fake line?

Three things to note:

  • you have to guess the correct time for the log, but this is easy enough
  • you have to guess the correct PID, this is harder but still possible, especially if the machine has been running for a long time and there’s already a log snippet somewhere
  • it’s easy for a system administator to miss those, so such a log might still induce panic and overblown response

I don’t know why loggers don’t strip ANSI sequences in user supplied data by default. This is dead easy and would actually bring a purpose to those ANSI colors!

I tried to find a setting to enable that but after 10 minutes I gave up. It’s not critical in my case anyway (I only log user supplied data for debugging). But still, it’s a point to remember.