You're claiming that I said something that I didn't. I never said that attestation was DRM, or that SafetyNet attestation in particular was DRM. Using it for this purpose is what I am referring to as DRM i.e. enforcing restrictions on what the user can do with the app or content.
Conversation
I also never said that DRM was inherently evil. A video game using attestation to implement anti-cheat is DRM. It prevents a user from doing something like using a modified client with color blind support. I don't think it's evil to do that, but I definitely do think it's DRM.
2
Replying to
You are still double-tweet-replying to each of my tweets. Stop.
You abused "DRM". Period, full stop.
You also seem to be excusing fraud. What else are we to use than the tech Google and FB use on their native stacks to get low fraud rates, vs. the JS tag-soup programmatic hell?
1
Replying to
Seriously? I can't spread out my response over 2 tweets? If you want to reply with 2 tweets you can do the same. If the character limit was still 140 characters, yours would be split across multiple tweets too. It's how I use the platform. A thought per tweet in multiple tweets.
2
You cannot take this approach to debate and then get mad at me for needing to respond in multiple tweets:
en.wikipedia.org/wiki/Gish_gall
You keep repeating the claim I'm misrepresenting DRM or falsely calling it DRM but I think the majority of people would agree with my definition.
2
I'm hardly the only person referring to these kinds of anti-fraud / anti-cheat mechanisms as DRM. It's standard practice to refer to anti-cheat / anti-modding as DRM:
pcgamingwiki.com/wiki/Digital_r
I'm not the one being misleading and dishonest. That's you folks. Consistently now.
1
Replying to
No, you flunk EFF's DRM definition (eff.org/issues/drm). We do not prevent you from using your purchased+owned hardware and software as you see fit. We simply don't share ad revenue with you if safetynet says "nope!"
Without further explication you arrantly excuse ad fraud.
1
Replying to
That's one form of DRM. It's not the entire picture. Software trying to enforce restrictions on usage and trying to prevent it from being bypassed is what myself and many others refer to as DRM and it includes anti-fraud and anti-cheat mechanisms. To me, that's what it means.
2
1
Replying to
We restrict giving you crypto-tokens if you flunk OS-level antifraud. That is not DRM. Right?
1
Replying to
Attestation support is not specifically an anti-fraud feature. It's a generic attestation feature. It's not specifically for use cases like this. The primarily purpose for the hardware-based attestation support is actually to verify that keys are hardware backed in a basic way.
2
That supports verified boot state, key, patch level, etc. attestation as a bonus along with chaining to the app for arbitrary app-based security checks. Of course, that can be used for anti-fraud / anti-cheat / anti-modding which is what I am calling DRM. Attestation isn't DRM.
It's this way of using attestation that's DRM, whether it's the near useless (at the moment) SafetyNet attestation or the hardware-based attestation support which is much more useful, but still not a strong security feature if you're only verifying with the root of trust.
1
Replying to
In this case, it is implemented with DRM. The software implements restrictions on usage of the app / content based on attestation. Attestation is not DRM, but it can be used to implement DRM. I also didn't generalize all anti-fraud as DRM. Some approaches aren't broken like this.