Re: Question from IETF's Interenet Architecture Board (IAB) web apps, native apps, web-based apps

Hi Hannes,

thanks for your clarifications, some (strictly personal) notes below.

On Jun 12, 2012, at 17:52 , Hannes Tschofenig wrote:
> last year a few IAB members published a document (which we typically refer as "post standardization"), see http://tools.ietf.org/html/draft-tschofenig-post-standardization-02. 

A few quick notes on this document while I'm reading it:

• It states that the perception of JS as a limited language has changed "over the last couple of years". That misses the mark. The first W3C workshop on Web Applications took place in 2004, and many of us thought that it had been too long in coming back then. So "over the past decade" would be more correct.

• Concerning crypto, you may wish to note that there is now a WebCrypto working group (I forget the exact name/link and am on a train with no connectivity, but it ought to be easily found). There is also a System Applications group being chartered (as well as, relatedly, an NFC one) for which access to hardware Secure Elements has been proposed: http://www.w3.org/2012/05/sysapps-wg-charter.html. There is however uncertainty as to whether it will be kept as a deliverable (moving it to the NFC group being an option).

• The paragraph that discusses the security of widgets and JS is very confused. It discusses a "security model of JavaScript" when there is no such thing — I believe it intends to refer to the browser security model. It then conflates OS X Dashboard widgets, Win7 Gadgets, W3C Widgets, etc. when all of these — while superficially similar — have very different security models. For instance, Dashboard widgets can all execute arbitrary shell commands as the user as soon as they're installed and with no check (the term "security model" may therefore be somewhat overextended here) whereas W3C Widgets have essentially the same security model as the browser but in which it is possible to poke holes, primarily to relax some Same-Origin restrictions or to enable specific features. It then goes on to state that JS does not declare what operations it is intended to perform when in fact that is precisely what happens in a W3C Widget (and it is rather possible that this model will be brought to the browser). Note that while this is a contentious feature, W3C Widgets also support signatures if you wish to know who claims to have verified their content.

• It is unclear to me how the SIP privacy mechanisms related to JS privacy mechanisms and I'd be very interested in understanding more about this.

• Have you considered the notion that while strict client-server communication may require decreasing standardisation, new work that allows for peer-to-peer communication between clients (WebRTC) or communication between a client and an arbitrary service of a given type (Web Intents) may actually require more standardisation?

• It's not entirely clear to me what you mean when saying that "extending JavaScript" may "require new Document Object Models"? A lot of people have been working pretty hard for quite a long time to make sure that there's only one of those!

• I'm not convinced that the increased power of JS applications will lead to introspection-based mitigation, that could then be circumvented by the invention of other scripting languages. Unless I missed some interesting research, I don't think that this would be anything other than brittle already today (further note that we already have a vibrant ecosystem of compile-to-JS languages). The browser security model as it exists today is (thankfully) orthogonal to JS, and I would be very surprised if it were to change at the introduction of a new language. To me that sounds like saying that you can circumvent the Unix file permission control by switching from bash to zsh, and that admins are likely to implement security by automatically analysing the content of shell scripts to make sure they don't call superuser-only commands.

• Advanced security issues, as are pertinent to a Web application context that is granted greater execution power than what is available in the browser (typically for a Web operating system) are expected to be tackled by the aforementioned SysApps WG (if and when chartered).

> There are two fundamental ways to write applications (as they have always been), namely 
> 
> 1) Native applications focused on the target operating system
> 2) Web applications that run in the browser regardless of the operating system

It's a bit more complicated than that actually, and there is strong dissent about whether this distinction is actually relevant or if it should only be used as a shortcut that is highly dependent on the state of play at this very moment (but will likely be obsolete as a concept relatively soon).

To take examples that don't clearly fit above:

• We used to have applications built with Java, that target the VM rather than the OS. In which box do these fit? The same question applies to using Perl/Ruby/Python/Tcl/JS/whatever with a common toolkit such as Tk or WxWindows.

• If all the application-level layers of your operating system are Web-based (B2G, Tizen, webOS) or a substantial part of them (Win8), when you build an application is it Web or native?

Is it a Web application only if it runs in the browser? Is it okay if it saves an icon to your desktop that launches it in a chromeless browser? What if it runs in a browser but as proprietary content interpreted through a plugin?

By and large, I don't think that that distinction is useful beyond discussions clearly rooted in the current situation and not meant to be future-looking.

> In addition to these two approaches there is also a third one in the mobile space where you package a Web application so that it looks like a native application. 

That is known as a hybrid application. The same sort of issues apply as discussed in the previous section.

> From year 2000 onwards we had seen a lot of shift from native applications to Web applications. There may be many reasons for that but I believe the main advantages were: (...)
> * The security of downloadable native applications was just horrible. Web pages with JavaScript in there offered much better properties in that regard. 

Actually I don't think that that was a driving factor apart from maybe a tiny geek elite. Today's app stores are extremely successful despite offering pretty laughable security overall.

> Over the last few years there was a lot of development in the operating system section (on the mobile side) and the application eco-system has changed quite a bit as well. The development had impact from a security and an economic point of view. There seems to be some excitement for application stores that aims to provide additional revenue to developers and at the same time they serve as a gateway function for distributing applications. 
> 
> While there is great progress with the work you guys are doing in the W3C on the Web platform environment (as would call it), I would mostly say in the area of JavaScript APIs, there is still the question of where the development will be going. 

I'm still rather vague as to where the exact question is in that statement, are you looking for something similar to http://berjon.com/blog/2011/07/there-is-still-a-frontier.html ? The content in there is pretty old and it doesn't cover the progress we've made since thinking about privacy and security, improved thinking on Web Intents and what it means for the Web, or the more recent discussions around cars programmed with Web technology (which are moving fast, figuratively). Or TV. It also doesn't discuss issues with the security of the home network once exposed to the Web, which is a very interesting space (where by "interesting" I mean that it's a complete mess and we'll need a solution).

Do those notes help? Or were you looking for something else?

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Wednesday, 13 June 2012 20:52:14 UTC