It is now possible again to get Anonymous access to region-restricted apps: see this post for details (though, in my experience I didn’t need to use a VPN, just enable the Insecure anonymous session setting)
2 Likes
Is this not the same process used by
That would be cool if it is the case as I installed hypatia after reading about it on the divestos thread
@rainwalker Sorry, maybe my question wasn’t clear. If I am not mistaken you are being critical of how the /e/ app store processes .apks, correct? (" ‘Apps are checked either using a PGP signature check, or a checksum.’ – who does that?") My question is, isn’t a similar/same process used by Divest/Hapatia looking for malicious apps? Please see my screenshot posted above, “Checked all SHA/MD5…”.
Ah, lol, no my question was genuine - as in, who is checking the app signatures, the /e/ team or the cleanapk team. I’d feel better if the /e/ team were doing it.
On a separate note, your screen shot shows hypatia successfully checked md5 hashes, but mine always fails to find the md5 database. Do I need to also selected large database in settings?
1 Like
39 posts and we arrived at no answer! 
2 Likes
I use the default databases and have not adjusted. 
I currently use F-Droid (with a few added repositories) and Aurora (for a couple apps Sandboxed using Shelter) only. But yes agreed, it would be nice if team /e/ was verifying themselves, that seems to be a large task.
My bad on misinterpreting your original post, sorry. I now see my error. 
To further explain App Store performs some sanity checks here based on information received from cleanapk. It verifies shasum for google apps and pgp signature for fdroid apps. Apps store cannot directly verify signature of google apps because there is no reliable service which can provide this info so it relies on cleanapk. We are trying to improve this process though.
Also as mentioned previously if there is a better option of an application store which caters to all users - those who want FOSS only and those who want apps they used on stock ROM’s then we will be more than glad to use it. Off course it would still require a lot of customization of code to adapt it to work seamlessly on /e/OS.
1 Like
Perhaps /e/ could host their own application store along the same lines as Cleanapk. At least we know who owns and runs /e/. Or, as a major user of cleanapk’s API’s, /e/ could ask Cleanapk to be more open and transparent about who they are.
I’m relatively happy that the apks from Cleanapk, that /e/ serves up via Apps, are safe and haven’t been tampered with (I’ve not heard of any problems with them), but I really don’t like doing business with organisations that try to hide their ownership and/or location. It makes me wonder what else they have to hide.
/e/ cant do that because it is illegal, you can’t redistribute as stated in Gooles tos So i think they are lucky they have found cleanapk 
If it’s illegal for /e/ to do it then surely it’s illegal for cleanapk too? So /e/ won’t break the (unspecified) law, but they’re happy to use an anonymous company that will break the (unspecified) law. Not a lot if difference that I can see.
I think there will be a big difference in court if you are the owner or the client.
I think
Gogol and cleanapk relation may depends on U.S. reglementation,
but
Cleanapk and /e/ relation may depends on E.U. reglementation.
But we don’t know who the owner of cleanapk.org is. It might be /e/ as a corporation, it might be someone connected with /e/ in a personal capacity, it might be Google, it might be the Tooth Fairy
In any case, I still don’t know what is illegal about what cleanapk are doing. You quoted Google Play’s Terms of Service, but if we believe their solitary web page, cleanapk aren’t getting the apks from Google, so Google’s ToS are irrelevant.
What laws are cleanapk actually breaking? If they aren’t breaking any, then there’s no reason why /e/ shouldn’t openly follow their model, or buy them, or make them an offer they can’t refuse 
. If cleanapk are breaking some laws, then I would have thought that, by using the cleanapk API’s (which they definitely do - you can see it in the source code) /e/ are also in a dodgy position legally.
I have my own theories about who owns and/or controls cleanapk.org, but I think that /e/ should be open and transparent about it (assuming /e/ know: if they really don’t know, then they really shouldn’t be using cleanapk.org). Until they are open about it, then it will continue to be a distraction from the great things that /e/ is doing, and may put potential users off using /e/ at all.
Anyway, I really should get back to testing v0.18 ROMs
1 Like
See my comment above
I can answer one of your questions
How do I know the apks haven’t been tampered with?
The signing certificate per appid is not allowed to change over the appids lifetime (if a private key is compromised, publishers have to republish under a new appid). As new Apk installs are trust-on-first-use, if the package was signed by the proper certificate you have authenticity assurance for the lifetime of the install and later updates. Packages themselves have an integrity mechanism that is signed by the certificate.
How to deduct the Apk is signed by the original publisher certificate? there is no public notary (yet), but I speculate cleanapk does check this certificate fingerprint against prior fingerprints of the same package name. If they are identical as recorded (for month or years for historical known packages) cleanapk themselves have assurance too of uploading an Apk as intended by the publisher. Obviously an apk mirror can’t do this for never-before-seen appids. If you have a Play console developer account you should be able to query the Google Publisher API and get some datapoints from “upstream”.
I think similar to what Hypatia does for known-bad package cert fingerprints it would heighten assurance if a database of known-good appid:certfingerprint is preseeded on the device and pinning to the appids cert fingerprint on install.
Marlinspike of Signal created a community effort in 2011 for SSL certificates as alternative to CAs / Web PKI, “convergence” (defunct since a few years). It queried multiple notaries for their view on the websites SSL cert fingerprints to establish a quorum. If you get malicious certificates, a majority disagrees and warns. Something akin I envision for apk packages, then the apk mirror source is less of a concern on TOFU.
I wrote [HOWTO] verify Apk signatures and reflect on Publisher trust if anyone want to read more on it. There are websites recording historical certificate fingerprints, they offer their database to researchers or offer their services (androidobservatory (not active anymore), scatterscam (close to exodus-privacy), pithus).
2 Likes
You talk a lot on signatures and certificates. What about signature spoofing for microg on e? Weaker security, yes?
What about signature spoofing for microg on e?
I can see your concern and never reasoned about if on package install mayFakeSignature() is hit. Will test this on the weekend if a malicious package by barely having the fake sig perm in its manifest can supply arbitrary signatures at install time - it’s possible, while I think at install time without yet having granted the permission it should not be possible.
That said, I think /e/ should integrate mayFakeSignature() like Calyx did, narrowing down the possibility to two package names and using a constant for the spoofed signature. Too, also offering a devoptions switch to disable fake sig spoofing (https://gitlab.e.foundation/e/backlog/-/issues/1302) could settle concerns.
1 Like
2 Likes