On 19 Jun 2013, at 07:59, Charles McCathie Nevile wrote: > On Wed, 19 Jun 2013 06:56:13 +0200, Anne van Kesteren <[email protected]> > wrote: > >> On Tue, May 14, 2013 at 7:47 PM, Marcos Caceres <[email protected]> wrote: >>> The current proposal can be found here: >>> http://manifest.sysapps.org/ >> >> I wonder to what extent we actually need a manifest. I think it's main >> benefit might be in grouping a set of pages, but whether that needs to >> be via a manifest I'm less sure about. > > I think pretty much any mechanism that groups pages *is* a manifest. There > are lots of ways to make them, but given that most shipping solutions have > converged on something that looks a lot like the W3C widgets manifest format > (in XML), or something in JSON that is very similar, it seems reasonable to > assume that isn't a bad starting point.
Its certainly been the usual end point, whether its Java's MANIFEST.MF, imsmanifest.xml for training content, or container.xml for ePub. Given how similar they are it still amazes me how many different ones keep being invented. If I contributed to the app manifest work, it would mainly be to make sure I could easily convert them into either Widgets or OpenSocial, whichever is the best fit, given Apache has projects implementing both of those specs already. > >> A requirement that keeps coming back for web applications (i.e. those >> served in a browser over HTTP, such as https://www.twitter.com/ ) is >> that multiple of them per origin should be supported. > > Yes. For portals, e.g. Apache Rave, the approach is often to generate per-instance origins, e.g. gadget-122423534534.myportal.net/apps/gadgetx, to prevent XSS attacks. Rave, Shindig and Wookie all support this. > >> Reasoning for this is simplicity of deploying new applications and to >> some extent to reduce the number of DNS queries for a suite of >> applications. > >> Downside of that approach is increased attack surface for a suite >> applications > > Can you please expand on that? > >> and no trivial boundary between them (given a URL it's not >> clear to which application it belongs). > > Well, it is true that a given URL might not be able to say what application > it belongs to. But then, it may not need to, or even be desirable. To take > silly examples, images rarely know what pages they are part of and scripts > often don't. That seems to be a feature, not a bug. > >> Navigation Controller solves the grouping of a set of pages using an >> origin plus wildcard matching for a set of URLs, although as currently >> proposed a subset of those URLs might be something else altogether >> again, without much declarative control. >> >> For event pages/workers you'll want something similar. To identify >> what a URL's associated event page/worker is. >> >> It might be though that maybe we should put the boundary for >> applications on the web on the origin level. It would certainly be >> extremely convenient and allow for a whole bunch of simplifications. > > Yeah, but the price of enforcing origin-based restrictions on the Web is that > we break a lot of the "web"-ness. While there are security reasons for doing > so in many cases, I think the platform loses each time we build such a > restriction. The purpose of things like CORS is to reduce that cost compared > to the simplified case of a rigid same-origin policy, and I think that's a > pretty good thing. > > just 2 kopecks > > chaals > > -- > Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex > [email protected] Find more at http://yandex.com >
PGP.sig
Description: This is a digitally signed message part
