On Wed, Jul 29, 2009 at 11:28 AM, Drew Wilson <[email protected]> wrote:
> I've been starting to lean in this direction as well. The problem is that > extensions are currently not cross-platform and would require separate > implementations for each platform. And in many cases the extension delivery > mechanism is under the control of an arbitrary third party (i.e. Google, > Mozilla, Apple, etc) who has control over which extensions can be hosted, > which is not particularly "open-web"-by. > It seems that a good approach is to make as much of the api into html5 as possible (like Shared Workers). Then there could be a small bit that is extension (platform) specific (making the Shared Worker a Persistent Worker). Then there is a small surface area which is not html 5. This also allows apps that to do a lot of things in a similar manner (even when they don't get the extra permissions). dave > > It might be a reasonable starting point, though, with the goal being to > sort through the security and installation issues and eventually come up > with a cross-platform API in a future HTML version. > > -atw > > > On Wed, Jul 29, 2009 at 11:15 AM, Linus Upson <[email protected]> wrote: > >> I'm coming to the opinion that we should leverage the install mechanism of >> the extension system for apps that need special permissions, increased >> quotas, expanded lifetimes, etc. The extension can be almost vacuous, and in >> our extension world exceptionally lightweight. It only needs to make the >> special capability available to the page. >> As Maciej brought up on the whatwg list, the extension system gives us >> multiple affirmative steps, >> vetting, reputation and revocation. It also gives us a UI access point. All >> of these are important for controlling apps that aren't safe and stateless. >> >> Linus >> >> >> On Wed, Jul 29, 2009 at 10:24 AM, Ian Fette <[email protected]> wrote: >> >>> I would say that if all the browsers are doing 5MB fixed quota for local >>> storage, it is a good way to start. Sadly, I think we need to start thinking >>> about this now for databases though (certainly I don't want to hit yes 4,000 >>> times as my gmail syncs up to 20GB) >>> 2009/7/29 Jeremy Orlow <[email protected]> >>> >>> On Wed, Jul 29, 2009 at 9:37 AM, Peter Kasting <[email protected]>wrote: >>>> >>>>> On Wed, Jul 29, 2009 at 12:39 AM, Ben Laurie <[email protected]> wrote: >>>>> >>>>>> That seems overly simplistic to me - for example, just because I >>>>>> sometimes want to let a chat app have access to my camera, doesn't >>>>>> mean I want it always to have access. Given the number of users I've >>>>>> seen fix this problem with duct tape, I think I can conclude that >>>>>> users would use controls if they had controls they understood and >>>>>> trusted. >>>>>> >>>>> >>>>> I don't agree. I believe granularity is not only useless but harmful >>>>> for the majority of users. See user studies of desktop app install flows >>>>> or >>>>> options dialogs that universally conclude that giving people more choices >>>>> helps a small number of people and loses a large number. This is the >>>>> philosophy we designed Chrome around, so we're strong backers of it. >>>>> >>>> >>>> I agree on principle. I can imagine a couple ways the web app might >>>> state the capabilities it needs up front. The problem is that, with newer >>>> "versions" of the application, the needs might change. But how do we keep >>>> them from changing so often that the user just gets used to clicking 'yes' >>>> every time? I can't think of any good solution for this. >>>> >>>> Anyway, I think we've gotten a bit abstract here. It's good to talk >>>> about this in general, but in the mean time I'm not sure what to do for >>>> LocalStorage. >>>> >>>> Is the fixed quota per origin a good way to start? If so, is the plan >>>> to leave it that way until someone tries to tackle this stuff in a more >>>> unified way? >>>> >>>> J >>>> >>>> >>>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Chromium-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~----------~----~----~----~------~----~------~--~---
