Tim Berners-Lee: If I can't give power to web apps, they can't compete

http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html#start464

by _urga • 14 years ago

134 73 14 years ago

lists.w3.org

asolove• 14 years ago

I love the web, but let's be serious here.

  As a user when I install an app, I want to be able to give
  it access to a selection of:
  
  - Program storage, to a limit
  - Whether it is permanently available or downloaded or cached for a while
  - Access to RAM at runtime, to a limit
  ...

No no no. Normal people want to install an app and just have it work. They trust iOS apps because of a perception that they are carefully monitored, and because nothing particularly bad has ever happened. They don't trust the web because everyone has heard of email, credit card, etc. scams. One big reason for Apply to only allow in-app purchases through their system is that, therefore, third-party apps never see credit card information and can't do too much damage.

If you want web apps to succeed, figure out how a normal person is going to find, install, and trust a web app not to steal their credit card info. The only answer I can think of is through app stores run by trusted browser vendors.

bthomas• 14 years ago

Agree, but only because the items you cite here are too technical for an average user. I think the way the iPad implements location API is an example of permissions working really well.

icebraining3• 14 years ago

I think he's making a different point. He's talking about what capabilities web apps should have, not necessarily about the UI. The user will have to give it those permissions; it's irrelevant to this discussion whether the user understands those details and if these are defined one-by-one or by a combination of trusting the app store and clicking "install".

dreamdu5t• 14 years ago

Why can't we have both? It can be easy for "normal" people to install while also giving "advanced" users the control they desire.

chubot• 14 years ago

I see your basic point, but in the iOS case, something bad HAS happened -- your personal contacts may have been uploaded to the servers of many different companies without your permission.

The crux of the issue is that the web can't be designed like Apple. The reason the web took off is that it's decentralized. You don't need anyone's permission to set up a web site.

And in fact the contacts fiasco kind of illustrates the point. That happened because a company has monopoly on the (hidden) policies of their ecosystem.

I think one solution is to have programs that manage other programs in a future operating system. You could configure that Berners-Lee mentions by hand. But more likely you there could be a very simple system level app that presents a wizard: "You're running out of storage. Here is a list of all apps and how much storage their using." And it will guide the user through some actions to adjust the capabilities.

It is an open problem to determine whether general users can infer "access to my address book" + "network connectivity" -> "company can permanently store my contacts and spam my friends", and the like.

Retric• 14 years ago

You did need someones permission to setup a website and the web still took off.

PS: DNS

IsaacL• 14 years ago

It sounds like he's taking about the "permissions model" that exists on Android, Facebook, etc. That is, before the user installs the app, they're given a list of what operations that app will be allowed to perform. It's a very simple interface, just one screen with "accept" or "decline".

nilliams• 14 years ago

> The only answer I can think of is through app stores run by trusted browser vendors.

Exactly, that's clearly what Google are thinking too, as you can install apps from the Chrome web store with elevated privileges today, e.g. the Secure Shell app: https://chrome.google.com/webstore/detail/pnhechapfaindjhomp...

ktizo3• 14 years ago

Yes yes yes. Normal people want to install an app and just have it work. Which is exactly what Tim is describing the technical requirements of in terms of web apps.

Joeri• 14 years ago

"They don't trust the web because everyone has heard of email, credit card, etc. scams. One big reason for Apply to only allow in-app purchases through their system is that, therefore, third-party apps never see credit card information and can't do too much damage."

That's very easily solved. We just need a w3c spec for auth and payments in the browser, using browser-native UI and a pluggable framework so different identity providers and payment processors can hook into your browser.

If you think about it, the current system is equivalent to permanently giving a copy of your credit card to every shop you visit and telling them "bill me if you think i owe you something". The level of trust involved is mind boggling, and a system like that cannot ever become secure.

Nobody should see your cc details except your payment processor. Nobody should see your e-mail address except your identity provider (if a site wants to send you a mail, they should be using a browser-based notification api). The native app platforms have shown this works way better than the current browser model, so browsers need to play catch-up here.

danso• 14 years ago

