upend Obviously not as if it doesn't exist, but as I currently see it, that is, with a watermelon-sized hole in it thanks to the IPC. This is about the AOSP, not GrapheneOS which merely inherits the problem and fortunately plans on fixing it. We can go back and forth on the particular descriptor but when it comes down to it, isn't that the crux of the fix, the WIP application scopes feature? To give users control that is currently missing and underserved by the network toggle and profiles?
It is not missing. I already provided you with multiple ways to achieve exactly what I described. Separation by profiles, usage of the upcoming Private Space feature already available in our experimental Android 15 port, etc.
The app communication restriction feature, which will be named that and not "App communication scopes" is meant to reduce attack surface by removing various ways that apps can use to communicate with each other, but the team understands that there are so many ways for an app to communicate with another app if they're both colluding that they don't need IPC. In the vast majority of cases, IPC is used to provide base functionality. The narrative that mainstream apps are using IPC maliciously is one that has been constructed within our community exactly because our team has explained what is possible. The fact that something can be done, doesn't mean it's being done in practice.
upend I didn't mention the team once but putting that aside, what exactly do you think I don't fully understand? That comment is rather patronising. I install SwiftKey (from the Play Store as recommended by the developers) and turn off its network permissions but guess what? That's all for naught because it communicates with the Play Store to download and install features activated by the most modest of accidental taps. You can say users should pick better apps but needless to say, SwiftKey is neither unique nor even the biggest culprit here. GrapheneOS itself doesn't accept such reasoning, evidenced by the existence and development of various spoofing features to fool apps taking advantage of permissions.
I specifically mentioned the team, but it is the team that introduced this concept to the community when explaining these topics. You will notice that IPC as a vector for app collusion is rarely mentioned outside of the GrapheneOS community. In the team's attempt to explain the complex internals of Android to people to help them make informed decisions, people tend to hyperfixate on this one very specific thing and making it sound like a much bigger deal than it is, especially in practice. You criticize opposing positions for saying that badness enumeration doesn't work due to the very nature of the adversary being able to adapt, and yes you're calling IPC a "watermelon-sized hole", and the best example you can muster is one that requires explicit user input to fire off? If imperfect adblockers are good enough, a sandbox that allows well-defined communication where both apps have to agree with one another means it has a "watermelon-sized hole"? That sounds like a pretty major double standard. I apologize that you felt any part of my response is patronizing. I can assure you that is not my intention, and I'm trying to engage your arguments as they come.
upend You may take umbrage with my description but I consider that subversion to be quite significant.
I take issue with your description because it fails to consider the way IPC works (explicit mutually agreed upon communication by both parties) and devalues the sandbox as a result. If you're using an app that is malicious and that you think will collude with another app to siphon your data or something else equally malicious, why would IPC be the only method that it tries to do that by? You need to trust apps with the data you allow it to access. It will be a great shame if people misunderstand the upcoming communication restriction feature as "it doesn't matter if the app is malicious, they can't do anythng to exfiltrate data". Even if we could put individual apps in their own VMs, there would probably still be ways for an app to signal stuff out.
upend https://www.bleepingcomputer.com/news/technology/youtube-tests-blocking-videos-unless-you-disable-ad-blockers/
Which, as should already be clear, is not to say YouTube is the only entity we can look to to disprove the claims in the article.
I am confused concerning what point this is proving? Do you mean to say that adblocking is effective that YouTube's only recourse it to try and get people to disable it entirely rather than bypassing it?
If so, I counter with this: https://uk.pcmag.com/video-streaming-services/152839/youtube-tries-a-new-harder-to-bypass-method-for-stopping-ad-blockers
This is the equivalent of a website or app using first-party domains or domains that are required for base functionality for serving ads, telemetry etc. This is already widely used and should be done server-side anyway. Services are already moving towards that. You don't like the Facebook example and consider it pedantic, but it is a very clear example of the approach not working, and shows where things are headed.
upend This patronising framing and dismissal is my main issue. We've had uBlock Origin and similar for over a decade at this point yet their utility and effectiveness is trivialised and their operation mispresented as an impenetrable enigma "the rest of us" are too uneducated to understand and grasp. Particularly awful is the inconsistent application of this tenuous logic. We're told to eschew adblockers and quests for similar tools because they aren't absolute yet have the sandbox on a pedestal despite it currently suffering from the same issue.
No. You're told to not rely on the badness enumeration approach of an adblocker as a privacy and security measure. Nobody said adblockers today are not very effective at blocking ads. I will reiterate that Vanadium has adblocking integrated in there. It's simply not marketed as a privacy and security feature.
upend I dread to imagine how unusable the web would be today if the creators and maintainers of uBlock Origin took such comments to heart when starting out. That amazingly critical tool would probably be stuck in the perpetual "Exodus lists 0 trackers" stage, and all because of a strawman about omnipotent threat actors.
No, it wouldn't, because again, adblockers are useful (security concerns with using extensions aside, that's a different conversation) for blocking ads. Their approach is not useful when it comes to implementing a robust privacy and security strategy, however.
I see that you didn't reply to everything I said in my own reply, rather focusing on specific points that you think help your point.
I hope that this will not become a 50 reply back-and-forth where we keep banging our respective heads on the wall and talking past each other. I hope that the frustration that led you to finally create a GrapheneOS forum account will lead to you contributing productively, rather than using your account to argue with people.