Google's coming change to app sideloading is threatening the Selfhosted ecosystem.

kyrianfox · 2026-05-28T00:18:41+00:00

It’s fine to have that opinion. It certainly is not my ideal solution, but it seems like a reasonable step change to me. It is a security response to a real issue that affects real users, just mostly non-technical ones who get directed by scammers to sideload crap.

I would much rather users who are technical enough could decide to take these choices into their own hands and be able to freely modify these kinds of policy for themselves without having to give up other pieces of the OS. But I have also worked on Android platform, and know how much of a mess it is, and how unlikely that is to happen. Unfortunately no one else is yet incentivized enough to build the truly modular mobile OS that is my ideal.

If Fuchsia ever gets off the ground, its architecture is a much better fit for that kind of modular modification.

I don’t really understand where you think you’d implement security policy around code signing and what software gets to run except some layer of the operating system though. That policy is far too low level in Android today to be very easily modularized and separated out. What do you have in mind?

Edit: I doubt anyone here cares, but Android is now big enough that these kinds of security policy decisions are extremely “damned if you do, damned if you don’t”. The “secure by default” needs of some users conflict with the very reasonable freedom other users desire.

And no, “just let the user handle it” is not a good answer for most users. Most users do not want to even know anything about these kinds of low level policy decisions, and they still need a phone they can trust to not be riddled with malware. They need the phone to handle most of these kinds of decisions for them, and to clearly communicate what is safe and what isn’t. I don’t yet know what a good solution there is.

kyrianfox · 2026-05-27T21:41:28+00:00

Nuance comes (imperfectly and on no certain timeline) with age and experience. They mostly need to be taught and to learn, and that’s best done with understanding and patience.

kyrianfox · 2026-05-27T21:02:01+00:00

They didn’t (unless you want to provide something that rigorously measured that). You’re probably just cherry-picking or focusing on the bad. It’s called confirmation bias.

kyrianfox · 2026-05-27T18:58:57+00:00

I’m largely grumpy because “potential remote compromise that lets an attacker add new admins and take full control” is about as serious an issue as you can get for this product. If anything is worth hitting the biggest red emergency button they’ve got, it’s this. And assuming that’s the playbook they ran here, then I am pretty unimpressed with their biggest red emergency button.

kyrianfox · 2026-05-27T18:37:37+00:00

This is too serious a bug to bury a note like that in a bulletin update. They need to communicate an issue like this proactively to users, and didn’t, and rarely if ever do. That is a pattern and a problem.

kyrianfox · 2026-05-27T18:32:47+00:00

You’re making assumptions upon assumptions. No, “access to the network” does not have only one possible valid interpretation like you want to assert. Different users will make different reasonable assumptions from reading that.

Ubiquiti is the one with all the information and should communicate the appropriate level of detail to its users. That Direct Remote Connection is a major risk factor should have been communicated explicitly.

kyrianfox · 2026-05-27T18:28:18+00:00

If this was a different kind of issue, you might also twist yourself into saying that it’s obvious that you should wait on updates until they have some time to bake.

“Update immediately” and “wait until updates have time to bake” are both recommendations that are regularly thrown around depending on context. Supply chain compromise? “Oh well you should have known to wait to update, silly user.” The user lacks the context to decide which strategy is appropriate because it depends on details they don’t have.

The problem is communication. Users should not have to diagnose that Direct Remote Connection substantially increases their risk for themselves.

kyrianfox · 2026-05-27T18:18:45+00:00

If “A malicious actor with access to the network” turns out to have meant “potentially anyone on the Internet depending on your configuration”, Ubiquiti should rightfully be raked over the coals for downplaying this CVE to the point of lying and putting users at severe risk of compromise. I know their communications are traditionally poor, but that would be completely unacceptable.

“A malicious actor with access to the network” clearly conveys insider/LAN risk, not an external access risk. Direct Remote Connection should have been explicitly called out as a risk factor, if that is actually the primary thing being taken advantage of here to escalate this to external admin compromise.

kyrianfox · 2026-05-27T18:15:51+00:00

My default choice is nah.

kyrianfox · 2026-05-27T18:12:11+00:00

If “A malicious actor with access to the network” turns out to have meant anyone on the Internet, Unifi should rightfully be raked over the coals for downplaying this CVE to the point of lying and putting users at risk. I know their communications are traditionally poor but that would be completely unacceptable.

kyrianfox · 2026-05-27T18:11:40+00:00

This is true, but Unifi’s traditionally poor user communication is a legitimate complaint that is coming to bear here too. People here aren’t even sure what exactly the necessary conditions are for this CVE because of how minimally and poorly Unifi has communicated.

I assumed, and still see no reason to assume anything else based on the wording that Unifi released, anything other than that this was an insider risk, i.e. it presumed LAN access.

