DownrightNifty

If you're gonna use Claude for writing in some capacity, this is definitely the way to do it. Thanks for not letting it write for you.

Many of those points reveal lack of knowledge about Windows administration capabilities.

Do those capabilities require a more expensive edition of Windows?

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?

[1] https://eylenburg.github.io/android_comparison.htm

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 :)

But as the title of the post says, browsers already solved this problem.

https://www.xudongz.com/blog/2017/idn-phishing/

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.

Wow, this is great. Would you mind if I reached out over email?

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.)

[1] They recommend using a secondary Apple ID, which eliminates most of the risk: https://swiftpackageindex.com/xtool-org/xtool/1.10.1/documen...

Mega cool!

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):

https://faq.altstore.io/altstore-classic/how-to-install-alts...

https://docs.sidestore.io/docs/installation/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.

https://www.lenovo.com/us/en/p/laptops/thinkpad/thinkpadx1/t...

The latest model X1 Carbon (Gen 13) doesn't appear to officially support Linux at this time, unfortunately.

Extra context I forgot to provide:

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.)

many developers are waiting for Google to add RCS to the same API that SMS/MMS already exposes because they don't want to implement RCS themselves.

Is that a planned feature? It's frustrating that third party messaging apps don't work with RCS. I hope we don't have to get the EU involved here...

Thanks for the suggestion. Feel free to contribute this change yourself if you want: https://github.com/DownrightNifty/dihsy/blob/main/dihsy.md

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.

[1] https://archive.is/9jdW7

Delta seems to be allowed (at least partially) because of the DMA and the EU.

Yeah, that's an important point. Delta on the App Store is most likely a direct result of the Digital Markets Act: https://www.theverge.com/2024/4/5/24122341/apple-app-store-g...

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.

Since DMA came into effect almost two years ago, can anyone comment on its effectiveness?

I'm so glad you asked, because I wrote an entire website about it: https://doesioshavesideloadingyet.com/

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.

We might hear another update from the EU rather soon though: https://9to5mac.com/2025/03/10/report-apple-will-be-fined-by...

I really hope that the DMA does not go down in history as a failed experiment, because that will be a huge loss for open platforms as a whole.

I personally don’t care about alternative app stores

I've seen this sentiment a couple of times here and I think it's the wrong framing on what the EU is trying to do. Third party app stores aren't the point; they're just a vehicle enabling users to choose which software they want to use without interference from Apple. The indie devs using AltStore PAL don't all necessarily want to use it, but they're forced to because of the way Apple chose to implement DMA compliance.

In fact, the DMA doesn't even explicitly require that gatekeepers allow third party app stores; they can only allow direct distribution (e.g. via web sites) instead, if they want (this is to the best of my understanding of the text, but IANAL).

When you say you don't care about alternative app stores, what you're really saying is that you don't care about the end user's ability to use apps that aren't approved by Apple. That is certainly an opinion that many folks have, but I'd prefer that they refrain from hiding behind the shield of "third party app stores are weird and who even cares", whether deliberately or not.

I believe this is the full text of the decision: https://sei.cade.gov.br/sei/modulos/pesquisa/md_pesq_documen...

It uses the word "sideloading" and doesn't appear to have carveouts allowing Apple to block apps for "security" like the EU legislation does. But at the end of the day it really just depends on what their legislators are going to allow Apple to get away with, and Apple will probably attempt bare-minimum compliance at least initially, like they did in the EU.

Sorry, I should've clarified that I was asking about whether you had a source for the claim that this legislation will not allow sideloading. I agree regarding the definition!

It's certainly a shame that piracy is a real factor here :(

It should probably be noted, however, that from what I understand, technically speaking, the only reason that piracy is possible in the first place is due to Apple's failures to prevent jailbreaking? iOS apps are encrypted and you need a jailbreak to decrypt them and redistribute them on shady websites. If Apple finally stomps jailbreaking out for good one day (which they are trying to do), then piracy should become impossible even if sideloading becomes an option.

See also: Xbox One has a developer mode that allows unsigned code execution, but that still doesn't allow for piracy because nobody's hacked the console, so nobody can obtain the game binaries to pirate.

Do you have a source for that?

I added it to the tracker:

https://doesioshavesideloadingyet.com/#which-countries-are-l...

Fingers crossed this enables true sideloading and not just third party app stores!

But option like "a possibility" available with hoops to software engineers or tech savvy people can't be.

