Agreed, the only thing that is certain is that they are cheating themselves.
While it can be useful to use LLMs as a tutor if you're stuck. The moment that you use it to provide a solution, you stop learning and the tool becomes a required stepping stone.
Yes, it would stop somebody's key from working, and that's the entire point, because most key fobs work on rolling ciphers, and if you block one, you can reuse it. Typically the fob will allow like 10 or so presses. It depends on the model before you're forced to re pair to the car. But by jamming it and capturing what it sent, you can then use that to get into the car.
@arti_chaud, out of curiosity, did you explicitly choose not to support what seems like a de facto standard for music servers? Or did you have to create the server to support the player?
I did choose to not use other standards as the main features of Meelo (multiple album/song versions, getting B-Sides, etc.) are not supported by them.
The server's API follows its own design.
It makes sense, since Meelo's main strength is the rich metadata model. You'd have to butcher it into a lowest-common-denominator format, which in many of these subtle cases would be missing the entire point.
I think people who would rather use streaming apps should just stick to Jellyfin or Navidrome.
I still prefer to listen to music through a native/dedicated app on desktop (and definitely on mobile). As much as I don't like Electron, Cider went with it and it's not that bad.
That... doesn't make things particularly secure. First of all MQTT doesn't require authentication. Secondly FTP is involved which is generally deprecated on most sensible servers and networks. Finally, sending passwords in the clear over an encrypted wire to an end device has been an obsolete technique for over 20 years. People still do it, but they shouldn't. It's the reason we have Kerberos, OAuth2/OIDC, and x509 client authentication with Mutual TLS.
If MQTT is fundamentally insecure, someone needs to inform the AWS IoT and Azure IoT teams.
While they are at it, they need to change their user admin consoles to only allow access via mTLS rather than sending "plain text" passwords over HTTPS as part of their OAuth 2.0 logins.
Yes, hyperbole, but there are many threat models and mTLS isn't some magic panacea, there are tough issues around key deployment and management which Bambu obviously haven't thought through.
Just like HTTP, there will always be someone who manages to misconfigure or turn off all the security. That doesn't make the protocol bad or irrelevant.
The majority of deployed MTLS certificates I've seen in the wild are used in IoT contexts to auth against MQTT servers because of the many advantages MQTT has over HTTPS for that use case.
I didn't say "inherently" or "fundamentally" insecure in my post. I said "generally". Generally, it's hard to deploy MQTT in a secure way, as it has many options that are insecure. In particular, you'll want to use mTLS, which itself is tricky to deploy due to the need for client cert verification. MQTT without mTLS is also prone to DDOS with less widely known techniques for mitigation than HTTPS.
The public HTTP web generally doesn't need client authentication, most just want server authentication, and thus it's a bit easier to deploy and use 3rd party services to mitigate DDOS attacks.
Nah, you made an absolute statement that MQTT was insecure, that was demonstrated to be incorrect. If HTTP can be made secure by relying on a secure transport, then MQTT can as well.
Additionally, MQTT does allow for authentication. I've personally set up brokers many times that will not allow anonymous connections.
Misconfiguration of services, does not constitute an error in the protocol itself.
It certainly has an optimized kernel for its use case. I believe it also includes ZFS by default. I wouldn't be surprised if the Proxmox developers would prefer to upstream these defaults, but they likely would introduce regressions for the common use case that Debian optimizes for.
Ultimately, I use Proxmox as a hardware hypervisor only, so I don't mind that it uses its own kernel. Everything I run is in its own VM, with its own kernel that is setup the way I want.
You think they are, but you have to trust that this happens. And even if they are, what happens if the grid is offline and comes online while the inverter is operational, how long does it take, if it does at all, to adjust itself.
If the product doesn't explicitly state this on its packaging there is absolutely a chance for competing sine waves. If this wasn't the case, transfer switches wouldn't have been invented. The original comment I replied to is simply dangerous.
> I put a lot of the blame here on Windows and its persistent refusal to implement a decent way to uninstall programs without using a vendor-provided binary/script.
While the install & uninstall process certainly be criticized. The fact remains that the uninstall script is made by Adobe. They deserve credit for all dark patterns that script contains.
Other systems have similarly opaque places where configuration can be left. Look at dot file structures, gconf, et al. on linux. As well as Preferences, extensions, input managers, Library folders on Mac.
Until we get a system that is entirely containerized, this will continue to be an issue.
We should probably keep the focus on Adobe lest we distract from their bad practices.
I agree that they deserve all the credit for the dark patterns in their uninstall script and people should be pissed. I just also think this was an incredibly obvious outcome, and would not have been a problem at all _if Windows hadn't handed them sole authority to uninstall themselves_.
This isn't even a new issue, I remember jokes about how hard McAfee was to uninstall like a decade ago. Adobe deserves hate for abusing a loophole, and Windows deserves hate for creating and maintaining that loophole through who knows how many issues with it.
> Other systems have similarly opaque places where configuration can be left. Look at dot file structures, gconf, et al. on linux. As well as Preferences, extensions, input managers, Library folders on Mac.
I can't speak for Mac because I lack the context, but there are like a dozen ways to deal with this on Linux. strace, iotrace, selinux audit mode, lsof in a loop if you're lazy and don't care too much, there are some tools built for basically this that use fanotify, I think sar might include this with the right config.
It's like moderate difficulty to write a shell script that will print all the files a process accesses, and trivial difficulty to consume the same.
It's also worth pointing out that a filesystem doesn't typically get "bogged down" the same way the registry does; i.e. there being unused config or cache files on the filesystem doesn't typically harm the filesystem in the same way that having useless entries in the Registry does. There's ups and downs to that kind of centralized config service.
> Until we get a system that is entirely containerized, this will continue to be an issue.
You can do this on Linux already for many things, depending on how much you need it to be isolated and what it does.
In the simplest manner, jails or chroot is probably enough to isolate most
applications' filesystems; I'm doubtful they even try to break out of them.
Selinux could be used; first run it in audit mode to generate a list of files it's allowed to access (and record the same), then set it to enforce on the app to prevent other access. AppArmor might also work, not sure.
I believe snaps and/or flatpaks can have their "filesystem" isolated to certain paths.
Docker containers are an option, or just regular old cgroups.
The most basic and common option on Linux is just to install and run it as a separate user. There are certainly ways around that, but most of them would require either giving the installer root access or the kinds of filesystem permissions that malware dreams of.
reply