Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Attestation is service that can only be provided by the builder of the phone. Most commercially available Android phones provide this, and banks and DRM rely on it. https://developer.android.com/training/safetynet/attestation and https://developer.android.com/google/play/integrity/overview


That API is not useful for anti-spam purposes, as individual devices cannot be banned for spamming by their serial number. Quoting that page:

> The API is not designed to fulfill the following use cases:

> Contain signals for app-specific use-cases, such as device identifiers


Android does provide device attestation via Keymaster 3 and has for years: https://source.android.com/security/keystore/attestation

SafetyNet does not specifically give you a device ID, but keystore attestation does. SafetyNet is a higher-level API used to verify you're in a trusted compute environment (which is also sufficient for anti-spam, btw). The keystore attestation API provides everything you need to acquire signed data directly from the HSM with things like device IDs and security trust level baked in.

You need to read up: https://datatracker.ietf.org/doc/draft-bweeks-acme-device-at...


That can be built trivially using this API. The app stores an identifier, which it knows has not been tampered with because of attestation. Giving apps access to a unique device identifier shared across apps is a privacy leak but can be obtained with the proper scary permission.


> Giving apps access to a unique device identifier shared across apps is a privacy leak

Correct: 'Non-heuristic antispam' and 'Private device identifiers' are incompatible requirements, unless you introduce another expensive obstacle to overcome. Spamming depends on cheap/free sock puppet accounts. The cost per account is inversely proportional to the value it holds to spammers. That cost can be in Apple's iMessage terms: $100+ per serial number, all devices must include burned-in serial number attestation in their server communications. Or that cost can be in bureaucracy: $10 per notarized "account signup request with verified citizenship", but now all communications can be associated with the notary's logs of your citizenship ID number.

There is no way to stop spam without incurring one or another cost to each user. Apple's method doesn't care who you are, so long as you possess Apple hardware. The Pluton method wouldn't either. What other methods exist that are unconcerned with the exact identity of the user, but still make spamming unprofitable?


I mean, maybe expensive dongles should be a thing of the past and Apple should invest in machine learning a bit more. My Pixel does a great job filtering out SMS spam, with 2 false positives (both automated messages) and zero false negatives in the last month.


I have received a single iMessage spam message in ten years, total. You would have, statistically, received at least 240 false positives in that time assuming current heuristics technology. I don’t think heuristics are the answer if your goal is Project Zero Spam.


My goal is not project zero spam, my goal is interoperability and the end of expensive dongles.


I just showed how Apple could implement exactly its method on Android. I'm not sure why you're looking for other methods.

As far as private antispam, you can imagine a hashcash-like system that takes into account how many messages you've accepted from the sender, but this is a completely different discussion.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: