In what ways does LineageOS trail behind AOSP in terms of security? I looked at the comparison chart you linked elsewhere and the privacy/security sections only seem to list advantages over OEM Android (not AOSP), with the exception of secure boot [1], but AOSP (not OEM Android) doesn't have that out-of-the-box either. Unless you are comparing Lineage with OEM Android?
They do provide installation commands for every platform that aren't vulnerable to homograph attacks due to GitHub not allowing Unicode characters in user/repo names :)
It does make running commands from an untrusted website a little safer, which is nice. I imagine it's not uncommon to copy installation scripts from random StackOverflow comments or blog posts, for example. But that's still not safe even with this tool. Homograph attacks aside, how can you tell if a URL you're pasting into your terminal is the official source for something? It's trivial to create fake GitHub accounts or organizations.
A simpler solution: examine the URL displayed in the browser window before copying terminal commands from the page. E.g. "starts with github.com" -> "trusted GitHub UI indicates the repo is the official one for this project" -> "URL points to the official project README" -> "terminal commands are most likely not malicious, and if they are, there's a bigger problem here".
Of course, more secure installation methods should be preferred, but those are not always available. I am simply comparing the provided solution to homograph attacks with another solution to the same problem.
The linked article seems to imply that this remains a good design choice even today:
> The use of this rule can be seen for example in MacOS, which always places the menu bar on the top left edge of the screen instead of the current program's windowframe.
I guess now that the browser is the one app you probably spend the most amount of time in, it might make a little less sense? Android's lack of a menu bar system makes it make very little sense there.
True, it's far from ideal, and not entirely without Apple's approval. You need an Apple ID, to accept Apple's EULA (which probably forbids such activities), to accept the risk of your Apple ID being banned [1], to accept the risk of Apple breaking things (intentionally or not), and to continue asking Apple's server for new signatures every week into the foreseeable future.
Still better than nothing, for those already fully immersed in the Apple ecosystem, with no hope of escape? (I still use and recommend Android, but I have a spare iPad to play around with, so I enjoy seeing stuff like this come out.)
We should all be taking full advantage of the amazing capabilities of the pocket supercomputers we all carry around with us at all times (even if the companies who make them don't want us to or don't care about us). Anything less would be silly! Now Linux and Windows users (the majority of iPhone users) can do easily do so, and that's great.
To install your own personal homebrew apps without Apple's approval, use AltStore (Windows) or SideStore (Linux):
Most laptops run Linux, but few provide official support for it. The Gen 12 and 11 did, and you could get Linux pre-installed. But there's no "Linux" option on the Gen 13 store page.
> RCS may require access to certain SIM card information, which only pre-installed apps can do
> because they don't want to implement RCS themselves.
Sounds like they can't implement RCS themselves even if they wanted to, not simply that Google doesn't provide an open source implementation? (Referring to app developers here, not custom ROM devs.)
I'll probably end up adding it myself if you don't want to, because it's actually something I wanted to include originally but forgot to.
This is definitely a huge issue with the current implementation of DMA compliance. Apple's mandatory DRM encryption scheme as part of the notarization process doesn't just block reproducible builds and the improved security that those offer, but also means that third party app stores aren't capable of auditing the apps they offer in any way. If Apple lets something slip through their notarization review (which is not an impossibility, since it's happened on the App Store before), then the third party store carrying that app will be unfairly blamed for the incident.
Some good points overall, and I think I agree in a lot of ways, actually.
> (or have the capability to jailbreak their iPhone and know what they’re getting themselves into)
It is a common misconception that people can "just" jailbreak their iPhone if they're not happy with the walled garden. This requires someone finding a critical-impact zero day vulnerability in iOS, quite literally worth around half a million dollars [1]. Apple is hard at work as we speak trying their hardest to prevent those from slipping in -- and that is a good thing, in general. It's not currently possible to jailbreak any up-to-date iOS device.
I'm all for sandboxing and other iOS security features; I'm not proposing that we get rid of any of that. Sideloaded apps would presumably still be fully sandboxed, and would still only be able to access sensitive data with explicit user consent. This is very different than the situation on Windows, where in 2025 you can still double click an .exe and instantly have all of your passwords and credit cards stolen (not an exaggeration; this literally happens).
I'm also not against the idea of making it difficult enough to enable sideloading so as to make social engineering attacks against grandma effectively impossible. This is what Chromebooks are doing; nerds get root, but grandma doesn't.
However, the DMA is more concerned with delivering alternative apps to everyone than it is concerned with empowering techies. So I can see why you might not support it even if you want to have a little more control over your phone, as a techie.
That is listed under "unofficial sideloading methods". A more accurate title would've been "Does iOS support sideloading yet?" but I wanted to keep the domain name as short as possible :)
The Apple Developer program is not intended as an option for end users to enable sideloading on their device, even if that is a side effect of joining it. It is only intended to allow developers to briefly test new builds of their own apps in a limited capacity before uploading them to the App Store (or third party stores in the EU). Apps "installed" this way expire after a certain length of time and you must ask Apple's cloud service for a new certificate each time that happens in order to keep using them. You're still tied to Apple indefinitely this way. If your developer account is terminated for whatever reason, or Apple decides to increase the price such that you can no longer afford your account, then suddenly you no longer have sideloading, and you no longer have access to any of the apps you previously sideloaded.
Therefore, I lump it into the same category as jailbreaking -- yes, you can argue that the existence of that means iOS already has sideloading, but it's not officially supported.
Sidenote: You don't need to spend $100/yr if you want to go the "unofficial sideloading" route; AltStore (Classic) is available for free: https://altstore.io/
The DMA allows Apple to take "strictly necessary and proportionate" measures to ensure that alternative apps do not "endanger the integrity of the hardware or operating system". IMO iOS notarization (which is a different and more involved process with many more rules than notarization on macOS) goes well beyond that, but it's up to the EU to decide.
Executive summary: Epic Games benefits greatly from the DMA, but powerusers and smaller developers don't get much benefit. This is due to Apple's lackluster compliance measures that are currently being investigated and may be deemed illegal.