# I am the Watcher. I am your guide through this vast new twtiverse.
#
# Usage:
# https://watcher.sour.is/api/plain/users View list of users and latest twt date.
# https://watcher.sour.is/api/plain/twt View all twts.
# https://watcher.sour.is/api/plain/mentions?uri=:uri View all mentions for uri.
# https://watcher.sour.is/api/plain/conv/:hash View all twts for a conversation subject.
#
# Options:
# uri Filter to show a specific users twts.
# offset Start index for quey.
# limit Count of items to return (going back in time).
#
# twt range = 1 7
# self = https://watcher.sour.is/conv/2sqadwa
Just one link I found. There is a vast literature on this topic. The basic idea is to describe whatever protocol--be it key exchange or some other thing--in a formal way (programming language), and then run automated verification algorithms to ensure the protocol is actually providing the security guarantees you want it to. Experience shows it's wayyyyyyyy too easy to convince yourself that a protocol is secure when it is not, and that trusting someone else's algorithm doesn't solve this problem nearly as well as formal methods do.
A for instance: security researchers found that combining Rust or Go code and C code produced systems that were *less* secure than C itself. This is counter-intuitive to many people, because they perceive Rust and Go to have "solved" many of the issues that plague C. However, what was found is that the combination of the two languages allows for essentially new kinds of security vulnerabilities. So, the "intuition" that you cane make a C codebase safer by using Rust or Go with it is wrong--in fact you make it less safe, in general.
https://www.ndss-symposium.org/wp-content/uploads/2022-78-paper.pdf
> We show that because language safety checks in safe
languages and exploit mitigation techniques applied to unsafe
languages (e.g., Control-Flow Integrity) break different stages of
an exploit to prevent control hijacking attacks, an attacker can
carefully maneuver between the languages to mount a successful
attack. In essence, we illustrate that the incompatible set of
assumptions made in various languages enables attacks that are
not possible in each language alone.
This says to me that if you wanted to write Go software that was intended to be secure, you should be very careful about depending on C/C++ code, and you should be very careful about depending on Go code that depends on C/C++ code, and.....all the way down the dependency chain.
And you should formally verify your security protocols, too, on top of that.
I buy this 👌 stick to pure X where X is a safe language 👌
I buy this 👌 stick to pure X where X is a safe language 👌