154 karma · joined October 1, 2009
ie the annoying way that LLMs interact with users
> The switch is useless in either of these threat models:
> To prevent cell tower triangulation, you can simply enable airplane mode and it is just as effective.
Folks interested in this space might also be interested in the system I spend most of my time working on: Shadow. It also performs deterministic simulation of a network of hosts, but it intercepts network and system interactions at the syscall level via seccomp. As such it can work with binaries compiled from ~any language, usually without any code modification or special compilation. https://shadow.github.io/
On recent Linux distros, by default you can't ptrace (or read memory via /proc/x/mem etc) of non-child processes https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama....
When I started long boarding at ~38, I practiced throwing myself into a roll first from a crouch, then standing, then standing on the board - onto grass of course. It helped a lot when I did inevitably have unplanned falls on the pavement.
The example I'm most familiar with, because I work on it, is Shadow. We used ptrace for a bit but now use seccomp.
For when I'm feeling very self conscious I have a script that turns off echoing to the terminal and streams everything I write to the clipboard (in case I decide I want to review/save after all)
The larger concern for deanonymization is typically flooding the network with relays, since it increases the ability to do e.g. timing-based de-anonymization attacks. This is a bit of an arms race. As @ajvs points out though, the known cases of tor users being de-anonymized were not due to attacking Tor itself, but via other channels. I'm not aware of any known real-world cases of users being deanonymized by attacking or analyzing Tor itself, let alone users being "arrested regularly"
As always it's probably a good idea to reach out to chat about what you have in mind before getting too far with implementation. #tor-dev on OFTC IRC (bridged to Matrix)
https://www.torproject.org/contact/ https://blog.torproject.org/entering-the-matrix/
The community does a lot of active monitoring to kick out misbehaving relays. "Misbehaving" includes running multiple relays without correctly setting the family attribute to identify them as being run by a single entity.
The main danger of malicious exit relays beyond other relays is that they perform some man-in-the-middle active attack. This is largely mitigated by end-to-end encryption. Tor Browser will soon be HTTPS only (other than explicit manual overrides) to help avoid inavertent non-e2e protected connections.
More in another recent blog post: https://blog.torproject.org/malicious-relays-health-tor-netw...
The lead dev on this feature, who also wrote the blog post, is taking some well deserved r&r after getting this feature out the door. I was somewhat tangentially involved (I work on the Shadow simulator, which we used to test, evaluate, and tune this feature) but can take a stab at answering questions.
Otoh comments on the blog post itself are likely to be seen by more experienced tor devs than myself :)
Disclaimer: am a Tor developer and employee.
obs4: https://github.com/Yawning/obfs4
obs4 in tor: https://support.torproject.org/glossary/obfs4/
We have recently learned of an interesting technique that dettrace [1] uses of combining seccomp with an eBPF filter and ptrace. Instead of generating a ptrace-stop for every syscall (as we do now, using PTRACE_SYSEMU), they use a seccomp policy with an eBPF filter, s.t. a ptrace-stop is only generated for syscalls that violate the policy, allowing them to emulate the result of those syscalls. syscalls that don't violate the policy are allowed to execute natively, saving a lot of overhead.
[1]: https://github.com/dettrace/dettrace
This works great for them since they want to emulate a relatively small subset of syscalls. In our case we want to emulate most syscalls, so it's not as clear-cut of a win. We have found though that if we use an LD_PRELOAD'd shim in the target process to intercept syscalls and then service them via IPC, that's substantially faster than catching them with ptrace. That runs back into the problems with LD_PRELOAD in general of there being various ways of missing syscalls. but, we may be able to use that technique along with ptrace+seccomp+ebpf to intercept any syscalls that we'd otherwise miss. The seccomp technique would allow us to exempt the syscalls that our shim itself is making to do the IPC.
The previous update has links back to the whole series; I stopped including it in the most-recent update since it was getting a bit cumbersome: https://github.com/shadow/shadow/discussions/1060
We recently added a discussion section to Shadow's GH repo: https://github.com/shadow/shadow/discussions. That'd be a good place for your questions. More knowledgeable folks are pretty responsive there, but aren't on HN :)
Mininet looks cool!
It looks like Mininet lets programs run pretty close to natively, using network namespaces to pipe data over its simulated network, and some other lightweight techniques for isolation and some extent of reproducibility (e.g. using the fifo scheduler).
Shadow intercepts the libc API via LD_PRELOAD, allowing finer grained control over the process's view of the world. In particular it lets us emulate time - we can run simulations with tens of thousands of endpoints on a single physical machine; even if we don't have the CPU power to run it in real-time, the simulation behaves as if we do. Conversely, small simulations can be run faster than real-time.
The down-side is that it's more difficult to support arbitrary software, since there are various ways of "escaping" LD_PRELOAD, and we don't support the full libc API. We're in the process of switching to a ptrace-based approach that is more robust, at the cost of some additional runtime overhead.
> Not sure exactly the extent of networking you can simulate with this toolset, but mininet lets you put entire simulated autonomous systems on a single laptop and you can mess around with BGP policies.
It sounds like mininet has a lower-level model of the network itself. Shadow simulates links between endpoints, including bandwidth limitations and drop rates. It doesn't model individual routers along the path, so yeah I don't think you could use it to simulate BGP.
Shadow's primary use-case is simulating the Tor network. Shadow's tor plugin has a step-by-step for getting a tor network simulation in particular running: https://github.com/shadow/shadow-plugin-tor/wiki
Yes, unfortunately some sites and such "protection" services block Tor IP addresses to mitigate abuse. While just blocking exit nodes would be sufficient (though still an overly blunt instrument), some carelessly block Tor relays as well.
In the case of Onion Services, unlike running a Tor relay or exit node, you are using Tor as a client, much the same as when you use the Tor Browser. Your IP is not on any such global list of "Tor IPs". Your ISP (or VPN, if applicable), can see that you're using Tor (unless you use a bridge), but this doesn't get you on these sort of block lists.
On a side-note, if you're thinking of running a Tor relay from home to help contribute to the Tor network, but don't want to risk getting your IP address blocked, consider running a bridge instead. https://community.torproject.org/relay/setup/bridge/
I agree that was a little unclear. I think what he's saying is that since humans can't hear above ~20 KHz, frequencies above that are lost. The 'wobbles' in the square wave are what happens when you take a square wave (which is a summation of infinite sine saves with frequencies an integer multiple of the fundamental) and drop the frequencies above the ~20 KHz cutoff.
In other words, it has nothing to do with any analog/digital conversion. It's just what happens if you ignore frequencies above 20 KHz, which we can't hear anyways. We can't hear any difference between a 'perfect' square wave and the bandwidth limited one.
I also don't completely understand about their being only one possible solution. It makes sense if you know that the signal is a single sine wave, but since in general the signal is a summation of an unknown number of sine waves, it's not clear. I guess this is something he didn't have time to get into more depth for the quick overview :)
> Isn't there also an argument that frequencies above 19khz
The rule of thumb I've heard is 20 KHz. I also wondered if this is an issue. It'd be interesting to know the distribution of how many people can perceive frequencies how much higher than that. I think though that the 20 KHz is already fairly far along the long tail, and most people's cutoffs are actually lower.
The main weak point is there's no way for the user to know if the javascript they're downloading is the correct Clipperz javascript, or a trojan'd version that will send my master password and decrypted database off somewhere. So, pretty much all is still lost if someone is able to break into Clipperz and modify the javascript without being noticed for a while.
A possible solution to that is to implement a browser extension to hash the javascript (and perhaps display it as a visual hash) so the user can at least easily check whether it's changed. This has been on my "possible side-project" list for a while...