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.
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".
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.
As far as I know, there was never any registrar who insisted on approving your site's content before they would give you a DNS entry. Even if there was, there were many other places you could register that didn't.
What's relatively late? The 2600 vs Ford fuckgeneralmotors.com lawsuit dates back to 2001, more or less predating "serious" web apps (I don't have a better date for the end of the swearing ban, but it's been at least ten years).
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".
"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.
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.
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.
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.
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.
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.
Those aren't pure TCP sockets, though, since the server needs to support WS handshaking. You can't, e.g. write an IRC client that connects directly to IRC servers.
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?
Why? What are we gaining by cramming everything into the browser? We already have OS'es, networking stacks, and technologies for remoting out the UI of server based apps, as well as techniques for delivering code to where the data lives. Why not just use a tool that was designed for the task in question, instead of building some unholy golem-like chimera of parts and bits and pieces cribbed from here and there...
Seriously, a modern web-browser /web-app combo seems like something better suited for a Lovecraft story (I'm thinking "Herbert West: Reanimator" in particular) than real life. :-(
Actually, yes, at least sometimes. Web based email clients are useful on occasion, but that has nothing to do with the point I'm trying to make, which is that we could do something better than either "traditional" desktop apps, or golem-like chimera apps crammed into a web-browser.
Why not use the browser for navigating hypermedia and then let the browser handoff to a different app to do things that require richer interaction? It doesn't have to be a pre-installed traditional desktop app... there's the aforementioned JNLP, and who-knows-what-as-yet-uninvented approach. I'd love to see more people spending time on that "as yet uninvented" thing that trying to turn a browser into a crappy X server, and goofing around with nasty, brutal hacks like AJAX.
I think you are overselling X server, I don't know if you've ever tried to use X over a network but it's pretty awful. The web is not a crappy X server. It's a much much much superior approach to the X server- in that it allows code to run in the gui without the latency of sending every single mouse click and key press over the network, and every single low level drawing command and uncompressed pixel put back.
I think what you want has already been tried with Java applets. Java applets had 10 years to establish themselves as the one true way to make professional web apps and replace the OS. It was a monumental failure of epic proportions, and javascript+html won that battle a thousand times over. Now you want to try it again because .. why? Because you think it's a technically better approach. It's just history disagrees with you.
The web can work over a modem and crummy mobile phone connections. X would be hopelessly unusable under such conditions so it's a complete mystery to me why you are claiming that the web is a "poor man's" X-server. You'd have to be half mad to think that. The web could be 10 times more shitty than it is and would still beat X for quality and responsiveness. So really... HUH!? WHAT?
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.
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.
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.
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".
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.
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.
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.
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.
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.
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:
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.
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.
> 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.
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.
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?
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
"writing a browser" is a little bit of an exaggeration, since it's just all the chrome being implemented, and HTML rendering is handled by gecko. But, it's still a browser being implemented in js. It's pretty sweet.
I'm working on a tcpsocket API for js for the same project. It's being used to implement an imap client in js. It's all part of the boot 2 gecko project. It's quite fun!
Sounds good. Any chance you can encourage Mozilla to share UDP, TCP, POSIX with those outside of boot2gecko? i.e. someone else who wants to build something like boot2gecko but outside of Mozilla?
B2G is 100% open-source and developed in the open. They even take pull requests and have open meetings. They are going to be taking their work to standards bodies and hopefully a lot of it gets picked up.
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.
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.
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.
Except Chrome OS is developed by people who are motivated to hold your data for you. I don't have a lot of faith in Chrome OS's ability to be independent of a server model when it so much in Google's interest for you to be effectively tethered to their servers.
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
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.