A couple of feature requests.

[Blaine Cook]

I think I speak for everyone when I say that I'm extremely excited
about the announcement of Chromium Apps. Browsers have long opted to
sit on the sidelines just serving up web pages; with HTML5, app
development completely within the browser environment is a completely
achievable goal.

I know that the plans that have been sketched on the documentation
site[1] are still very preliminary. With that in mind, I'd like to
very strongly ask the Chromium developers to consider the following
three things that HTML5 Apps need to be able to do:

1. Arbitrary HTTP requests.
2. Content-type handlers.
3. Protocol handlers.

Firefox has support for the latter two without requiring a manifest,
so it should be pretty straightforward to support (and would make
things like mailto: support actually possible within the browser, so I
anticipate their addition).

Arbitrary HTTP requests are the blind-spot of HTML5. So much time has
been spent bickering about CORS and UMP, which don't actually address
the fundamental need for *applications that interact with the web to
be able to make HTTP requests.* JSONP isn't enough, CORS isn't enough.
I can't download ePub files from anywhere-on-the-web in my open source
HTML5 ePub reader without setting up an open proxy for all to use.
Image editor apps can't import images without going through the local
file system. Developers can't leverage APIs unless JSONP support has
been added, and then they have to trust the remote site to not inject
malicious code into the JSONP.

I've written more about this here: http://blog.romeda.org/2010/05/three-simple-things-that-browser.html

With the arrival of Chromium Apps, this is a totally viable thing that
appears to be explicitly forbidden according to the current
documentation. Please, please fix it!

Thanks to everyone at Google for your hard work on this!

b.

[1] http://code.google.com/chrome/apps/docs/developers_guide.html#live

[Aaron Boodman]

Hey Blaine,

I've read your blog post about this when it was first posted. Allowing
cross-origin requests is not a possibility because it would be a huge
security issue. For example, it would allow web sites on the internet
to crawl a user's intranet.

If you need cross-origin requests, you can implement your app as a
Chrome extension. Extensions are higher privilege, and have more
strenuous security warnings. We want to keep web apps nice and safe so
that the install can be very lightweight.

- a

[Blaine Cook]

On 19 May 2010 12:07, Aaron Boodman <a...@google.com> wrote:
> Hey Blaine,
>
> I've read your blog post about this when it was first posted. Allowing
> cross-origin requests is not a possibility because it would be a huge
> security issue. For example, it would allow web sites on the internet
> to crawl a user's intranet.

I'm sad to hear this. I understand the security implications, but
disagree on your tactic here. I can publish a native app that is
downloadable and immediately executable with absolutely no security
warnings whatsoever.

Intranet administrators avoid this security issue by issuing policies
that users aren't allowed to download arbitrary apps and install them.
By offloading just this one point of control to the web, we're
seriously restricting the utility of HTML5 Apps. For example, a
Twitter client like Tweetie would be impossible to build without JSONP
or CORS support from every single service involved in building that
app; the cost to rapid development is immense, and I hope Google
reconsiders this.

> If you need cross-origin requests, you can implement your app as a
> Chrome extension. Extensions are higher privilege, and have more
> strenuous security warnings. We want to keep web apps nice and safe so
> that the install can be very lightweight.

I have to push back here a little – a web app that I have essentially
no relationship with will be able to:

- know my exact physical location
- consume all the storage on my device, potentially performing a DoS attack
- read local files from my hard drive (via the FileAPI)
- [eventually] use my microphone and my video camera

But it's too much to ask it to be able to make web requests?

The privacy and security implications of web-based apps funnelling all
of a user's activities through a single domain are far scarier than
arbitrary web requests. The latter is well understood in the context
of the desktop OS. Every single application you download has these
permissions. We're only just beginning to struggle with the
implications of the former, and the backlash against Facebook is only
the beginning.

Another way of putting it is that I trust applications that I've
installed and for which I can view the source code to verify that
they're not doing creepy "phone-home" things with my data more than I
do a web app that hides from me what its actual actions are in a sea
of "proxying".

Since I'm ranting, I may as well mention that the same-origin policy
isn't actually specified anywhere; it's just one of many approaches to
security. Intranet administrators have many other issues to deal with
as I mentioned above, and the same-origin policy doesn't really make
things any easier for people trying to prevent XSS attacks, since as a
site developer you still need to validate each and every request. It's
a useful tool, but it's just a tool, and blind devotion to it is
holding back what can be done with HTML5 Apps.

b.

[mokkabonna]

To me Chrome web apps (serverless ones) seems very similar to opera
widgets, which do allow for cross domain ajax requests though. They
use the terms private and public networks based on ip ranges (dunno
how good that is) and a widget/app has to opt-in for access to those.

Would something similar be possible for chrome apps? Or is the opera
widgets security model not good enough in your opinion? Read more
about it here:
http://dev.opera.com/articles/view/opera-widgets-security-model/


Martin

[Gregor Hochmuth]

The security of end-users is at the heart of this design decision - we also don't plan to diverge from the model that web apps use today for cross-site communication because we want these apps to work in other browsers.

That said, your feedback on this is important to us -- whenever you can share scenarios that you find impossible to implement, we'd appreciate it and we'll take them into account as we design the details this platform and share our progress with you.