A theoretical way to circumvent Android developer verification
81–90 of 185 posts
Re: A theoretical way to circumvent Android developer verification
#82Earlier quoted context omitted.
> I hope we can get the EU to fund a truly open Android Fork. How are things in the EU on whether it's legal to buy a SIM card without showing ID?
A secure OS is a prerequisite for secure digital services. We can agree on that, right? The task, therefore, is to convince enough politicians to establish an independent unit that can address this issue without direct political influence. Fund the unit with enough money so that it can take care of the cybersecurity and sovereignty of all citizens. A side effect of this would hopefully be that these politicians would…
Re: A theoretical way to circumvent Android developer verification
#83It's going to be the same as Play Protect using the PackageVerifier API. Even if won't trust that Play Protect will continue to allow adb installs, if you go to the developer options you can disable package verifiers for adb installs.
>the concept
This would not really work considering you can't do a lot of things at runtime. You can't create activities, you can't create services, you can't declare permissions, you can't use permissions, etc. Pretty much everything in your manifest can't be done properly. You can't really do a job faking it. You would have to declare a ton of dummy activities with all different permutations of things like launch mode, document launch mode, intent filters, etc.
What you can do are things like game engines like how the android godot editor works where you aren't loading full android apps, but projects into the editor.
Re: A theoretical way to circumvent Android developer verification
#84While it is technically feasible, it is not a good idea to try and find a technical solution to a people/organisation problem. Do not accept the premise of assholes. I hope we can get the EU to fund a truly open Android Fork. Maybe under some organisation similar to NL Labs. --- edit --- Furthermore, the need for a trustworthy binary to be auditable to a certain hash or something would make banning this a simple task…
What's wrong with lineage?
https://images.squarespace-cdn.com/content/v1/60f1421e1afcf4...
Re: A theoretical way to circumvent Android developer verification
#85While it is technically feasible, it is not a good idea to try and find a technical solution to a people/organisation problem. Do not accept the premise of assholes. I hope we can get the EU to fund a truly open Android Fork. Maybe under some organisation similar to NL Labs. --- edit --- Furthermore, the need for a trustworthy binary to be auditable to a certain hash or something would make banning this a simple task…
This is actually the advantage of doing it. You make the thing (call it a "personal app loader" or something rather than a "circumvention tool"), they ban it, now you campaign against them or make antitrust arguments presenting the ban as an anti-competitive practice or use the ban to refute claims that they're not inhibiting third party app distribution.
Even if you know they're going to be the villains, you still want to make them actually do it so that everyone can see them doing it.
Re: A theoretical way to circumvent Android developer verification
#86Earlier quoted context omitted.
I'm confused, how are those two things related?
The commenter you replied to was implying that the EU does not respect the privacy/freedom of mobile device users.
I was confused bexause anonymity against the state is hardly the only, or even a main point of android forks.
Privacy usually is, but against big tech typically.
Re: A theoretical way to circumvent Android developer verification
#87Earlier quoted context omitted.
What's wrong with lineage?
It's not a good, secure project by a longshot. There's a good comparison floating around: https://images.squarespace-cdn.com/content/v1/60f1421e1afcf4...
Several of those are the opposite of security features, like SafetyNet support, which might be a convenience in some cases but it mostly makes it so you can't upgrade certain parts of the system to newer versions even when the old versions have security vulnerabilities.
Re: A theoretical way to circumvent Android developer verification
#88While it is technically feasible, it is not a good idea to try and find a technical solution to a people/organisation problem. Do not accept the premise of assholes. I hope we can get the EU to fund a truly open Android Fork. Maybe under some organisation similar to NL Labs. --- edit --- Furthermore, the need for a trustworthy binary to be auditable to a certain hash or something would make banning this a simple task…
The same EU that's doing Chat Control?
Re: A theoretical way to circumvent Android developer verification
#89While it is technically feasible, it is not a good idea to try and find a technical solution to a people/organisation problem. Do not accept the premise of assholes. I hope we can get the EU to fund a truly open Android Fork. Maybe under some organisation similar to NL Labs. --- edit --- Furthermore, the need for a trustworthy binary to be auditable to a certain hash or something would make banning this a simple task…
The same EU that keeps pushing for breaking encryption and chatcontrol? No thank you
Re: A theoretical way to circumvent Android developer verification
#90Earlier quoted context omitted.
It's not a good, secure project by a longshot. There's a good comparison floating around: https://images.squarespace-cdn.com/content/v1/60f1421e1afcf4...
That looks like someone made a list of mostly features specific to GrapheneOS so they could make a chart where all of the other alternatives (including stock Android) are full of red boxes. Several of those are the opposite of security features, like SafetyNet support, which might be a convenience in some cases but it mostly makes it so you can't upgrade certain parts of the system to newer versions even when the old…
No one else even bothered to make a list.
>Several of those are the opposite of security features, like SafetyNet support, which might be a convenience in some cases but it mostly makes it so you can't upgrade certain parts of the system to newer versions even when the old versions have security vulnerabilities.
Citation needed