NotPractical

What does "retina" mean exactly? From what I can tell it's a general Apple marketing term rather than something concrete. Are 4K monitors unsupported by macOS? I've been using one with my MacBook for a while and I haven't noticed blurriness.

Source?

I tend to not really care about these things as long as powerusers have a way around it. Yeah, it'd be great if everyone was technically literate, but most people simply don't care to be, and I think that's okay?

IMHO there's a huge difference between no freedom for anyone (iOS) and secure-by-default, freedom only for powerusers (macOS / Android / Chromebooks / ARM Windows devices) ¯\_(ツ)_/¯

Perhaps they could've done something like...

    sudo tccutil disable_monthly_screen_recording_prompt [bundle_id]

tccutil(1) is already a thing, which by its name you'd think would give you full CLI control over the macOS permission system (TCC), but strangely it only has one command as of now: "reset" (in Sonoma at least, haven't checked Sequoia yet).

You seriously can't disable Private Cloud Compute or Apple Intelligence on iOS??

I was expecting to see something about how Debian's updates are slow. Instead I learned something about SELinux, which is cool. However, I don't think it's fair to extrapolate from this that Debian is less secure in general. A case has been made here that Debian is less secure for containers and server usage. For desktop users who just want sandboxed applications, I don't think Red Hat's SELinux implementation does much to protect them.

Sidenote: I don't like the implication that community-driven projects are inherently less secure.

> Lack of Resources: Debian as a community-driven project lacks the resources to develop and maintain comprehensive security policies comparable to those provided by Red Hat.

> access memory of processes run by your user

I don't think this is possible on Windows without administrator. It certainly shouldn't be, if it is.

But anyway, the fact that any userspace software can read all your personal files without any user confirmation as soon as you double-click on it is not a good thing, and as I said, all desktop operating systems are attempting to address this problem in some way, including Windows. I imagine the normalization of rootkit-style anticheat has become a pain point for the security team at Microsoft.

Kernel vs user mode. On most desktop platforms there's barely any difference, but they're all moving towards supporting sandboxing to some extent.

Sandboxing on desktop isn't there yet, but on macOS and Linux it's possible to sandbox games such that they only have network access. If most games start requiring administrator/root access for anticheat purposes, sandboxing them at all becomes a non-starter.

Nobody wants that running on their computer though.

Maybe it's time to just give up on PC gaming and use dedicated game consoles instead, which are locked down by design? The only real alternative seems to be running a cryptographically-verified known-good OS signed by one of the big three OS companies, which is also locked down enough such that cheating becomes impossible, or installing what is essentially kernel-level malware, just to play the latest games.

How do you avoid carrying credit cards? Do you not carry a wallet? What happens if your phone dies?

> they are extremely against MicroG

They are? I thought that was GrapheneOS. (Not commenting on which side is "correct".)

It's not malicious compliance, it's non-compliance. Apple still has 100% control over which apps you can install on your iPhone in the EU. The EU must force Apple to provide EU citizens with some way to bypass mandatory "notarization"[*]. Don't get me wrong, I'm all for scary warning screens -- malicious software does exist and Apple devices should be secure by default. But the DMA is toothless if Apple can "comply" and still have their final say over what EU citizens can and cannot install.

[*] "Notarization" for iOS is a misnomer and imposes a laundry list of requirements in addition to "the app isn't malware". The guidelines aren't even a separate document; they're quite literally a subset of the App Store guidelines (notice the "only notarization requirements" checkbox):

https://developer.apple.com/app-store/review/guidelines/

Compare that to the macOS notarization requirements, which are quite succinct and are anything but a subset of the macOS App Store guidelines: https://developer.apple.com/documentation/security/notarizin...

(macOS of course still allows you run apps that aren't notarized after passing through several scary warning screens.)

These extra unnecessary guidelines, along with the fact that you still need a paid Apple Developer account at $100/year to submit your apps for notarization (even if you just want to use them on your own device and distribute them nowhere), shut out FOSS entirely and render the DMA nearly useless from my point of view.

I have a feeling this might be a rhetorical question, but in case it isn't: the answer is no. Apple apps get special permissions, as per usual in the Apple ecosystem. Apple apps are automatically granted screen recording permission and can bypass the screen recording indicator entirely.

As long as it's not an ARM Chromebook, yes. (I think due to ARM just being difficult to work with in general rather than malicious behavior from Google?)

Also note that you'll most likely have to open it up and unscrew the firmware protection screw. It's kind of annoying but it's not difficult and at least it's not iPhone-style "impossible".

Do you have a recommendation to address #4? That seems like an intrinsic problem for web apps, see also ProtonMail.

Who is "we"? Big Tech?

> I don't see a conservative Federal judge gutting this ruling any more than I do a liberal one.

Can you explain how free market capitalism and deregulation of corporations is compatible with lawsuits like this one?

The GrapheneOS developers don't see it that way, and even think they have legal grounds to sue Google: https://news.ycombinator.com/item?id=41119047

In a world where the iPhone exists and there's no effective regulations against their obvious anti-competive behavior (even the EU's DMA hardly did anything), I doubt any U.S. court will take them seriously, but I guess we'll see.