I think it's great that Tim Berners-Lee is still chiming in on the contemporary issues involving the Web. From a latecomer like me, it seems the Web (and the whole of society) has incomprehensibly changed since he first specced it. That he can stay still be a leader goes to show how solid his original proposals were.

notatoad2• 14 years ago

note that he's not just "chiming in", he's employed by the W3C. It is his job to be a part of discussions like this.

lmm• 14 years ago

Didn't he react quite negatively when someone else added images to the web?

ktizo3• 14 years ago

Hmmm. But I hadn't wanted a special tag.

http://1997.webhistory.org/www.lists/www-talk.1993q1/0186.ht...

Maybe in the mildest sense imaginable, because he thought there was a better way of implementing it.

_urga2• 14 years ago

There's a difference between a sandboxed web page, and a web app that you want to install and use as a trusted application.

If UDP, TCP and POSIX were possible in the browser, with a simple permissions dialog, web apps would be competitive with native apps. As Douglas Crockford said, HTML5 has become everything but the kitchen sink.

It's not more high-level APIs that web apps need. It's three brilliant low-level APIs implemented properly in Chrome and Firefox and Opera and Safari with simple permissions. UDP, TCP, POSIX. Node has already done the work of providing a cross-platform implementation and reasonably well-accepted interface for these, that vendors could adopt. With these basic building blocks in place, the community would be able to do the rest.

There's no reason why a web app should by definition not be able to do anything that a native app can do.

mtgx• 14 years ago

What about Native Client? If he wants "web apps" to be as powerful as native apps, isn't that a good direction?

mindcrime3• 14 years ago

What about Native Client? If he wants "web apps" to be as powerful as native apps, isn't that a good direction?

That's another option. But don't forget about using JNLP / Java Web Start if you want the power of "native" apps, but delivered over the web. Trying to turn a web browser into an Operating System + Crappy X-Server is just silly. We're layering hacks on top of hacks on top of hacks, to use a web-browser to do something it wasn't meant to do: remote application delivery / UI remoting.

Web browsers are great at browsing hypermedia, is it really necessary that they also try to replace the OS, networking stack and implement a poor man's X server?

wmf• 14 years ago

NaCl is totally orthogonal since it has the same sandbox/permission stuff as JavaScript; it's just faster.

drivebyacct22• 14 years ago

For many intents and purposes UDP will be possible soon.

ehsanu1• 14 years ago

How so? I'm really curious, do you have any links detailing the upcoming availability of UDP in the browser?

icebraining3• 14 years ago

Firefox has had support for raw sockets in web applications since its inception. Unfortunately, it's platform specific, it's ugly as hell and, from what I can tell, a pain to give it permissions.

mburns• 14 years ago

https://en.wikipedia.org/wiki/WebSocket

TCP sockets in Javascript are getting standardized.

revelation• 14 years ago

You want to expose all of POSIX to some page with a one-time POSIX permission click? I can see a very limited need for raw TCP and UDP, but even in those there is a tremendous potential to have single pages knowingly or unknowingly (with the number of JS scripts people embed from 3rd party sources these days) leverage their users into a terabit DoS bandwidth weapon.

showwayer• 14 years ago

Isn't HTML5 the effort of making web apps comparable to native apps?

famousactress• 14 years ago

He's just described native apps, but called them 'web'. The argument is semantic at this point.

Lerc4• 14 years ago

I don't like the term web-apps for this reason. Some places refer to them as apps using web technologies to indicate that the things involved are HTML+JS rather than things that come via a Web Server.

I don't think that makes it a semantic argument. I think it's more of semantic confusion. Too many people wanting different things are assembling under the one banner without realising how different their goals are.

I can make an app that does 90% of what I want quite quickly in HTML+JS, but I don't use that because I know the critical remaining 10% is impossible.

laughinghan2• 14 years ago

No, he didn't. Native platforms simply don't have the commitment to openness and cross- and backwards-compatibility that the Web does. He described all the advantages of native apps, but the disadvantages, the advantages of the Web, are so uncompromisable they were implicit, so he didn't mention them.

There's a reason that compared to native platforms, the Web has way fewer problems with proprietary standards, walled gardens, dependency and upgrade hell.

floomp• 14 years ago

> There's a reason that compared to native platforms, the Web has way fewer problems with proprietary standards, walled gardens, dependency and upgrade hell.

