NotPractical

Is this legal case still ongoing? At first I was under the impression that this was about Apple's lackluster compliance with the DMA, but it looks like it might be about whether the DMA applies to Apple at all.

[Edit]

They submitted a report to the European Commission describing why they think Apple's compliance is insufficient: https://fsfe.org/news/2024/news-20240627-01.en.html

From this article, it seems they've been actively involved in the regulatory process for some time now, which is really cool. I had no idea that the concerns of free software advocates were legitimately being taken into consideration here.

Looks like Apple v. EC (over whether the DMA should apply to Apple) is indeed still ongoing at the same time as the EC's non-compliance investigations. FSFE submitted arguments to the court in favor of the EC just last month.

Those apps are deactivated after 7 days unless you pay for an Apple Developer subscription. There's the non-EU version of the AltStore which attempts to circumvent this restriction, but it's a dirty hack and I expect Apple to patch it out eventually.

No, it's not close at all. macOS allows you to sideload, EU iOS still does not. macOS allows you to write programs for your own device without paying Apple $100 every year, EU iOS still does not. macOS provides an environment for general purpose computing, EU iOS still does not.

Maybe not for long though: https://digital-markets-act.ec.europa.eu/commission-sends-pr...

Love the brutal honesty! Even as a macOS user I admit that it's difficult to justify learning the Apple-proprietary tech needed to port apps to it (and automated testing is indeed a nightmare). Curious as to your thoughts on Android?

> Safari listed as supported

Interesting, does this work on the latest releases? If so you might want to let this fellow know to adjust their threat model accordingly :)

https://news.ycombinator.com/item?id=41912226

Yes, on WPA2. WPA3 introduced per-client encryption keys.

Seems the article hasn't been updated to indicate his role as head of the Yuzu and Citra projects (recently DMCA'd by Nintendo).

Chrome uses it too. However the CDP protocol allows any local app to control the browser so you can use that to open the browser in windowless mode, examine the list of passwords at chrome://passwords, then open a bunch of tabs to all of those sites and extract the passwords from the HTML forms they get auto-inserted into.

This is a much more likely attack scenario than browser zero days.

* Some functionality is off-limits for sites loaded via HTTP. (Another commenter mentioned clipboard access.)

* Browsers will display annoying warning symbols whenever you try to access sites via HTTP.

* If you live in a shared living space such as an apartment you probably don't have control over your home network.

* Even if you have control over your network, a single compromised IoT device is enough to sniff your internal network traffic, assuming WPA2. (Probably not super likely tbh.)

