Re: Installing web apps

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

Received on Wednesday, 1 February 2012 19:40:27 UTC