Okay, then the only disagreement we seem to have is that you think that everyone who sideloads should continue to give a yearly donation of $100 to Apple (which they don't need or want) for the rest of their lives?

That is a very strange perspective. Keep in mind that I would fully understand if you don't think Apple should be forced by governments to provide sideloading for free; that's a separate issue, and I don't explicitly advocate for it on my website. The EU legislation has already passed; I'm just explaining what it means for tech enthusiasts.

Only in EU I guess?

I'm referring to the "classic" version of AltStore. The EU version only allows you to install Apple-approved apps and as such doesn't present any additional risk for malware. The classic version is available worldwide and it makes use of signing certificates from Xcode.

https://faq.altstore.io/altstore-classic/how-to-install-alts...

OK. Add couple more hundred bucks. Doesn't change the point.

It absolutely does change the point. You claimed that anyone with the required technical skills can sideload, but that isn't true; they need to be able to afford and justify spending an additional $8.33 every month to access a feature which is free on every other mainstream computing device.

From my vantage point allowing easy sideloading and alt stores are changes I don't want

I don't want that either, as I already said.

1) big corporations who want to run their own stores and not pay Apple a cut for creating and maintaining the hardware and ecosystem

I don't have any sympathy for Epic Games either.

3) regular people who want to pirate apps and not pay small-time developers and don't realize security implications

Sideloading doesn't inherently provide the ability to pirate apps. All iOS apps are encrypted and the binaries can't be accessed by other apps; the only way to obtain them is through jailbreaking, and that's something which probably won't exist forever. There's also of course unbreakable cryptographic measures such as remote attestation that Apple could employ if the problem grows into something too bad.

[Author of the site here]

It seems we're actually in agreement here :)

You say that any option will be social engineered, and then you go on to explain an option that Apple has already implemented that you don't believe is susceptible to social engineering.

Grandma could theoretically install AltStore, and then proceed to install malicious apps from unknown sources, right now, if she really wanted to. But she won't, because it's too complicated.

I'm not asking for an easy way to sideload. I wouldn't mind if it was made even more difficult than it is now, in fact. All I want is an officially-supported option to do so that isn't prohibitively expensive. An example I provided on the website is Google's ChromeOS. They make it difficult enough to enable developer mode that it's practically invulnerable to social engineering attacks. It's much more difficult to enable sideloading on a Chromebook than it is on an iOS device.

If you are dead set on it just mentally map in your head the price of a 1000$ device to 1100$ and be done with it

No, it's $100/yr, every year into the foreseeable future, and the cost could change at any time without prior notice. If you stop paying, your apps will stop working, so if you've grown attached to and have become dependent upon your sideloaded apps, it's quite unlikely you'll stop paying.

The Apple Developer Program is not intended as an option to enable sideloading on your device, and it never was. Apple only wants you signing up if you plan on submitting apps to the App Store, which is a benefit you're completely missing out on if you use it exclusively for sideloading.

"if you really care about it, you can do it" is a fair state of affairs

I would 100% agree, if that were an accurate description of reality, but unfortunately it's not. If you can't afford $100/yr, then no, you cannot do it. It doesn't matter how much technical knowledge you have; you simply cannot do it.

(I am a bit exaggerating the point but just because it seems like almost everyone is on the other side of the argument)

You and I must not be reading the same website? There is a very large anti-sideloading presence here on Hacker News. Most of it is based on strawman arguments and flawed assumptions, but it's there, and surfaces on almost every thread discussing the topic.

Yes, you're correct.

$100/year is too much

That's the issue, really. If you're paying for the developer program but you aren't uploading apps to the App Store, then you aren't using the program for its intended purpose.

I honestly don't think Apple even wants to collect your $100/yr, which is a pretty insignificant sum from their perspective. It's probably just used as a basic anti-spam measure allowing their reviewers to keep up with the pace of App Store submissions and to do their job properly.

They certainly would be entirely unaffected if they stopped collecting developer fees from the people who only use their membership for sideloading, since that number is most likely low enough to be completely insignificant.

Anyway, I specify this under the "What would it mean for iOS to have sideloading?" section:

For the purposes of this website, an operating system supports sideloading if it provides some means for technically-inclined end users to permanently install native apps without prior approval from any company or organization, either free of charge, or for a reasonable one-time fee. [...]

Apple would not have to make sweeping changes to iOS in order to qualify; in fact, a minor policy change would be more than sufficient. For example, all it would take to qualify is for Apple to remove the unnecessary expiry dates from development certificates (which can only be used on the creator's own devices, and cannot be used for distribution). They currently expire after 7 days for free accounts, or 1 year for paid accounts.

---

but if you’re paying $1000+ every 2-3 years...

I think this is unfair. iOS devices receive updates for at least 5 years, and they don't suddenly become useless after that point either. I for one don't upgrade my mobile devices until they stop getting updates, and I don't find myself yearning for the minor yearly upgrades we've been seeing lately (across the industry, not just Apple).

Spotify had previously posted the code for its uboot and kernel to GitHub, under the very unassuming name "spsgsb" and with no announcement

Interesting. Why not make some tiny announcement about it somewhere?