Chrome Apps Office Hours


Uploaded by GoogleDevelopers on 21.08.2012

Transcript:
[MUSIC PLAYING]
MALE SPEAKER 1: Shanghai GDG is a very interesting
developer community.
FEMALE SPEAKER 1: I'm glad somebody
has asked this question.
MALE SPEAKER 2: This is where the magic happens.
FEMALE SPEAKER 2: This is primarily a question and
answer show, so if any of you out there
would like to ask questions.

PETE LAPAGE: Well, welcome everybody.
Kind of a fun day, a special day for the Chrome Apps
Hangout today.
We have many of our Chrome folks here, in
Mountain View, with us.
To my right, we've got Paul Kinlan.
PAUL KINLAN: Hello.
PETE LAPAGE: Paul wasn't with us last week but is going to
be joining us regularly.
Paul?
PAUL KINLAN: Yeah, I was on vacation.
So I had a nice time off, relaxed in the British sun.
PETE LAPAGE: Ooh, the British sun, is that different than
the Brazilian sun or the American sun?
PAUL KINLAN: It's a little bit--
RENATO DIAS: Definitely.
PETE LAPAGE: Do you want to introduce yourself?
PAUL KINLAN: Yes, so I'm Paul Kinlan.
I'm a developer at Google, working on Chrome Apps and
also Web Intents.
I have to keep saying this every single time I do a
presentation.
PETE LAPAGE: I thought you weren't allowed to say Web
Intents anymore though?
PAUL KINLAN: Oh yeah, It's Stnetni Bew, isn't it?
PETE LAPAGE: Yes.
PAUL KINLAN: We say Stnetni Bew, which is Web Intents
backwards, but anyway.
Yeah, I'm Paul Kinlan.
I'm developer advocate at Google.
I'm just here in Mountain View for the week.
PETE LAPAGE: Awesome.
PAUL KINLAN: So yeah, I thought I'd come and say hello
to all you guys.
And let's talk about some Chrome Apps things.
PETE LAPAGE: Cool Awesome.
And we also have Renato.
RENATO DIAS: Yeah, I'm a developer program engineer for
Chrome Apps.
And this is the second session I've participated in.
And hopefully, we'll have several
others, many other APIs.
PAUL KINLAN: Apparently, I'm just hear for the banter,
which when I was asked to come along for this, I said, why am
I going to be a Star Wars character, one of those big
woolly mammoths?
And then I realized I'm here for the funny conversation.
PETE LAPAGE: Yes, well, there's that, too.
PAUL KINLAN: I've been preparing that joke all week.
PETE LAPAGE: Thanks very much.
We'll be here next week, too.
We also have Paul Lewis joining us.
Paul, do you want to say, hi, and introduce yourself?
PAUL LEWIS: Yeah, hi, from London.
I'm Paul Lewis, a developer programs engineer also on the
Chrome team, Chrome Apps.
And I also look at GPU and performance stuff as well, but
primarily today, Chrome Apps.
PETE LAPAGE: So I'm Pete LaPage.
I'm a developer advocate on the Chrome team, working on
Chrome Apps and Chrome Mobile and all sorts of really cool
Chrome stuff.
We've got a pretty exciting show this week.
Last week, we gave you the introduction to Chrome Apps.
We talked about, hey, what are they?
How do they work?
We showed you some samples.
We showed you some cool stuff on how you can get started.
This week we're going to dive into some of the recent
changes as well as we're going to build the Hello World and
take it into a little bit of a Hello Galaxy sample and show
you some of the things that are available with the
Windowing API.
Got to refer back to your wookie joke.
Well, I guess it wasn't a wookie joke, but banter joke.
PAUL KINLAN: I was looking at Wookiepedia today.
PETE LAPAGE: Oh, there you go.
PAUL KINLAN: Just to make sure.
I just realized as well, looking at the camera as well,
I'm the only one who is color coordinated.
I have the blue Chrome logo as my T-shirt.
PETE LAPAGE: Well, I've got the blue Chrome logo.
I've got a stripe.