Compared to proprietary platforms like Windows or OS X, sure, but free platforms like Linux and *BSD avoid all of that except maybe upgrades, and that's only a minor inconvenience since package managers are pretty good. Plus, you have the advantage of not being beholden to the web app provider's upgrade schedule, where you can almost never revert to a previous version.

And while web apps (at least in their state today) are necessarily open in the front-end, they're usually very closed on the server-side, which is definitely a step backwards from Linux/BSD.

throwaway64• 14 years ago

whats so open about facebook?

simonbrown• 14 years ago

  a web browser

Why would I want a web browser inside a web browser?

  a calendar client

There are plenty of online calendars. I'm not familiar with calendar clients, but what's the advantage of setting up a calendar protocol server rather than using an online calendar or installing similar software?

  an IMAP client

Webmail?

daleharvey• 14 years ago

Web apps cannot talk imap or to ical whatever, they need to be able to talk to another non web platform that can do these things, usually via requests to a web server.

I am currently writing a web browser in JavaScript for boot2gecko, there is a need

MatthewPhillips3• 14 years ago

Do you work for Mozilla or is this your own project?

notatoad2• 14 years ago

maybe you don't want a web browser inside a browser, but think about something like mozilla's boot-to-gecko project. the browser engine is a given, and the browser UI is actually just a web app.

similarly, an online calendar is a calendar client. It interacts with some server somewhere. Same idea with mail - Gmail is an IMAP client.

lifeisstillgood• 14 years ago

TBL hits the nail on the head again CORS is a massive and crippling restriction and needs to be overcome. Signing packaged js apps is one method perhaps - but whatever we do we need to over ome the app store gatekeeper somehow.

Kilimanjaro• 14 years ago

Let's say we have a calendar web app that we can run in the browser, or as a chromeless popup, or downloaded as a chromeless app.

That calendar.app is a container to all the resources that conform the app, made from html, css, js and varied media (img,audio,video) in plain readable code, which has made the web safer, so everybody can poke under the hood.

    calendar.app
        /media
        /storage
        config.js
        main.js
        style.css

That app must explicitly say what resources it will access in a config.js json file but still, all resources will be off by default, so the first time it uses a defined resource it asks the user for permission, like location, network traffic, storage, webcam, mic, etc. and it can never use any resource not defined in the config.js file so no sneaky pics from the cam if webcam is not define in the config.

The app would be sandboxed in its own installation folder and would have access only to its own storage folder, plus, as TBL suggests, a shared storage folder.

This all can be done today, we just need to put all the pieces together, so I see that vision fully implemented in the very near future.

bendemott2• 14 years ago

This all seems to assume that Javascript,css,html and the web 'stack' in general are reasonable and efficient ways to write robust applications. I fundamentally disagree.

gue5t• 14 years ago

Finally some reason. Tried and true native methods are superior in just about every aspect except 'shininess' (the DOM-based styling of CSS) and simplicity for end-users that wish to not understand even the basic concepts behind the systems they use. There's no reason to build on the abstraction of a browser in order to build applications /except/ that it's ubiquitous/instant. This seems to attract developers that want to get users more than they want to develop truly excellent software.