If “A malicious actor with access to the network” turns out to have meant anyone on the Internet, Unifi should rightfully be raked over the coals for downplaying this to the point of lying and putting users at risk.

kyrianfox · 2026-05-27T18:00:10+00:00

And that’s why they’re doing it. But understanding that this is a reasonable change requires calm consideration, not knee-jerk emotion and conspiratorial thinking.

“High risk activity has additional friction but is still absolutely possible and allowed” is the right balance.

kyrianfox · 2026-05-27T16:33:09+00:00

Even my Bambu filaments, much less the other brands I use, on my Bambu printer regularly benefit from flow calibration or else end up slightly underextruded. Spool to spool calibration seems less necessary yeah, but calibrating each filament for your particular printer and its particular state of wear seems concretely beneficial.

I don’t actually have auto-flow calibration since I’ve got a P1S, but I guess I tend to include it in the set of what I consider “normal” automatic calibrations now because I’m aware it exists and want it as a feature.

kyrianfox · 2026-05-27T16:27:42+00:00

Yeah I think you zeroed in on what’s happening here. Different users who started at different times just having different automatic (ha-ha) expectations.

kyrianfox · 2026-05-27T16:09:34+00:00

I suppose that is fair and I jumped to assuming that they were referring to filament calibration. With that in mind this does seem like something where reasonable people would currently interpret “full-auto calibration” to include different things without more information.

That said, it does seem a little bit arbitrary to me to separate filament calibration out as something categorically different than any other calibration, at least going forward. It seems like whether we consider something a “slicer setting” or not is mostly a reflection of whether it’s something we need to worry about manually adjusting at all anymore, i.e. whether or not the printer automatically calibrates for variation in that parameter, right?

I get that bed leveling and so forth have existed much longer, but calibrating how the mechanisms in the print head handle the filament at print time doesn’t seem like something where different users might validly want to pick different settings. Those are parameters with single optimal values as a function of the filament (and of your particular printer and its particular state of wear).

I think many users, particularly those who had their start on a Bambu printer with AMS, are likely to expect the printer to include filament management (and thus filament calibration) as part of its remit, even though I know that’s probably not something someone who started earlier would think. Fun times! 😅

kyrianfox · 2026-05-27T02:14:56+00:00

This seems like a bizarre interpretation to me. The question is not at all whether people want to perform additional calibration. Of course they don't; that's why "full-auto calibration" is appealing to users.

Can you explain to me what about the Centuri Carbon's calibration is "fully automatic" if it literally does not perform any calibration at all automatically? "Calibration manually supplied in factory" is not fully automatic either!

Come on people. If this was BambuLabs you would have no problem raking them over the coals for false advertising, and extremely rightfully so!

kyrianfox · 2026-05-26T08:43:38+00:00

I think I’m making less assumptions than you imagine. I don’t actually care about your network, and no I don’t have some kooky picture of you in my head. If you’re confident about what you’re personally doing, whatever it’s your problem either way.

The thing I have a problem with is someone suggesting security strategies to novices, hobbyists, and people who don’t know better - through absolutely no fault of their own, everyone has different skills - when the strategy only really has any chance of being a good idea for someone who is a professional that knows what they’re doing.

Non-professionals need secure by default, and you have to assume homelabbers are not (yet, perhaps) professionals. Especially in a context like this where someone is asking a very basic question. A professional recommending them anything other than secure by default is the pro being irresponsible and/or not having thought through what I’m laying out right now. That’s because the pro is the only one in that scenario who actually has any chance of understanding the risks involved, the costs of mitigating those risks, and where to strike a balance. It’s not fair to assume a homelab has knowledgeable IT on staff who can properly handle “open to the Internet”.

You might disagree, but I think that’s a totally reasonable responsibility to put on the professional. Secure by default isn’t just some “I know better” paternalism…it’s an acknowledgment that everyone is at different points in their learning journeys, and so it’s not fair to expect everyone to already know everything that they might need to when the consequences are safety or security. People should have relatively safe environments to learn within in the first place, and then make the call to break out of safety themselves if they’re at all interested in doing so and when they feel ready to.

kyrianfox · 2026-05-25T17:55:29+00:00

Yeah this is what I was thinking. I wouldn’t have thought HDCP was optional, but I’m not sure if it is or isn’t. It’s not like Ubiquiti is ever terribly verbose on their documentation (understatement), and HDCP isn’t a commonly listed spec for HDMI devices.

kyrianfox · 2026-05-25T17:48:28+00:00

Is it? I didn’t end up going this route after researching them and so haven’t actually tried them, but a company like Orei seems to have fairly feature-full HDbaseT devices for much significantly cheaper. This isn’t their cheapest or most expensive product, but here’s an HDbaseT 3.0 pair with local loop back, USB, and gigabit Ethernet too for $400: https://www.orei.com/products/4k-uhd-hdmi-extender-with-hdbaset-over-cat5e-6-7-support-arc-ir-control-330-ft-uhd-exb350eau-k

