That is may (or may not) fine for desktop web apps. But for mobile devices (B2G), web access won't always be available. Even on a desktop, I can enable a rule in a tool like Little Snitch and keep an app from connecting to a specific server/port. There are lots of apps that don't need server connections for full functionality.
What I would like to see is a threat tree, how we may mitigate the various threats, and an assessment of how far we feel we need to go. That's why I'm adding in dev-security to this thread. I want us to have a robust developer community. I suspect that if it is too easy to rip off developers they won't participate. On Mar 19, 2012, at 4:17 PM, Anant Narayanan wrote: > On Mar 19, 2012, at 12:19 PM, Jim Straus wrote: >> I don't see how this helps with someone copying an app and >> modifying/removing the receipt checking code/declaration. If hacked Angry >> Birds declares to just run with no receipt, a pirate can rip it off easily. >> And since the code to validate a receipt must be in the engine itself (to >> handle bad receipts), why not just expose that function to the application? > > Receipt checking code cannot be implemented client side for paid apps that > are worried about copying. Piracy protection in these cases is done at the > web server level, where resources are only served upon presenting a valid > receipt. > > The model is exactly the same as websites adopt currently (with exactly the > same infrastructure to detect fraud, for example). > > -Anant > _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
