On 2/1/12 11:03 AM, Ian Hickson wrote:
On Wed, 1 Feb 2012, Tim Berners-Lee wrote:
These apps have got to be able to completely
act as agents trusted by the user, like for example
- a web browser
You want to write a Web browser in a Web browser?
Ian, at present, you're the one defining what a web browser means. We've
had some of this discussion on the "Attitudes and Direction" thread.
I've written an SVG implementation inside of a web browser. I've also
produced HTML authoring tools inside the browser.
The browser is a great place to do it; it's got backup implementations,
a safe scripting environment, CSS and DOM parts; it's well tested, and
modern browsers are already installed on many machines. Many people do
special kiosk implementations inside the browser. Some people even write
ATs inside the browser.
Yes, a browser in a browser. Two browser vendors are pushing
browser-only operating systems.
- an IMAP client
There are lots of mail clients written on the Web today.
As I understand it, gmail is a 300k LOC beast, and drove many early
innovations in the Chrome web browser.
An IMAP client requires TCP acccess; this is something that I can see
the Chrome browser is looking to open up through a websockets proxy.
and so on, none of these can you currently write as a web app, because
of CORS.
to work around by just wrapping IMAP in WebSockets. Nothing to do with
CORS (or even the same-origin policy).
It has something to do with CORS if the CORS policy on the remote server
doesn't allow it.
Yes, I can waste bandwidth and use a trusted proxy server. But I don't
want to, and I'd like to use my own cookies.
That's the CORS issue.
As a user when I install an app, I want to be able to give it access to
a selection of:
Providing access to these things when the app is installed is IMHO a net
worse security model than granting access to these things implicitly when
the feature is needed.
Mozilla said they were getting rid of their enable privilege API. I
don't know that they have. Chrome certainly went for the privilege
model, with the chrome.permissions namespace.
Providing granular access is a nice thing. There are times, such as
kiosk setups and corporate intranets, where the access should be granted
all at once. For trusted applications.
I've found that even for applicationCache, it helps to have an "install"
button. Cause I hate showing off a project to someone and seeing a
permissions prompt on load.
I've not figured out how to evict the app cache, though.
Of the things you list, the following are already possible without an
up-front permission grant, in a manner more secure than an up-front grant:
- Whether it is permanently available or downloaded or cached for a while
We do not have long running shared workers. There's no means to tell the
browser that a page should run in the background at system start-up (or
browser start-up) and continue running. We're close, on that end, but
there is no BackgroundWindow spec at the moment.
Chrome just hacked on window.open('url', '#background') or #bg, or
something like that.
- Ability to access anything on the web
What's the use case for this?
Authoring tools, assistive technologies and everything in between. And
proxies and traffic shaping.
Google did a good job in their latest releases with "Copy Image". That
feature actually works now to copy an image from one frame to another.
Copy and paste works fairly well (I'm working on the bug reports);
allowing a user to copy and paste sections of a page from one site to
another.
But they're only partial solutions, and they certainly don't match the
ability granted in the chrome.webRequest namespace.
I want to be able to se where all my resources (including CPU, RAM,
'disk') on my laptop or tablet or phone are being used up, just like I
do with music and movies.
You can do that today without an up-front permission grant. (q.v. Chrome's
task manager, for example.)
And in private namespaces, I'm sure you can access the data
programatically. Or will be able to at some point.
Perhaps there's confusion here as to what an "application" means to you,
Ian.
If I can't give power to apps, then the web app platform cannot compete
with native apps.
There's plenty of things we can do to make the Web platform more
compelling and a better competitor to native apps, but adding "installing"
isn't one of them. That would in fact take one of the Web's current
significant advantages over native apps and kill it.
What does "installing" mean to you?
For me, applicationCache is installing. Using web storage is installing.
Hell even using Cookies can be argued as installing. Thus the backlash
against advertisers installing trackers on a person's computer.
On the iPhone, adding a bookmark to the home screen is installing. On
the chrome store, it's often the case that people notice "hey, this is
just a bookmark to a webpage". Fancy bookmarks are installing.
For web app authors like me, who have put everything we can behind using
web apps instead of native apps, "installing" is the only thing that
gives us a real chance of meeting our goals. I'm looking forward to
seeing more items from Google's "chrome.*" namespace hit the general web
ecosystem.
-Charles
