• 9 Posts
  • 223 Comments
Joined 1 year ago
cake
Cake day: August 4th, 2023

help-circle


  • Not really saying otherwise. What I am saying is that for your electronic devices to have “explosives” in them would require that a supplychain attack of a similar sort.

    It’s almost definitely not the case that any electronics manufacturers are systematically putting explosives in every smartphone or whatever that they manufacture and supplychain attacks are much more likely to be a targeted thing rather than “all Samsung phones” or whatever. If they weren’t targeted, it’s pretty certain that the presence of explosives in devices would be noticed even just by regular end-users with a bit of a tinkering proclivity within weeks. So if your devices are more than a couple of months old have been in reasonably normal use for most of that time and you haven’t been specifically targeted by any particular government or anyone who might have the ability to tamper with the supplychain, you’re almost certainly safe specifically from explosive-laced consumer electronics devices.

    Also, it seems unlikely that a state police agency (like the “sheriffs” you’re talking about) could leverage enough power to compel an electronics company to allow such a thing without the FBI or DHS involved. I’d imagine state police folks would more likely resort to more low-tech approaches like the Tulsa race massacre air firebombing.

    Again, I’m not saying it’s impossible that your phone contains explosives. And as I said in another comment, it might be possible to remotely get a device to cause its battery to catch fire. Maybe.

    Also, I am in the U.S., but what made you think that was the case?


  • Wow. Jeez. I’m sorry this is so close to you.

    can they do that to phones, without the phones being rigged?

    I’m not any kind of expert. But as others in this post have said, theoretically… possibly technically yes. If the firmware can be modified remotely to cause the phone to allow, for instance, overcharging the battery, then it’s possible the phone could be made to explode without physical access to the phone.

    How likely it is that you or your family specifically would be targeted, I couldn’t say. It seems unlikely…? And we don’t have specific knowledge that Isreal has tried any such attacks that didn’t involve direct physical access to the devices which later exploded. (And also no indication they’ve targeted any Samsung devices.)

    Again, I’m no expert, but if you wanted to take precautions, I’m thinking the precautions to take would be to put any mobile devices that contain rechargeable batteries and have wireless connectivity far away from your house and your family and stick to devices with no batteries (and preferably ones you’ve had for a “long time”) for a while.

    I’m sorry you’re in a situation where you’re having to weigh these risks. Again, it seems unlikely that you and your family could be in danger regarding ostensibly-stock Samsung phones that you’ve had for a while.

    Also, no condemnation is strong enough for this indiscriminate attack by Isreal on the people of Lebanon. Netanyahu must really be heartless to have authorized this. I hope this results in real pressure on Isreal to stop its indiscriminate terrorist acts.

    Good luck and stay safe.

    Edit: Hmm. Not sure why I’m getting downvoted so much. Maybe the downvoters think I’m making it sound more likely than is realistic that there’s a threat to Peepo specifically?


  • You should understand that what happened in Lebanon involved the government of Isreal physically modifying the pagers (and walkies) in question by adding explosives to them, turning them into remote-triggerable bombs.

    (The term “supplychain attack” has been used a lot to describe this attack. Isreal intercepted the order of pagers between when the order was placed and when the pagers were delivered. And either physically altered the pagers ordered or replaced them with altered/tampered-with pagers.)


  • So, I accept the premise that something that started as an abbreviation can take on a different meaning than just what it stands for.

    And I do feel it’s most reasonable to consider the term “incel” to include an attitude of entitlement to sex without consideration for the bodily autonomy of whoever they feel should be providing it.

    But I think that attitude is already baked into the un-abbreviated form. The term “involuntarily celibate” implies bigoted entitlement. It implies a worldview in which someone (typically women) owe the person who identifies as “involuntarily celibate” sex.

    If someone wants to murder people and nobody will let themselves be murdered to satisfy the wannabe murderer’s impulse, well, the wannabe murderer clearly has some issues to work through anyway, but calling themselves “involuntarily murderless” or whatever is highly fucked. The wannabe murderer has to already be thinking in terms of entitlement to kill people to adopt or identify with that term.

    If someone is “celibate” and would prefer to be in a relationship, don’t call them “incel” or “involuntarily celibate” unless they’re entitled bigoted assholes about it, in which case just call them “incels”.

    If they’re “celibate” and would prefer to be in a relationship but isn’t bigoted about it… probably prefer whatever term they would prefer you use, but maybe something like “single and looking” would be a reasonable term.

    If they’re “celibate” and don’t want to be in a relationship and are bigoted, “volcel” or “MGTOW” (with a derisive dip in tone) is probably a reasonably good term.

    If they’re “celibate” and don’t want to be in a relationship and aren’t bigoted, again, whatever they prefer, but “asexual” and/or “aromantic” might be reasonable.





  • Do they play a part in commercial DDOS protection?

    Absolutely! As well as mitigating other types of threats. “Web Application Firewalls” (don’t be fooled, they’re not like regular firewalls really) are a type of transparent web proxy that watch requests for anything that “looks like” a SQL injection or XSS payload and block those requests if necessary. Transparent web proxies may also do things like caching or even “honeypot” functionality that may shunt likely bot traffic to a fake version of the website to prevent scraping of real site content.


  • Ooo. This is a good one.

    A computer can have more than one network interface, right? (Like, you can be plugged into ethernet at home but also connected to the WIFI of the coffee shop across the street.)

    A VPN gives you a whole new network device (“virtual ethernet card” if you will) that works as if that card was connected to some LAN somewhere else. Typically, you’d forward “all” of your computer’s/smartphone’s/etc traffic through the VPN so that your computer “thinks it’s on that remote LAN” rather than on your home WIFI or whatever.

    Proxies… well the term can mean a few different things in different contexts, really. But generally you’re not forwarding “all” traffic through them, just HTTP traffic (and usually only a subset of all HTTP traffic) or just traffic that is specifically told to be forwarded through them.

    An opaque web proxy is one that you can point your browser (or other HTTP interface) to. It won’t handle protocols other than HTTP. And when you want to use an opaque web proxy, your HTTP client has to know how to do that. (Whereas with VPN’s, it’s your operating system, not your individual applications, that need to know how to forward through it.)

    A transparent web proxy can be something you (and your apps and OS) don’t know you’re even using. When you point your browser or app to a Lemmy instance, it’s almost certain that the domain is pointed not at an application server that actually runs the Lemmy code, but rather at a transparent web proxy that does stuff on the instance-owner’s end like preventing spamming or whatever. This type of proxy is sometimes called a “reverse web proxy” and can also only work with HTTP.

    A SOCKS proxy, like an opaque web proxy, requires applications to know how to use it. (Ok, technically that’s not 100% true. It’s possible in some cases to have a transparent proxy of some sort forward through a SOCKS proxy in a way that the application doesn’t know SOCKS is involved. There are also some cool OS-level hacks that can force an app to go through a SOCKS proxy without the app knowing anything about SOCKS. But if you’re doing those things, you’re a hacker.) And with a SOCKS proxy, your computer doesn’t “think” it’s connected to a whole different LAN. Individual applications know that they’re forwarding through SOCKS. SOCKS supports more protocols than just HTTP. Probably all TCP-based protocols, but I don’t think it has any support for UDP. So you won’t be torrenting through SOCKS.

    That’s all I can think to say at the moment. There are special-purpose proxies for things like security auditing (like Burp Suite, for instance.) But I’m guessing that’s not the sort of thing you’re asking about.



  • I write Java for a paycheck, but I really hate it.

    It feels like everything is layers and layers of overengineered cruft, each added to the precarious tower for something extremely minor. But every subsequent card in the house of cards makes it more precarious. “But look, I don’t have to write accessors.” “But look, I eliminated the need for the web.xml file.” “But look, I don’t have to understand SQL now.” But look, the codebase depends on a shit-ton of completely opaque Automagic™ that you have no hope of understanding the moment something goes wrong – which it will if you even think of changing your Java version. And since it’s practically impossible to understand what’s going on under-the-hood of whichever dependency is fubar’d this week, you have to resort to a mixture of trial-and-error and copy-pasting shit (that you also don’t understand) from StackOverflow and praying to Cthulhu something works – which is also trial-and-error because Java questions in particular have tons of just straight up wrong answers.

    To be fair, I’m the guy on my team who people come to when they run into those sorts of “I bumped up one subminor version of Mockito to fix a bug that was preventing my unit test from working but now literally half of our unit tests won’t build” or “I added the war plugin to the build.gradle and now SwaggerUI is broken.” So maybe I see more than my fair share of “well shit, I guess I’ll just spend the next three hours hunting down which magical combination of Jar version numbers will fix things” kind of problems. But damn. This shit didn’t ever happen back when I was doing Python for a paycheck.

    I don’t use Java if I don’t have to. If I have to use Java, I prefer to just use Servlets (mostly I do web development) and absolutely as few dependencies as I can possibly get away with. Fewer moving parts mean less that can break.