News for hackers. Stuff that matters.

DownrightNifty

To be fair, that sounds pretty bad?
Android 15+ has Private Space which is basically an additional work profile but managed by the system and not a third party app.

https://support.google.com/android/answer/15341885?hl=en

Under Signal's original leadership, there was definitely a hard stance against third party clients connecting to the network. I think they've been quiet on third party clients since Moxie left.
It's unlikely that their ToS would be enforceable in court. The fact that Apple never tried to sue Beeper speaks to this.
> Even if you change Signal's code to add a feature to export the DB, it apparently cannot see your DB, because iOS sandboxes that so that it is only visible to Signal builds signed with the Signal developers' keys.

This is not something exclusive to iOS; Android does the same thing.

Re:A Gallery of Installing from .dmg on Thursday August 06, 2026 @11:35AM (#49198135)
> they started forcing things to need to be in Applications

Since when?

Agree with your other points overall.

Re:Adding a feature to a closed-source app on Tuesday May 05, 2026 @08:04PM (#48030468)
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; my slop detector would've caught it and skipped this.
Re:Things Linux Can Do That Windows Still Can't on Monday March 16, 2026 @05:42PM (#47405340)
> Many of those points reveal lack of knowledge about Windows administration capabilities.

Do those capabilities require a more expensive edition of Windows?

Re:GrapheneOS – Break Free from Google and Apple on Tuesday February 17, 2026 @07:15PM (#47055353)
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

Re:The browser catches homograph attacks. Your terminal doesn't on Saturday February 07, 2026 @12:12PM (#46925485)
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 :)
Re:The browser catches homograph attacks. Your terminal doesn't on Saturday February 07, 2026 @11:10AM (#46924923)
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 less sense. Android's lack of a menu bar system makes it make even less sense there.

Re:Bitrig (YC S25) – Build Swift Apps on Your iPhone on Thursday August 28, 2025 @03:53PM (#45056324)
Wow, this is great. Would you mind if I reached out over email?
Re:Build iOS Apps on Linux and Windows (WSL) on Monday May 12, 2025 @05:17PM (#43967543)
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...

Re:Build iOS Apps on Linux and Windows (WSL) on Sunday May 11, 2025 @06:34PM (#43957775)
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 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.

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.

Re:Apple has 90 days to allow app sideloading in Brazil on Sunday March 09, 2025 @01:51PM (#43311722)
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.

Re:Apple has 90 days to allow app sideloading in Brazil on Saturday March 08, 2025 @12:52PM (#43301983)
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!
Re:Apple has 90 days to allow app sideloading in Brazil on Saturday March 08, 2025 @02:55AM (#43298402)
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.

Older »