Those are vague examples of what the NDK could be used for, not an exhaustive list of all supported use cases. And Syncthing is really just trying to re-use their existing code on Android (example use case #2). It doesn't even require low-level syscalls, it just needs to be able to call fopen() on files which the user has explicitly granted to the app, which you'd expect would be available within the application sandbox.

> And most likely safety, not having C and C++ dealing directly with random bytes from untrusted files

You might as well just axe the entire NDK if you're worried about unsafe code.

I'm always happy to see F-Droid exclusive apps. Gives Google less power over what they can do.

fopen(), fwrite(), etc. are a part of libc and as such are officially supported [1], but they become somewhat useless with SAF. (It makes sense that you'd at least have to use some Java to open a file picker and request access, but why not provide native access as well when a file is picked?)

[1] https://developer.android.com/ndk/guides/stable_apis

> Take the downvote button away from imbeciles

People that aren't familiar with Android's proprietary labyrinth of a filesystem API, you mean? If you had provided evidence that it does instead of just saying so in your first revision, you probably wouldn't have been downvoted.

You have to use `termux-setup-storage` to gain access to shared storage. If you're referring to an app's private app data folder, there's no way to access that without root via any app.

You're right, it's far from perfect, but it shows that it's not difficult to restrict native access to specific files/folders using the kernel and not weird Java IPC (which I guess should be obvious anyway). Google could've opted to provide native access to files, in addition to access via SAF, when you select a file via the picker, but they didn't. Graphene did it correctly from the low-level implementation side, not the UX side (but they can't really make the UX easier without breaking compatibility with standard Android apps AFAIK).

You're nearly correct, actually. In addition to security, SAF was supposed to provide a consistent interface to access files from various sources, including network sources, not just the local filesystem. Unfortunately the implementation just kind of sucks.

I wonder how many people using Syncthing actually obtained it from the Play Store and not F-Droid? The whole point of it is decentralization, right?

SAF is a slow, buggy mess, and it only works in Java/Kotlin, so it's understandable that they don't want to use it. GrapheneOS manages to allow native access (via Java or machine code) to only specific user-selected directories through its Storage Scopes feature [1]. They basically did SAF but correctly and without the funding of a megacorp.

[1] https://grapheneos.org/features#storage-scopes

> lack of meaningful right to repair regulation over the past two decades

https://www.theregister.com/2023/05/25/minnesota_right_to_re...

> Trump's VP nominee likes what the FTC is doing

Actions speak louder than words, and the DNC's VP passed the most comprehensive right to repair legislation ever in the U.S. in his home state: https://www.theregister.com/2023/05/25/minnesota_right_to_re...

(Doesn't cover farming equipment but still a huge step in the right direction.) You can also be certain that Big Tech was fuming when this was passed.

Most likely, Lina Khan will be removed, the FTC will return to being largely inactive, and John Deere (and Big Tech) wins.

Not surprised that you're being downvoted despite telling the truth, because "politics is off-topic while technology is on-topic" (even though politics is often deeply intertwined with technology).

> Some interesting talks and videos [...] GNU is Bloated! by Luke Smith

Strange reference because that video isn't relevant to the topic at all. It's about the difference between GNU coreutils command line options and other standards such as BSD and POSIX (the title is mostly a joke). In fact Luke Smith is vehemently against the idea of AppImages/Flatpaks/Snaps and believe they go against the spirit of GNU/Linux [1].

[1] https://www.youtube.com/watch?v=JPXLpLwEQ_E

I see this kind of sentiment on HN a lot and it's weird to me. Like, what's the issue with discussing on a hacker forum ways that Google is making Android worse for hackers? Especially considering the alternative is iOS and it's much worse in that regard.

> they refuse to acknowledge the way is via Java user space

I don't think that has much to do with it. Google's problem with Termux is that it downloads and executes native code. Also, you're phrasing that like refusing to acknowledge a megacorporation's version of the truth is a bad thing.

After some reflection I'm not too proud of this comment :)

But is it time to give up just because there hasn't been much progress yet? It seems now that we have #2 there's little incentive for #1, whereas there was plenty incentive for #1 before even if little action.

Smartphones are special, since they're practically mandatory at this point, are the primary gateway to the Internet and digital platforms for a lot of people, and are specifically designed to be general purpose computing devices (even if unnecessary restrictions on who gets to write apps for them are placed on top of that). I mean heck, even Apple all but advertises the iPad Pro (an iOS device) as a computer [*]. I don't care if Nintendo locks down their gaming console. Nobody needs a gaming console. The Nintendo Switch's OS was made solely to run games and has very limited functionality by design. (I'm also overjoyed when I see people hack it, but that's a bonus and I have no expectation of that.)

For example, the EU's DMA provides a precise definition of "digital gatekeeper" and the rules only apply to them [1]. Gaming consoles and other embedded devices are excluded.

If there were more than two real choices available, I'd feel less strongly about this. And I realize that Apple isn't necessarily responsible for there only being two options (if anything, Google may be more to blame for this). But that's just how it is.

[*] I don't know if their marketing materials ever unambiguously refer to the iPad as a "computer", perhaps intentionally, but they've run ads like this: https://www.youtube.com/watch?v=3S5BLs51yDQ

[1] https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%...

AOSP is a separate initiative from Google to release the source code of Android to the public on a regular basis. Development of Android happens almost entirely in-house and contributions/requests from the general public are treated with minimum priority. The public AOSP repo is only updated with these changes after each new release of Android is finished. Google is not forced to release the source code, aside from their changes to the Linux kernel, which are minimal anyway as Android is moving closer to mainline. They may have separate agreements with OEMs that guarantee source code access but that's of no concern to Epic Games as a user/developer on the platform and not an OEM.