Just about every other property of the web as a runtime makes a solid argument against its usability: stability (browsers are trying to implement a process model now because the JS/DOM sandbox/environment is not sufficiently robust to be depended on to not crash), standardization ("use webkit" or "use compatibility libraries in js" is a weak answer compared to real guarantees from fairly static and mature standards), efficiency (everything goes through at least: parsing, the DOM, javascript's broken (mostly-missing) typesystem, etc., all at runtime or application startup), and simplicity (more layers mean more complexity; we have various openGL standards and now also WebGL, implemented on top of one or more of them on each platform; javascript as a 'bytecode analogue' for slightly more usable languages such as coffeescript).

Throwing more code at problems has rarely resulted in an elegant and efficient solution, but that's the approach we're taking to try to get back the performance and featureset lost from running web apps in a JS/DOM container. We've wrapped enough fundamental OS features in JS libraries/DOM extensions/HTML features. It's time to end this nonsense and create a real standardized and generalized sandboxing model if that's what we want.

laughinghan2• 14 years ago

I consider ubiquity and instant-ness (i.e., accessibility) to be quite important aspects in which the Web platform is superior to native platforms.

I don't know what you mean by "truly excellent software", but I'd rather make imperfect, useful software than perfect software no one uses, wouldn't you? And it is certainly possible, and nowadays routine, to create simple, elegant, well-architected, maintainable, efficient, performant, small-footprint Web applications.

Yes, the Web platform has all kinds of warts and scars. In and of itself, all else being equal, they are of course strictly a bad thing. But the principle of openness and cross- and backwards compatibility--the principle that technical concerns must be balanced against community concerns--that is their root cause, I believe to be superior to any of the alternatives we've seen, which have given rise to proprietary standards, walled gardens, dependency and upgrade hell.

I agree that "throwing" more code at problems rarely results in elegant and efficient solutions, but disregarding existing community concerns, like legacy software or standards, rarely results in successful solutions.

coopdog3• 14 years ago

I think the web could handle a fully re-imagined stack. So long as it adhered to well defined standards and kept dns, with buy in from the major browsers the two stacks could co-exist.

malandrew• 14 years ago

Due to network effects, some developers can only create the app they want and have it succeed by making sure they can get users. Excellence for such software is dependent upon adoption.

weixiyen• 14 years ago

Or maybe it's assuming that the write once, run anywhere paradigm is superior to creating apps in different languages for different platforms.

Lerc4• 14 years ago

I came up with a simple idea that will demonstrate when web-apps can compete with native apps.

Replace notepad.exe with a webapp. Let it launch by double clicking on a .txt file. Let you edit,open..., save, save as..., print, exit etc.

If you can't do everything notepad.exe does, your platform is crippled.

By all means allow protections so that this behaviour isn't available to every app, but without those basics I'm not interested in using them, and it is certainly a blocker for me to be developing them.

ZenPsycho6• 14 years ago

replicating native file system functionality is not necessarily desirable from a ux perspective.

Lerc4• 14 years ago

It's not something that everything should be able to do, but it needs to be possible.

It doesn't actually matter in the long run what the specific capabilities are, The important thing is for web apps to be genuine apps that matter they need to do anything that would be allowed from native code.

I don't actually mind them making a crippled platform, as long as they admit that it is a crippled platform that can't do much of what I want.

Selectively disallowing certain behaviours is really something that should occur at a different level that affects native and HTML/JS apps equally.

coopdog3• 14 years ago

http://webintents.org/

julian37• 14 years ago

TBL's proposal reminds me of OLPC Bitfrost, which blew me away in 2006 (?) when I first read about it (and OLPC was still hot.)

I don't actually know what became of it--unfortunately, I didn't yet get a chance to play with an OLPC device, and after they forfeit large parts of their vision in favor of a Microsoft-based solution I admittedly lost some of my interest--but at any rate, looking over the Bitfrost spec again today I think it is still relevant, and fairly close to what TBL has in mind:

http://wiki.laptop.org/go/Bitfrost

programminggeek• 14 years ago

You can do this right now, it's called Apache Cordova(Phonegap) or Appcelerator. He's right, without giving a web app a more direct interface into your device, they can't compete with web connected "native apps".

It is not that you can't write highly complex native feeling things in HTML and JS, it's that without real native hooks (both UI and hardware), it is simply impossible to do things from the web that a user would expect their device to be able to do.

If the user expects to be able to do something and they can't, it is a bad experience and they find a better alternative, which right now means "native apps".

pjmlp2• 14 years ago

And gladly so.

The Internet is for network protocols and documents.

Although I develop web applications, not by choice, I'll take a native desktop application always over a so called "web application", when possible.

coopdog3• 14 years ago

What I love about web apps is that they're so ephemeral. You open it, try it, close the window, and it's gone. And it only comes back if you ever go to that domain again

Downloading an app, worrying about spyware, having something run constantly in the background, no thanks

Got to love that sandboxing

pjmlp2• 14 years ago

> Got to love that sandboxing

The browser as application can also be exploited...

Tim Berners-Lee: If I can't give power to web apps, they can't compete

Related Stories