Pup Biru

voyager automatically opens links in reader mode for me and it works about 80% of the time

(but this article it doesn’t work for)

this entire thread is about the STG petition, and thus about the theoretical possibility of how laws could change

mandatory minimum warranties are also not relatively minimal effort and yet we have laws that require those… most consumer protection standards aren’t minimal effort: that doesn’t mean we don’t make laws to ensure consumers get what they are expecting when they hand over money

why shouldn’t handing over source code to a game that’s being shut down (and apparently that nobody finds any value in since it wasn’t even bought in bankruptcy auction) be mandated as a last resort?

literally what STG is about

and the law is able to make license conditions illegal/unenforceable (like non-compete clauses in employment contracts)

usually in bankruptcy the game gets sold in order to help pay debts… whoever buys the game assumes the responsibility of contributing to run the online services, or provide options for others to… in the case that nobody buys the game (im not entirely sure what happens to the IP in that case) but it’s relatively minimal effort to release server source code or documentation OR even just remove the online parts that’s usually just for DRM which is now pretty irrelevant because you’re shutting it down anyway so why would anyone care if someone pirates it?!

not to mention whose recent valuations have basically been about selling their data to train models which will be used to make AI slop

A group of conscripted cooks took down a helicopter of landing marines

kinda reminds me of this: https://www.theage.com.au/national/collins-sub-shines-in-us-war-game-20021013-gduomk.html

during war games one of australia’s collins class submarines (diesel electric, quite dated at this point) managed to “kill” a los angeles class nuclear submarine (several times over?) when the US sub was also aided by 2 destroyers

there are public STUN servers: just like DNS, STUN is a fairly critical part of modern infrastructure

peer to peer real time video is a fairly solved problem. the fact that we have google/amazon/zoom/etc in the middle isn’t because it’s necessary

that having been said, STUN servers are also incredibly cheap to run… i wouldn’t consider it exactly off the cards for a company that’s selling products to support a public STUN server indefinitely… it’s not quite as simple as them having to pay tens of thousands /mo in infrastructure costs to keep the lights on: it’s more like $100/mo, which at numbers that small you’d make back in just interest on the sales you made… but i reckon it could go something like “support for 10 years” and then they release an update that lets you set your own STUN server; perhaps defaulting to a public, free one

you can make very cheap to maintain peer to peer solutions

you can use a STUN server to discover your public IP and use a method called UDP hole punching to open a port others can connect to. STUN servers are very cheap to run: they don’t actually handle the data; just provide a kind of handshake service in the middle for coordinating

this is often used for peer to peer video chat etc

right? like yeah i remember XMPP being cool n all, but all the experiences suuuuucked, not to mention (back in the day… i think its fixed now?) figuring out how the hell to get video calling working… “what extension does your client support?” is not a question a lay-person will ask: centralised systems don’t have extensions… they have “the way it’s done” and that’s it

inefficient in the sense that

• traffic go over the internet rather than internal networks which means the routing is much longer, over slower links
• not to mention that in distributed systems information frequently is duplicated many times rather than referenced on some internal system (sending out an email to 20 people duplicates that email 20 times across many providers rather than simply referencing an internal ID… you can just centralise content and send out a small notification message, but that’s generally not what people are talking about when they’re talking about modern distributed systems)
• each system can’t trust any other, so there’s a lot more processing that each node has to do in order to maintain a consistent internal state: validating and transforming raw data for itself - not usually a particularly big task, but multiplied by millions per second it adds up fast
• hardware scaling is simply not as easy either… with centralised systems you have, say, 1000 servers at 95% capacity (whatever that means): you can run them close to capacity because your traffic is generally insulated from load spikes due to volume, and generally you wouldn’t get 5% more load faster than you can scale up another server. in distributed systems (or rather smaller systems, because that’s implicit here unless you’re just running the hardware and software to duplicate the whole network, which would take more servers anyway due to the other inefficiencies and now you’re multiplying them) you need to have much more “room to breathe” to absorb load spikes
• things like spares and redundancy for outage mitigations also become more expensive: if you have 1000 servers, having a couple of hot spares (either parts or entire systems depending on system architecture and uptime requirements) isn’t that big of a deal but in a distributed system you probably need those hot spares, but all of a sudden every instance needs those hot spares somewhere (though this can be seen as a similar issue to traffic issue: spares of all kinds are just unused capacity, so the higher your ratio the more under-utilised your hardware)
• this is all without getting into the human effort of building systems… instance owners all need to manage their infrastructure which means that the mechanisms to handle things like upgrade without downtime, scaling, spam protection, bots, etc have all been built many many times

NONE of this is to say that they’re worse. in many ways the have a lot of advantages, but it’s not a clear-cut win in a lot of cases either… as with most things in life “it depends”. distributed systems are resistant to whole-network outages (at the expense of many more partial network outages), they’re resistant to censorship, they implicitly have a machine to machine interface, so the network as a whole is implicitly automatable (that might be a bad thing for things like spam, privacy, bots, etc), but people tend to generally be pro-bots and pro-3rd party apps

Having a unique password per device is best practices.

yup that’s all i’m getting at… this vacuum has unprotected access to ADB, which another user likened to root access, and i just think that in circumstances that are root-like, even physical access shouldn’t grant unprotected root

this seems needlessly combative… prevailing opinions are exactly as signal says… think differently? great! let’s do it, talk about it, see how it goes, and when the solution has scaled in the real world to what it’s competing against then you can feel superior as the one that had the vision to see it

but scaling is hard, and distributed tech is hugely inefficient

there are so many unknowns

anyone can follow a random “getting stared with web framework X” guide to make a twitter clone… making a twitter clone that handles the throughput that twitter does, that takes legitimately hard computer science (fuck twitter, but it remains both a good and common example)

heck even lemmy has huge issues with sync at its current tiny scale when there’s any reasonable latency involved… i remember only months ago when aussie.zone was getting updates days late because of a 300ms latency to EU/US and lemmys sequential handling of outboxes (afaik)

they’re not going to go after the robot vacuum when the thermostat, tablets, computers, TV, router, access point, etc are right there.

… and all of those things should be equally protected

they’re going to go for the easiest thing to extract information or escalate

since they have root they can add a password themselves!

the most absurd thing is assuming that an end-user is going do add a root password to a serial interface

i’m not saying end users shouldn’t be able to gain root somehow, simply that it shouldn’t be wide open by default… there should be some process, perhaps involving a unique password per device

doesn’t mean it can’t do damage - like fox news

hell you don’t even need a lab for a lot of bio plastics: you can produce them in your kitchen

Even 50 days is relatively fine if it’s cheap enough to replace saran wrap for food products

well we already have that

and that’s 50 days total, so those big commercial rolls of plastic wrap are much harder because they’re now perishable too: you can’t just stock a warehouse up

you’re on programming.dev so i assume you know that secrets is a generic term to cover things like your cloud account login (whatever form that may take - a password, token, api key, etc) for the robot vacuum service and you’re being intentionally obtuse

it’s a realistic attack scenario for some people - think celebrities etc, who might be being targeted… if someone knows what type of vacuum you have, it’s not “carefully take apart” - it’d take 30s, and then you have local network access which is an escalation that can lead to significantly more surveillance like security cameras, and devices with unsecured local access

just because it doesn’t apply to you doesn’t mean it doesn’t apply to anyone… unsecured or default password root access, even with physical access, is considered a security issue

yes and no… i agree with the sentiment, but with root you can extract wifi credentials and various other secrets… you shouldn’t be able to get these things even when you have physical access to the device… the root access itself isn’t the problem