Next time, I'll try better.
So with that, why don't we pass it over to Renato, who is
going to talk about some of the recent changes this week.
RENATO DIAS: Yeah, this week we had a breaking change on
the way you launch a new window.
And previously, you launched a window using the Chrome
experimental app API.
And this is, as it says in the menu, experimental.
And after we had a few weeks of feedback from you, we
transformed this API to an app runtime API.
And it's not experimental anymore.
So you should not expect that many changes on this API
practical area.
PETE LAPAGE: So that's a really good point.
Many of these APIs right now are under the experimental,
which means they're going to change.
And so, when they're going to change, you just sort of have
to be a little bit aware of that.
And at some point, they'll come out of that
experimental state.
RENATO DIAS: Exactly.
PETE LAPAGE: And what does it mean when they come out of
that experimental state?
PAUL KINLAN: It means they're relatively set in stone.
Obviously nothing is completely set in stone.
But the general idea is that we're pretty
happy with this API.
We've got hold of the developer feedback, and we're
pretty confident that it's not going to change that much.
So it's like a little bit more confidence that it's going to
be stable for the foreseeable future or the near foreseeable
future at least.
RENATO DIAS: And talking about window, we
also have a new feature.
It's not a breaking change.
But it's really cool, indeed, where you can specify that
your window is Chromeless.
Chromeless means it has no title bar.
And you have control of all the UI of your application.
For this specifically, it is still being developed.
PETE LAPAGE: So if it's under development, it's probably
under the experimental API?
RENATO DIAS: Exactly.
PETE LAPAGE: So we need to remember that.
It may change.
And we want your feedback.
If it's under experimental, we want to hear from you.
RENATO DIAS: Yeah, exactly.
Please, for all the APIs, specifically for experimental
APIs, go to the Chromium Apps forum.
We are there.
We answer any questions there.
And we really want to hear your feedback.
For this frameless window, what it means to be frameless,
it means basically for comparing to the actual framed
window, we have a title bar, and we have Close buttons and
Minimize buttons.
For the frameless windows, it's just a window where you
draw on any part of it.
It brings a problem, because you need part of your window
to be draggable, and you also need a close button.
And we all are working on this, specifically on the
draggable and on the default title bar.
But for now, you can already create a frameless window on
some platforms.
And Paul Lewis will show you an example of that.
Paul?
PETE LAPAGE: Paul, why don't you start off with a little
bit of a Hello World.
PAUL LEWIS: Before I do that, I'm going to just quickly show
you this frameless window, which I've got open here.
So this is on the Chrome app samples GitHub repro.
So get the source code for this right now.
PETE LAPAGE: So that's the GitHub repro, which we've got
a URL for that, which we'll show in a sec.
PAUL LEWIS: Yeah, And you see that the window that it's
launched has nothing other than the content.
So it's exactly as Renato said.
We haven't got any close buttons.
We haven't got anything else.
And if I check this box over here, it introduces a title
bar, which means I can now drag this around.
I can't drag using anything else.
We have top and bottom.
PETE LAPAGE: Now are those customizable?
PAUL LEWIS: Yeah, I believe they're completely within the
developer's control as to what they want to put there.
PETE LAPAGE: Very cool.
PAUL LEWIS: Yeah, total control over
how your window looks.
And then a close button as well.
So that's a quick look at that.
PAUL KINLAN: They look like the widgets, don't they?
Do you know, like the little notepad widgets with all the
little stickies and all that type of stuff.
It's kind of cool the things that you could do with that.
It's pretty cool, I think.
PAUL LEWIS: Cool.
So what I'm going to do is I was just going to go through
the process of creating Hello World.
And so you guys hopefully can see what
I've got on my screen.
And what I'm going to do is I'm going to step through
creating, as I said, a Hello World app.
I just talk through the various parts of it.
Guys, if you've got any questions as I'm going, just
feel free to shout.
So the first thing that we need is a manifest, which
basically tells Chrome about the app, thus a JSON file.
So we'll start out with that.
And we will call it manifest.json.
We need a "t" on the end of that.
PETE LAPAGE: I kind of feel like we should be doing the
Muppet thing.
We're the old guys, sitting up on the top of the thing with
Muppets and making the crazy comments.
PAUL LEWIS: I think you guys would make fantastic Muppets,
for what it's worth.
PAUL KINLAN: I was going to try and do a Fozzy Bear
impression.
Awww!
Sorry.
[LAUGHTER]
PETE LAPAGE: Paul, why don't you keep going.
PAUL KINLAN: We'll be quiet.
PETE LAPAGE: The peanut gallery will now shut up.
PAUL LEWIS: So far, I've got two properties.
And the manifest version is what tells Chrome that this is
going to be a packaged app, Version 2.
Version 1, which is the next property that I've got, it
actually says this is the version of the app.
So if you update that to 1or 1.1 or something like that,
that's what you put there.
And the name of the app-- let me put that in keys-- which is
going to be Hello World.

