• 0 Posts
  • 20 Comments
Joined 1 year ago
cake
Cake day: June 8th, 2023

help-circle

  • If you’d like to look into it further. the +i flag in chattr is setting an attribute making the file (everything in Linux is a file, so yes this even means directories) immutable. When a file is immutable, it isn’t possible to change the ownership, group, name, or permissions of the file, nor will you be able to write, append, or truncate the file.

    It’s been a while since I’ve used it, but I don’t believe it’s possible to have an immutable directory where you can still modify the contents therein, but I may be misremembering that. It would seem unlikely since adding content to the directory should require that you modify the links for the directory, which shouldn’t be allowable with an immutable object?

    It’s possible that the +a chattr attribute may achieve what you’d prefer. I believe that flag will make it so that files (and again, everything in Linux is a file) can be created and modified, but never deleted. I’ve actually never used this one, but I can foresee how this still may not be ideal for your wishes since updates to games may expect to be able to delete old content which would be thwarted here. 🤷



  • If gaming with Nvidia hardware is your primary concern, then maybe Bazzite would suit you. It’s based on Immutable Fedora, with tweaks to give it a SteamOS like experience. It offers Gnome or KDE for the desktop, and supposedly has everything dialed in for gaming. I’ve heard a bunch about it doing great with Nvidia cards and gaming in general, I suspect that you’d be able to do everything else you might need via the desktop it provides, but I have no knowledge of how it handles multiple monitors so maybe therein lies the fatal flaw.


  • If you use a fancy official VPN client from Mullvad, PIA, etc, you won’t need this since most clients already have a kill switch built in (also called Lockdown Mode in Mullvad).

    According to the researchers

    The result of this is the user transmits packets that are never encrypted by a VPN, and an attacker can snoop their traffic. We are using the term decloaking to refer to this effect. Importantly, the VPN control channel is maintained so features such as kill switches are never tripped, and users continue to show as connected to a VPN in all the cases we’ve observed.

    Killswitches are insufficient protection since the TunnelVision attack never disables the VPN tunnel. The TunnelVision attackers are instructing your physical layer connection to route everything through a node of their choosing rather than killing your VPN connection, and since the VPN connection never drops, a killswitch will never engage. The VPN stays up, thinking it is doing a good job, but in the meantime your network interface has been instructed to route no traffic through the VPN and instead route everything to the location of the attacker’s choosing. I have heard that a couple of VPNs think their clients are not vulnerable here, but I haven’t seen independent conclusive proof one way or the other yet.

    I suspect that your “Solution” also fails to mitigate the issues in TunnelVision because it allows LAN access to the physical interface. In a TunnelVision attack the hostile has to be on your LAN (or rather the same LAN you are on since I suspect that “The coffee shop wi-fi” is the more likely network for an attack like this) already, so if they’re going to tell your interface to route traffic somewhere else, in all likelihood that somewhere else will already be in the same LAN you are and their exfiltration will be allowed under your configuration.


  • I’ve dabbled with Linux on Mac hardware a couple of times and I’ve got to say that Linux DEs generally hew closer to Windows conventions than Mac ones and I found using the Mac keyboard with Linux to be a dreadful experience without the fact that the chiclet keyboards are the worst shit I’ve ever put my fingers on.

    I very quickly snagged a standard mechanical qwerty 104 key with brown switches and cursed every moment that I had to use that abominable keyboard built into the stupid MacBook. Apple seems determined to do things different for the sake of different as much as they possibly can and trying to adapt all their nonsense to the Win/Lin way of doing things made my life worse in numerous ways (most DEs have great remapping for keys and such, but it gets messy fast if you’ve got apps from different paradigms.)

    I’d very much recommend against going out of your way to get a Mac keyboard for using Linux unless you enjoy fighting against things. But hey, if that’s your kink, then a Mac keyboard with Linux would be my recommended way to go.




  • A process running as root does not need a prompt or any user interaction to do whatever the hell it wants on most (nearing ALL, but I’d be wary of absolutes with Linux) systems. I’m unaware of any means that a Desktop Environment could restrict a process running with root permissions by requiring an interactive prompt of some sort for anything. If your DE is running as root, all of its children are also running as root (unless you’ve rigged things up to run explicitly as other users) which means just about anything you are doing could be running rampant malicious actors on your system and nothing would seem amiss until it made itself evident.

    Now, it does seem unlikely that anyone has written any malicious code that would run in a browser expecting to be root on a Linux system, so that’s likely the saving grace here, but that’s only security through obscurity and that’s not much to hang your hopes on for any system you care about.





  • Your Mastodon data is already an open book to Meta if they care to have it. The protocol is open, they could already be black-ops scooping up everything that’s fit to federate without turning on Threads federation, so them doing that really changes nothing. And what I mean by that is that they could already have set up unknown instances to leech whatever data they want out of the Fediverse, which instances masquerade as normal mom and pop installs just federating and sucking up everything without bringing anything back to the table. There’s literally nothing stopping them from leeching everything out of the Fediverse at any time other than people being better at detecting their activity (and actively thwarting that activity) than Meta is at keeping it off the radar.

    In this case they’re making it so that I might have a chance to follow and interact with people already in the Meta/Instagram/Threads atmosphere without having to convince those people to leave the confines of what they’re comfortable with and find a Mastodon instance to sign up for. Maybe they’ll be more comfortable with leaving Meta after dipping their toes in the open spec?

    How is that not a win? If Meta/Threads decide that they want to fracture the protocol and go do their own thing later, so what? We’ll go right back to where we were before they brought their users into the Fediverse. If people decide that they value the Threads extras/connections more than they value the purity of the ActivityPub protocol then maybe Meta is actually providing something that matters and we’ve lost by not supplying that need before the corporate interest figured out that it existed. In that case we’ll deserve the death that causes in use of the open spec, but the open spec will still be there and people who want to do their own thing with it can’t be stopped now. The code to run an open ActivityPub Mastodon instance is already out there and it’s impossible to take it back now.

    Everyone is out here decrying this as a subtle takeover of the Fediverse by Meta, but did Facebook “takeover” the HTTP spec when they started operating facebook (dot) com on the world wide web over the HTTP protocol? It’s an insane assertion. I’ve been running my own opensource web servers since well before Facebook was a thing and I’ve continued to do so despite most people opting to depend on a mega-corp to be steward of their online presence. That Meta has a very successful and popular website that I’ve never been a fan of has never impacted my ability to use the open protocol they operate on to continue doing my own thing. The same thing will be true here.

    It really seems like people are just upset that Threads might bring ActivityPub to the mainstream and force them to contend with the realization that a diaspora of open spec implementations already lost the war to Meta/Facebook. We had that once before. It was called the World Wide Web and you could go and find forums, fan pages, company websites, and everything else back then that has since moved to Facebook (or other content aggregator sites) because people value the network effects and homogenization more than they care about one big company being in charge of it all. (…and not to belabor the point, but most of that stuff is still out there, it’s just waned in popularity because the network effects are not there.) Here we are with a chance to try and break things out again and people are seemingly worried that we can’t if we let the Meta users in? Maybe they’re right, maybe it’s impossible to achieve victory here, but gatekeeping the standard and enacting some purity test for which providers are allowed on the protocol isn’t going to tip the scales in favor of the open standards implementation.

    If the protocol is truly open, then how can a corporation embracing it be a danger? We’re all free to adopt any changes or not at any point in the journey so it’s impossible to lose, you’re free to keep doing your own thing any way you look at it. Tell me how any of this is untrue.

    TL;DR: Threads coming to the Fediverse is a good thing. It’ll make it possible to expand the network effects of an open protocol far faster and more than any amount of Fedinerds proselyting the gospel of ActivityPub ever will. The only thing that is at risk of being lost is that we’ll refuse to adapt to what end users want fast enough to keep a large corporation from bending the spec to their ends. Which loss again only means that you’d be cutting yourself off from those who WANT to embrace the revised spec by not adopting those changes yourself. That option (to just not adopt changes to the spec) can’t be taken away from you in the future, so worrying is only warranted if you feel like your ideal ActivityPub implementation can’t win out in the marketplace of ideas and that you’re owed that victory even if others are able to expand it in ways that people actually want to use enough to dismiss whatever downsides it contains.


  • I’ve a Mazda with Android Auto that doesn’t use a touch screen. It’s all controlled with a joystick/knob/button setup that is actually really nice. I wish my Nissan had a similar setup all the time.

    In the Mazda I know how many physical interactions will get me the result I want, it takes barely more than a glance at the screen to know what’s up. With the touch interface I have to put my eyes on the screen to confirm that the car didn’t bounce when I went to tap a “button” and/or confirm that the tap was actually registered. I know that GM has to know that Android Auto supports non touchscreen interactions. If they’re concerned about how unsafe touchscreens are, just add a knob to the center console that doubles as a 4-way joystick like Mazda has and all those concerns go away. It’s really that simple and it IS miles better than using touch for everything.



  • Any sites that attempted to restrict browser access based on WEI signals alone would have also restricted access to a significant enough proportion of attestable devices to disincentivize this behavior.

    If it’s actually a “significant enough proportion of attestable devices to disincentivize this behavior” why would anyone want to rely on this mechanism? I have a means to check if a device should be trusted, but it fails enough of the time that I shouldn’t depend on it… Why would I ever depend on it? What use case allows for an expected 10% failure rate?


  • The objective of WEI is to provide a signal that a device can be trusted

    This is exactly the opposite of everything anyone would learn in CompSci 101.

    NEVER TRUST THE CLIENT. CLIENTS CANNOT BE TRUSTED. CLIENTS ARE NOT SANE. THAR BE DRAGONS THERE. (Maybe that last one is pirate treasure maps, but I think it holds.)

    Anyone who is buying this guy’s argument that they’re trying to make it so you can trust clients, should immediately be removed from any computers they are in possession of and be “invited” by men in black suits to go live on a nice agrarian farm where the only computer available is an air-gapped Tandy TRS-80 MC-10. They can rejoin humanity when they’ve relearned the lessons of the last 40 years and understand why this is just patently insane.