• 5 Posts
  • 50 Comments
Joined 5 months ago
cake
Cake day: April 20th, 2024

help-circle
  • 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.





  • Random guy with no affiliation to crypto and only a vague understanding of monero from another instance here, who saw the post on /all.

    Most people stumbling over posts like this probably see yet another shady cryptocurrency and aren’t interested or even actively dislike it, resulting in downvotes. Calling people “grudgeful bitfags” and “overly-sensitive leftist fediverse dwellers” probably doesn’t help all that much either, neither do comments that attribute a general disinterest to a “very successful psyop by the CIA to make crypto look like a scam”.



  • 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.



  • Windows, as any operating system, is best run in a context most useful to the user and appropriate for the user’s technical level.

    • Need to run Windows apps/games and aren’t afraid to tinker around if and when something doesn’t work as expected or your software simply isn’t supported? WINE/Proton.
    • Need to run mostly light Windows apps and don’t want to tinker around? VM.
    • Need to run Windows apps/games that don’t rely on Kernel-Level Anti-Cheat, want direct hardware access and aren’t afraid to tinker around, especially if you only have one GPU, and when something doesn’t work as expected? KVM
    • Need to run any Windows app/game without things constantly breaking or the need to tinker around and staying on top of things? Dual-Boot from different disks, utilize LUKS/FDE and be done with it.

  • Why do you keep stating blatantly false info as facts when it is obvious that you’re knowledge of the topic at hand is superficial at best?

    In this comment thread alone you’ve stated that:

    • to avoid “Google Android”, one should use Lineage OS (?)
    • Apps on Lineage are some kind of separated on Lineage OS and not abandonware (??)
    • Lineage OS is not terrible for security, because you haven’t found anything wrong with it besides that small little, insignificant detail of an unlocked bootloader (???)
    • DivestOS has “all the same issues” as GrapheneOS(???)

    Genuinely not trying to stir up shit, I’m curious. Why?


  • 15-20 years ago, I’d have agreed with you. But apart from a select few news sites and exceedingly rare static sites, what percentage of websites most users use day to day actually function even minimally without JavaScript?

    I’m convinced that in practice, most users would be conditioned to whitelist pretty much every site they visit due to all the breakage. Still a privacy and security improvement, but a massive one? I’m not sure.

    Very happy to be convinced otherwise.







  • Oh, neat! Never noticed that option in the Wireguard app before. That’s very helpful already. Regarding your opnsense setup:

    I’ve dabbled in some (simple) routing before, but I’m far from anything one could call competent in that regard and even if I’d read up properly before writing my own routes/rules, I’d probably still wouldn’t trust that I hadn’t forgotten something to e.g. prevent IP/DNS leaks.

    I’m mainly relying on a Docker and was hoping for pointers on how to configure a Wireguard host container to route only internet traffic through another Wireguard Client container.

    I found this example, which is pretty close to my ideal setup. I’ll read up on that.



  • 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.