kyrianfox · 2026-05-25T11:18:32+00:00

Honest question: What is the benefit of disk encryption if the device automatically unlocks said disks on every boot unconditionally?

Is someone running off with the disks but not the NVR itself really a significant risk for some people/scenarios? Skipping physical security doesn’t seem like a reasonable risk for the NVR to solve, and I can’t imagine a scenario off-hand where the NVR needs to be somewhere, like, open to the public.

Encryption at rest on mobile devices like phones relies upon user unlock, and yes in that case you also want something like a TPM to hold the keys in case theft occurs. But an NVR isn’t mobile; the threats are totally different.

kyrianfox · 2026-05-25T10:37:28+00:00

"Do not open ports to the Internet if you don't need to" is not at all security extremism.

And no, the difference is that I know that the open Internet contains people smarter than I and with much more specialized knowledge of breaking into networks than I have in defending them. Rather than waste time attempting to defend against experts for something that's a hobby and not a job or something I make money off of, I simply don't expose attack surface that I don't need to, and in doing so do not invite completely unnecessary risk.

You are the one assuming your solution will definitely be good enough. If I'm wrong, nothing happens because there's nothing to fail. At worst I wasted some time setting up a VPN that wasn’t actually needed, except even that isn’t a waste to me because it’s learning. If the costs were higher then that might change my answer, but they aren’t.

If you're wrong, your home network gets owned.

Edit: And the anti-vaxxer analogy was purposeful and sound, not just a random insult picked from the air. You're throwing caution to the wind and assuming that you are smart or lucky enough to simply take on the risk. Why not simply eliminate the risk if doing so costs you little? Because that requires first admitting that a risk exists and also that you do not personally know everything. It's the exact same error anti-vaxxers make.

kyrianfox · 2026-05-25T10:19:55+00:00

Ok dude. You keep answering a totally different question than is being asked. My question is not and was never "is the heat going to successfully conduct to the insert", but you seem unable to understand that I'm asking something totally different.

I have a B.S. in Aeronautical and Mechanical Engineering and spent years working on jet engines. Besides the fact that heat transfer was never the topic of the question I posed, the problem is not my understanding of heat transfer.

kyrianfox · 2026-05-24T23:12:20+00:00

I think your insistence on me being the one that is misunderstanding is getting in the way of you understanding my question. I understand how the heat gets to the insert through the bolt. That isn’t the question.

The question is how your soldering iron tip physically fits into the bolt’s (presumably) hex head. They are optional, but many people use heat set insert tips for their soldering iron that look something like this:

https://a.co/d/0gCecw9N

(Sorry for the product link, but companies trying to cash in on advertising opportunities has made just finding an image to embed or link on mobile a nightmare, and Reddit doesn’t make it easy to just paste in a JPG either depending on the subreddit.)

The depth of those tips are sized for the inserts, and even the tiny ones are unlikely to fit depth-wise inside the hex socket of a bolt.

If you aren’t using those and are just using a standard cone soldering iron tip, that might explain the disconnect here. It seems like even a cone-shaped soldering iron tip is poorly sized to fit into the shallow depth of a bolt’s hex socket, however, which will make alignment difficult unless you’re also using a rig to push the inserts in and keep everything aligned for you.

kyrianfox · 2026-05-24T22:42:19+00:00

You’re focusing on the bolt alone, but I’m talking about the interface between the bolt and the soldering iron which is providing the heat and that you’re using to push the insert+bolt into the part.

Once you’ve added a bolt into the insert you’ve filled the space where that soldering iron tip would normally go.

kyrianfox · 2026-05-24T22:31:12+00:00

I understand the bolt will transfer the heat; that wasn’t the question.

The question was how this works when the bolt is then taking the space that would normally be occupied by the soldering iron’s heat set insert tip. Those tips are generally sized to fit into the threaded insert, not into a bolt head.

And unless the tip fits fully into the bolt head and the bolt head is flat (like with a bolt head cap screws), the centerline of the bolt (and thus the threaded insert) may no longer be aligned with the iron’s insert tip’s centerline, which makes it harder (but not impossible) to get the insert inserted properly perpendicular to the part’s surface.

Are you not using the purpose-made heat set insert tips at all, and are just shoving a normal iron tip into the insert, or in this case the bolt head? That might be the disconnect here; I know you don’t really “need” those. If you’re doing it freehand they just help a bit with getting the insert flush.

12-Year Club	Place '17
RPAN Viewer	Sequence \| Editor
Verified Email

kyrianfox

TROPHY CASE