We talked about this last time.
We tell Chrome that we want to run this as an app.
And the background script that we want to
run is going to be--
get this right--
main.js.
And this is the script that runs in the background.
It's like the hub of all our app's communication.
So it's what's actually going to be responsible for
launching the windows.
It would be listening for the on-launched event, which is
the one that Renato just told you has changed.
So this is the manifest.
And the next file that we create is
going to be this main.js.
PETE LAPAGE: Now, can I just ask a quick question?
You said it has to be main.js.
Can it be like pete.js or fred.js, as long as it's just
something .js?
PAUL LEWIS: You're telling Chrome here what the script is
that you want to use as the background script.
So you can call it anything you like.
Conventions says it might be something like main.
PETE LAPAGE: Main, maybe app.js, something like that.
PAUL LEWIS: Exactly.
Something that is indicative of the role
it's playing, I guess.
So new file.
PAUL KINLAN: And I'd say the really cool thing there as
well is you can actually have multiple main files in that
list as well.
So you can break up your applications--
PETE LAPAGE: Oh, cool!
Yeah, and because you're not actually pulling files down
over the internet, there's no latency or delay or anything,
it's just like that.
PAUL KINLAN: Yeah.
PAUL LEWIS: So this is actually an array.
So it's just an array with a single item in it.
So the main.js, as I say, this is the hook of the app.
This is the thing that Chrome is running in the background.
So the first thing we want to do is we want to-- and this on
the new namespace, which is the new API, the
chrome.app.runtime.
And we want to attach a listener to the on-launched
event, which is what we want Chrome to do whenever we
actually kick off the app.
So here we go.
And I throw a function in there.
That always works.
And inside that, we're going to say, chome.app.window,
which is one of our new APIs.
Create, and we want to create--
the first thing we do is we tell which HTML file we want
it to load.
And then we give it an object with a load of properties
there which specify things like width.

I won't add it to this, but you could, if you wanted to,
add the new frame None, which is exactly how you get that
frameless window.
So if you want to create a frameless window, you add the
frame None property to when you create a window, and that
will let you do that.
So now I've got a main.js and the manifest.
But the last thing I need at this stage is the index, which
is going to be what we actually try and load up.
PETE LAPAGE: Now again, you can use any
file name you want.
You don't have to call it Index.
You could call it, MyMainApp.html.

PAUL LEWIS: Exactly.
And I'm just making life simple for myself.
I'm just going to call it, say, Hello World.

So that's it.
That's about all you need to actually
create a packaged app.
So hopefully now, if I go over here--
and I'm in Canary.
I've enabled the experimental APIs and all those kinds of
things we talked about last time.
And you can see, I've got Hello World here that I'm
going to try and load unpacked.
And all being well, it's added itself.
Yay!
So now, if I go over here and I click on this, I get my
window with Hello World in.
So that's all working.
That's exactly--
PETE LAPAGE: And it opens the size that you said that you
want it to open because you didn't say No Frame.
It still got the normal things.
And you can drag it around, just like you normally would
any other application window, right?
PAUL LEWIS: Exactly.
So at this stage, it's like these are almost things that
you'd expect from a web app so that the
window is slightly different.
But one of the things that you can do, we mentioned before,
is the Windowing API, which is new controls that you've never
had before for handling windows.
So I'm going to close this down.
And I'm going to go back to my source.
I'm going to add in a button.
And I'm going to give it something descriptive, because
I'm helpful like that.
And I'm going to make mention of a script.
And I'm just going to call this app.js.
Again, you don't have to call it--
PETE LAPAGE: So why not just put the script inline?
PAUL LEWIS: Now, we will talk about this.
[LAUGHTER]
PAUL LEWIS: I'm glad you brought it up now, though.
There are Content Security Policies.
There are restrictions on scripts.
And we'll talk about this in a little bit.
One of the restrictions right now is that you can't put
inline scripts in place.
This is supposed to protect your app from injections and
cross-site scripts and those kinds of attacks.
So I'm bouncing this script that I need out to this app.js
file, which I'll go ahead and make now--
app.js.
And I'm just going to spit up a little bit of code here.
All being well, I'll immediately invoke function
expression.

So what I want to do is I want to grab my button from my
HTML, and I want to add a click handler.
So adding that listener, click.
And when you click it, what I'd like to do is I would like
to call chrome.app.window.minimize.

