On Tue, Oct 20, 2009 at 6:35 PM, Alex Russell <slightly...@google.com> wrote:
> The first was to perhaps use AppCache manifests to declare this sort
> of metadata. You might have some sort of header in the manifest that
> describes the page as "persistently bless-able" (much like Ben's
> description), followed by the list of requested permissions. UA's
> would fetch the AppCache, detect that it corresponds to a blessable
> app and handle the process of granting privs enumerated in the
> manifest. It'd be up to the UA to find some way to offer the ability
> to bless the app/page in it's UI, but in the case of Chromium you
> could imagine this all getting integrated into a process by which you
> bless an app and it asks for perms like:
>
> * app-mode desktop shortcut
> * location
> * persistent storage that's not subject to cache clearing
There is a problem with leaning on app cache. We cannot grant extended
permissions to resources served over plain-old HTTP because of MITM.
The resources could be intercepted and malicious third parties could
gain the extra permissions.
This is what led to the current signed-package design of the Chromium
extension system.
If you really want to serve resources live (not have to package an
application), then you could restrict extra permissions to apps that
are served over SSL. Or perhaps extend appcache to allow signatures
for each resource.
Or maybe we continue to insist that we don't need or want elevated
permissions for any kinds of apps.
- a
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
