Since, I'm still in process of moving my blog here, I have posted last post in both blogs, older and here. Reactions came from some interesting people, so I decided to transfer comments from old blog here, to have all comments in one place.
Once again, thank you all for paying attention to this issue.
1. - Hello,
We are building an App registry, where the primary key is the AppId and we will have a validation service that will evolve.
We also plan to introduce an App Certification process very soon.
In order for an app to be certified, the application developers would need to publish their Apollo project to our CVS/SVN repository, and we would certify that the app contained no malicious code or procedures that, as you point out, could otherwise be very dangerous if someone uses an untrusted, malicious application.
Tune into ApolloApps.com (http://www.apolloapps.com) for details that will emerge soon.
2. My first point is that the verification system is not supported in the alpha release.
The second point is that unless ApolloApps is going to do on-the-fly compilation, verifying the source code is pointless.
thought it best to indicate in the UI that the publisher was
unverified--which, in fact, is correct. Once the signature and
verification feature is fully implemented you will see applications
with verified publisher information and a different set of warnings.
To your second point, yes, all Apollo applications currently have the
same filesystem access as any other desktop application. As with any
desktop application, an Apollo application should not be installed
unless you trust it. The signing and verification feature is designed
to give you additional reliable information with which to make this
decision, but you still have to make that decision for yourself.
Adobe Systems Inc
ads: Monetize Your Site