Now this is not something you can normally do with a window.
You can only tell the browser, hey, I'd like you to minimize
the window.
And then what I'm going to do is I'm going to set a timeout,
where I'm going to say, OK, well, after about 4 seconds,
chrome.app.window.restore.
So not only can you minimize windows,
you can restore windows.
PETE LAPAGE: Sweet!
PAUL LEWIS: So all being well now, if I go back to here and
launch this, I should have a Minimize button.
And if this works, there we go, minimized.
And after a few seconds, if the set-timer
works, there it goes.
It's back.
The window has come back up.
PETE LAPAGE: Very nice!
PAUL LEWIS: So these kind of capabilities and more, you now
have available to you through the Windowing API.
And there are tons of APIs like this, and
they're so much fun.
And you see how simple that was.
That was just two lines of code for Minimize and Restore.
So there we go.
PETE LAPAGE: Excellent!
So there's a whole Windowing API set of instructions that
folks can go have a look that allow you to minimize,
maximize, restore.
What else is in there?
PAUL LEWIS: There's resizing, moving.
But there is a sample in the Chrome sample where one window
is set to mimic its sibling, which is quite interesting.
So you can do quite a lot of complex logic with these,
where you could have conceivably panel windows,
especially with the frameless.
So if you're making an app with a main window and you
wanted panels to snap to the screen edges and things like,
you could totally aim for that kind of thing with these APIs.
PETE LAPAGE: OK.
PAUL LEWIS: All right?
PETE LAPAGE: Awesome.
Well, thank you.
PAUL KINLAN: That's pretty cool.
PETE LAPAGE: Yeah.
All right, well, we started to talk about that whole Content
Security Policy bit.
Content Security Policy, I think, is something that's
really interesting and will really help protect
applications from a certain set of vulnerabilities.
Paul, do you want to tell us a little bit more about Content
Security Policy?
PAUL KINLAN: Yeah, so Content Security Policy is quite
interesting.
I say interesting.
Actually, it is interesting.
I did have a full head of hair before I started
messing with it.
And now--
sorry, it's a bad joke.
PAUL LEWIS: Believe me, I know this stuff, my friend.
PAUL KINLAN: So Content Security Policy is basically a
framework that is designed to mitigate the risks of people
injecting code directly into your web page.
As you know, with HTML and JavaScript, it's actually
pretty easy, unfortunately, to cross-site script on different
sites, just by injecting malformed HTML into a page or
any kind of malformed content into a page.
And when you think about the capabilities that these
applications have, whether it's access to USB or
Bluetooth--
PETE LAPAGE: They have advanced access.
They have things that normal web apps, normal websites
don't have access to.
PAUL KINLAN: Exactly right.
So even things like Chrome Synchronized Storage, for
instance, you don't want to basically get people injecting
a small piece of JavaScript or HTML inside your application.
PETE LAPAGE: Oh, yeah.
PAUL KINLAN: And then kind of--
I'm not saying take over the system, but do things that the
user didn't expect on the system from that single
application.
So Content Security Policy is designed to restrict the types
of things that people could do inside your application in the
sense of executing arbitrary JavaScript and HTML.
So some of the things we've seen before and Paul mentioned
it earlier on was you're not allowed to have any inline
JavaScript inside the page.
That's like on-click, so a button on-click, for instance,
which Paul didn't do--
PETE LAPAGE: Oh, yeah, so if actually put on-click inside
the button.
PAUL KINLAN: Yeah, you can't put the
JavaScript inside there.
It's pretty to hijack that if you didn't have Content
Security Policy in place.
And then likewise, inline script elements, you can't
have them inside the page.
They have to be inside a separate artifact that's
inside the Chrome package, for instance.
So they're just some of the basic things.
There are other things as well that you find in Chrome
packaged applications at least that is enforced by the
Content Security Policy is that you can't directly
reference external resources.
PETE LAPAGE: Oh.
OK, so I couldn't necessarily say, hey, I want to go grab
some fonts from TypeKit or something like that.
PAUL KINLAN: The fonts are interesting.
I believe not at the moment.
But there are other things as well.
You can't load JavaScript from arbitrary sources outside your
application.
Obviously, you can do
cross-domain XML HTTP requests.
So we've always had the ability in Chrome Apps be able
to specify a white-listed set of sites, for instance, like
your application can XML HTTP request to.
And then you can bring the content in.
But it has to be brought in and maintained and locally
stored inside your application.
PAUL LEWIS: This is why we were talking about last time,
and I think it's worth saying again, that
it's offline first.
And you really do you need to think about those terms.
PAUL KINLAN: Exactly right.
I mean, one of the things that you find as well is that
images, for instance, you are not really supposed to
reference images that are normally structural, for
instance, remotely.
So what we're trying to do is get developers to make sure
that their applications, all that images that they need,
are referenced locally.
This introduces some complexities.
You might have to download the image, store it locally inside
the applications local file system API or the local file
system sandbox and then reference from there.
And we've got, actually, some great examples.
So there is one news reader application, which basically
fetches data from the Google News RSS feeds, but it stores
all the RSS feeds in local storage.
And it does a XML HTTP request to go out, brings it into
local storage.
And then that makes sure that the actual content that you've
requested is available regardless of whether you're
online or not.
It's pretty interesting how you're going to get around
this at the moment.
But it's there primarily as a protection thing.
Secondary as well is to make sure these
applications work offline.
There are two exceptions, video and audio, where you
might want to stream the audio in off the web, if you're
doing a streaming-based audio player.
You might want to bring that in off the web and just have
access to that.
And interestingly as well, in our GitHub account, we've also
got a demonstration that does that.
So basically it goes out, and you can stream video from,
say, your local network into your application.
PETE LAPAGE: And those are on the Chrome App samples?
PAUL KINLAN: It's a separate repository on the Google
Chrome GitHub user account.
I believe it's called Video Player.
We can share the link later as well.
But essentially, you can go off, connect to your remote
networks, your home networks, stream the video in, and then
just kind of say, well, you know what I'm going to do?
I'm going to save this for later, bring it in, store it
in your local file system API, and then play it back offline.
So that's interesting.
There's two other little bits as well.
You're not allowed to do dynamic code
execution as well in CSP.
So that basically removes the EVAL essentially.
PETE LAPAGE: Yeah, EVAL, EVAL evil.
PAUL KINLAN: Which does cause some issues in the sense of a
lot of template and libraries have been built to basically
build up a function dynamically based off the
template structure and then execute it as you build the
template out.
There are workarounds for it.
You can either precompile a template.
So things like Handlebars, for instance.
You can use Handlebars to precompile a template.
I mean, there's not a lot of people who actually
dynamically compile templates on the fly anyway.
It's a convenience thing normally.
But essentially, what you'll try and do is you will just
compile it and include it inside your application, and
it works absolutely fine.
It works brilliantly.
And then there's other template frameworks, things
like Angular.
Sorry, it's not a template framework.
But Angular has got the ability to build these
templates on the fly, because it's more of a DOM-based
structure anyway.
So it doesn't go off and execute a new function.
It can just do it.
PETE LAPAGE: It just does it.
PAUL KINLAN: Because it builds the structure of the DOM up
automatically.
So CSP does introduce this restriction.
We think it's a good restrictions for users.
It's a little bit awkward for developers in the fact that
you have to maybe retool it a little bit.
But it's not too hard to get around.
PETE LAPAGE: It sounds like there's going to be some
rethinking in terms of there were things we used to do that
could sometimes allows cross-site scripting
vulnerabilities or security vulnerabilities.
And now these things put us into a more strict way of
writing our code but will also help us to make sure that we
write better code.
And that's important.
I want to write better code every day.
I want to make sure that I'm not exposing my users to like,
oops, sorry, lost some information for you.
Oops.
PAUL KINLAN: If you look on the developers.chrome--
is it developer.chrome or developers.chrome.com/apps--
we actually include a list of frameworks we know to work
with CSP and workarounds as well.
The interesting thing if you're building a backbone-
based application, the default template and library doesn't
work, which is the underscore template and library, because
it builds a function of a runtime and
then executes that.
Just use Handlebars for it.
RENATO DIAS: Talking about the documentation, we are also
working on that page, specifically.
And we will show some samples of the most important or the
most used frameworks and how to use it on packaged apps.
So in a few weeks, we will have a more complete page with
more samples.
PAUL KINLAN: I mean, and this goes out to the audience as
well, is if you're building applications and testing
applications today and you find that one of your template
and libraries or maybe a framework doesn't work, please
let us know.
Just go on the Chromium Apps Google group.
Email any of us directly.
I'm talking PaulKinlan@Google or my Google+ page.
We'll feed that back to the team and try and make those
things work.
PETE LAPAGE: Yeah, we definitely want to hear about
the things that you're using, the things that
you're running into.
PAUL KINLAN: Yeah, because it shouldn't be hard to build
these applications.
And we find that it's not.
It's just a little bit of a mind shift to get these
frameworks working.
PETE LAPAGE: And I think Mike West on our team has written a
really great article on Content Security Policy that's
up on HTML5 Rocks.
You can go check that out.
It's a great Content Security Policy primer and how-to.
A really great article, it helped a lot for me.
RENATO DIAS: There's one specific situation on Chrome
packaged apps is that you cannot relax the CSP rules.
So on extensions and on websites, you
can white-list domains.
You can white-list specific script source or image source.
In Chrome App package apps, they are not--
PAUL KINLAN: It's basically set to local packet.
Everything is pretty much set to the local package.
RENATO DIAS: That is very important.
PAUL KINLAN: You know you can store an image in the file
system API.
You can directly reference it like a normal image link.
It's fine.
It's just that you've got to try and get the image into
your application as well, whether that's zipping it up
or downloading it and installing it later.
PETE LAPAGE: Now, Renato, when we were talking earlier, you'd
talked about some of the things beyond
CSP that have changed.
Do you want to talk a little bit about that and some of the
things that developers should know about?
RENATO DIAS: Yeah, I will walk through some of the features.
Talking about the mindset change that Paul mentioned,
there are few things that doesn't make sense in the
context of an app.
And there are a few things that for security reasons,
like CSP, were disabled on purpose.
So you have the list of all these disabled web features on
our documentation website.
We'll show you the link in a few seconds.
Am I right about the link?
PETE LAPAGE: I think I got it in yesterday.
I think I made it.
But if it's not, we'll just put it in the
notes after the fact.
RENATO DIAS: Yeah, absolutely.
I grouped those web features by the
reason they are disabled.
So I will just walk through them and explain quickly.
The first group is we have a different flow, workflow, on
an app that makes sense on an app and doesn't make sense on
the web, on the open web.
And these features, disabled features, are for this group
is form submission.
It doesn't make sense to submit a form to an XML server
for obvious reasons.
Because you can do that.
You can use a JavaScript to grab the submit event and then
Ajax, use XML HTTP request to submit that asynchronously.
You cannot use the APIs--
feel free to interrupt me.
PAUL KINLAN: On anything?
Well, can we get some football in?
PETE LAPAGE: So you had a fun flight yesterday?
Nah.

