New Chrome feature frees Web apps from the browser
news.cnet.com
news.cnet.com
https://www.mozilla.org/en-US/apps/partners/
As others have said, the goal ultimately with this kind of work is (or should be) standardization. Web tech-based apps really should be able to run anywhere you have a decent browser.
(I work for Mozilla, but not on our Apps work specifically)
A shameless plug https://chrome.google.com/webstore/detail/fddboknafkepdchido...
edit: to be precise, my app is almost a year old and the packaged app stuff was there even before that. And in chrome world, twelve months is a very long time.
Still, I like the approach Ubuntu is taking much more as it integrates into the desktop and is cleaner. http://techcrunch.com/2012/07/19/ubuntu-web-apps-aim-to-brid...
HTML5 apps were Steves original vision. Add to homescreen exist because that was supposed to be the way to deliver new apps to users on smart phones.
Why should Apple destroy that? To protect their 30% cut from a store that doesn't bring in a profit? For heavens sake why?
Apple makes money when you buy an Apple product. They want to make it so that you want to buy more Apple products, not fewer. If removing the capability to add HTML5 apps to the home screen causes a loss of just one Apple product sale, it is not going to happen.
1. User sees a listing of XLS or DOC files in the web app, stored in the web app's local storage, user clicks to open a file in a default native office application such as MS Office, and registers a "watchFile" callback to be notified of any changes to the underlying file data (when the user presses CTRL+S in the native office application), to enable syncing to the web app's local storage.
2. Web app is granted read/write access to a directory on the user's system, so that if a user opens a file in this directory from outside the web app, the web app can still watch changes made to these files to enable syncing to a backup server etc.
3. Packaged apps as complete binary installs, without requiring Chrome to be installed on the user's machine, and without requiring the user to visit a proprietary web store or sign up as a Google user. The user should not know that they are installing a packaged app. This binary would need to be able to be marketed and installed from outside of proprietary web stores if packaged apps are to be a success. i.e. a website could offer a .dmg or .exe download link depending on the platform. The app would include the Chrome updater and auto-update to track the latest packaged app apis.
It would also be a huge help if the POSIX, TCP, UDP APIs could match that of Node.js and have similar performance characteristics and capabilities (fsync etc).
I'll stick to the browser made by a foundation, not a for-profit company trying to gain control over the web. I remember IE6.
(BTW, IE gave us XmlHttpRequest. It was not introduced by a standards body. )
Also, I'll give you a much worse example, that has already happened, rather than something that may happen in the future, like what you're suggesting - h.264. It "completely bypassed" the standards body as well. The standards body would've much rather used something open source and free, but since most browsers used h.264 for the video tag, and since 2 of the major browser makers, Microsoft and Apple, were unwilling to go with an open source codec, the standards body was forced to adopt h.264.
The WHATWG did not adopt h.264 as a standard, nor any other codec.
And btw did you miss the experiment part of all the non-standard APIs? About the only thing that wasn't was the manifest (which is JSON) and the icons.
If so, then: No. thank. you.
I will just never, ever, ever, EVER build software that needs to go through some sort of "approval process", unless I'm being paid a lot of money to do so. The fact that some dweeb at google has ultimate power to simply reject all my hard work, or even worse, approve it first and then remove it at a later time, barring all my users from accessing the app, all without me having ANYTHING to say about it is just fascist and wrong. I would never work under such a system (App Store, Windows Store, Chrome Store, etc...)
I need to be free to provide my application by any method I want, that includes a download link anywhere on the internet that lets users install the app when they want, if they want, however they want, without fear of some overlord stepping in and banning the app.
"Don't mind me, just makin' a straw man, knocking it down..."
Chromium is entirely open source. A quick search shows that there are many bugs/mailing list posts mentioning packaged apps within the Chromium project. So the answer to your hypothetical question is: no, you're likely not right. Google may control the experience in the Chrome browser, but by providing all the code they use, you're free to implement whatever system you want on your own machine.
It still works on Windows, just rename a .html file .hta. You get the appearance of a real application and special privileges through windows scripting.
On an unrelated note I like that application development is moving in the direction of using web technologies for offline software, but I don't like the fragmentation I'm seeing with the Windows Metro apps, Chrome apps, Firefox OS apps, Phonegap apps all using different manifests/APIs.
It would make more sense for developers and consumers if some of the people working on these were to work together and come up with a standard.
Or ios's "Add to HomeScreen" alongside "Offline Web Applications"[0], which I believe has been there since the first iphone.
[0] http://www.whatwg.org/specs/web-apps/current-work/multipage/...
Does "Create Application Shortcut" stuff work offline for compatible web applications, or does it just create a shortcut to a chromeless version (à la Fluid)? I can find no conclusive evidence towards the former by browsing.
What if I want to open another web app, like a calculator?
Say I create an App Launcher where I drop web app icons and expect them to run on click. How do I do that?
* Found it: chromium-apps
http://code.google.com/chrome/extensions/trunk/apps/manifest...
HTAs also lack many of the aspects of real applications. Many common operations just aren't possible with an HTA (e.g. basic network sockets, USB devices). And HTAs don't support any significant OS integration, such as file associations. In contrast, Chrome apps are intended to be robust enough to support something as ambitious as implementing your own browser, but to do so using a safe, portable framework.
Bring it on!
What people have invented is HTML applications, much as Microsoft promoted in the early 00's with some marketing and store ceremony around them.
Also, let's look at NaCl while we're here: it's basically a modern version of ActiveX.
Then we had silverlight, which was glorified Flash for LOB applications and could be out-of-browser. I wonder how long it'll be before Google invent that again.
All those are dead, and for a good reason.
Microsoft even sees that these approaches are just bad and has pushed away from them heavily recently apart from in the desktop and mobile space where they are 100% REQUIRED.
As far as their integration goes now, you can pin sites to the taskbar and there is no massive ceremony or framework around it - it's just a glorified bookmark.
Just because Google packages it up and throws it into the fad browser of the day, don't assume it's not the same golden turd that we've all hated in the past.
George Santayana: "Those who cannot remember the past are condemned to repeat it."
1. IE4 worked on UNIX (Solaris/HP-UX) and supported ActiveX.
2. MainSoft provided tools to port your ActiveX to UNIX (Usually a straight recompilation and little else required).
3. Other vendors are allowed to use Silverlight - look: http://www.mono-project.com/Moonlight
4. ActiveX,COM,MSRPC are all open specifications here: http://msdn.microsoft.com/en-us/library/dd208104(v=prot.10)
1-2 died because there was lack of demand.
3 died because there was lack of demand and MS decided it was the wrong route.
4 is used by MANY open source projects from Samba to tsclient.
As far as improving things goes, I've had many a thing fixed by Microsoft over the years. They ALWAYS solve a problem.
Both have sandboxes (ActiveX since Windows 6.0, IE7), both have restricted APIs, both run native code.
PNaCl is equivalent of silverlight which is cut down CLR.
More performance - I doubt it. CLR+JVM is pretty much up there. The moment you add any virtualization, trap code or translation layer to native code via NaCl which you will require for security, there is going to be overhead which will knock it inline with a VM architecture. Startup time might be less - that is it.
Better security - that's a lie. Virtualization on any layer never gave anyone better security. It's throwing stones in glass houses. The only hard security boundary is at the MMU/page table. As NaCl grows, you will see it break.
No-one getting sued? I'm sure the EU will have something to say when no other vendor implements it and Google uses it to leverage market share, much like Microsoft did in the late 90's and early 00's.
> Both have sandboxes (ActiveX since Windows 6.0, IE7), both have restricted APIs, both run native code.
ActiveX is a general purpose object API and has no sandbox at all. IE 7+ on Vista+ can instantiate ActiveX controls in a weak sandbox via low-integrity mode, but to imply it's comparable to the NaCl sandbox is just comically ignorant. NaCl validates the nexe's conformance and its subset of x86 instructions before it will run it (in that way being very similar to Java and .NET CLR). And NaCl runs entirely in an outer, system-level sandbox that denies all system and object access.
In contrast, IE's low integrity mode lets you read anything the user can, exposes massive chunks of the system as attack surface, and provides various writeable locations. On top of that, all non-trivial ActiveX controls in IE implement brokers which run fully outside the sandbox--something that's not even possible with NaCl.
> PNaCl is equivalent of silverlight which is cut down CLR.
Nope. And making that claim begins to underscore just how little you know about this.
> More performance - I doubt it. CLR+JVM is pretty much up there. The moment you add any virtualization, trap code or translation layer to native code via NaCl which you will require for security, there is going to be overhead which will knock it inline with a VM architecture. Startup time might be less - that is it.
Virtualization or trap layer? That's not even close to how NaCl works. It's really sad that you couldn't be bothered to read a one-page explanation of before you launched into this completely wrong-headed diatribe. Please, start here next time, so your trolling can at least be superficially informed: https://developers.google.com/native-client/overview
> Better security - that's a lie. Virtualization on any layer never gave anyone better security. It's throwing stones in glass houses. The only hard security boundary is at the MMU/page table. As NaCl grows, you will see it break.
Once again, premised on your total ignorance of the subject matter. Come back when you have at least a basic knowledge of the thing you're criticizing.
> No-one getting sued? I'm sure the EU will have something to say when no other vendor implements it and Google uses it to leverage market share, much like Microsoft did in the late 90's and early 00's.
I'm sure there was an attempt at making an argument in this last line, but mostly it just seems to be randomly scrambling for scary sounding words.
So basically, NaCl:
1. Validates the binary image. Of course that validation has no holes in it. When it does it...
2. Stops unsafe operations. Of course it never misses any and knows every instruction side effect...
3. Oh wait...
I'd put cash on someone breaking the sandbox, I mean after all it's perfect isn't it:
http://www.matasano.com/research/NaCl_Summary-Team-CJETM.pdf
You can't build a flawless sandbox on top of a system by closing the holes one by one, especially on x86/x86-64. The number of edge cases is immense.
As for the strawman in your latest comment, no one made any claims of "a flawless sandbox." I rightly pointed out that the security model of NaCl is far more robust, and you've offered nothing to counter that. Now, of course, software is going to have bugs, and the ones listed in that paper are significant. Fortunately, no combination of those bugs could have breached the outer sandbox, and would not have represented a real-world system compromise.
The origin of that paper also circles back to a very important point. We realize that we need to attack security from many different angles (fuzzing, sandboxing, bounty programs, etc.). And that paper you cited was actually the result of Google sponsored competition in 2009 against a pre-release version of NaCl. The authors were the second place winners, and have continued to research NaCl's security both as independent researchers and paid consultants. (One of them is actually presenting at Black Hat on NaCl security this week.)
My point here is that an objective read of the paper really paints NaCl very positively from a security perspective. Had you actually looked at the content rather than just made an assumption based on the title you would have been aware of that.
This is the same problem with NaCL. The API is complicated and has a bunch of browser-specific features. Firefox can't just include "pepper.c" and have NaCL support, there's tons of work involved. One result is that Firefox won't support Flash for Linux anymore. Implementing Pepper, even though it's "open source" is more of a hindrance than not having Flash.
NaCL is better technology than ActiveX, but uses the same idea of leveraging a OS/browser-specific API as a handicap for competitors.
So Google spends 6 months working on the next version and Firefox and Opera don't even get access to it until the next SDK and are 6 months behind, and they have zero input in how it evolves. That's not how open source should work.
http://www.chromium.org/nativeclient/pnacl/building-and-test...
Source: http://src.chromium.org/viewvc/native_client/trunk/src/nativ...
That wasn't hard to find.
http://src.chromium.org/viewvc/native_client/trunk/src/nativ...
The other is a link to a build of pnacl sdk that also doesn't include source (src/ folder is empty).
Am I being dense here? Where's the hg, github, code.google link that actually has the source code? I couldn't find where the source is. You would think that would be pretty obvious for an open-source project, like maybe some giant button on the project page.
Anyway it doesn't change the point. This isn't being developed as a public open-source project. It isn't designed to be easily added to browsers other than Chrome. Like ActiveX, it's being used as leverage to make one browser better at the expense of others.
Why it isn't just in a public repo, I don't know. It looks like it is set up so they can pull it at a moment's notice.
I agree with your comments.
It seems like a snapshotting tool, so you check out the stub and then dump the snapshot into it from the depot.
(this is similar to how Windows is built inside Microsoft).
Everything is in public svn and/or git repositories. The thing that's confusing you is probably how modules are split out as dependencies. They're not checked directly into the tree, and instead are listed by repository URL and pinned revision in DEPS files. On checkout and sync gclient pulls the correct revision from the appropriate repository: http://dev.chromium.org/developers/how-tos/depottools#TOC-DE...
Some dependencies are pulled in and set-up by the checkout scripts, which is not an unusual degree of complexity for a large group of projects with such broad dependencies. It's all clearly documented and everything you need to know to checkout, build, and contribute code is linked from right here: http://www.chromium.org/nativeclient
I guess Mozilla is unusually capable then because their download link is right here:
https://developer.mozilla.org/en/Mozilla_Source_Code_%28Merc...
Pretty simple.
So you're working on Chromium and think navigating a buildbot to get python scripts that download from a private svn is not unusual... ok fine, but don't be surprised if people don't want to touch it (or even can figure out how to). I certainly understand better now why Mozilla would rather just drop Flash support.
Seriously, this is just absurd. I don't know what you think you're arguing at this point, but I don't have the energy to correct you anymore.
Maybe it's just me, but I'm having a difficult time trying to comprehend how this statement relates to your argument. Some perspective please?
Basically the principle turns the world wide web into another WalMart or McDonald's rather than a vast library.
I guess the difference this time is that HTML5 APIs are actually good enough to build functional offline apps.
Shall we start the countdown until this is supported in Chrome for Android as well?