I'm pretty sure they already do that. As always, the standard network security advice is "don't trust the client", and yeah, it'd be nice to be able to trust the client, but it would also mean the total abandonment of any meaningful user control over their own devices, so it's not worth it IMO.

> But it also does a bunch of stuff in the name of user privacy that Google would never sign off on.

I don't think that's necessarily true. It's actually kind of confusing to me that Google doesn't whitelist GrapheneOS. According to their website [1]:

> GrapheneOS not only upholds the app security model but substantially reinforces it, so it cannot be justified with reasoning based on security, anti-fraud, etc.

Ever since I discovered this article, as a GrapheneOS user, I've felt sort of conflicted about it. On one hand, it would be good to see more apps support GrapheneOS. On the other hand, as a FOSS advocate, it irks me that I can't make arbitrary changes to my OS without taking the risk that certain apps might stop working for no reason [2].

It also places GrapheneOS in a bit of an awkward position as a open source project, where it's possible that they might be forced not to include certain features because they made this promise to banking apps. For example, they would probably not accept a location spoofing feature that can't be detected by app developers, because banking apps could no longer trust the OS-provided APIs.

But again on the other hand, this policy means it's not off the table that Google might whitelist GrapheneOS in Play Integrity one day, which I think would be a good thing (of course there's business interests at play here, but there's no valid non-business reason for them not to).

Overall, the entire mobile phone ecosystem depresses me. I just try to avoid using my phone as much as possible, and keep the number of installed apps to a minimum. I'll probably give the iPhone a try if they ever start allowing sideloading (wishful thinking). Unfortunately it seems like it may become unsustainable to avoid placing full trust in your phone's manufacturer, and I'd only be comfortable giving that to Apple, not Google or Samsung.

[1] https://grapheneos.org/articles/attestation-compatibility-gu...

[2] It should be noted that, as of today, I don't think any banking app has added explicit compatibility for GrapheneOS. AFAIK all the banking apps that work with GrapheneOS also work with any (non-rooted) open-source Android alternative. As a sidenote, I currently work around this issue entirely by simply using my bank's website instead of their silly app, and this will continue to work as long as hackers continue to fight against Google's dystopian plan for the web: https://en.wikipedia.org/wiki/Web_Environment_Integrity

I agree in principle that you should call out all companies equally when they do bad things, but there's hardly any love for Google here. Meanwhile Apple's product announcements routinely get over 1k upvotes: https://news.ycombinator.com/item?id=40636844, https://news.ycombinator.com/item?id=40286029

If you search HN stories by popularity for "Google" and "Apple" on the first page you get:

Apple: 10 positive, 10 neutral, 10 negative.

Google: 2 positive, 10 neutral, 18 negative.

Not even close, but that pretty much aligns with my personal experience on the site.

> Is installing altstore to sideload really that offensive?

Yes. AltStore is a gross hack and will most likely be patched out by Apple if enough people start using it.

There's little evidence that this isn't simply because Apple is better at policing their store. It probably also helps that an Apple developer license costs $99/year, whereas Google Play has a one-time $25 fee. Keep in mind that the Play Store is just one of Google's many endeavors, whereas the iPhone is Apple's premier product, and as such, one of their top priorities.

Regarding dynamic native code execution, please see saagarjha's comment and my reply.

> Apple's security model

It would be more accurate to say "the iOS security model", because as beeboobaa3 mentioned, macOS fully allows apps from outside the App Store, dynamic native code execution, and most other "insecure" things that are blocked on iOS.