RENATO DIAS: The APIs to change the browser Chrome, the
visual aspects of the browser that are available on
extensions are not available on the app for
obvious reasons also.
We also have some limits on the navigation object.
If you open a link, the link will open on a browser, not on
your web application.
This is very important, because you don't want the
user to be disrupted by clicking on links and get out
of your application.
PAUL KINLAN: Does this include links internally as well,
internal to the app?
RENATO DIAS: No, it doesn't.
PAUL KINLAN: The window will never change.
But I'm presuming you have to manage and intercept the click
and then do it.
RENATO DIAS: Yeah, this is very important stuff.
We are working to create samples.
Because most of the frameworks that manage the navigation
process depends on the link.

When I mentioned this change on the list of frameworks, we
also have a code for some of the frameworks that depend on
that and how it is going to be.
PAUL KINLAN: So how to do hijacks.
RENATO DIAS: Yeah, Exactly.
And the cookie--
PETE LAPAGE: Cookies?
Cookies?
RENATO DIAS: Where?
Where?
It's not lunchtime yet.
PETE LAPAGE: Darn.
RENATO DIAS: The document cookies doesn't make sense in
a client-only environment.
Cookies are basically to send information to the server and
if you're using a server to generate
content for your client.
So also you can use OAuth and other stuff, too, to
circumvent that.
Regarding safety and CSP, we disabled Flash.
We disabled inline JavaScript and the non-sandboxed plugins.

