On your first point, it depends on the application. For some applications, this javascript level already exists or is appealing. I could even see this being very useful for siliverlight applications which will call back to the server via ajax anyway.
On the second point, not at all. You should never trust user data, regardless of when, where, how it was submitted. Whether you sync via a local SQL Lite db or just allow postbacks, data is data and you need to be careful.
"How secure can your web app really be if all data access is open for anyone with "view source"?"
Security Through Obscurity is generally regarded as a bad thing.
I think you have Google phobia, You will not use Google reader now you doubt about Google gears without developing anything using it.
Khuzema : Phobia?
I use Gmail as my email solution, Google Desktop as my offline search, I google apps for domains, and I use Feedburner, which was just bought by Google. I also use Picasa (owned by Google), GoogleMaps, I have Google Earth installed and probably a couple more google stuff somewhere.
Is asking a question about something you're not sure about a phobia? Or rational thinking?
I don't think the data access issue you mentioned is a problem. My hunch is that the developers of Gears intended it (mainly) to be used as local store for client-side user data, such as preferences/options, local data caches, etc. - not sensitive information (why would you do this in an app where the source code is partially visible??).
As for the maintenance issue with Javascript, I'm not sure I follow how it's differenct from any other language - it's still code in the end, and there will always be folks (like me) who enjoy working on the JS land.
I agree, its not something that i find very useful. Even though its from "Google"(and they can do no wrong) I greet Gears with a healthy dose of skepticism. Just as i would if Microsoft or Sun put it out on the market.
@commenter
...and exposing your data access logic for someone to try SQL injection attacks is even more bad.
I've been thinking similar thoughts. It's just a matter of time until JavaScript is the end-to-end programming language of choice in some environments. Imagine TDD domain-driven design where the domain model and tests are all JavaScript, the data access layer is a JavaScript ORM against SQL Lite, SQL Server, etc., and the same ORM runs on the client's browser as well as on the server using Microsoft's new DLR. Some would argue that it brings web development up to the same productivity level that you get with XAML/C# in the WPF/Silverlight world. One language for markup, one language for code. It's not a world I want to see, but you know it's very attractive to many web developers who hate having to context-switch to the back-end set of technologies to make their pretty GUI work do something useful.
What's the problem with having application logic in JavaScript? Is it something about the differences between runtime implementations (which I could buy) or something about the language itself (which I'd be interested in hearing an argument for)? Or something else entirely....
My point was that all web applications expose their data access facilities directly or indirectly - and hoping that people wont exploit that through making the interface more obscure is not good enough.
Not only I don't agree with you, but I think you fail to see the far end of Gears which is not necessarily web, but RIA's...
It may be. Not because of writing complex applications in Javascript. Properly structured JS is as good as anything else. Not because anyone can see your application. Some of the most secure software in the world are open source.
The potential risk is with any new "sandbox" where you have to provide a secure way for applications to store their stuff and not be able to grab anyone elses stuff or worse stuff on yoru PC. Can it be done? Sure it can. Will there be holes that are exploited? It is a pretty good bet there will be and hopefully they will be patched quickly. I would much prefer if Google Gears were open source so that many "eyes" could look at it and make sure it is secure.
Having said that I think we will all look back on this moment as the beginning of the next generation of the web where really complex applications can enjoy the security and portability of being browser based.