On Thu, Jun 19, 2014 at 5:06 PM, David Bruant <[email protected]> wrote: > Le 18/06/2014 20:28, Jonas Sicking a écrit : > >> It would be great if we could get rid of the need for signing. However >> for now they solve very important problems for us. For some APIs they >> are the only ways to secure what could be argued are legacy features, >> like TCPSocket, UDPSocket and System XHR (I.e. raw HTTP). Ideally >> everyone would move to using WebSocket, WebRTC and CORS, but we're >> likely many years away from that. > > I'm not sure I understand this paragraph. How is WebSocket easier to secure > than SystemXHR, for instance?
Because the WebSocket protocol was designed with server security in mind. The protocol contains steps where the client says "this is origin X, are you ok with me connecting to you" and where the server can accept the connection or not. HTTP on the other hand does not. Many HTTP servers that live inside corporate firewalls use the assumption that if a client can connect to the server, then it must be a trusted client. They were built with this assumption because this has been true in browsers since day one. >> Second, having to juggle multiple files can be a big annoyance. Anyone >> who has created a HTML slide deck knows how annoying it is to then >> send that slide deck to someone. You are forced to either do inlining >> hacks like the ones described above, or to zip all dependencies into a >> single file and then ask the person you are sending the deck to to >> unpack them. Compare this to sending a keynote or powerpoint file to >> anyone who can then simply double-click the file to watch it. > > +1. But this will require a form of OS cooperation that is hard to achieve, > no? Not more than we have for single-file HTML files today. We can simply make Firefox register a .webpacket extension with the OS which causes any such files to be opened in the browser. Other browsers can and should do the same. >> So the question is, how can we make sure that packages have all the >> benefits that normal webpages have today. I propose that we do the >> following: >> >> 1. Create a new package format. > > Have the existing packaging formats been investigated? Yes. Some of them. > Chrome extensions and > apps have a package format ending in .crx (if only we knew some people who > work on Chrome apps :-p). Maybe it already fits? > Likewise for Mozilla Jetpack extensions (.cfx). They're another way to > package a bunch of resources together. > I think Tizen has its thing as well (based on the W3C Widget spec IIRC). IIRC none of these fit since they are all based on zip which neither supports the type of metadata that we need, nor does it support streaming as well as we need. But certainly, if we find an existing package format that fits the needs, then there's no reason not to reuse it. >> Not only will finding the proper solutions here take a while, a lot of >> this stuff needs to be standardized which means that it'll take quite >> some time before we can rely on cross-platform solutions. > > Has discussion already been engaged with other browser vendors or > mobile-web-app-platform vendors? There's been lots of discussions about web-app-platforms. And lots of standards written. And none that have been particularly successful. There are some discussions currently around simply focusing on simply adding a packaging format to the web, but otherwise not changing anything. I.e. no new security models, no new "app" formats, no new extensions. I have high hopes that this will succeed. Once we will hopefully have almost everything that we need to support browsable packaged apps. An "app" and a "website" is really not that different after all, so if websites can use packages, then apps should be able to as well. Standardizing additional security models, like privileged/signed/certified apps, on top of this is likely going to be dramatically more controversial. But maybe it will be easier once all other pieces are in place. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
