Along the lines of Thinker's remarks about controlling when to update, some updates may be large (a new set of maps for an offline navigation app is a good example) and I might not want to update them when on a paid or slow pipe (cellular). Also, I sometimes don't update if comments indicate an app has become less stable (I'll wait for a follow on update) or has lost some portion of functionality. -Jim Straus
On Apr 30, 2012, at 12:46 AM, Lucas Adamski wrote: > On Apr 21, 2012, at 10:35 PM, Thinker K.F. Li wrote: > >> Hi, >> >> Although we donwload pages automatically if the cache manifest changes, >> but the new cache will only be used for next time of launching. >> >> I concern more about faults of networks. Internet is not always stable >> and secured. For some buggy implementations of infrastructures, the >> cache manifest can be broken or touched. We can not tell, for now, if a >> copy of the cache manifest is complete or not. These situation can kill >> the app from the offline cache. More worse is that you get only a part >> of lauch path or a changed copy, but you don't know it, and it can not >> used to trigger an updating (no manifest attribute of html tag). The >> only thing you can do is to reinstall it after an uninstalling if you >> aware it. >> >> So, I think app manifests and cache manifests need some kind of integral >> checking. We also need to provide a way that the user can control when >> to udpate. I don't like to update the apps when I was jailed behind >> some kind of firewall (national level, sigh!). >> > > Not related to Open Web Apps API per se, but that is the intent of > authenticated (trusted) and certified apps. The authenticity and integrity > of the app would be verified, assuring that the user received the same > unmodified & complete app that the app store reviewed and approved. > > Now if you're asking about unauthenticated apps, its true that providing the > integrity checks without authenticity verification would still provide some > useful benefits. Thanks! > Lucas. > > _______________________________________________ > dev-webapi mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapi _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
