Open Bug 2016895 Opened 8 months ago Updated 19 days ago

Use Android Hardware Attestation instead of Google Play Integrity API

Categories

(Firefox for Android :: Browser Engine, enhancement)

Firefox 149
All
Android
enhancement

Tracking

()

UNCONFIRMED

People

(Reporter: celenity, Unassigned)

References

Details

Bug 2015109 added integration with the Google Play Integrity API to Fenix, though I’m unable to find the reasoning/rationale for why (Would be interested to hear more about it).

Is there a reason Play Integrity was chosen over Android’s standard Hardware Attestation API? Given Mozilla’s focus on free, open source, and privacy-respecting software/solutions, it’s disappointing to see another dependency on Google Play Services introduced.

For more information, I’d recommend checking out GrapheneOS’ attestation compatibility guide - their article details some of the problems with Play Integrity, and how the Hardware Attestation API can be used/implemented instead.

IMO: To align with Mozilla’s core mission/ideals, Mozilla should consider adopting the Hardware Attestation API instead of Play Integrity, assuming that it’s feasible for the intended use case here.

Flags: needinfo?(jboek)
See Also: → 2015109

Hey celenity, thanks for raising this issue! The Google Play Integrity API was added as an authentication method for the MLPA backend. I surfaced these APIs to the team to see if we can use it as an alternative method to the play integrity APIs.

Severity: -- → N/A
Flags: needinfo?(jboek)

Thanks for passing this on and providing that clarification!

Remote attestation for end-user consumer devices shouldn't exist. Using any form of this, for any reason is unethical.

(In reply to Zak Wilson from comment #3)

Remote attestation for end-user consumer devices shouldn't exist. Using any form of this, for any reason is unethical.

The attestation is in place to ensure no abuse of mozillas resources with the MLPA - your grandstanding of absolute ethics is on shaky ground.
Without the API it would be trivial for someone to run an x86 copy of the android app en-masse, meaning a tsunami of requests would be allowed through and wasting power, water, etc all in the name of "ethics".

It seems you have a personal issue with Google and Google Play, and you are letting this blind you to the point you are blindly spouting ethics and virtues while ignoring the very reasonable and rather ethical reason why this check is in place. You have not clearly or effectively communicated why having any form of attestation is a bad idea beyond a knee-jerk and fist shake.

(In reply to Pengu from comment #4)

My problem with vendor lock-in mechanisms is not that I dislike a specific vendor. Firefox also shouldn't use GraphenOS attestation or Android hardware attestation because they're all mechanisms to transfer control over computing from end users to centralized authorities. Firefox once served to move the needle in the other direction, preventing Microsoft from controlling the web.

Without the API it would be trivial for someone to run an x86 copy of the android app

So? Nobody should care whether I'm running a browser on ARM, x86, RiscV, or something weirder.

en-masse

Now you've identified the problem, and demanding proof the OS is from a certain vendor doesn't really solve it; requiring an account and metering usage does.

You need to log in before you can comment on or make changes to this bug.