I agree. But it's at least worth noting that Google has taken steps towards blocking this as well, and it will likely be fully blocked in a future release of Android. From what I understand, it's partially to protect apps from themselves rather than the OS from apps, however. Additionally, it breaks legitimate apps like Termux, which many Android users see as a major regression. I personally think it's just another example of Apple-ish security theater, but Google has been known to copy some unfortunate things from Apple in attempt to mirror their success (see also: headphone jack, SafetyNet). Regardless, it goes to show that Android security is still evolving and the referenced 2020 article likely doesn't reflect the current state of things.

I avoided making a claim regarding the relative "security level" of Android vs. iOS because it's not easy to precisely define what that means. All I was saying was that Android's security model explicitly accommodates openness. If your standard for a "strong" security model excludes openness entirely, that's fair I suppose, but I personally find it unacceptable. Supposing we keep openness as a factor for its own sake, I'm not sure how you can improve much on Android's model.

This discussion seems to be headed in an ideological direction rather than a technical one, and I'm not very interested in that.

> Counterpoint: tech websites have literally warned users that they need to be wary of installing apps from inside Google's walled garden.

This is not a counterpoint to what I was saying. I'm talking about sideloaded apps, not apps from Google Play. I agree that Google should work to improve their app vetting process, but that's a separate issue entirely, and one I'm not personally interested in.

> This technical failing probably, partially, explains why they are so against allowing sideloading.

This occurred to me the other day. I've always laughed at the idea that Apple blocks sideloading for security purposes, but if the first line of defense is and always has been security through obscurity + manual App Store review (>= 2.0) on iOS, it's very possible that sideloading could cause problems. iOS didn't even have an App Store in release 1.0, meanwhile the Android security model has taken into account sideloaded apps since the very beginning [1]:

> Android is designed to be open. [...] Securing an open platform requires a strong security architecture and rigorous security programs. Android was designed with multilayered security that's flexible enough to support an open platform while still protecting all users of the platform.

[1] https://source.android.com/docs/security/overview

Edit: Language revised to clarify that I'm poking fun of the idea and not the one who believes it.

> GrapheneOS already has fine-grained firewall support exposed to the user via the standard VPN service feature which despite misconceptions can be used while also using an actual VPN and there are multiple apps supporting this.

Interesting, didn't know that. Maybe I should file an issue with the official WireGuard app asking them to support this. It would be nice if "multiple VPNs" was provided as an OS feature.

> It's not simply difficult to set up firewall rules where leaks aren't possible but rather it doesn't really work because not everything is done via direct socket access from the apps.

This only applies to rules intended for specific apps and not system-wide rules, no? I'd hope so, since as you said people are already applying system-wide (or at least user-wide) rules using the VPN interface.

Not OP, but I think that their concerns are legitimate for the most part. One example they've brought up is that, with root, a single bug in the display server could lead to complete and immediate compromise of the entire device (assuming root access is gated by UI prompts as is common on most rooted ROMs). Additionally, with verified boot, persistent changes to the OS made via root would cause the phone to be unable to reboot, which limits what you can do with root (assuming you still want verified boot). GrapheneOS standards are much higher than on desktop Linux, where root can be acquired as easily as injecting a fake `sudo` into ~/.bashrc.

Basically the idea is that there should be no need for root if everything is nicely gated by permission controls and high-level APIs. If every component of Android were actually well-designed, this idea would have more merit, but unfortunately there are still a few big gaps in what you can do with a rooted versus non-rooted device, e.g. custom firewall rules (which could provide a hotfix for the issue at hand here). When asked to expose more fine-grained firewall control to the end user, the Graphene devs basically responded that it's extremely difficult to set up firewall rules properly such that leaks are impossible [1], which may be true, but I'd like to think it's better than nothing.

Also, because root access would break Android's protection against end user application tampering, that would likely rule out the possibility of GrapheneOS receiving special support from banking apps, which is something they hope to see in the future [2].

Anyway, this particular issue is definitely a bug in AOSP, and will hopefully be resolved promptly. It's being tracked here: https://issuetracker.google.com/issues/337961996

[1] https://discuss.grapheneos.org/d/4113/6

[2] https://grapheneos.org/articles/attestation-compatibility-gu...

Minor conveniences like this are not worth the complete erosion of privacy, in my opinion. Just go to the nearest ATM to deposit checks (who uses checks anymore, btw?) and use the site for everything else. Not everyone even has a smartphone, and out of those that do, many prefer banking on their laptop over their phone anyway, which incentivizes banks to create feature-rich websites. If the mobile site isn't any good, usually the "desktop site" isn't too difficult to navigate on mobile, if you need to.