Application trust models; Expanding Web applications out of the sandbox
A few years back Web developers were celebrating the glimpse of a beautiful Winter as some of our best hacked our way out of the prehistoric ages to give us Ajax.
Fast forward to Hope year and we have seen the Web platform explode. We have gone from Web hack to the mobile phone and even the desktop.
With technology such as Prism, Fluid, Gears, and AIR we get to use our Web skills to build desktop applications. If you play the numbers game and realise how many people understand how to hack on the Web versus write native applications you can see how if harnessed correctly, the Web could be a dominant platform far beyond the browser as we know it.
However, how do we break out of the Web sandbox? We gain a great deal of this “secure” (don’t say that to Crockford) place for us to build applications and we can’t just break out willy-nilly.
The problem is, that if we don’t come up with something you will always end up saying “I can’t prompt my users for every little thing, so I guess I will just write a native application.”
This of course doesn’t actually help make life secure for the end users. Instead, they hit OK on the “Sure, I know I downloaded that from the Internet” dialog and now native code is doing whatever it wants too!
ASIDE: I would love to know how many people: a) download something from the Web, b) run it, c) see that dialog and then d) say “oh, OK no.” I know what I am willing to bet on ;)
What if we took the weakness of the current Web sandbox and make it a strength. If our platform is able to intercept what is going on, imagine if we could have metrics that show us exactly what an application is doing. Chrome does one small thing here, showing you the memory that a tab is using. This is a great start. What if we go further and you think of iStatMenu being somewhere in the browser:
Now for every browser application you can see not only its memory footprint, but you can see if it is using your location, how it uses the network, the local database, and even the file system. Instead of asking once “is it ok for this app to do anything” we can ask a more nuanced question, but also give a lot of feedback after the fact, way after you have forgotten what you said would be OK.
We could also have power user modes that allow you to visually see the heap, allowing you to navigate it as you debug your application. Detailed networking views. And, more.
Of course, the best way of doing this work is through implicit interfaces. Having a Google Search with a “[x] near my location” checkbox is the obvious example.
This is a delicate issue, but I believe that the Web needs to move in a broad direction, and we need to work through these problems. What do you think?
December 1st, 2008 at 10:24 am
Spot on! It’s not good enough – it shouldn’t be in the future anyway – for apps to just say “I need access to the kitchen sink”. There are several ways to attack this problem and the containers must play a big role in it. It dovetails with proper process management, which is part of the next evolution of browsers that Chrome has kick started.
“ASIDE: I would love to know how many people: a) download something from the Web, b) run it, c) see that dialog and then d) say “oh, OK no.” I know what I am willing to bet on ;)”
December 1st, 2008 at 11:16 am
“Instead of asking once “is it ok for this app to do anything” we can ask a more nuanced question”
I think this point is extremely important. I know it’s perhaps orthogonal to your core idea, but the question should be user meaningful, and in the case of multiple questions we should visually prioritize based on user risk, to the extent that we can determine relative risks. Lots of hard work left here to do to generate a simple, uncluttered, straightforward question.
And as you implied the question is the fallback.. “implicit interfaces” which provide implicit permission are the key, getting consent through user interaction that is required anyway to complete the user-important task.
The tightrope we’re walking here is the line between what the page controls and what they don’t. What are the tools we use to enforce that the user clicking on the box in “[x] near my location”, actually allows a site to use location for this purpose only? Is this acceptable risk all things considered?
I guess my question in this example is, should the page be able to state what the location will be used for? Potentially a more nuanced user question can be generated (implicit or explicit), but pages can lie.
Yabber aside, I think understandable visual feedback on what a page is doing on your box would make things much better, and a whole class of questions could be safely delayed.
To realize this auditing goal, it seems like everything running in a browser as a result of a pages actions should be put in a bucket that we can audit. Namely, web plugins would need to be audited in the same way as browser built-in stuff… Now how might we accomplish that?
December 1st, 2008 at 11:17 am
Totally agree. Excited to see how things progress.
December 2nd, 2008 at 12:50 pm
first, great winter photo above; gorgeous place.
agree a new permission model is needed and it applies for local/native and web. android when you download/install you give permissions right there, one, which is not painful. On the web w/ access to local (I’m talking about mobile here) security issues will exist, but we should ask the user *once*.
…and I really like the idea of having like a grand view “monitor” of some kind that gives you visual hints on what apps are doing…
December 5th, 2008 at 9:38 am
Thanks for the great post, I started my career in nursing after finishing a associate degree in nursing from associate degree nursing schools