Well, you're not supposed to use Tor from browsers that don't explicitly support it. Tor Browser, Brave, and I'm sure some others really wouldn't mind HTTP hidden service traffic.
I didn't know BSD had an IPv4/IPv6 translation mechanism built-in. On Linux the state of the art seems to be Jool[1], which is unfortunately an out-of-tree kernel module. IIUC, they currently share the limitation of not being able to translate locally-originated packets, which can be annoying unless you have a machine to dedicate to the translation.
Wait this looks interesting. I am a biologist so I might get the terminology wrong. Would this allow me to run a ipv4 to ipv6 and back service?
I got some services with only ipv6 addresses and want clients with only ipv4 (sadly still exists) to at least be able to reach them. So could I dedicate a machine to translating for them using this tool?
Yes, translating packets between IPv6 and IPv4 is precisely what Jool does.
From what you're describing I think you have to options: if you have enough IPv4 addresses at your disposal to cover your IPv6-only machines, you can use the so called "SIIT-DC" mode [1].
Otherwise, if you have less IPv4 addresses, say just one on your router, and multiple IPv6 machine you can setup a stateful NAT64 [2] with some static BIB entries. NAT64 is basically the familiar NAT, just with IPv6 in the LAN instead of private IPv4 addresses (say 192.168.1.0), and static BIB entries are the equivalent of port forwarding.
In this case you would run Jool on your router.
I am using socat right now to achieve this translation but it is rather slow. So o hope a proper solution using tool might be more powerful. But it seems it requires at least a bit more networking insight than what I have at this moment.
It's an opportunity to learn something new for me
Right now I simply rent a hetzner machine including a v4 ip to route the traffic to my V6 services.
However, I personally would just do it in userspace, especially for that simple of a use. I'm doing the opposite; I have a webapp that somehow doesn't handle IPv6, so to access it over a pure-v6 network I just run this on the same host:
socat TCP6-LISTEN:8002,fork TCP4:127.0.0.1:8000
I believe you could trivially reverse this;
socat TCP4-LISTEN:8002,fork TCP6:[::1]:8000
should serve [::1]:8000 as 0.0.0.0:8002 (I don't remember if changing ports was strictly required; that may be a quirk of my exact setup).
The point of Jool and similar tools (there is also one called Tayga that runs in userspace, if you want) is to translate network traffic between multiple hosts, where some only have IPv6 and others only IPv4 addresses.
If your machine has both IPv6 and IPv4 addresses you don't need to any translation.
I interpreted "services with only IPv6 addresses" as IPv6-only servers, in which case some sort of translation is needed, but if these are just processes in a dual stack server, then yes.
6to4 solves a different problem: it's a way to provide IPv6 internet access to some host with only IPv4 internet access. It's basically a VPN you need to configure on the client.
NAT64 and SIIT (what Jool and af-to are implementing) instead are a way to let (potentially) any IPv4-only client to connect to some IPv6-only machine you control. The client need to be aware its actually talking to an IPv6 machine, because there is a translator (typicall a router between them) that transparently translate the packet so they understand each other.
As much as Americans like to think everything is about America, I doubt this is somehow connected. These goverment-appointed officials, like the Secretary General of the Privacy Watchdog, tend to be incompetent and corrupt buffoons.
Just two months ago, the previous Secretary General was forced to resign[1] after he tried to spy on his own employees in a botched attempt to find a whistle-blower that had exposed his corruption. He couldn't get away with it only because the head of IT (who he ordered to carry out the actual spying) happened to be the son-in-law of the President of the Republic, which is practically the last remaining institution with some integrity in the political landscape.
To understand the magnitude of the incompetence of that fool, just know that he had asked IT to retrieve employees access logs and all emails for the past 25 years (hundreds of TB of data) and put them on a DVD so he could check them out [2].
I mean in a normal math curriculum you would define only the multiplicative inverse and then there is a separate way to define fraction, if you start out with certain rings. It is kind of surprising to me that they did a lazy definition of division.
This is the PoW scheme that Monero currently uses:
> RandomX utilizes a virtual machine that executes programs in a special instruction set that consists of integer math, floating point math and branches.
> These programs can be translated into the CPU's native machine code on the fly (example: program.asm).
> At the end, the outputs of the executed programs are consolidated into a 256-bit result using a cryptographic hashing function (Blake2b).
I doubt that you anyone managed to create an ASIC that does this more efficiently and cost effective than a basic CPU.
So, no, probably no one is mining Monero using an ASIC.
There are no excuses, this protocol is just terrible: it could have been made much much more secure without any kind of virtualisation or sandboxing.
For example, the kernel could be used[1] to store the secrets in memory and only authorize the userspace process that created it to read it; other processes could request access to a secret and only be given if you accept.
Yes, it's 100% a security theatre. Programs aren't even allowd to set their own icon because it's not considered secure, I'm not joking. The reasoning goes something like: what if a malicious program set its name to "firefox" and uses the firefox icon and then prompts you for the gmail password, eh?
At the same time a malware can just get all of your passwords without even asking using d-bus or read all of your files since it's running as your uid.
> Programs aren't even allowd to set their own icon
In GNOME. There is a protocol to set your window icon, and it will be respected by the Wayland compositors which are considering that there is value at having custom icons for each window. GNOME also considers it's confusing to have multiple windows from the same program with different icons, especially since the only places those icons could be displayed on GNOME are in the dock and in the Alt+Tab menu, but you pin apps to the dock, so those custom icons cannot be displayed there when there are multiple windows from the same app.
> At the same time a malware can just get all of your passwords without even asking using d-bus or read all of your files since it's running as your uid.
Thats not exactly true since this requires the application to have permission to talk to the secrets service (if using Flatpak)
Sandboxing on the Linux desktop is far from common and the flatpak security is kind of a joke [1] [2], unless something changed recently. For starters, it's the application that has to ask to be sandboxed, so if I were to make a malicious flatpak I will just ask for full file system access or d-bus.
I agree the flatpak defaults are not at all secure, as they often let the developer choose what to sandbox. I think this is fair, but the user has recourse: you can globally block all installed flatpaks from having access to a specific resource, even if the app "requests" it.
All my apps by defaults have no /home and no network access. I do this by writing to .local/share/flatpak/overrides/global (per user) or /var/lib/flatpak/overrides/global for the system. I wish this was publicized more. The defacto app for flatpak permissions, flatseal, doesn't have this capability yet to my knowledge.
> For starters, it's the application that has to ask to be sandboxed
Are you sure about this? My belief was that all flatpak apps run inside a bubblewrap (bwrap) sandbox. I just checked and that's exactly how it runs for me.
> so if I were to make a malicious flatpak I will just ask for full file system access or d-bus.
This is done at install time. The application inside the flatpak can't change it on its own. Reputed repositories like Flathub check the permissions and flag them if they are too broad. And you can also change it using something like FlatSeal. This is almost the same permissions model followed by Android.
Flatkill is very out of date and disingenuous. Flathub is very explicit and obnoxious about such unsafe permissions and can easily be modified by the user. It's also amusing that people here claim Wayland is a security theater too while posting about flatpak being bad because it's vulnerable to x11 issues.
No security boundary can prevent bad permissions just like in android.
> It's also amusing that people here claim Wayland is a security theater too while posting about flatpak being bad because it's vulnerable to x11 issues.
They both create an illusion of safety. We all know that X.org had no security model and it sucks. Wayland put restrictions that would make sense if the rest of the desktop ecosystem was made with security in mind, but it wasn't. I've heard way too many claims like "Wayland makes keyloggers impossible" that are technically true but irrelevant in the real world, because a desktop environment is not just Wayland.
Flatpack is also misleading and its sanboxing is just not great, regardless of the problem with X11.
> No security boundary can prevent bad permissions just like in android.
Good bringing this up: in Android the applications ask the user for permissions, in flatpak permissions are granted based on what the developed asked. That's just bad.
This would be very optimistic, essentially the project meeting its main goal, I'm not sure why you're calling it dark comedy. A 20 minutes pulse alone would mean the fuel injection, aux heating, plasma control systems and the divertor are working as designed. Net positive energy also means we got the physics of a burning plasma right.
The most recent timeline I know (from 2024) in fact puts the start of the DT operation at 2035, so I doubt ITER would achieve such a huge result within less than an year.
I think it's the "consecutive" that makes it funny. This thing that entire continents have been working on together for decades was operational for 20 consecutive minutes?!?
It's dark comedy because the progress of fusion just feels so agonizingly slow, that even a very optimistic prediction for 10 years from now sounds like such small and functionally useless progress.
And there's no shade toward any of the entities involved, it's a hard problem, but it's still funny.
No you don't. Commercial use means it makes economical sense. When you have to spend more on maintainance (and recycling/dumping contaminated wall material amd somehow get the fuel) then you never can hope to make any profit.
A running ITER with positive energy output for 20 minutes just proofs that the concept can actually work. From there to commercial use would still be a long way, if it ever can compete at all, except in niches, like deep space.
Nah, it's huge, you just have to remember the best result so far: the JET DTE-3 record that produced the energy to boil 60 tea kettles in a whopping 5 seconds pulse.
I know, the fact that "consecutive" is actually significant in this context is part of the joke. Just try to read it from the perspective of someone that isn't steeped in the details (and expectations) of the slog of fusion. Relative to any kind of aspirational "flying cars" or "wacky ideas" future predictions, it sounds very underwhelming.
reply