No, numbers stations are not permitted on amateur frequencies in the US. There are some notable cases of foreign governments setting these up and interfering with amateur allocations [1], but there's not much the FCC can do about that.
> Voice encryption/scramble on Amateur-Band's is not allowed, everything else is ok.
It seems like you're saying voice encryption is not permitted, but data encryption is? This is not true in the US. Any encoding used for the purpose of "obscuring meaning" is not permitted on amateur frequencies. Even using code phrases like "the eagle has landed" is arguably not allowed. There are some narrow exceptions for things like satellite control codes, but nothing that applies to hobby mesh nets.
> No amateur station shall transmit: [...] messages encoded for the purpose of obscuring their meaning, except as otherwise provided herein; obscene or indecent words or language; or false or deceptive messages, signals or identification.
It sounds like GPS, and thus a GPS-based stratum 1 server, uses these time servers, but they were successfully failed over:
> Jeff finished off the email mentioning the US GPS system failed over successfully to the WWV-Ft. Collins campus. So again, for almost everyone, there was zero issue, and the redundancy designed into the system worked like it's supposed to.
So failures in these systems are potentially correlated.
The author mentions another solution. Apparently he runs his own atomic clock. I didn’t know this was a thing an individual could do.
> But even with multiple time sources, some places need more. I have two Rubidium atomic clocks in my studio, including the one inside a fancy GPS Disciplined Oscillator (GPSDO). That's good for holdover. Even if someone were jamming my signal, or my GPS antenna broke, I could keep my time accurate to nanoseconds for a while, and milliseconds for months. That'd be good enough for me.
I self host an Immich [1] instance to backup photos on my iPhone. It’s OSS and has a level of polish I’ve rarely seen in free software. Really, it’s shockingly good. The iOS app whisks my photo off to my home server several times per day.
What I’m not sure about is how to backup things like iMessages, Notes, and my Contacts. Every time I’ve looked, it appears the only options are random GitHub scripts that have reverse engineered the iMessage database.
I don't understand why people downvote questions like this rather than just answer the question. It's a perfectly reasonable question imo given that it's not clear how this feature is being disabled. It appears that most of this is based on reddit speculation and the OEMs don't provide a definitive answer.
Meta: recently it seems like the community has been way too loose with the downvote button, but I'm not sure if I'm just noticing it more because it's getting on my nerves, or if there has actually been a change in behavior.
> This allows for some interesting new deployment models for DuckDB, for example, we could now put an encrypted DuckDB database file on a Content Delivery Network (CDN). A fleet of DuckDB instances could attach to this file read-only using the decryption key. This elegantly allows efficient distribution of private background data in a similar way like encrypted Parquet files, but of course with many more features like multi-table storage. When using DuckDB with encrypted storage, we can also simplify threat modeling when – for example – using DuckDB on cloud providers. While in the past access to DuckDB storage would have been enough to leak data, we can now relax paranoia regarding storage a little, especially since temporary files and WAL are also encrypted.
Seagate has a proprietary version of SMART called FARM. It’s supposed to be more tamper resistant than SMART, but it appears the fraudsters have figured out how to manipulate it too [1].
The best you can do is check FARM if available and perform a long burn-in with something like badblocks. Then compare the SMART data before and after the burn in. Checking the serial number against the manufacturers database if available is also a good precaution.
These are probably things you should be doing whether or not the drive is allegedly new.
I took a second look at ad blockers on the app store, and many report that they collect various bits of data. Are you saying that there's a special content blocker component to all of these that can't collect data because they're isolated by iOS? I'm not sure how anyone who isn't a iOS developer is supposed to navigate this. To uBlock's credit, their App Store page reports that they collect no data, but is this enforced by iOS? Or just a checkbox that the developer clicked?
Scrolling through the comments reading about all the adblockers that folks recommend makes my head spin. Why exactly should I trust any of these to have full access to my browser? Looking through the app store I see so many that are clearly trying to impersonate the well known ones by using similar names. It sounds like uBlock Origin Lite is trusted by many, but watch out for Ublock and 1Block, which are also top App Store results. Going off memory, the the chrome store is even worse. The whole situation is extremely sketchy. This is not even to mention supply chain attacks which could hijack even honest projects.
Personally I’ve settled on blocking at the DNS level with unbound and a blocklist. It’s not perfect but it limits the blast radius.
Terminal.shop lets you order coffee over ssh, which is kind of novel and fun. I did it, and the coffee was good! This post reminded me that they've gotten enough questions about security that they've added this to their FAQ:
> is ordering via ssh secure?# you bet it is. arguably more secure than your browser. ssh incorporates encryption and authentication via a process called public key cryptography. if that doesn’t sound secure we don’t know what does. [1]
I think this is wrong though for exactly the reasons described in this post. TLS verifies that the URL matches the cert through the chain of trust, whereas SSH leaves this up to the user to do out-of-band, which of course no one does.
But then the author of this article goes on to say (emphasis mine):
> This result represents good news for both the SSL/TLS PKI camps and the SSH non-PKI camps, since SSH advocates can rejoice over the fact that the expensive PKI-based approach is no better than the SSH one, while PKI advocates can rest assured that their solution is no less secure than the SSH one.
Which feels like it comes out of left field. Certainly the chain of trust adds some security, even if it's imperfect. I know many people just click through the warning, but I certainly don't.
I posted this in a sibling comment, but I can confirm Beelink's EQ14 [1] works well with OPNsense (FreeBSD based instead of OpenBSD). The dual NIC model uses the Intel KTI226-V chipset which has rock solid FreeBSD drivers.
I don't think I've run into any bugs, but there are also entire sections of the controller I haven't explored yet. I have a pretty typical homelab style setup with multiple wifi SSIDs for trusted devices and untrusted devices, and several VLANs to isolate them. I guess it's good to know rumors of Ubiquiti's death have been greatly exaggerated in case my Omada hardware starts acting up.
I've only been using it for a couple months, but OPNsense (FreeBSD based) is such a solid piece of software. I installed it on a cheap Beelink mini PC with dual 2.5 gb NICs and an N150 processor (model EQ14), and it's been reliable and a pleasure to use as my router. I have a TP-Link Omada setup which I've been pleased with, but I feel no need to purchase one of their gateways.
I ended up going with TP-Link Omada and have been happy so far (a managed switch and wifi 6 WAPs). I am a bit concerned about their security track record given how bad their soho products are, so I ended up sticking with my opnsense router at the perimeter as the first line of defense.
I’m curious to hear what you think you’re missing out on with Omada.
You can also block any arbitrary page element and that block will persist between page loads. I think it’s in right click menu. I used this to permanently block the YouTube chat feature.
It doesn’t seem like email scanning is necessary to explain this. It appears that simply having a “bad” subdomain can trigger this. Obviously this heuristic isn’t working well, but you can see the naive logic of it: anything with the subdomain “apple” might be trying to impersonate Apple, so let’s flag it. This has happened to me on internal domains on my home network that I've exposed to no one. This also has been reported at the jellyfin project: https://github.com/jellyfin/jellyfin-web/issues/4076