PAUL KINLAN: So we can still run Native Client code, right?
RENATO DIAS: Pardon me?
PAUL KINLAN: We can still run Native Client code?
RENATO DIAS: Yeah, we can run NaCl.
We absolutely can run NaCl.
I think we have samples for that also.
And the games we showed on the Google I/O, they use NaCl.
It's pretty amazing.
We also cannot show external resource.
We talked about that before.
And for this synchronous nature of some of the web
features, we have disabled them, because it stops the
flow of the JavaScript execution.
And those are the model dialogues, like Alert,
Confirm, the local storage, and the synchronous Ajax, the
XML HTTP request.
PAUL KINLAN: So can we go into local storage a little bit
more and tell us why--
things that you might have to do?
RENATO DIAS: Yeah.
If you are using local storage, you should be use the
indexed [INAUDIBLE] changer code to index the [INAUDIBLE]
because it's asynchronous, and it allows storing BLOBS and
storing objects.
You don't have to change out your code, too.
PETE LAPAGE: But there's also Chrome Sync with is, I think,
where you were getting at.
RENATO DIAS: Yeah, absolutely.
PETE LAPAGE: Which is cool.
PAUL KINLAN: I mean, it's relatively like the local
storage API.
It's key value pair based.
The idea behind it is it tries to be asynchronous.
One of the guiding principals--
PETE LAPAGE: There is two of them.
There's chrome.storage.local and chrome.storage.sync.
PAUL KINLAN: Actually, that's a good point.
So local is entirely local to the application.
And the synchronized one--
PETE LAPAGE: So if I think of chrome.storage.local, that's
almost identical to local storage, in that everything
sits on my one computer, one machine, doesn't go anywhere.
It's asynchronous versus synchronous.
RENATO DIAS: And it allows known strings.
PETE LAPAGE: So I can store--
[INTERPOSING VOICES]
PETE LAPAGE: --true objects in it.
So then with chrome.storage.sync--
now, this is the one that I go, this is kind of cool.
PAUL KINLAN: Yeah, so the chrome.storage.sync will allow
you to basically say, well, I've got my app installed on
three different machines.
How do I get the settings between those, for instance?
And it's just using the synchronization framework
built into Chrome already to make sure that those settings
and the data are replicated across.
And there are a couple of events that tell you when data
has arrived and all this type of stuff as well.
So it's pretty cool.
It's relatively limited in amount of data that can store
in it and the amount of operations that you can do.
So right now, we're basically trying to say if you've got
local application settings, for instance, that's what
you'll store in the Chrome Synchronized Storage.
Because that's one of the things that everyone hates
about being on multiple machines is that your basic
configuration is not
replicated across the machines.
PETE LAPAGE: And that's one of the things I love about Chrome
is that I go to one computer, to another computer, and
everything is just all shared.
PAUL KINLAN: You don't have to use a developer.
You don't have to build the infrastructure for
synchronization.
RENATO DIAS: And it's all there for you.
PETE LAPAGE: Now, could I put gigabytes worth of data into
Chrome Sync?
PAUL KINLAN: No, I think it's limited to a
couple of hundred kilobytes.
PETE LAPAGE: So I couldn't actually go and put
everything in there?
PAUL KINLAN: All your movies.
PETE LAPAGE: All my movies.
PAUL LEWIS: The documentation does list the quotas.
So there's the limit on the number of items, the item
size, and the number of requests that you can make.
So make sure to check out the documentation.
It lists those.
PETE LAPAGE: That's an important thing to just keep
in mind, that you can't put everything in there.
It's not like a big dump truck that you can just shove
everything in.
The internet is a bunch of tubes.
PAUL KINLAN: So can I just actually preempt one of the
questions that we've got on the Moderator?
PETE LAPAGE: In fact, you know what?
PAUL KINLAN: Because it's relevant to this.
PETE LAPAGE: Sure.
PAUL KINLAN: So we had a question, quite early on in
the Moderator queue, which basically said how do you
migrate your local storage settings from your Chrome apps
to synchronized storage?
PETE LAPAGE: Oh, good question.
PAUL KINLAN: It has to be a manual taskk, right?
I say manual.
It's like a developer manual task.
You have to have a step inside your application, which
basically says migrate all these local storage key value
pairs into Chrome's local storage.
PETE LAPAGE: Will that work though?
Because from within the app, you don't have
access to local storage.
PETE LAPAGE: So this is actually a really good point.
You got to remember is that these apps aren't yet
available on the Chrome Web Store.
So if you're going to do it now with your packaged app or
extension and you've got them stored in local storage, I
think Manifest Version 2 is fine for these.
You might want to start to think about migrating your
application as opposed to sitting in storage right now.
PETE LAPAGE: So if you've got a packaged app with a Manifest
Version 1 today, you have access to local storage and
you have access to Chrome Synced storage, so you should
move it there.
So that way when you ship your Manifest Version 2, your
updated Chrome packaged app, it now has access to this.
PAUL KINLAN: That's the theory.
PETE LAPAGE: Cool.
OK, that makes a lot more sense.
And if you didn't see my hands, I went like here to
here, and then from here to here.
PAUL KINLAN: Or we could just say the word "synchronize,"
and then we'd be fine.
PETE LAPAGE: That would work, too.
So on that note, I want to remind folks of the survey
that we're asking folks to go and do.
That survey is what Chrome APIs are you
most interested in?
What are the things you want us to talk about?
We're going to plan our next couple of Hangouts based on
the feedback we get from you.
We want to dive into some of these APIs.
Today we talked a little bit about the Windowing API.
But there's the USB.
There's Bluetooth.
There's serial.
There's networking.
There's all sorts of cool APIs.
Tell us which ones you're most interested in so that we can
try and really focus on the ones you're most
interested in first.
And I think with that, we've got a about five minutes, six
minutes left.
So let's go to the Moderator and take a
couple of the questions.
PAUL KINLAN: It's changed quite a bit, actually, since
we've started this.
So should we start from the first one?
RENATO DIAS: The first one is from Tim.
And he asks, "For enterprise, some companies dislike
auto-updating apps.
Would it be possible to embed a version of Chrome inside
your Chrome app?"
PAUL KINLAN: I think the answer--
yeah, that's a hard, good question.
RENATO DIAS: I think the answer currently is no.
PAUL KINLAN: I think there are device policies.
There are policies for Chrome--
PETE LAPAGE: There are some enterprise policies that, as
an enterprise, you can say I do not want Chrome to
auto-update.
I want to manage the roll-out of Chrome in my organization.
So once you do that, you should be able to control how
that comes out.
RENATO DIAS: But I'm curious if the question
is I want the Chrome--
PAUL KINLAN: Things like Enterprise apps?
RENATO DIAS: The whole Chrome runtime on the computer runs a
specific version, or if the Chrome apps runs it different?
PAUL KINLAN: It's like, you don't want Chrome to update.
And then if you don't want Chrome to update, you've
probably got a very restrictive policy about apps
updating as well.
I think you might be able to control the
update policy for apps.
PETE LAPAGE: I believe you may be able to do that.
If you're using Google Apps dashboard and you're
installing your apps through there, I believe you're right.
You can.
PAUL KINLAN: But if it's a public app that you found on
the public web store, essentially, I don't believe
you have any ability to control that at the moment.
I don't know.
It's feedback that we get.
And I've heard it quite a few times.
RENATO DIAS: Let's go to the next.
It's from Russell.
"Apps and extensions have very exciting features, bringing
new possibilities in being able to personalize Chrome.
When using Chrome for Android, however, it doesn't work.
Are they going to be added?
When can we write an app for my phone?" We had this same
question last week, right?
PETE LAPAGE: Yeah, Paul, do you want to go ahead?
PAUL LEWIS: I was going to say some guy talked about this at
I/O. That's right, right?
PETE LAPAGE: Yep.
PAUL LEWIS: And the plan is that we do want to bring all
these apps to mobile, to all platforms, really.
It's about what we're trying to do at the moment is get the
desktop story correct and make sure that we are consistent
there and we iron out any kinks.
And then we don't have a date or time or anything, but we,
as I say, do plan to roll it out.
It's just about getting that right on the desktop first.
PETE LAPAGE: Yeah.
RENATO DIAS: Jake sent a lot of good questions last week.
And this week, he also has a very good question.
We would take the chance that Paul Kinlan is here and would
be able to answer this.
PAUL KINLAN: Is this the Open-With question?
RENATO DIAS: Yes.
PETE LAPAGE: Is this a Stnetni Bew question?
PAUL KINLAN: It might be.
RENATO DIAS: Let's say that I have implemented simple text
[INAUDIBLE] packaged Chrome app.
Is there any way to expose this app and open with context
menu, which shows up when a user right-clicks on TXT files
in File Manager?"
PAUL KINLAN: Yeah.
RENATO DIAS: OK.
PETE LAPAGE: All right, so the answer is yes.
Next question.
PAUL KINLAN: It's not quite there just yet.
I mean, the intention--
to excuse the pun--
was to have your application--
thank you.
We need sound effects for--
[LAUGHTER]
PAUL KINLAN: The intention was to basically say Web Intents
has got a view intent.
The user intends to do view some content, essentially.
They don't particularly intend to edit it or
do some other stuff.
They just want to view it.
And whilst we don't have it in the platform just yet, with
the ability to say, look, I want to be in the Open-With
for text files, that was the goal I had quite early on with
this whole thing, was we've got the ability to say I need
to view text files.
I need to view images.
And I need to view videos and all this type of stuff.
Therefore, you should be able to use the existing Web
Intents functionality to say to the system I want to be
able to view these types--
my application can view these types of files.
So when the user says, I want to view it, like an image or a
video, your application will be listed there.
I think we're a little bit away from that, just getting
that in right now.
The goal is there to do that, I think.
The general idea behind Web Intents inside these platform
apps is it is like IPC basically for these web
platform type of apps.
So the idea is that you might be able to say, well, I need
to do some other different types of actions, and your
applications will be able to talk to
each other via Intents.
So the goal is there.
I don't think it's available just yet.
PETE LAPAGE: But it's coming?
PAUL KINLAN: Well, if you look at Chrome itself, I think in
the beta channel, it's got the ability to view RSS feeds
inside an application.
So your application can say I need view RSS or Atom feeds.
You'll see it today.
We've got a couple of extensions.
I think Wordpress has got an extension.
And RSS Feed Viewer, he's had like 60,000 installs in week
just from this piece of technology.
But the idea behind that is you say, I need to view an RSS
feed, You can open in a viewer inside your
application of choice.
PETE LAPAGE: So I think we have time
for one more question.
So do we want grab one more?
PAUL KINLAN: Well, actually, there's one here. "Can I make
a window always on top?" By Marco.
Right now, no.
I believe you can't make a window stay on top at all.
It's good piece of feedback that we should give back to
the team, actually.
PETE LAPAGE: So we'll get that back to the team.
But it's always helpful if you guys go and file bugs on
Chromium bugs.
Because that way, not only do we get the feedback to the
team, and they hear it from us, but everybody else who's
watching today can go star that issue and say, yeah, I
want that, too.
Don't add the comment that says I want that, too, but
just star it so that the engineering team sits there
and goes, oh wow, this really is a popular thing.
So I think that's probably about all the
time we have for today.
I want to thank these two for being here and Paul for
joining us from London.
We'll be back next week, though everybody is going to
be in their home location.
I'll be back in New York.
You're back in London.
RENATO DIAS: And I'm back in Sao Paulo.
PETE LAPAGE: You're in Sao Paulo.
So we're going to be coming to you from all over the world.
PAUL KINLAN: Before we finish, there's actually about 18 or
19 questions on the Moderator.
We only had three at the start of this talk.
Is there anyway that we can just start to answer some of
these questions?
PETE LAPAGE: Why don't we take a stab at answering some of
these questions in the setting responses in
the Moderator queue.
So we'll take a stab to give you some
answers on some of these.
So have a look at the Moderator queue for
this after the fact.
We'll try and get some of the--
PAUL KINLAN: We've run a little bit late.
I was doing the banter.

PETE LAPAGE: Well, with that, guys, yep, exactly.
Paul's hiding his head.
I'm going to hide myself.
With that, thank you very much.
We look forward to seeing you next week, 9:00 AM Pacific,
noon Eastern, 5 o'clock in London,
somewhere around the world.
Can't wait to see you.
Thanks everybody.
PAUL KINLAN: Bye.
RENATO DIAS: Bye-bye.
[MUSIC PLAYING]