Pup Biru

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

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

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

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

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

plus one of the main issues with desalination plants for fresh water is… getting rid of the sodium

but that’s a compromise… it’s not categorically better

you can’t run a bank like you run distributed instances, for example

services have different uptime requirements… this is perhaps the first time i’ve ever heard of signal having downtime, and the second time ever that i can remember there’s been a global AWS incident like this

and not only that, but lemmy and every service you listed aren’t even close to the scale of their centralised counterparts. we just aren’t there with the knowledge for how to build these services to simply say that centralised services are always worse, less reliable, etc. twitter is the usual example of this. it seems really easy, and arguably you can build a microblogging service in about 30min, but to scale it to the size that it handles is incredibly difficult and involves a lot of computer science (not just software engineering)

that’s pretty disingenuous though… individual lemmy instances go down or have issues regularly… they’re different, but not necessarily worse in the case of stability… robustness of the system as a whole there’s perhaps an argument in favour of distributed, but the system as a whole isn’t a particularly helpful argument when you’re trying to access your specific account

centralised services are just inherently more stable for the same type of workload because they tend to be less complex, less networking interconnectedness to cause issues, and you can focus a lot more energy building out automation and recovery than spending energy repeatedly building the same things… that energy is distributed, but again it’s still human effort: centralised systems are likely to be more stable because they’ve had significantly more work put into stability, detection, and recovery

no matter where you host, outages are going to happen… AWS really doesn’t have many… it’s just that it’s so big that everyone notices - it causes internet-wide issues

i think they need to use smaller words for themself because that is not the correct way to use that one

local storage isolation is the less interesting part, because that’s achieved much more cleanly with containers… profiles allow a kinda separate instance of your browser with different browser settings, addons, addon configuration, bookmarks, etc

i guess you’d need to expose both options: the ability to sync some profiles to some accounts and others to another… for example, i probably wouldn’t want my personal profile to sync to my work devices but id want my work profiles to sync between each other and be accessible from some of my home devices

totally; and i think that’s very fair for the large majority of use-cases… most people don’t need different browser settings: they just need different local storage

containers are for general browsing; profiles are for the whole browser

profiles allow you to have different addons installed, different configurations between addons in different profiles, different browser settings (eg a SOCKS proxy for work profile, or a different default search engine, default fonts, etc… or for technical users you can have a profile with experimental settings turned on)

also different addons, and different configuration for addons etc

profiles also allow different addons and addon configurations, default fonts, browser config, etc… it’s kinda like having a whole other user account or a whole other copy of the browser, rather than just cookie and storage isolation

…button