Yeah, that’s one of those tropes I hate pretty much everywhere, but (old) Star Trek is great enough to look past it.

They are skilled and professional. But how incompetently was the playbook written, if pretty much everyone can come up with something previously not derived spontaneously, if it’s that easy?

Great points.

Regular solar cells with better efficiency are already are thing, even in a compact travel format or as a novelty part of some electric cars. Those are cheap to produce, but still aren’t practical at all, unless we’re talking about something like a 2m² solar panel to charge a phone in a somewhat reasonable time on a very sunny day in an off-grid situation.

Using transparent solar cells additionally to regular ones in buildings instead of windows is pretty much the only reasonable application I can think of right now, but with a visible transmittance of 20% that’s kinda farfetched as well.

Yup. A variation of the quote (basically capitalists instead of American businessmen) is commonly attributed to Lenin instead of Khrushchev. But that, too, can’t be verified and is said to be fake.

Buying a domain. There might be some free services that, similar to DuckDNS in the beginning, work reliably for now. But IMHO they are not worth the potential headaches.

DuckDNS pretty often has problems and fails to propagate properly. It’s not very good, especially with frequent IP changes.

Damn, that’s wild. Cheers for sharing!

I have an understanding of the underlying concepts. I’m mostly interested in the war driving. War driving, at least in my understanding, implies that someone, a state agency in this case, physically went to the very specific location of the suspect, penetrated their (wireless) network and therefore executed a successful traffic correlation attack.

I’m interested in how they got their suspects narrowed down that drastically in the first place. Traffic correlation attacks, at least in my experience, usually happen in a WAN context, not LAN, for example with the help of ISPs.

Sounds interesting, got any links for further reading on that?

I can’t quite connect the dots between wifi/internet traffic spikes when IRC is so light on traffic that it’s basically background noise and war driving.

Nice message, but the thought of the existence of a competitive scene of contractors specializing in mounting TVs is hilarious. Also, that mounting plate is crooked af.

deleted by creator

I wrote a simple, locally running Webapp some time ago, that targets the Lemmy Import-/Export-API and supports transferring only specific userdata between accounts, as demonstrated in this corresponding Wiki Entry.

The import functionality in Lemmy is additive in nature, meaning anything you import gets added on top of existing settings instead of replacing it.

Does the same thing as these manual instructions for this usecase, may be helpful to some.

Ah. So Lemmy with version 0.19.4+ allows users to set a custom thumbnail URL for a post, which can be set to pretty much anything resembling a valid link, especially a link to another image in the local pictrs db and trigger a deletion of both when a minimum age check is passed.

Also this:

Except that the field allows some funny URLs e.g. https://t.t/;';'%22;...[:%3C%3E?]%27;%20yaba%20daba%20doo, if this is an issue too is not confirmed

"Oi mate, I wonder if this codebase uses color or colour. Anyway, push to PROD. "

To add to this:

We have to differentiate between physical and cybersecurity.

Are you more likely to physically lose your smartphone you carry around with you all day than your full ATX desktop standing in your office? Yeah.

But let’s consider the consequences for a moment.

If someone physically stole your desktop, chances are that at least a part of your data isn’t encrypted, the boot sequence probably isn’t (at least completely) verified, and your OS is wide open. There is little to no real isolation in most desktop setups. Once somebody managed to gain access to your system, it is outright trivial to steal your browser sessions, modify commands or run some code, at least in userland.

Physically stealing your smartphone is easy. But a modern smartphone is usually protected by verified boot and a password+fingerprint/Face ID combo. Unless you take active steps to compromise the security of the phone like rooting/jailbreaking it, disabling verified boot or disabling the passcode, it’s pretty hard if not near impossible to gain access to your data or modify it in a harmful way. If you visit an infected site or install an infected app, the damage is usually confined to that app’s data and the data accessible to it by permissions you probably had to allow to be set in the first place.

Now that’s speaking to your usual bad actors and usual setups. Exceptions, as always, make the rule. As soon as a sufficiently motivated and technically able actor with access to 0-day exploits, like a state actor, targets you for some reason, all bets are off. But even in this case, due to the advanced verified boot chain on most modern smartphones, those exploits rarely have the ability to survive beyond a reboot.

Interesting read.

So, in short:

• The attacker needs to have access to your LAN and become the DHCP server, e.g. by a starvation attack or timing attacks
• The attacked host system needs to support DHCP option 121 (atm basically every OS except Android)
• by abusing DHCP option 121, the attacker can push routes to the attacked host system that supersede other rules in most network stacks by having a more specific prefix, e.g. a 192.168.1.1/32 will supersede 0.0.0.0/0
• The attacker can now force the attacked host system to route the traffic intended for a VPN virtual network interface (to be encrypted and forwarded to the VPN server) to the (physical) interface used for DHCP
• This leads to traffic intended to be sent over the VPN to not get encrypted and being sent outside the tunnel.
• This attack can be used before or after a VPN connection is established
• Since the VPN tunnel is still established, any implemented kill switch doesn’t get triggered

DHCP option 121 is still used for a reason, especially in business networks. At least on Linux, using network namespaces will fix this. Firewall mitigations can also work, but create other (very theoretical) attack surfaces.