ANDREW WARREN: Today we're
going to be talking a little bit
about what Weave is and some of
the developer components to it.
And then in a little bit, Sam
is going to join me out here,
and we're going to
talk about Brillo.
And we're going to try to
leave some time towards the end
for Q&A as well.
And there are some
mics along the sides
as well as on the
balcony for folks
to line up for that
if they need to.
So without further
ado, let's dive in.
Before we get into
really what Weave is,
and what the
components there are,
I want to talk a little bit
more about the context of some
of what we're seeing of shifting
user expectations in this area
because that actually informed
a lot of what we were doing
from the Brillo and Weave side.
And I think it'll
help to understand
why some of the
decisions were made,
particularly around privacy and
security, but some other things
as well.
So we're seeing actually
a pretty quickly shifting
landscape in terms of user
expectations around devices.
And here I don't just
mean connected devices,
but even the devices that people
normally have in their homes,
at their offices, and in a
variety of different places.
And one of the first and the
most visible ones of those
is around the
user's expectations
around the experience
with their devices.
So there was a
time when in order
to bring a device
into your home,
it was generally a look
through the manual,
figure out what
magical combination
of buttons and arrow keys
to press on the top of it
to get it set up.
Sometimes you might have to
download a Windows application.
And then you'd have to go
through it finding the IP
address of the device
on the local network,
and then opening up a browser
to the on-board web server.
And thankfully those days
are fast retreating from us.
But what that means
is that users are also
starting to expect that there's
better experiences with regards
to getting devices
out of the boxes,
that there are better
experiences with regards
to getting these devices set
up and then ready to use,
and then actually
starting to use those.
And that actually comes
into the second piece
of this, which is really
about mobile experiences
playing a larger role in users
interacting with their devices.
So again, back when users
really needed in order
to have their computer
talk to their device,
that kind of experience
didn't really
work out very well because the
computer wasn't very portable
and often neither
was the device.
Mobile has started
to change that a bit.
It's easier to carry around
your mobile phone with you
and interact with
devices in whatever room
of the house you are in or the
device you're talking to is in.
We're also seeing as part
of that growing interaction
between mobile and the devices
that we have in our homes
the addition of an increased
intelligence and kind
of adaptation to the
user's circumstances
and to their behavior.
We now have vacuum
cleaners that know
when we are or are not
home and have the ability
to learn our floor plans.
And again these are still very
early days for a lot of that,
but it's starting to shift
user expectations around what
their devices should
be doing for them.
And that's something
that we have
to take into consideration
to some extent as well.
Another side of this
that we're seeing
as we're kind of looking
over at some of the landscape
here is that these devices
are starting to get
better and better over time.
And the user
expectations are starting
to shift to orient
around that as well.
This really started to some
extent with the internet
and with web applications and
web services getting better
each day you come back
and reload the page.
And then that carried over
to the mobile landscape,
where the internet also
allows the mobile experiences
to get better day by day.
And if you have a problem, if
you have a bug, if things don't
work quite the
way you want, take
the next app update and
everything works better
or you hope so at least.
And so that kind of
expectation is also
starting to bleed over a bit
into the connected devices
space and the consumer
devices space--
not just because the
device itself maybe
gets better, but
also the experiences
that come along with
it are getting better
because you can update those
mobile apps and these kinds
of things.
The next piece is actually,
probably, to some extent
the most important piece of
this, which is as connectivity
starts to come to devices
in the home, in the office,
and in these kinds
of places, with it
comes all of the security
and privacy considerations
that have dominated really
the rest of the digital age
all together.
And so devices now have to play
in the same security landscape
to some extent.
And user expectations
around security
and around privacy and
ownership of their data
becomes just as important
for these kinds of devices
and for consumer
electronics as it really
has historically for computers
and for mobile devices
and these kinds of things.
And the last piece is a little
bit on the technical side
in addition to on the
consumer expectations side.
But there's really an increased
expectation that these devices
can actually update.
Historically, devices,
once they hit the shelves,
were really frozen in time.
You bring a device
home and you can
tell what year a
kitchen was last
remodeled just by taking a
quick look at the devices in it.
But we can't really
get continuous updates
and continuous improvements
to the experience
if there's not an ability to
update these kinds of devices.
And more importantly,
devices can't
sit in the home for two
years, five years, 10 years,
and continue to be secure
with the constantly
evolving security
landscape of the web
if they're not updatable.
And so there's an
increasing expectation
and reliance on these devices
to be updatable over the air.
So this is just
again some context
of some of what we're
seeing looking out
over the expectations
landscape from the consumer
perspective that help to inform
some parts of what you're
going to see with regards
to Brillo and Weave.
So with that, let's go into
a little bit on what Weave is
as well as the experiences
that are a part of Weave.
And then we'll lead right into
some of the components that
are available for developers
because that's really
the most important part here.
And there will be several more
talks over the course of today
as well as tomorrow getting
into not only specifics
of the developer experience
for parts of these,
but also around
the actual code lab
so that you can
get your feet wet
and try to play around
with a lot of this.
So the best way to
think of Weave, I think,
is as an
application-layer protocol
that tries to include
a number of pieces that
are fairly integral to
this kind of experience
of building a connected device.
These include turkey support
for things like device discovery
over a number of
different transports,
for things like authentication
against devices,
and more importantly in some
situations authorization
for who or what has
access to those devices.
It includes provisioning
and the ability
to get a device set
up out of the box.
And to go from out
of box to ready
to use as quickly as possible
and as easily as possible.
And it also includes
realtime communication
in both directions
to try to make sure
that if a client
application or a service
wants to tell a device you
need to do this thing now,
the device knows as
quickly as possible that it
needs to do that.
And likewise in the
opposite direction,
if the device's state updates,
if the status of that device
changes-- I'm now broken,
the temperature has changed,
any of these kinds of
things-- it's important
that they be able to notify
applications and services that
are subscribed to that state
as quickly as possible.
So this enables a variety of
different kind of experiences
that we're trying to make
sure are built on top of this
and to make sure are easily
accessible to the user.
The first and one of the
more important ones of those
is around the device
setup experience.
So one of the things we found as
we are talking to manufacturers
is that actually this
is where a lot of users
fall off the connectivity train.
A lot of these devices
have different ways
of setting up the device.
Again it's still a combination
of directional keys
on the top of the device or
some combination of those
in an application that you
have to find in the store
and make sure you pick the
right one with the right name
and then download and install
and all this kind of stuff
and it gets very cumbersome.
And then on top of that,
the user frequently
needs to remember
their Wi-Fi network
password and a lot
of other details
that then just makes this
a very difficult process.
So talking to
manufacturers, we actually
found that this creates
a lot of support volume
and that this creates
a lot of user confusion
that ultimately leads to people
not using the advanced features
of their devices.
So what we tried to do was just
bake this directly into Weave
and to make it a simple
easy consistent experience
for users out of the box.
You can see the kind of
parts of this experience
here on Android.
Without the user needing
to install an app,
without the user needing
to go and find anything
to begin with, they
can just come directly
to this experience, find
the devices around them
that are available to set
up, choose the network
that they want to get
that device onto if it's
a Wi-Fi connected device.
And importantly
there on Android,
we're actually able to-- if
that mobile device has connected
to the network before-- just
pull the network password
directly from the system
with the user permission
to make sure that the
user doesn't have to go
and hunt down the little
notebooks where they wrote down
their Wi-Fi password two
years ago or things like this.
And then take the
user to a place
where they can basically
choose an account
if they want to control
authenticated access
to this device.
And then just get the
app and go directly
into the experience that
came with the device.
So really the aim
here is out of box
to ready to use in
less than a minute.
And we're trying to make
sure that that's also
a very consistent simple
experience so that users
don't have to re-learn it every
time they get a new device.
As long as they pick up one
of these devices in the store
they should know
exactly what to expect
in terms of getting it
set up and ready to go.
There's a few other
parts of the experience
that we also consider to
be very important to kind
of align this protocol
around, the first of which
is being able to share
access to these devices.
So mobile devices today
are very one-to-one.
It's really a personal device.
And although you may have
lots of accounts on it,
oftentimes all of
those accounts are you.
And in very limited
cases they're
shared between a number
of different people.
These devices typically
live in our homes
and office spaces which are
very much shared spaces.
And as a result, being
able to say something like,
"This is my family.
I trust them.
They all have access
to this thing"
is a very important
capability to have.
And likewise, being able
to say, "These people
are not my family.
I do not trust them.
They are my tenants
and they should not
be able to control these things
and change the cost of washing
machines and dryers.
But they should be
able to see them
and to see whether or not
they're currently in use
so that they can decide when
to go down to the laundry."
That's also equally important.
So we've tried to make sure
that from the ground up,
these devices are sharable and
that it's very easy to users
to grant access at different
levels to different people.
The next part of
this that's important
is making sure that this
protocol-- and especially
for that bi-directional
communication--
is fast and secure.
Security, obviously, is
a fairly important piece
on any transport.
And that has to be
taken care of as well
in a privacy-centric fashion.
The other side of
it, though, is speed.
A lot of people today, when
they flip a light switch
or when they tell their
microwave to turn off
or these kinds of things,
expect instantaneous response.
They expect the devices
to do what they say
and to do it immediately.
Once you get into connectivity
and into a variety
of different
wireless transports,
that starts to become
a higher bar to hit.
And so part of what
we've tried to do
is we've tried to layer Weave
on top of both the local network
and remote hops
through the cloud
and adding additional
transports as we go along
to try to make sure that we can
always pick the fastest route
to get a message to the device.
So if your phone is
on 4G, and your light
is on the local Wi-Fi
network, or on BLE,
or in this case on
the Wi-Fi network,
then the message would take
a trip through the cloud
and we'd get there as
quickly as possible.
But if your phone is on
the local network as well,
that message shouldn't
bother going to the cloud.
It should just go
directly to the light.
And it should go as
quickly as possible
to make sure the user feels
no noticeable delay there.
So that's part of what we
mean by fast communication.
The second piece of that
that's important to us
is consumers shouldn't
have to know that.
And they shouldn't have
to understand that.
So you may have a variety of
different wireless protocols
being used in your home.
You shouldn't need to know
anything about them in order
to use these things.
And all of this should be
transparent to the user.
The other half of that
is that over time we're
hoping to make this relatively
transparent to the application
and the service developer
as well because learning
the different APIs for
every different operating
system and platform
you're building on,
for controlling the Bluetooth
radio or Wi-Fi or any
of these kinds of
things, is a chore that
really shouldn't be necessary.
So we want to make it
as easy as possible
for you to say, "Take this
command, send it to this light,
find the best way
to get it there."
And that's something
that we're trying
to bake into the
different client libraries
that we make available as well.
The last piece, or not
quite the last piece,
but one of the other
important pieces,
of the consumer experience that
we feel is fairly important
here is that users actually
have a choice in applications
and experiences.
So one of the things
that we've noticed--
and you've probably noticed,
too, with Google services
and applications-- is we can
build a fairly good experience
for about 80% of people.
And then what made that a
great experience for them
makes it not such a stellar
experience for another 20%.
The things that make
it good for some people
don't make it so
swell for others.
And so it's important to us
as we're building out this
platform that we acknowledge--
especially as you start to have
a variety of different
devices around you,
a variety of different
experiences--
that from the user perspective
there's not going to be
a one-size-fits-all solution.
And we're not going to build
a one-size-fits-all solution.
And manufacturers aren't going
to build a one-size-fits-all
solution.
There isn't going to
be that in this space.
And so we want to make sure
that this platform is very, very
open and allows
developers to build
all kinds of different,
rich experiences
that make sense for
different types of users
in different kinds of contexts.
So the one other piece
from the user perspective
that's important for
us and that we've
tried to make sure is
enabled by this protocol
is how to handle app
and service access.
So we talked a little
bit earlier about
granting users access, but what
does it mean once you actually
get access?
Does that mean
everything on your phone
can talk to these devices?
Does that mean if you grant
a particular application
access it gets full access
to all of your devices?
And the reality is there
are different devices
and different categories of
devices that are more privacy
sensitive or that are more
security sensitive or safety
sensitive.
So just because you bought
a toy that's a lot of fun
and that you want to
use an application with
doesn't mean that application
should also get access
to your oven or to your
scanner if you happen to have
left tax documents on it.
So one of the things that we're
trying very hard to make sure
that we have
enabled through this
is the ability
for a user-- well,
for an app developer
to start-- to be
able to say these are
the types of devices
I can work with, these
are the types of things
I need to be able to
do with these devices,
and then for the
user to easily grant
that access without
over-granting
a lot of additional access that
the application really doesn't
need and that the user
shouldn't really need
to trust that application with.
So this is another side of the
access controls and permissions
piece of it.
So going into the
components a little bit
of what comprises Weave across
the board, the first and one
of the key pieces is the
Weave service as a whole.
So by this I mean the
Weave cloud service.
We've built out a service that
users can register devices
to that basically
provides that cloud hop.
It provides a set
of rest APIs that
make it very easy for
web app developers
and for web apps and services
to interact with devices
and be part of this ecosystem.
It also provides that cloud hop
when a user is on their phone
and they're on a different
network than the device,
or when the user is not at home,
but they want to double check
that everything's going well.
These kinds of things go
through this cloud service.
And there's a flip
side to this that I
think is very
important to mention,
which is this cloud service
allows remote access,
but the user doesn't
have to use it.
So the user always
has the choice,
and you might have seen
that during the set up flow,
of whether or not to associate
any kind of account with this,
and whether or not to enable
any kind of remote access
to their device.
And if they choose
not to, that's fine.
All of these
applications will still
work in the local environment
without any modification.
So this is one of
the things that we
feel is very important here.
The user should
always have the choice
of whether or not to associate
their device with the cloud
and have that type
of remote access.
So that's the cloud
side of things.
On the device side, naturally
implementing this kind
protocol, especially with all
of the security considerations
and everything across
different transports
is a little bit of a mess.
And so we've tried to take
on as much of that work
as we can from the
Google perspective.
And we've built out a portable
C++ library that can be taken
into devices and used to
enable them with Weave.
We've tried to slim out
as many things that we can
that might already be
on an embedded system
to make sure that we're not
adding unnecessary resource
usage.
And in order to do
that, we've also
provided several
wrappers that make
it easy to integrate this
library onto common systems.
And so naturally,
Brillo is one of those.
There's an Ubuntu
wrapper available
and we'll be adding additional
wrappers for additional system
types as time goes on
to make it easy to build
that kind of thing into
the devices themselves
and to make it easy for OEMs
to build those experiences out.
The next piece of this beyond
the cloud and the device side
is naturally the client.
And by client here, I mean not
just mobile client applications
or desktop client applications
but also web applications.
This is an area that, of
course, is critically important
if we want to have an
ecosystem of these things.
And so on Android,
as I mentioned,
we've built the setup
directly into Play services
to make it easy for users to
get started even without an app.
And that goes back
to Gingerbread.
We also provide
an implementation
of the full protocol there
that your client application
or Android application
can call into in order
to discover devices,
send commands
to devices, query state updates,
and these kinds of things.
The other side of
this is, of course,
iOS, which is very
critical as well.
People use a lot of different
phones in their homes,
and sometimes the same
user has multiple.
But other times different
users in the home
have different mobile devices.
And so it's important we provide
all of that same functionality
for iOS.
So there, the setup
flow is built directly
into the client
applications since we
can't build it into the system.
And similarly, you get
all of the same access
to discovering devices,
interacting with devices,
subscribing to updates, et
cetera from iOS applications.
And the last side is, of course,
web applications and services.
And we're actually very
excited about the potential
for new applications
and services
to interact with a variety
of devices to be built.
So similar to other Google
APIs and web services,
we've created a variety of
different client libraries
for use in a variety
of different languages
since there's such a diversity
of frameworks and languages
in use in building
out web applications.
Users on desktop can
still set up devices.
There's a Chrome app
available for that.
But we anticipate
most of those users
will be using mobile
phones to do that.
The other couple of
things that we provide
are a few things in the
area of developer tools.
So we'll have a couple of other
conversations about this later.
One of these is the command
line tool which basically just
allows you to register devices,
send commands, query updates,
and these kinds of things
from the command line
either over the local
network or remotely.
And this makes it very easy
to start testing things out,
and further to start building
automation and especially test
automation from more popular
environments for that.
The second piece, which actually
we're very excited about
and you'll hear her a little bit
more from Lawrence and from Sam
later today, is the
Weave developer console.
And this both allows you
to easily prototype devices
before you've even built a
client application for them,
to start registering them,
testing them out, sending
commands, seeing the
state in real time,
these kinds of things.
And it also provides
several features
around fleet
management that we hope
will lead to more of that
continuous improvement
that we talked about earlier.
So in particular,
these are things
like access to
aggregated metrics
and about how the
fleet of devices
is being used to let you
understand what features are
popular and what
features are unpopular,
and whether you have
crashes going on,
and these kinds of things
so that you can improve
your devices over time.
And then on top, of
that, as I mentioned,
over-the-air updates
are very important.
Again we'll get into this
more a little bit later.
But we're trying to make that
very easy from this developer
console as well.
The last piece that
I want to talk about
from the Weave
development side is
interoperability and schemas.
So everything that I've said
so far during this presentation
has made it sound like we're
building a wonderful platform
for building new
silos on top of.
And everyone knows that
what the world really
needs right now is more silos
of individual app experiences
because we all really want to
have one app for every device
we bring into our home.
We've tried, from a
protocol standpoint,
to build in interoperability
at a very core
layer of all of this.
And we've tried to
make sure that you
won't end up in
that situation where
you have one app per device.
And part of what we're
doing for that is we're
working very closely with
all of the manufacturers
that we work with to build
schemas that represent
a device's capabilities and that
represent the types of states
and commands that a device needs
to use so that we can provide
a stable interface
to those devices,
to developers on the other
side, application developers,
and service developers.
So then when you get
access to a light,
you know that based on
the schema for that,
you will always find an
ability to turn the light on
and off for every light
that you have access to.
You'll find that some lights
are dimmable and some aren't.
But because of
Weave certification,
if the light can be dimmed,
you will have access to it.
And you'll have
access in a stable way
so that you understand exactly
how to do in that light.
There's a flip
side to these kinds
of schemas and
interoperability, which
is that if we're
not careful, we'll
end up boxing devices into
the types of functionality
they have today and
basically ensure
that that's the only
functionality they can ever
have.
So another part of how
we've addressed schemas
is ensuring that
they're extensible
both in terms of capabilities
for very popular device types
as well as in adding new
capabilities entirely
that aren't related to
current device types.
So manufacturers can add
new differentiating features
and come up with improved
ways to do things
that are outside of
the current schemas
as long as they're not blocking
off the core functionality
to you to use the typical core
functionality of that type
of device.
So this allows these
devices to continue
to evolve, for more
interesting and exciting things
to be added to the ecosystem
of devices over time
without cutting off the
interoperability piece.
And the certification program
keeps those things separate
and ensures that
core interoperable
devices are always consistent.
The one other thing
that I think it's worth
mentioning there is there
will be some device types
that are totally new.
There will be some device types
that aren't common in homes
and may not make sense for us
to define a schema yet for just
because it's very early days.
And so for communities
that are trying
to build those types of
devices, the schema format
does let you come up with
new commands and capabilities
and states, and you can have a
totally custom device, as long
as it's not of a type
that already is out there
and has a schema for it.
And so for communities
building new device types,
you can think of where maybe 3-D
printing was a few years ago.
Those communities can
come together and start
to agree upon a way to
represent this device
and can get interoperability
using these schemas
in their community even before
a proper schema has been
created as part of this system.
So we want to make sure that
this whole thing is very open
and extensible to that as well.
So with that, I'm going
to hand it off to Sam.
Sam is going to talk
to us a little bit more
about the Brillo side of things
and what we've built out there.
And then again, we'll
leave a few minutes
towards the end in case
you have any questions
so that we can answer those.
Thank you.
[APPLAUSE]
SAM BEDER: Thank you,
Andrew Hi, everyone.
My name is Sam Beder.
And I'm a product
manager on Brillo.
So today I'm going to
walk you through some
of the details of
Brillo and how we
can make the development
of your devices easier
and also make them
simpler to maintain.
So first, I want to talk
about what kind of devices
do we mean when we talk
about Brillo devices.
So one problem with
the internet of things
is that it means
everything to everyone.
And it means a lot to us, too.
But here is just one taxonomy
of how you can break up
the classes of devices
that we're talking about
with Brillo specifically.
One important thing to note
is that with Brillo, it's
not focusing on terminals.
And one reason for that
is that Google already
has other products such as
Android for Tablet, Chromecast,
Android TV, et cetera, that
are fixing a lot of problems
with terminals.
But there's this whole
class of other devices
where we think Brillo
is a perfect fit.
So there's the idea
of human augmentation
with wearable technologies.
There's robotics.
There's drones.
There's enchanted objects that
can power your smart home.
As you, as
developers, are trying
to build some of
these devices, we
want to make it as
easy as possible.
Before I go into the
details of Brillo,
I want to first break down a
few of the common developer
challenges that as
we're making Brillo
we want to make
sure that we solve.
So what are some of these
common developer challenges?
One major component that we
want to focus on is security.
Andrew already briefly
mentioned security.
But we think that any
IOT device needs to have
a really strong security story.
And the reason for
that is you need
to retain the trust of the user.
They need to trust that
they can use this device
and it will keep their
information private.
We think it's hugely
important also
because some of the
devices that are currently
in the marketplace
don't necessarily
have a strong enough story
with respect to security.
And so this is a really big deal
because if your device isn't
prepared for any
potential security flaw,
you need to have a plan before
the flaw comes into place.
Once the news story
comes out about this flaw
you only have a day
to make this change.
You can't have it rolling
out over the coming months.
So this is a really big deal.
And we think that for IOT to
be successful in the long term,
this needs to be stronger in
every device that's out there.
So what's the next common
developer challenge?
Not only does this
device that you
make need to be constantly
connected and secure,
but it needs to actually be
delivering additional value
to your users.
So both your company
and the end user
are going to expect
additional functionality,
additional features,
and new information
that they can get
from these devices.
Next is staying competitive.
So when you make
these IOT devices,
they need to be secure, have
new features, and everything,
but at the same time, you
can't be increasing the cost
of this device by very much.
In order to be successful
in the marketplace,
the cost of these
IOT devices needs
to be the same or
a very small amount
more than the non-IOT
counterparts to this device.
Finally, you need to do
all these things at scale.
So we think Brillo
is a perfect fit
to address all these challenges.
So what is Brillo?
What is Brillo?
Brillo is an Android-based
operating system that
has built-in support for Weave.
Because Brillo is Android-based,
if your chip vendor already
supports Android, then
they can support Brillo.
And this allows for
a greater ecosystem
of compatible
development hardware.
It also allows you, if you need
to switch which hardware using,
it's much easier with
Brillo because there
are a lot of options out there.
Next there's a Brillo
developer kit, or BDK,
that we give you to make your
development process easier
within Brillo and allows you to
configure your operating system
and build a device image.
You can change anything
about the device image
since you're
building from source.
So we're really not going
to stand in your way
with anything you want
to do with your device.
Finally, there's
a set of features,
such as updates, metrics,
and crash reporting,
to continue interacting
with your device
once it's already been launched.
Now let's go through all
these in a little more detail,
starting with what it means for
a Brillo to be Android-based.
So Brillo is based on just the
lower level layers of Android.
What this means is
that it is based
on the non-Java native
layers of Android.
And it's a stripped-down
version of Android
that is specifically made for
connected embedded devices.
Brillo also has this
well-defined board support
package and product concepts
that make your device much more
maintainable.
So because the board
support package
is completely separated
from your product code
you can update
each independently.
This also makes it much more
easy to plug in a new BSP
if you ever want to.
We also focused on making
Brillo really modularized.
What this means is
that, say, for example,
your device has no
need for graphics.
You can take out all
the graphics components.
And this will make your
end device much slimmer.
And the end product
will be cheaper,
which, as we mentioned,
is really important.
Also, all of Brillo
is open source
and developed in the
Android open source project.
It's there right now.
It's totally transparent,
exactly what's
going into Brillo.
You can go check it out.
So these are all features
that you get because Brillo
is Android-based.
Next I want to talk about
security because we also
worked really hard
on making sure
that we have a strong
security story with Brillo.
So Brillo has a verified
boot architecture
that can be used to check
all executable code.
This verified boot
architecture helps
ensure that the image
you put on the device
is the same image that runs.
Brillo also has software
fault isolation by default.
So all the Brillo-built
services are
sandboxed and de-privileged.
And you have the
capability of making it
so that your devices
run in the same way.
This makes sure that if
there is a problem in one
of the components
of your device,
it won't make it so it's a
problem in the whole device.
Sooner or later, there
might be a security problem
with your device.
And for that, Google provides
ongoing security fixes
with supported releases.
We also have our
updates go all the way
down through the
firmware and boot loader
so that when we provide
fixes to these devices,
it'll completely
fix the problem.
It will go through
the whole device.
So this is our
story for security.
We have another
talk specifically
on security because we
think this is a really
important for any IOT device.
And next I want to talk
about the Brillo developer
kit or BDK.
So Brillo provides
a number of tools
that will make your actual
development process easier.
Brill has standard embedded
development architecture
using adb and fastboot.
There's also this out-of-tree
and configuration model
where all of your code is
in your separate tree which
allows you to continue using
all of your existing development
tools and revision system.
And so it's entirely
in your own tree.
You control it completely.
But at the same time, you build
the device image from source.
So if there is a specific
kernel configuration
that you want to change,
you have that capability.
And for those who know Android
development a little already,
there's some other
native development tools
that we provide that make
your life a little easier.
Brillo uses Binder.
And so we give you some C++ AIDL
generation that you can use.
There's also Init and security
configuration and unit
and integration testing.
So these are all ways
that make the development
process within Brillo easier.
But as I said before, once
you deploy your device,
you may want to
continue improving it.
And so for that,
there's updates.
So with Brillo, you
can send updates
to some or all of your
devices over the internet.
This allows you to continue
improving your device
and fixing bugs after launch.
It's built on the same
infrastructure as Android.
So it scales really well
to all your devices.
You can rest assured
that millions of devices
will be able to
update effectively.
Since these IOT
devices are constantly
connected to the
internet, you don't really
want to have these
updates interrupt
the flow of the devices.
And so to that end, we
have these updates download
in the background.
And you can control
when the device
reboots to apply the changes.
We also make sure that the
update payload and the image
are independently secured.
What this means is that
the download integrity
is maintained separately
from the image integrity.
So the payload integrity
is secured by Google
so that you know that you're
downloading the actual changes
that you pushed out.
And finally, the image
integrity is protected by you
with your private
key so you know
that what's running
on the device
is the change that you made.
So updates are one way to
interact with your device
once it's been in the field.
However, you're going to want
to also receive information
from these devices.
And to do that we have the
developer console and metrics
and crash reporting.
So with metrics and
crash reporting,
you can see with
your devices how they
are performing in the field.
So, for example,
let's say you have
a set of refrigerator motors.
And in this case, the
refrigerator motors
are using 10% more energy
than you would expect.
With this graph on
the left, you can
imagine this showing the
efficiency of these motors.
And you can see right
there, really immediately,
that they're using more
energy than you would think.
There's also crash
reporting data
that you can see
for any things that
are failing about the motor.
So these tools we
think are really
useful to quickly iterate on
bugs and improve the device.
Because of the update
tools I just mentioned,
if there is a problem,
you can provide a fix
and see the results in
the developer console.
And you can go back
and forth and iterate
to fix the problem much
quicker than before.
The alternative of waiting
for users to report an issue
or having to go into
the field yourself
costs more and is
just less effective.
All this data is aggregated
in a way that retains
privacy for the end user.
So all these features I
just mentioned-- security,
the Brillo developer
kit, updates, metrics,
and crash reporting-- are
made so that your development
process is easy.
But we realize that it's
also important to make sure
that the process of
taking your existing work
and bringing it to
Brillo is easy as well.
So for that I want
to touch on adoption.
We worked really hard
in Brillo to make sure
that it will exist well
in your existing workflow.
So because Brillo
is Android-based,
there is this wide set
of industry support.
So you can likely keep
your chip supplier.
In addition to that, if
you need to change hardware
because a different
set of hardware
will make your device
more effective or cheaper,
we make that really easy, too.
Secondly, most embedded devices
today are already built using C
and C++.
So you can likely keep
your language as well.
In addition to that, because of
this out-of-tree concept where
all of your code is
in a separate tree,
we're not going to
stay in your way
if you want to use a
different language.
Next, Brillo has wide
support for a large set
of third-party libraries.
So these facts
together make it so
that the process of bringing
your code into the Brillo
environment is as easy
as we can make it.
And so finally, I wanted to
go through a thought exercise.
Suppose that there
is a major security
vulnerability in a single
library in all of your IOT
devices.
And you need to fix it.
If this is a major
threat, you need
to get this fix out tomorrow,
not over the coming months.
So here's our task, patch this
newly discovered vulnerability
in a single library of all of
your company's IOT devices.
As you're frantically
looking for how to fix this,
some of these questions might
be running through your head.
Do you know if all
of your devices
are running the same
version of the library?
Do you know if the
patch is compatible
with the other system
software on the device?
Do you know if
your Linux provider
has given you the patch?
Or do you have to
do it manually?
Next, once you
have this fix, how
are you going to push it
to all of your devices?
And finally, even after you push
it to your devices, how will
you know if it's working?
With Brillo we make answering
these questions really easy.
Once a vulnerability
becomes known,
Google can identify and
quickly generate a fix.
All you need to do is
download the new BDK,
press Make, generate the new
firmware, and push it out.
The staged rollouts
will kick in.
And you'll see it in
the developer console
as the patch is being
adopted by our users.
So this process for this very
real threat that could happen
becomes really simple with
all of the tools and features
that I just mentioned.
So I'm going to leave you
with our call to action.
Everyone here at
this conference now
has access to the Brillo
and Weave developer sites.
You can go on those sites,
go and download the BDK,
start running through
the code labs.
We have a large set
of code labs that
can get you started making
your device, trying an idea.
And we also have many
other talks today
that can go into more detail
about some of the things
that I mentioned.
We also have demos later today.
And we'll have some time right
now to answer your questions.
Thank you.
[APPLAUSE]
So Andrew can come
back out here.
As we mentioned before,
there's two mics
down here and then one mic in
the balcony that you can use.
So there's the mics there.
ANDREW WARREN: The one
complicating factor
is we can barely see
mics, so if we don't catch
you off-hand, wave really fast.
AUDIENCE: [INAUDIBLE]
ANDREW WARREN: So the question
was is there any invitation
necessary for using the BDK?
All of this is open source
and is available right now.
The documentation and everything
is still early access.
So you can't get access to
the documentation yet outside
of this conference.
Everyone in this conference
has access to this data.
AUDIENCE: OK.
Thank you.
ANDREW WARREN: Yes.
Is there a question over here?
SAM BEDER: No, I think
that was right here.
ANDREW WARREN: OK.
Thank you.
AUDIENCE: This
question's about Brillo.
If I've got a
connected device that
has a display screen
on it, is there
support for that in Brillo?
Or is that sort of
beyond its remit?
SAM BEDER: So the
question is, if you
have a device that
has a display screen,
is that supported by Brillo?
AUDIENCE: Yeah,
obviously, if you
put full Android on the device,
you get all the UI with it.
SAM BEDER: So I would say that
it's not the focus of Brillo,
but you can make anything
work really with Brillo.
And so since the product's
in your own tree,
there are capabilities
to have a display screen.
But that's really not the
focus of Brillo right now.
Brillo is improving over time.
And so as more and
more updates come out,
the capability for that
might become easier.
AUDIENCE: Thank you.
SAM BEDER: Thank you.
AUDIENCE: Hi.
So I'm just really excited to
add Weave support to my app.
I was just wondering
when do we expect
devices to start coming out for
being available to consumers?
Are there any available now?
Is it like a year or
six months or what?
ANDREW WARREN: Sure.
So around timelines for apps and
for hardware relating to Weave,
the general release
of Weave will be later
over the course of the
next quarter or so.
In terms of hardware, we're
expecting later this year
to have hardware out.
And since you have access
to the developer site
and to more information
about things,
you'll also have the
ability to check there
on the types of devices
we've built schemas around.
So you can figure
out what devices
you can start building
application experiences around
easily.
SAM BEDER: I think we have
someone in the balcony.
AUDIENCE: Yeah.
Are we restricted to any
particular cloud service
for using this?
ANDREW WARREN: So the
question is around
are you restricted to any
particular cloud service
to use Weave and presumably also
some of the Brillo services?
So in order to ensure
interoperability and the fact
that users always
are able to use
these devices from any
application they want,
devices do need to--
if they're certified
to use Weave-- need to be able
to register against the Weave
cloud.
In terms of building other
cloud services and web services
and these kinds of
things, we've tried
to make a very easy
developer experience
to tie those in so that they
can interact with these devices,
too.
And I think this is a similar
story for Brillo services.
So we provide a variety of
services out of the box.
You can always, of
course, bring along more
and add more to your device.
We've a question
here in the front.
Yes?
AUDIENCE: Does Weave also
handle the network management
[INAUDIBLE]
ANDREW WARREN: Yeah, so
the question was around
does Weave also handle
network management
and in particular cases where
the device may lose connection
to the network or
the user may need
to set it up to a new network--
AUDIENCE: [INAUDIBLE]
ANDREW WARREN: Sure.
And to discover devices on
the network from the client
perspective and these
types of things.
So the Weave library
for the device side does
need to be tied into the
network management stack
to do particular things
like handle provisioning
from the device side.
It also takes care of, if the
device falls off the network,
making itself available
to be brought back
on-- say, if a user changes the
network password or these kinds
of things.
But otherwise, there
can be other logic
on the device as well that's
handling the network stack.
From the client
application side,
the Weave SDKs for
Android and for iOS
does handle interfacing
with the system
for handling the protocol
over the different transports.
AUDIENCE: [INAUDIBLE]
ANDREW WARREN: Yeah, so
Weave isn't exclusive.
You can use other protocols
with these devices as well.
Absolutely.
Yes?
AUDIENCE: [INAUDIBLE]
ANDREW WARREN: The
list of devices,
by that do you mean
the schemas that
are available for
interacting with devices
or the developer boards, or--
AUDIENCE: [INAUDIBLE]
ANDREW WARREN: I see.
So the question is,
where does the user
maintain a list of all of
the different devices they
have access to and the
ability to control that.
So we provide a core UI that
users can use both on the web
as well as on Android for
finding the devices they have
access to and making sure
they have a fallback place
to control access
to those devices.
SAM BEDER: There's
someone at that mic.
AUDIENCE: A couple questions.
What are the supported
network interfaces for Weave?
And secondly, what
kind of consideration
is given for offline mode, when
devices go offline and come
back online?
ANDREW WARREN: Yeah.
So around network
interfaces used by Weave
and how do we handle offline.
So network interfaces,
Weave is currently available
over the local network as well
as through that cloud hop.
BLE support will be
coming relatively soon
over the course of
the next few months.
In terms of offline
capabilities, as I mentioned,
it's very important to
us that these devices
work as well even if the
user isn't registering them
with the cloud, even if the user
isn't going through the cloud.
And so the devices will continue
to work over the local network
just as well.
One of the things
that you won't see
quite in the set of software
that's available for you
as part of this early access
to folks at the conference
but that's actually
coming very soon
is the same layer of access
control over the local network
as you get through the cloud.
So the same ability to authorize
particular applications and not
others, to authorize particular
users and not others,
even when the device is offline,
to make sure that the user
even if their phone is offline
or their device is offline
is still able to get into
their home to use these things.
AUDIENCE: Do you maintain
the state of the devices
and cache them?
ANDREW WARREN: Yeah.
So we do cache the state
of the device cloud-side
for remote access.
The state of the device is
also easily discoverable
if you're local with the device
and you have access to it.
Question here on the side.
AUDIENCE: What kind
of security auditing
are you going to be doing before
a Brillo/Weave device goes out
with the name Brillo or Weave?
I mean not just are you
implementing the protocol
security, but also is a default
state relatively secure?
Or is it just really
easy for anybody
who wanders past your house
get access to you devices?
ANDREW WARREN: So
the question is
around what kinds
of auditing are
we doing to make sure
that devices that
have the Weave brand on it
or that are using Brillo
are secure out of the box.
And there's a couple of
different layers to that.
As you mentioned, certification
is a very important place
where we do a degree
of testing around
all of the different
kinds of issues
that we can from a
black box perspective
to ensure that this device isn't
susceptible to common security
issues.
A second part, part of the
schemas that we define,
is defining the minimum role
necessary for common types
of functionality with a device.
So as I mentioned,
there's different types
of access, different
levels of access,
that make sense for different
types of capabilities.
Each of those levels
of access should
be relevant to the type of
functionality on the device.
You may want to see whether
a scanner is on and off.
That doesn't mean you
should be able to see
what's sitting on
the documents scanner
and these kinds of things.
And so that's actually part
of the certification program
as well, testing
that default state
and making sure that
it actually implements
those minimum roles that are
defined as part of the schema.
AUDIENCE: Is it also
implementing different modes?
Or is it [INAUDIBLE]
SAM BEDER: Yes.
So the question
was is it also just
saying having a minimum rule for
a particularly sensitive state
like the lock state may be
too sensitive for anyone.
The roles go up to a fairly
high level, including
the owner of the device.
And so the way to handle that
is the minimal role is owner.
And, yes, that will be verified
as part of certification.
Saw the gentlman.
Yes?
AUDIENCE: [INAUDIBLE]
ANDREW WARREN: So the
question was around
if you have a home full of
Brillo and Weave devices,
and you have them all set up,
and they're all tied to you,
and then you move.
And then there's a couple
of implications of that.
How do you make sure that the
other person who's moved in
can't get access to your
kinds of data or things
you've done historically
with these devices--
AUDIENCE: [INAUDIBLE]
ANDREW WARREN: --and vice versa.
How does that new
person make sure
that you don't have the ability
to snoop on them and things
like this?
So these are great
questions, actually.
In the first case, the data is
again all tied to your account,
even if it's fully local
and you never associated it
with an account, it's tied to
the devices you used with it.
So that the new
person coming in isn't
going to be able to see
anything historical about how
these devices were used.
The flip case of how does that
person basically kick you out
of the home fully and make
sure that your devices aren't
spying on them or
doing things like
that-- all devices have to
have a way to reset them
if you have physical access.
AUDIENCE: [INAUDIBLE]
ANDREW WARREN: So there's
always going to be a way.
Now there's easier ways for
you to actually transition
to give that ownership to them.
At the moment, the
easiest way to do that
is simply to delete that
device and let it go back
into a provisional mode.
AUDIENCE: [INAUDIBLE]
ANDREW WARREN: At the moment
reprovisioning everything
is the best way to do it.
We're looking at ways to
handle ownership transfer,
but there's a lot of
security implications
that come with that, too.
AUDIENCE: Maybe a
related question
to what the gentleman asked.
So whenever today an end
user buys an Android phone,
they have to create a Google
account to use an Android
phone.
And whenever an OEM publishes
a newer version of Android,
the user accepts the
end user agreement
and updates the device to
a later version of Android.
So are we going to have
a similar model here
that everyone who will
use the end devices
will need to have
a Google account,
and they will have
new updates of Brillo
or Weave board support
package or application
through the OEM program?
Can the end user decide whether
they want to upgrade or not?
ANDREW WARREN: So I heard
two questions there.
SAM BEDER: So is the
main question can
the user decide whether
or not they're updating?
Did I understand that correctly?
AUDIENCE: First of all,
will the user have a log-in?
And second, does the
user decide to update
to the newer version of the
operating system as application
board?
ANDREW WARREN: So I can
at least answer partially
and then I think Sam can
probably give a little bit more
detail on the Brillo side.
The user doesn't have to
have a Google account to use
any of these things.
The user doesn't have to
associate for remote access
or any of that kind of thing.
And if they don't
have an account,
they should still be able to
use these devices in their home
without an issue.
In terms of the second
question of updates,
as part of the Weave
program, actually,
and the certification,
we're also
ensuring there is an
update mechanism in place
so that security fixes and
things like this can get out
to these devices.
And so at least from
the Weave perspective,
there has to be a
balance based on device
type of whether things
auto-update in the background
or whether or not
the user needs to be
there to actively authorize
something to the device.
Finding the right balance
between that friction
of the user and also
keeping things safe
is one of the things
that we're going
to be working with manufacturer
by manufacturer on to try
to make sure it works well.
SAM BEDER: And just to add,
with Brillo we are really
encouraging-- we're making
sure that we encourage
all developers of
products to push out
these updates, these security
fixes, and improvements
to their device.
And we're working
on the same balance
to figure out exactly how
to weigh forcing updates
versus just encouraging them.
ANDREW WARREN: I
think the preference
is to try to make sure that
auto-updates happen seamlessly
in the background
to some extent.
But in certain places that
can be disruptive to the user
experience.
And so we want to be
conscientious of that
and make sure that
that doesn't happen.
We've got a question
right over here.
AUDIENCE: [INAUDIBLE]
ANDREW WARREN: Sure.
So just to clarify,
the question was
around let's say you're
a manufacturer overseas
who's building a
particular device type.
Your government and
Google have a falling out
and agree to go separate ways.
Can you explain to me in
a little bit more detail
what that would entail?
AUDIENCE: [INAUDIBLE]
ANDREW WARREN: I see.
So the question is around would
Google cut off access for OEMs
within a particular country?
What happens if that happens?
What recourse does
the manufacturer have,
and these kinds of things?
I think this starts
to stray into some
of the legal territory
and that depends
on the context of what
exactly happens there.
I can say at the moment
there's no restriction
on these services outside
of embargoed countries
that US law dictates
Google can't act within.
So I would be surprised
if that were to happen,
but it would depend
on the particularities
of the circumstances.
We have a question
here in the back.
AUDIENCE: Yeah, to beat a dead
horse regarding caching device
information in the cloud, some
industries, due to compliance,
can't use-- well, they
have to use their own cloud
or their own private cloud are
their own old-fashioned LAN.
What's the situation there?
And then secondly,
somewhat related to that
but more on an OEM basis,
like compliance with things
like FIPS 140, certain
security protocols,
that's the only way certain
vendors can sell to, say,
certain federal government
institutions and what not.
What's the status there?
And related to
that, code signing.
How do you make sure the signing
is-- the integrity of that?
ANDREW WARREN: OK.
So the first part
of the question
is around different markets and
that particular device types
have certain requirements
from a regulatory standpoint
or from a certification
standpoint in terms of security
certifications or
potentially HIPAA
compliance or these kinds
of things as to where
they can store data.
The second part of the question
is around code signing.
I think you're mainly talking
about firmware updates
and things like
this, is that right?
AUDIENCE: Yes and maintaining
the integrity of it.
ANDREW WARREN: Right.
So just to talk to the
former a little bit,
naturally there are some
areas that Weave isn't
suitable for at the moment.
And that includes some things
like health care devices that
deal with HIPAA-compliant data.
It's going to be a
device by device type
kind of conversation there.
Over time, Google has
incorporated a variety
of different certifications
into its cloud infrastructure
for particular cases.
But it's a little bit nebulous
to try to talk to that right
now.
If you have a particular
device type in mind
or a particular set of
regulations in mind,
I'd be interested
in talking after.
Go ahead.
SAM BEDER: I think we're
just about out of time.
So I might just answer this and
then move on to the next talk.
Was there any part of the
question that I missed?
ANDREW WARREN: Specifically,
signing firmware updates
and software to
make sure that it
can't be interfered
with en route,
and that it's what was
meant for that device.
SAM BEDER: So we do take
measures to make sure
that the thing that is
going on in the device
is the same thing
that you pushed out.
So I think that
maybe the best advice
is we have a security
talk later today,
and by going to that I think
should answer your questions.
Or, if it doesn't, maybe
ask this question again,
and Paul will definitely
be able to answer it.
ANDREW WARREN: The
quick answer is there
will be signing of updates.
And Paul can probably go
into a little bit more detail
later today.
But that's definitely a part of
the auto-update infrastructure.
Cool.
SAM BEDER: OK?
All right.
Well, thank you very much.
ANDREW WARREN: Thank
you, guys, for your time.
[APPLAUSE]
[MUSIC PLAYING]
