Web vs. Native Mobile Apps: How to Choose the Right Approach (Cloud Next ’19)
Articles Blog

Web vs. Native Mobile Apps: How to Choose the Right Approach (Cloud Next ’19)

August 9, 2019

[MUSIC PLAYING] SEAN GINEVAN: Hi. My name’s Sean Ginevan. I work on a team here at Google
called Android Enterprise. Our team is responsible for the
business-to-business success of the Android platform. So if you’re an IT
organization like an HSBC or a Walmart or a
SAP, you’re often interacting with
folks on our team who are working
with partners that help you deploy those
devices, that help you build applications for those devices. Jon and myself work with
large enterprise ISVs as well, folks like Salesforce,
SAP, Manhattan Associates, ServiceNow, folks like that. But we find ourselves
being brought into a lot of conversations. It feels like that
right now we’re at this interesting
transition point where IT is being asked
to do more brand things. And as an example,
Jon and I were in a conversation with a
large retailer, and they said, hey, we really want
to go and optimize our consumer experience. And I told them, well
hey, you should probably be thinking about
building for the web– for a lot of different reasons
that we’ll talk about today. And then they said,
fantastic, and then we’ll use that for all of
our store associates. I said, whoa, whoa, whoa. Wait, wait. Not so fast. Let’s talk about what you want
to do for this project, what that means for running mobile
devices in the warehouse, and figure out which
technologies are going to be appropriate for you. And that’s what we want to get
out of today’s presentation. So let’s talk a little bit
about an overview of what we want to get out of
today’s presentation. What we really are
going to talk about is an overview of
web technologies as they apply
specifically to Android. We’ll touch a little bit
about other mobile platforms on the market as well. We’ll also talk about how
to think about building app experiences. So what are some of the design
and development considerations you want to think about when
building out web experiences specifically for mobile? And we’ll talk about some
considerations on trade-offs as you think about, on a
project-by-project basis, should I be building for the
web or building for native? This is not designed to
be a deep presentation about building for the web. It’s not designed to be
a presentation on how to implement service
workers, provide code level implementation for
PWA or for native. We’re also going to not
cover things like gray areas. There’s a lot of
initiatives around, how do I make apps
more discoverable? How do I make them
surface and search, things like Instant Apps on play. We’re not going
to talk about that as well because I
only have 50 minutes to get through the content. Thank you for
fixing the clicker. So we’ll start to frame out
this morning’s presentation with a little bit of a story. How many of you here
in the room traveled from outside of San Francisco
and needed a hotel in order to be able to attend Next? So most of you, about 2/3. So when you went
through that experience, the likelihood– this is
data from a talk McKinsey did back in 2018. They looked at some data around
how people in the travel sector were actually looking through
their purchase journeys. And what they found was
that’s 63% of those journeys so from, hey, I’m thinking
about traveling to Aruba, to actually getting my
plane tickets purchased, came from a mix of both mobile
and cross-device journeys. So what that meant is I likely
am on the train on my phone going, gosh, it would be
really great to go to Aruba. And then maybe I go through,
and I do some research. I pick that session
up on my desktop. I do a little bit more research. I start to narrow
down the hotels. Google doesn’t pay me enough,
so the five-star hotels get thrown out immediately. And I go back and forth until
I eventually go and make a purchasing decision. What they also found was
that 31% of those journeys came through search. So it’s not that I went directly
to travel.com or whatever website you choose– Google Flights, as an
example, or Google Maps to go buy a hotel– I went and used search to go
through and look for things like cheap flights to Aruba. Which hotels are best in Aruba? And I used that as a catalyst
to starting my purchase journey. 26% of those purchases
came from the mobile web. So that meant that somebody
in this cross-device journey was going through and
finishing that actual purchase on their phone. And this is really important
because it means that we really need to be optimizing
our experiences for a mix of different devices. We don’t necessarily know,
from the brand perspective, which particular
modality a person’s going to be using when
they actually go and enter into my site. And that is also likely
true for employee apps. We’re seeing a lot
of employees use a mix of mobile
devices and laptops to actually get their work done. And so it’s really
important, as we think about what tools are we
enabling our employees with, that we be enabling for both. Now, the web has changed a lot. Web pages used to
be super static. They used to load
everything at once. And for whatever reason,
back in the ’90s– I think mainly as developers
were like, oh, my gosh. If I add one more thing,
it’ll be that much better. Look, there’s a blink
tag, and I figured out how animations work. So let’s make things scroll
for inexplicable reasons– and overloaded the site. So this is actually an example
from Stack Overflow that they did for April Fools’. They actually redesigned
the entire site circa 1990. So the good news is that,
at least on the desktop web, things have changed a lot. We’re making sites
much more interactive. You can actually now run
Windows 2000 in a browser. I don’t know why you’d do that,
but it’s a really great example of WebAssembly. The challenge is that the
mobile web has traditionally been lackluster. A lot of brands,
many organizations, use the mobile web
as a place-holder, a static place-holder
to advertise the mobile app they’ve
built. And basically, there’s a link that says, visit
us on the App Store or visit us on Google Play. Or sometimes they’re not
particularly good at this game so they just they visit
us on the App Store, and it really infuriates
us Android users. And the challenge
there is that we know these patterns of
development behavior don’t work. The Google+ team, before
we wound down Google+, actually did an experiment,
and they added an advertisement to the Google+ app,
to plus.Google.com. So when you went on your mobile
phone to plus.Google.com, you saw this ad that’s up
here on the screen that says, get the app. And what they found in that
survey was that 69% of users abandoned the site entirely. They neither went to
the mobile website, nor did they actually go through
and download the application. Say what you will about
Google+ as a platform. I think this is indicative
of a broader user behavior. The activation energy to
download an application, particularly as a consumer
who’s not really attached to your brand, is high. I have to go to Play. I have to click Install. I have to wait. Then I have to sign
up for an account. And if I’ve never
heard of your brand before, why am I going to
go through all of that work? And so it’s really
important, I believe, to be thinking about at least
having much of my experience optimized for the mobile web. It doesn’t necessarily
mean abandon your mobile application. Spotify has actually gone
through this journey where they’ve said, hey, we want to
allow users to discover music. So if anybody has been
to BottleRock Napa Valley or other music
festivals, likely you get this custom
Spotify playlist that says it’s designed to get
you excited about the bands you’re going to go see. And it used to be you’d click
that link and it says, hi. Go download the Spotify app. And if your answer
is, what’s Spotify, you probably just abandon
that experience entirely. And so they’ve really seen
a high degree of conversions since opening Spotify up to the
web of people who are actually finding out about the service
through these other brand interactions, like music
festivals, like news articles, and the like. So we know that building for
the mobile web is important. So if we’re going to build
for a built better mobile web, what are some of the things
that we’re absolutely going to want to consider? One is around making our
web experience as engaging. That starts with UX and
really optimizing around the variety of form factors and
screens that the web presents. Not everything’s a phone. Not everything’s a tablet. Foldables are going to make this
even more confusing because it will be both in my pocket. And so we really want to make
sure that we’re making really dynamic UX experiences. We want to make our sites
engaging through things, potentially, like
hardware integration. So we’ll talk about
hardware in a minute– through push notifications,
so being able to go through and re-engage our users
that come to our site. Hey, I saw you liked this
pair of black slacks. They’re now 10% off, or
we now have them back in stock, which happens to me. And then credentials, being able
to go through and actually– if the user has
saved credentials, being able to reuse
those credentials or even potentially being
able to single sign-on through credential
stores like Google. Another consideration is
making the web installable. So if I, as a user,
have visited your brand, and I’m really showing a
high degree of engagement, how do I get them to come back? Now, one option may be, hey,
go download my mobile app. It really seems
like you like me. Another way is just
to say, hey, I’m going to add this web
experience to your home screen. And this experience
might not be everything that you want to do for
your mobile experience, but you’re bringing that
user into the experience, transition them
through, hey, I’m going to add this
to the home screen. Maybe with even more
engagement, I keep them there, or maybe I bring them
onto my mobile app. And so, in addition,
for those of you that are enterprise developers,
you can take web experiences and surface them through
Managed Google Play. Managed Google Play is a
version of the Play Store that’s available
for enterprises who want to distribute
internal applications out to their employees. And so you can create
basically your own private Play Store that distributes
native apps, and now you can distribute
web apps as well. We want to make
the sites reliable. For all the talk about 5G,
connectivity is not perfect. I read a stat recently
that roughly half of all connections on
the web are still coming from 3G devices or 3G networks. So we really need to be
thinking about performance optimization– which I guess
falls more in the fast bucket– but also, hey, I’m going
from London to Paris, and I go through a tunnel. I get back online, and I
go through a tunnel again. And I go back online, and
I’m on a tunnel again. This happened to
Jon and I recently because we were both in
France visiting customers. And I was not particularly
productive on those websites that didn’t know how to
optimize for offline. And then, finally, fast. So we really want to make sure
we’re optimizing performance. We know that low bandwidth, high
latency connections are still out there, and we want
to make sure that we’re optimizing for those. And we’ll talk about
some of that in a minute. One way to enable these
reliable experiences is through service workers. If you think about the
old way of doing the web, the old way is I would basically
have a server out there somewhere on the internet. My browser would go and
pop up, and it would download everything at once. That was fine. But as sites became more
complex and more interactive, it became really, really tricky
to go through and do everything at once. And so the idea
of service workers is that you can build out a
client site proxy in JavaScript and have a little agent
inside the browser that’s separate from the
DOM and separate from the main thread that
can do work on your behalf. Some of that work are things
like notification APIs that we’ll talk
about in a minute, push APIs, which allow you to
go and get push messages to go and do other things,
background synchronization, so you can go through and
start to go and paint the page and load additional
things in the background as the user starts to figure
out where they want to go. When we think about
the web, though, it’s great to have a bunch
of technical tools that are at our disposal. But one thing that I often
coach people about is you really want to build out
your UX to be dynamic. One way to do that is to use
a lot of the design patterns that are already in material. You can use things
like responsive grids and breakpoints to change the
UI as the screen size changes. Twitter, with Twitter Lite, has
done an excellent job of this where, as you go and
expand the screen, not only am I changing the
horizontal width of what’s being displayed, but as I
go from smartphone to tablet and out to desktop,
I’m actually uncovering additional functionality
and additional content because I now have
the additional screen real estate to do so. So you can see on
the right-hand side as the browser pane
goes and expands, Twitter actually goes
and says, hey, here’s who you should follow. Here’s trends in San Francisco,
in addition to the Twitter feed for Google Next 19. These design
patterns are not only relevant for the mobile web. These are also
design patterns are highly relevant for
native apps as well. Many of you are aware
that Android native apps can run on Chromebooks. And certainly Chromebooks–
if you’re designing for Chromebooks– need to be more
responsive, things like window resizing,
maximizing, and whatnot. It’s not particularly awesome
to be on your Chromebook and go, cool. A phone app. And it just looks
exactly like a phone app. You want to be
designing for both. One final thing about the web is
you can also design those apps and run those apps
in full screen. So you can actually have
your applications, your web applications, run almost as if
they were like a native app. Another way to think
about dynamic workflows is through hardware integration. So obviously,
cellular and Wi-Fi, those are going to be your base
connectivity mechanisms that are allowing you to go and
get content into the browser. But there’s a lot of other
hardware capabilities that come with building out
for PWA, things like GPS. Hey, I want to go
through and find what store locations
are near me or where something is in the mall. I can pop up my location and
provide some interactivity back to the user. Or potentially even
things like the camera for object recognition or
microphone for voice search. You have a lot of these hardware
capabilities at your disposal, whether you’re building for
the web or building for native. Jon will talk about in a
minute that this is not, obviously, the
totality of hardware that’s available on Android. And so you’ll need
to be thinking about the level of
hardware interactivity you have when deciding
which tool set you want to build for your projects. Push notifications
are a really great way to actually engage
with your users and actually get them to
re-engage with your website. One of the pieces of
guidance I give is, please don’t as soon as I hit
the site and say, hi, I’d like to subscribe you
to push notifications, because one, that’s
obnoxious, and two, I have not really shown a ton
of brand loyalty to you yet. You haven’t necessarily
earned the right to go through and
start sending me a bunch of additional
notifications. But if I’m– and Lancome
has actually done this on their site– shown a high degree
of interest on things, I’m actually navigating
through the site, I’m engaging with a lot
of different content, I can go and not only
ask for push notification but, more importantly,
emphasize what I’m going to get from
subscribing to those push notifications. So as an example,
I can emphasize– in the case of Lancome that,
hey, let me tell you what some of the best deals are. Let me tell you
about new products we’re going to bring
out for the season, and I’ll bring that
content to you right away. One of the things about
push notifications is, in Android,
when you subscribe to push notifications,
Android will wake you up in the background and actually
surface that push notification. In desktop, the browser
actually needs to be open or the browser
needs to be resonant in memory for those push
notifications to work. So the reliability of
those push notifications may change depending
on whether or not you’re designing on
desktop versus web. Credential Management also comes
up quite a bit from customers. And the good news is
that there’s really great APIs for the
web to handle things like Credential Management. So you can actually go
through and say, hey, surface out to the user. I know you’re
signing in locally. You’re not clicking
in sign with Google. You’re actually using local
account credentials to Acme, Inc. Do you want to
save these credentials? And Credential
Management allows you to save those into the browser. And in cases like
Chrome, you can actually save those credentials
across devices. So I can hop between my
Android device, my Chromebook, my Windows desktop. Why I would use
that, I don’t know. But I can go through and
have those credentials be stored across devices
not just across sessions. And you can decide
whether or not you want to store the entire
set of credentials, so username and password, or just
auto-fill username and have the user
type in password. Those decisions are up to you. The next is to create an
installable experience. Starbucks has done this
with their native– sorry. With their native. With their web-based
application for doing things like checking in Starbucks
rewards or going through and ordering lattes from
the local Starbucks. What the Add to Home Screen
prompt allows me to do is do just that, add that PWA
experience to my home screen. That allows the
web page to install much like a native
app and with things like an app menu in the apps
settings tray in Android. It adds, obviously, home
screen icons and the like. But again, you really
want to be triggering this prompt at a meaningful
moment for the user. I don’t necessarily want
to install the Starbucks experience the first time
I go to Starbucks.com. I might want to install the
Starbucks experience when I’ve successfully ordered
something or I’m checking my account or at
least I’ve logged in and saved credentials, because
the likelihood that I’ll want to come back to
that is much higher. I mentioned Managed Google Play. You can also surface
PWAs for your brand into Google Play itself. So if you’re
entirely on the web, you can actually publish
these web experiences both for employees as well as
for the consumer Play Store. When you’re distributing these
applications through Managed Play, you can decide both who
you want these applications to go to in your install base. So you can decide, hey, this
is a financial workflow app. Don’t publish it to
the entire company. Only publish it out to
the people in finance. And you don’t have to be a
G Suite customer to do that. There are tools out there where
you can federate Managed Google Play to your existing Active
Directory or other LDAP data store so you don’t have to go
and create a G Suite domain or create Gmail
accounts for every user inside of your organization. And as you go and create the App
Store listings for your users, you can decide how you want
that application to render. Do you want it to
render like a website and so show things like the
toolbar and the address bar? Do you want it to be more
of a minimal experience so users can
differentiate when they’re in a native app versus
when they’re in the web, or do you want to just have
it be a full-screen experience and feel much more like
a native application? You can publish these
applications out by a few different mechanisms. Certainly, you can publish
to the Play Console. But a couple of new mechanisms
we’ve recently introduced are custom publishing APIs,
which allow you to basically script a lot of
application management to Managed Play as well as
the Managed Play iframes. So for those of you that have
a mobility management system, you can now control Play
directly from your EMM. Who here has seen
this screen before? Now, I love when I
go offline because it means I get to go and
play the dinosaur game and figure out whether or
not I can beat my high score. And from this animation, I’m
not particularly good at it. But the point here is is
that as much as I might love this level of
interactivity, it’s not necessarily great for
your brand experience. It’s not going to help me
continue to research hotels. It’s not going to help me
figure out whether or not I want to go purchase something. So as designers and
developers, we really want to try and limit the
amount of offline messages that we give out
to the end user, potentially even have
quite a bit of workflow available even while
that user is offline. So one thing you can do– and this is both a
performance benefit as well as an offline benefit– is cache certain parts of your
site locally into the browser. That allows you to go
through and allows the user to have some degree
of interactivity and continue to browse
inside of your web app without necessarily
having to be online. More importantly,
you can go through– and this is super useful in
workflow-based applications. So imagine if you’re an airline. I don’t necessarily need to be
online to go get my boarding pass or to go look up my trip
itinerary or know what gate– I guess I– gates
change, but the idea here is that I can surface the
last known information about my flight without having
to necessarily be online. That’s super useful for
traveling internationally, by the way. But certainly also,
you want to allow users to continue
to use the site and alert them when
they’re offline. So pop open, and say, hey,
you’re offline right now. This is an example from trivago. You’re offline right now. I’m going to go and display what
I can, and you can reconnect. Or maybe you start
to go and start a workflow cache
in the background and resume it when the
user comes back online. And we know that in
addition to offline support, performance is
absolutely critical. There’s a recent study
from Accenture and Google looking at users
in Asia-Pacific. 53% of mobile visits
were likely to be abandoned if load times were
greater than three seconds. 20% of drop in conversions were
found for every second of delay in a mobile website. So in other words, if you
don’t have really fast sites, people won’t actually go
through your experience, and they won’t buy stuff. So we want to go
through and make sure that we use caching for
speed and reliability, speed up the load time
for returning visitors, ensure a consistent fast
experience, and also, again, lay that foundation
for offline experience. We also want to use
things like lazy loading. And lazy loading allows
you to go through and start to render the first
parts of the page but also work in the background
to go through and load things that don’t necessarily need
to be up there and up in front of the user in order for that
first piece of interactivity. This is actually an
example from Tinder where they were going
through and looking at how their site
was built, and they found they were
loading a lot of images from places like Facebook
and other places and the user hadn’t logged in yet. So what’s the point of
pre-loading all this content if the user hasn’t logged in
and hasn’t created a Tinder account? So you can go through and say,
hey, login or create account, and be in the background
loading all these images so the user has
a fast experience once they’ve gotten
through that first gate. Performance budgets are
another way to do this. You can go through and set
milestones to make sure that technical debt doesn’t
increase in your site and you don’t go and
degrade the experience as new features get
implemented over time. Just some milestones that
you might think about– these are actually from web.dev,
and given the Accenture data, I might say three
seconds instead of five for time to interactive. You can also look at things
like the size of the code that you’re having so
you can optimize that. But the milestones that you
really should be thinking about are First Contentful
Paint, which is basically when data starts to
be displayed into the browser. and then time to interactive. How quickly are loading that
site in order for the user to have a meaningful
interaction? Be using testing and
validation tools. We have things like
Lighthouse and web page calculate from Google that
can help you go through and optimize. But don’t just optimize once. This isn’t like
the rotisserie oven where you set it and forget it. You actually have to be doing
this as you go and re-release the site, or you can end up
with performance degradations. I’m going to skip that
slide because that’s not a particular useful slide. So let’s talk about this from
a case study perspective PWAs are great. They clearly offer
us a lot of benefit, but what does it look like
from an end-to-end experience? So this is actually
the trivago app again, just continuing with
our theme of travel. And you can see here,
when I go to trivago, I’m coming back as a user. It says, hey, would you
want us to go and add this to the home screen? So I can add trivago
out and come back to it. I type in San Francisco. I start to get my
wildly overpriced hotels here in the city because there’s
Next and two other conferences going on right now. And all of a sudden,
I’ve experienced a connectivity disruption,
which you can see actually here in the middle pane. And so you can see,
even though I’m– sorry. Here in the middle pane. So as I go through and I go
through that connectivity disruption, I can
still go through and browse through
the site, look at some amount of data that’s
been cached in the background. And then when I’ve reached
that limit of what’s been cached onto the
device, I go through and get a notification,
hey, you’re offline. Do you want to reconnect
and continue browsing? And obviously, when I
restore the connection, I can go out there
and buy my hotel. trivago’s also done
a really good job of optimizing their
web experience for native and mobile. So you can see that I’m getting
a very similar look and feel, whether I’m using this
on my Android device or whether I’m using
this on my Chromebook. So they know and I
think they understand this idea of multi-modality
interaction and the fact that I’m likely going to
go to trivago once, look at some stuff, go to trivago
again, look at some stuff. And the devices that
I do that with are going to vary, so
let’s make sure there’s a consistent
experience across them. In the trivago case, they’ve
seen a ton of benefit in migrating a lot of their
functionality to the web. They’ve so far launched across
33 languages and 55 countries. But more importantly, they saw
a 97% increase in click-outs to hotel offers when they
actually went and optimized for the web experience. So rather than telling the user,
hey, go download something. Go through lots of
additional steps in order to get into
trivago, they’re actually seeing people go
through a really elegant flow, and the users are then buying
at the end of that purchase. By going offline– and while
the data set is relatively small in the case study– they still saw a 67%
improvement in return visits to the site when there’s been
connectivity disruptions. So because they’re providing a
really interactive experience even when the user’s
offline, the user is willing to come
back or persist through the
connectivity disruption in order to go through and
engage with that brand. So we’re set. We’re all in for the web. Jon’s actually going to go and
talk a little bit about some of the challenges we’ve
seen with customers, particularly as they think
about enterprise app workflows. And why don’t I turn
the stage over to you to talk about native? JON MARKOFF: Hello? [INAUDIBLE] Thanks, Sean. So before we get started
here, when Sean first asked me to do
this talk with him, the first thought in my mind
was, this is a horrible idea. Web versus native
almost never goes well. There is always a
Twitter war or something that comes up from it. So I apologize in advance. I’m going to be as
objective as possible. A lot of people ask my
advice, and again, that’s why we’re doing this is
because people ask us so often, what do we build for? And obviously, the decision to
build for mobile or web really depends on what you’re
doing, and I never just say, oh, just because
I work on Android, you should always build
for Android or you should always build for native. So I would never say that. So just want to preamble
this section of the talk. So with that said, my
name is Jon Markoff. I lead developer relations
for Android Enterprise. And, as Sean mentioned, the
web has a lot of benefits and has a lot of great things. If you’re building native apps
in especially the enterprise space, there’s a
few other things you might want to
take into account. So if your app is going to store
a lot of information locally, web browsers,
especially in mobile, have more restrictions on
how much storage and data you can save offline. Chrome, for example,
you can save up to 6% of the free
space on the device whereas something
like Safari, you only get 50 megabytes total. So if your app is for
workers in a warehouse or delivering packages or
something like that, where you’re not going to have
connectivity all the time and you need to download a lot
of different things, especially if you are a service provider
or someone at a cable company fixing– and you need videos to be able
to understand and see different situations where you’re– you just need to have a
lot of space on the device. So if you’re downloading
videos, you’re downloading a lot of
local content for offline, the web might be a bit
challenging there for you, especially if your device
is lower-powered and doesn’t really come with
a lot of storage. So if you only have
four gigs of free space, you’re going to
have not too much with even Chrome in this case. So as Sean mentioned,
the web does give you a lot of [INAUDIBLE] hardware. But there’s a few things
that are different. So, for example,
NFC and attestation are two really large ones
that are missing from the web. You do have the ability
to use biometrics so you can authenticate
on the web. But if you want to do more
hardware-backed Android Keystore or crypto, you’ll
need to have a native app to access those features. And again, this is
just an overview of all the different web
browsers and the features that they support. So let’s talk about
native apps security. If you store files in
the local file system, who can access them? Ideally, only your user and
the person using the device. But what happens if
the device is stolen or if the device is
compromised in some way? How do you ensure that your data
is actually stored properly, especially in offline mode? With the web, you don’t
really have any options of how to change this
data because unless you do some sort of like JavaScript
crypto, which would not really be able to take advantage of the
Trusted Execution Environment on Android. So for data at rest– so if you
want to actually store files and you want to encrypt
them on the device– you can use the Android
Keystore with a native app to ensure that your
keys are never leaked and will never come
off the device. Your application cannot even
get the key material once it’s created. As a vendor at Oreo, we added
sensitive data protection. What this means
is, as a user, you must be using a phone
that’s been unlocked. So the key won’t be
available to the application if the device isn’t unlocked. And to add to this
even more, they also support biometric
authentication. So when you’re creating keys
with the Android Keystore you can actually set flags
to say, always require authentication. Have a timeout on
the authentication and require sensitive
data protection. So you could actually
have it require the user to be present for any time
the key’s even accessed, so depending on
the level of data that you’re working on here. With key attestation,
you can also ensure that your keys
haven’t been compromised and that they never
left the device. What about data in transit? What if I’m sending data? What if I’m calling
really sensitive services, and I need to make sure
that someone hasn’t injected a bad certificate? You can use OCSP, which is
the Online Certificate Status Protocol, which is built
into Android as of Nougat, which is Android 7. And that allows you to add
checks to actually ensure that you can talk to your
certificate authority and make sure that the
certificate is valid and it is what it says it is. One other thing you can do
as well is TLD verification. So that’s the top-level
domains and making sure that someone hasn’t created
a fake one or someone hasn’t tried to compromise the device. Protected Confirmation. We launched the Titan
Keys on Pixel devices, and we just announced
that we’re taking that to more devices as of yesterday
with Cloud and on Android. And Protected
Confirmation allows you to verify that
the transaction you’re trying to accomplish
is being executed by a actual person
on the device. So similar to a
YubiKey, if you use one to log in if you
have a corporate laptop, it basically make sure that
you are actually present, so someone’s not emulating or
stimulating your application in Android Studio
or other tools. And it provides the
fact that you’re there because if someone packet
sniffs your services, they can try to make
calls and replay calls. But with built-in
hardware in the device, you can’t fake that. SafetyNet. One other thing that
you can’t enforce when you’re building just
a pure web app on mobile is, how do I know if my
device has been rooted? How do I know if I’m actually
on a real Android device at all? Because you can rip
APKs from the web. You can rip them off your
phone and try to run them. You can deconstruct them
and figure out, how can I try to compromise this app? How can I try to replay and run
this app without doing that? SafetyNet allows you to
validate that you are actually on an actual device and
it’s a CTS-compliant device. That means that
Google knows about it, and it’s a device
that meets the test specifications of what we have. So someone just didn’t
build a random open source version of Android just to try
to compromise and run your app. As an example,
here’s what SafetyNet looks like after you call it. I’m not going to jump
into the code here, but just as an example,
the two last fields in this JSON signature
[INAUDIBLE] that come back are basicIntegrity,
which means has this device been rooted at
all, and ctsProfileMatch, which means that it’s
actually a device. And in more detail,
SafetyNet has a few steps that it takes, and
this is to ensure that one, you know that the
call is happening. You know what user’s is
actually calling the service, and then ensuring from
Google that I actually have a real response from SafetyNet. So to jump through
these really quick, the first thing
you’re going to do is you’re going to
generate a nonce, which is a one-time-use
token, and that should be tied to
whatever user is logged in through your application. And this is something
you save and make sure on your back-end
yourself that you know was only used
once and you know it’s tied to the correct person. In Android, you’d call the API
to attest that this device has not been rooted and to reach
out to Google to say, hey, do you know about this device? Has it been rooted? What’s going on here? You’re going to get back the
JSON web signature that I showed you earlier that
has a key signature and all the different fields that
you might want to look at, timestamps, APK, is
this compromised or not? And you need to send
this back to your server and check all these fields
just to make sure, hey, does this make sense? I just sent this. Does the time makes sense? Does the signature make sense? And you reach out
to Google to ask one last time, hey, by the
way, is this a real response? Does the signature match? If yes, that’s great. You’re fine. If not, then you know that
you can disable that user on your back-end as well. So that means that you know
that this user has been using a compromised device,
and you can block them from accessing any
services after that. One other thing as well that– you have some device management
with Chrome and web browsers on mobile, but you
have much more control over this with third-party
tools like EMMs which allow you to inject
settings into your application. So if you’re
building for the web, you would have to build in
all the different features. So if I wanted to have a
configurable application where I have different settings
based on different user types, you actually have to build
that into your web application. Or what you can do is, if you’re
using like a commercial EMM, you can inject settings
via managed config, which will configure each user’s
device from an admin console. So you don’t actually
have to write custom code to handle the
different situations, if that makes sense. Android. Not sure if everyone knows. There is a concept
of a work profile. So if your enterprise
or company supports bringing your own
device to work, you can install a
work profile, which is a separate container
on the device that allows you to basically separate
your work and personal life. It maintains privacy and it
will actually allows you to now you can turn it
off at night if you want to to not be getting
pings and work emails and everything all the time. And then on the corporate
side, if your company actually hands you a phone or
device, this device has a lot more features
that you can pull logs. There’s deep inspection. And it has full admin
visibility on everything that’s going on on it. So in these kinds of cases,
a lot more enterprises that are using– they use both, but for some
of the really specific use cases we’re talking about with
especially custom hardware, you probably have a
company-owned device. So here’s some
information on– we don’t go through
all these things, but if you’re building
for work profile, your application automatically
has to handle a few situations and scenarios. And this is important
because it allows you to run your app in a limited
privileged container, which it might not
necessarily be aware of. So a few things here. Not really going to go
over in super detail, but your app might not
act like it usually does. There’s going to be features
like the camera might not exist. You might not be
able to share things. You might not be able to save
files like you normally do. And you can’t handle
notifications in the same way. They work a little
bit differently in the work profile. So I mentioned Managed
Configurations earlier. Just to go through what
that flow looks like, when you’re building
an Android application, you’re going to define
like how it’s configurable. So let’s say I’m a email client. Well, you’re probably going to
have an email address, server, and depending on
that server type, you might have port and a
bunch of other information. So you’d generate a little
XML file, which defines, hey, I’m expecting an email
address, which is a string, and I’m expecting a
port, which is an end, and maybe know an address,
which is a string as well. And what that does is Play
automatically knows and reads that. So that gets injected
into Google Play, which talks to an EMM which says,
OK, this app has these settings to configure. So when they’re adding
from the EMM perspective or your admin is adding
a new phone or device, they would be able to set
those fields automatically. So you just start your
phone up and, oh, look. I know this is Jon. This is his email address. This is this. So I open the app and
it just works already. I don’t have to go try to figure
out what my email settings are, for example. Yeah, so that’s the
native side of things. We do have more resources. A couple things I didn’t mention
from a design perspective, and I mentioned that there’s
all the different browsers and challenges there. Obviously, also, there’s a lot
of different Android devices, a lot of different
Android versions. We launched Jetpack
two years ago at Google I/O, which is
a more holistic support library for Android. And that allows you
to more easily handle backwards compatibility. Yeah. So I think that’s it. I think we can– I’ll pass it back to
Sean, and then we’ll open it up for questions. SEAN GINEVAN: Yeah, absolutely. So thanks, Jon. I’m going to steal
the clicker back. JON MARKOFF: Yep. SEAN GINEVAN: So hopefully this
gives you a high-level overview of building for enterprise. I think what we often
coach folks on– and Jon brought this up at the
beginning of the presentation– this is not a religious war. At the end of the
day, what you’re building for needs to
depend on the projects that you’re actually building
inside of your organization. There are lots of cases
where building for the web is a really simple way
to get basic workflows into the hands of your users. It’s certainly, from a
brand and a B2C perspective, an absolutely critical way to
be engaging with your customers. But it’s not necessarily
the right technology, depending on what
types of workflows you’re building out
for your enterprise. So as Jon mentioned,
we have a ton of tools out there, whether you’re
trying to understand how to build out enterprise apps. Use some of the tools
that Jon had mentioned. Definitely encourage
you to go to those. [MUSIC PLAYING]

Leave a Reply

Your email address will not be published. Required fields are marked *