[MUSIC PLAYING]
CHRIS WILSON: I'm
going to introduce
the panel while they're
getting settled and everything.
But come on out.
Darren Fisher, VP of
Engineering for Chrome.
And by the way, some of
these may or may not be true.
Probably most of them are true.
But Paris Tabriz,
who her business card
reads Security Princess, which
I am most jealous of by the way.
Always have been.
Grace Kloba, Lead of the
Mobile Browsing team.
Thao Tran, my co-presenter
from this morning,
fellow cocktail aficionado,
and Head of Global Product
Partnerships for the web.
We are both looking forward to
the nitro cocktails by the way,
by this point.
Tal Oppenheimer, Product
Manager on Chrome for Android,
who makes sure Chrome and web
works well around the world.
Matt McNulty, who leads
the Developer Experience
team for Chrome, has
had to field complaints
about me spilling coffee on one
of his reports already today.
Alex Komoroske, who is one
of my two favorite Alexes.
And--
[LAUGHTER]
They're actually
not interchangeable.
See if I say that for
Alex Russell or not.
But Alex Komoroske is
the Group Program--
or Group Product Manager for
the Web Platform team in Chrome.
And finally, Alex Russell-- also
one of my two favorite Alexes.
This one's an engineer
in the Chrome team.
And he and I actually have
shared this enduring mission
in making the web a
first class platform.
We're super excited
about where we are today.
We worked together
longer than we've both
been at Google, which is
actually saying something
because I think we
both feel like we've
been at Google longer than
average, at the very least,
at this point.
And we first met when I worked
on the Internet Explorer team
and he was working
on Dojo Toolkit,
and he kept asking me really
pointed, hard questions.
But he was always like,
you were always so nice
about me asking
you hard questions.
And I was like, so were
you about asking them
in a nice way.
I had to give some
credit for that.
So we are using Slido
for the questions.
And I won't promise to take
all the questions in order.
But if you think of things,
whatever, file them there.
We actually are live moderating
them during the panel
and we may pick them
up and ask them.
So let's go to Slido.
And I, like I said, I won't
promise to take these in order.
In fact, I actually
want to start
with a different question,
which is, Where can I get dino
sweater that Mariko is wearing?
And so I kind of want Mariko
to answer that question
if she's available.
MARIKO KOSAKA: The
answer is you can't.
It's my handknit.
Not only-- not only the
sweater, I also have a beanie.
[LAUGHTER]
Presented here, which I gifted
to Alex Russell last Christmas.
Thank you for bringing this up.
ALEX RUSSELL: Should I wear it?
MARIKO KOSAKA: Yeah, sure.
CHRIS WILSON: Oh, sure.
ALEX RUSSELL: I
get to put it on.
MARIKO KOSAKA: So if
you want to get this,
I do have a pattern if you
want to knit it by yourself.
And also I gave one extra one
to one of the Chrome engineers.
So you should talk to engineers
and find out who has one
and be nice to them
and get one of them.
[LAUGHTER]
CHRIS WILSON: OK,
so you know, I have
to credit the number of
votes for this question.
So I think we're
going to start with,
Does Google see AMP as
a long-term solution
or a temporary patch for the
web's performance problems?
Is the goal a fast web
regardless of implementation
or is the goal AMP?
Anyone?
DARIN FISHER: You know, we
don't have the AMP team here
to speak to this, but I
think we can sort of talk
about how we've sort of--
we've been working with
the AMP team a lot on AMP.
And for sure we share
the goal of making
the web work a lot better,
especially the mobile web.
And performance is
absolutely a big part
of the motivation for AMP.
The way I look at it is--
that you know, the
question, the second part
of the question there,
is the goal a fast web--
absolutely.
The goal is a fast web.
And AMP is definitely
an enabler there.
We've seen people
have a lot of success
at building fast experiences.
And again, I think
this point was
made today, a couple
of times at least,
that AMP is really built
for web components.
It's built with
web technologies.
It's in many ways
giving people a lot
of guidance on how to create
a really fast experience.
But there's nothing
that keeps you
from creating a great
experience without AMP as well.
And I think we've seen
a lot of content today,
and you'll see more tomorrow
that can help you do that.
THAO TRAN: Yeah, and I
want to weigh in here.
And it's, the long-term
solution is a fast web.
That's like, that's really
what the long-term solution is
going to be.
And when we talk to a lot
of developers and partners,
it's really about making sure
that your performance is great,
making sure that you're taking
care of the overall user
experience.
And if folks want
to use AMP, if they
want to hand tune
their own site,
I think it's really
up to them, and I
think we really want
to just make sure
that we provide the right
set of tools and features,
and give developers and
partners a lot of options.
CHRIS WILSON: Cool.
Let's go to the next question.
Why was there not a
PWA summit this year?
An interesting one.
I mean--
PARISA TABRIZ: How am
I supposed to plan it?
ALEX KOMOROSKE:
Chris, is that you?
I forget.
PARISA TABRIZ: Chris,
why didn't you?
CHRIS WILSON: I'm
not a panelist.
I'm not a panelist.
I just ask the questions.
I mean, I think really because
I am in the developer relations
team, this is a conscious choice
that it's not just about PWAs.
And we talked about it
in our talk this morning.
This is really just
the modern web.
And the PWAs are
kind of just a way
of capturing that at a point.
And the whole focus
on installability,
it's super important for
users to have a quick entry.
But the web is
more than that too.
And what you need to do I think
is probably more than that.
ALEX KOMOROSKE:
And I think of it
the same way as I think
of Ajax back in the day
or responsive web design.
At the beginning
it's like oh, it's
a thing that means something.
And over time it just
becomes, well duh, right?
I feel like we're starting
to get to that point, which
is really cool to see.
CHRIS WILSON: OK, next, how--
sorry, this is taking
a second to update.
It's our new tool that
we're trying this year.
ALEX KOMOROSKE: Is it a PWA?
CHRIS WILSON: It actually,
it ranks really highly
in Lighthouse but not a
Progressive Web App yet.
We are going to fix that
though, so it's fine.
All right.
ALEX KOMOROSKE: It's missing
a manifest or a service
worker, not running on HTTPS?
CHRIS WILSON:
Manifest, manifest.
We don't need to
debug it on stage.
ALEX RUSSELL: We can run
Lighthouse on it if we--
ALEX KOMOROSKE:
You know, it's not
that hard to create a manifest.
CHRIS WILSON: I understand this.
I'm not going to create them
personally for everyone.
DARIN FISHER: I tried to make
it easy for people, you know.
CHRIS WILSON: I did point out
as moderator before the panel
that I don't actually
report in the same orgs.
None of these people
can get fired.
And someone on the panel
said, well not directly.
So anyhow, next question.
In August Mozilla and Facebook
submitted a JavaScript binary
AST proposal to ECMA TC-39,
reducing JS parse times
by 70% to 90%.
Is the Chrome team interested
in supporting a binary AST?
ALEX RUSSELL: So I guess
I'll take this one.
So we work very closely
with the performance team
at Facebook who have done an
incredible job at telling us
what we do wrong, which has
been really outstanding,
and helping us find
places to improve.
Binary AST is one way to maybe
cut down on the initial parse
time of loading large
JavaScript applications, which
of course Facebook is one of.
There are other ways that we
can improve the loading times
for applications that we
use a lot, like putting
the code that they're using
frequently inside the service
worker cache.
We've seen large gains
from that already
and we're very excited
about being more aggressive
about that.
The binary AST proposal has a
lot of long-term consequences,
not all of which we think
we understand entirely.
And so we're trying to
figure out the right way
to think about
improving parse time.
We're not sure that that's it.
But we are interested in
improving our performance
in that area.
But yeah, service worker
cache or JavaScript, do that.
CHRIS WILSON: Sorry these
are bouncing around a little.
All right, well let's
ask another fun one.
So Add-to-Homescreen
in Progressive Web Apps
has been great for creating
native-like user experiences.
When can we expect to
have this functionality
on desktop operating systems?
ALEX KOMOROSKE: I
think we actually
had Owen spoke earlier
today about this.
So this is something
that actually you can do.
You have been able
to do it for a while.
It's kind of buried,
but you can add an icon
to a site on your home
screen-- or on your desktop
I guess it's called on desktop.
And to be honest it's
one of the things--
what's cool about PWAs
is that in general
if you built these things
in a responsive way
they just kind of
work on desktop.
But it's not as clear
about what exactly
the user mental model
should be in that context.
On mobile it
launches full screen,
it just sort of takes
over the whole app.
But as Owen announced earlier
today in one of the talks,
this is an area that we're
actively investing in
and we're hoping to bring
something that will target
the space the next n months.
I don't know.
ALEX RUSSELL: Look for
it in Chrome flags.
ALEX KOMOROSKE: Yeah.
CHRIS WILSON: So, what would
you recommend using nowadays?
Sorry, would you
recommend nowadays
using ES6 directly or
transpiling to ES5?
ALEX RUSSELL: Where
are your users?
I mean if you've got an entirely
ES6 compatible user base,
please, by all means.
It will save you
bytes on the wire.
It'll save you a lot
of hassle, especially
if you're using web components,
because custom elements v1 does
integrate with the
native class syntax
and it's difficult
to do that otherwise.
Otherwise, transpile.
Look at your user base.
CHRIS WILSON: In
2013 the Chrome team
forked WebKit to build
the Blink engine.
Chrome now has a ton of
nifty features not available
on Safari, but
developers hesitate
to adopt those features because
they don't work in Safari.
How would today's web developers
be better and worse off
without the Blink fork?
ALEX KOMOROSKE: Wow.
That's a really
interesting one, huh?
And I really haven't thought, I
guess, about the counterfactual
of what would happen.
CHRIS WILSON: And I want to
hear better and worse by the way
because I can think of both.
[INTERPOSING VOICES]
ALEX KOMOROSKE: One
thing I will say
is I'm very proud of the
way the Blink community has
sort of evolved over the years.
We had our most recent BlinkOn
in Tokyo just a few weeks ago.
And it was huge.
We had a ton of people there.
We were maxing out the space.
And so it's been
really cool to see
lots of other companies come in
and participate and build off
of Chromium and participate
in Blink as well.
I think ultimately we
have goals of really
pushing the web as far as
we can as quickly as we can
and working with other browser
vendors and specification
bodies to decide how
to build these things.
It has allowed us, I think, to
move differently than maybe it
would have been had we still
been sharing a codebase,
per se.
But I'm not sure.
I don't know.
ALEX RUSSELL: I mean one
of the things you get out
of competition is competition.
And that's something
that we value heavily.
And one of the things that's
difficult about sharing
an open source code base is that
in order to get code landed,
everyone has to agree
through a single governance
system what should land.
Having separate
code bases let's us
take a different view of
what's most important,
and we compete on
different axes.
And it's easier for us to
compete with the Safari team
in a more full-on way,
which benefits everyone.
So we may go deliver
features that improve
performance in one aspect.
They'll work on features that
improve performance in another.
And then we have to go figure
out which is most important.
And that is a great
outcome I think.
ALEX KOMOROSKE: One extra--
OK.
DARIN FISHER: Sorry.
I was going to say that one of
the things that you might think
is worse is that you might
think that because there's two
that there's going to be
more incompatibilities
between the two.
Well, you know one
of the things that
informed our decision to
fork in the first place
was that we realized we were
actually already forked.
We ifdeffed the
heck out of WebKit.
And we were shipping
features that Apple didn't
feel comfortable shipping yet.
Because of this very
idea that we actually
wanted to really push and try
to bring some nifty features
to you developers, we
already were shipping things
they weren't shipping.
And so it's kind of like we
recognized what reality was
and we realized we should just
optimize for that reality.
And so that's really where we
were at that point in time.
We thought yes, we
should just fork.
ALEX KOMOROSKE: One
thing that I think
is worse is we talk a lot
of these kinds of events
about the big
flashy new features
that you can use as developers.
But in our day-to-day
lives, a lot of it
is what random little edge
cases worked differently
in different browsers.
And when we used to be
part of one codebase,
one change there would make
that behavior, the sort of edge
cases similar across
the different browsers.
And so actually we invest
quite a bit in this.
We don't just invest in
the cool flashy features
that we can talk
about on stage here.
We also have a bunch of folks--
we call this a
predictability effort--
that focus on
cross-browser testing
through web platform tests.
We also have folks that land
changes to other open source
rendering engines to help fix
some of those issues that cause
a lot of annoyance day to day.
And that's one thing that
requires active effort now
that wouldn't have if we
hadn't gone our separate ways.
CHRIS WILSON: I think
on the same vein
there's a question about if
there's any interest in having
several teams of
very smart people
who work on several rendering
engines at the same time.
Should we just cross-pollinate
between those browsers
or should we just build one
single browser that everyone
ends up using the engine from?
ALEX RUSSELL: Should we have
one JavaScript engine, right?
I mean as a former developer
I can say with confidence
that hell is other browsers.
It's very much the case
that your favorite browser
is your favorite browser
and compatibility
with anything else sucks.
It's just always going
to be hard to get that.
And that's one of
the unfortunate
aspects of competition.
But the benefit is that it means
that there isn't a monoculture.
If one browser engine
starts to get stagnant
and they don't continue
to lead, then it's
possible for someone else to
come in and do a better job.
And that's a huge
and valuable thing
that we've seen play
out multiple times,
hell, as long as I've
been working on the web.
Chris, you might have
some insight into that.
CHRIS WILSON: No comment.
ALEX KOMOROSKE: But
in seriousness, I
mean I have actually a
sociological background,
and a lot of times we
miss this, but this
is one of the few examples
where you have competitors who
are also sort of cooperating.
They're working
together on standards.
You're shipping things
are mostly interoperable
and they can compete on
which features to offer
and how to implement them.
And that kind of
competition, while still
being interoperable, is
pretty special about the web.
And I think it's
pretty fundamental.
GRACE KLOBA: I also
want to add one point.
It's like with multiple kind
of vendors working on it,
it's increasing diversity.
It's like a group,
different people
having different opinions.
What is the more important
versus the single voice.
ALEX KOMOROSKE: And some of the
work going on in Gecko right
now is really interesting,
a lot of really interesting
approaches in layout.
It's just great to see
different engines looking
at different aspects.
CHRIS WILSON: So sorry,
just lost a question here.
So I think there's
a lot of questions
that sort of center around
this topic of, Google
seems to have somewhat
of an identity crisis.
On the one hand there's a
large push for Progressive Web
Apps in emerging markets.
And on the other hand there's
things like Instant Apps.
Why does Google continue to
march forward with Android
rather than doubling down
on their core business
as inherently web-based?
I am totally throwing them
under the bus on this one.
DARIN FISHER: Anybody
here from the Android team
want to talk about it?
PARISA TABRIZ: I think
you can transition
from just the point of
competition to some extent
and recognizing there's
different needs and developers
want different things.
And that's actually not
necessarily a bad thing.
You don't want to say
like, this is the only way
and we're only going to do this.
I think I sympathize
with the point of hearing
kind of a lot of
different options
for how to create content,
and that maybe not having
a holistic narrative.
But I also think that
one of Google's strengths
is actually not just
sticking to one thing
and continuing to
invest in what makes
sense for this environment
and seeding new ideas.
DARIN FISHER: I think meeting
developers where they are.
I know Tal, you talk
a lot about this when
you reach out to developers.
TAL OPPENHEIMER:
Yeah, I was going
to say as well the question
itself somewhat answered
parts of it and highlighted
that Progressive Web Apps do
resonate particularly well
in various countries that
have different constraints.
And so the reality is is that
different technologies can work
better depending on
who your users are
and who you're targeting
and whether you're really
aiming to have a lot of users
from a lot of different areas,
or if you're really focused in
on one particular set of users
and how do you best match those.
And so some technologies
of Progressive Web Apps
work really well for
those, and other aspects
that Android and native
provides works better
for other use cases.
PARISA TABRIZ:
Obviously we're going
to trumpet the awesome benefits
of Progressive Web Apps.
But I also think it's not
a bad thing for the world
to have options.
CHRIS WILSON: Yeah.
And I mean the user's experience
is surrounded by stuff too,
right?
Like ChromeOS I've
always thought
was awesome because it's
really just the web,
but it does have
a user experience.
And users get used to those
consistent ways of interacting
with their system.
And they're different when
you change different devices.
So I'm going to have to go
with my friend Jason Grigsby
question of, why
does Google highlight
AMP in search results instead
of Progressive Web Apps?
When will Google search have
ambient badging for PDAs--
or for PWAs?
[LAUGHTER]
PARISA TABRIZ: Never for PDAs.
CHRIS WILSON: Never for PDAs.
DARIN FISHER: Never again.
CHRIS WILSON: And keeping
in mind, because I'm
going to channel Darin.
He's sitting right next to me.
The search team isn't here.
DARIN FISHER: We
can say anything?
CHRIS WILSON: We
can say anything.
Yeah, whatever you say I
think they have to do, right?
Is that how this works?
ALEX KOMOROSKE: I think
if you get 76 votes then
we must legally do it I
think is what happens, 75%.
CHRIS WILSON: I'm going to
watch that number roll up
as you say this.
MATTHEW MCNULTY: I'm pretty
sure Parisa's pillow is
a spokesperson for the
search team, right?
PARISA TABRIZ: What?
You don't want a panel
of Chrome managers
to be answering this question
because we have no idea?
I don't know if there's
anything for us to say.
DARIN FISHER: But if you
think about it, so when
we talk about
Progressive Web Apps,
we talk about building
best in class,
building really great mobile
web experiences, right?
And what is search
really great at doing?
It's helping you find
great web experiences.
And so search already
points you to PWAs,
already points you to websites.
And search is very motivated to
help you find the best sites,
right?
And we're motivated to help
you build the best sites.
So I feel like there's a
lot of alignment there.
When we talk about
PWAs, we're not so much
saying it's a different thing.
It's the mobile web.
It's mobile web
sites built well.
And that's what we're here to
try to help you accomplish.
CHRIS WILSON: OK, so on
a similar vein though,
what's up with Google launching
so many Chrome-only sites?
DARIN FISHER:
What's up with that?
PARISA TABRIZ:
What's up with that?
We shouldn't be doing that.
Are We doing--
ALEX KOMOROSKE: There
was one last week
I saw that was bouncing
around on Twitter.
Every time we see one of these
we dive in, like oh crap.
And we chase down the CL
internally that led to it,
reach out to the teams,
try to catch them
beforehand obviously.
I think this one was
actually someone using
a very old version of Firefox.
ALEX RUSSELL: It was
Firefox on Linux, which
was incorrectly blacklisted.
ALEX KOMOROSKE:
And ultimately we
try to make the case for
lots of the other teams--
very large company--
about the benefits
of progressive enhancement
where possible,
allowing users to access
those sites even if they
aren't fully sure it's tested.
MATTHEW MCNULTY:
Yeah, to be clear,
everyone up here on this
stage generally really, really
dislikes it when a Google
property does this.
So we're some of the people that
actually object the most to it.
DARIN FISHER: And in
fact the whole concept
around progressive
enhancement, twofold.
One is there's a path
forward for a developer
to create an experience that
can embrace new features when
it's available.
And that allows them to create
and experiment with new APIs
and create experiences
that are better
for that set of users
who happen to have
the browser with those features.
But it also tells developers
of the other browsers that
haven't implemented those
features that that's actually
a feature worth building,
because developers
want to use it.
So it all really works
well when you kind of
go down that progressive
enhancement path.
And in general, when
it's possible to do that,
I think with Google, that's
mostly where the focus is.
There's been just a few
incidents recently where
people motivate discussion.
And like we are saying, the last
one was actually kind of a bug.
Anyways, I should
probably stop talking.
ALEX RUSSELL: There are ways
to do this better than not.
So for instance you
could give users
a link to let them
continue to try it anyway.
There are ways to
communicate that you're
expanding your browser
support in the future.
There are ways to
say, hey, here's why.
And those are things that we're
advocating for internally.
So come to us.
We'll advocate to the
other teams on your behalf.
That's a service we provide.
CHRIS WILSON: Absolutely.
And I will say I don't think
the Chrome team has ever made
any Chrome-only web services.
ALEX RUSSELL: Well
let's not open that can.
CHRIS WILSON: But definitely
treat the Chrome team
as your helpers in this.
There's a lot of discussion
around offline capabilities.
I actually chose this
question because this is one
that I've thought about too.
That's great to have
offline capabilities,
but how much storage can a web
page really respectfully expect
to have locally?
There's likely an expectation
from the user that you're not
going to take a huge
amount of space,
store a bunch of
stuff on their phone.
How does this work
when you have media
apps like the ones we were
talking about this morning?
ALEX RUSSELL: So we've
changed this a lot recently--
ALEX KOMOROSKE: For the better.
ALEX RUSSELL: Yeah.
Well, it depends on who you are.
We think that because it's not--
the contract we give developers
isn't the same as a native app
gets, right?
A native app gets
as much storage
as is available on the disk
without a lot of limits
up until the OS
says you're cut off.
We are the ones
cutting sites off.
So we impose tighter limits.
Historically they've
been very, very low.
I think the number that's
still kicking around
in some people's mind is 50
megabytes or 5 megabytes.
Those are pathologically
low limits
if you're trying to
build anything serious.
And so instead we've
shifted our implementation
to look at the amount of
total free space on the device
and we've expanded
the amount that Chrome
is allowed to take quite
a lot, because you might
be using Chrome as
the primary reason
that you're on the device.
So it's sort of comical
that we would only
take 15% of the total space.
We've fixed that.
So now you'll see quite a
bit more space available
if you use the Quota
APIs to interrogate it.
But we also are trying to ensure
that the sites that you engage
most heavily with are
the things that are kept
or the things that you have more
storage space allocated for.
So think of it like a big pool
and we'll throw the things out
that you don't use frequently.
So if your site
engagement score is high,
you're much less
likely to get evicted.
But the amount of
space that a site gets
is now largely unlimited.
ALEX KOMOROSKE: And this is one
of the places where the web has
an amazing ephemeral
model where users
don't have to be afraid to
tap any link to go somewhere.
And that's huge.
It's foundational.
But it means that some of these
questions are very different.
Like what does a user expect
to have more storage saved?
And so there's things
like if the user has added
to home screen, we're more
likely to allow that thing
to save more content because
the user would likely
expect that thing to be able
to save more things offline.
It ultimately is about
giving the developer ability
to understand what's
going on and have
better control over it.
CHRIS WILSON: Cool.
So now for another fun one.
Fun is in quotes here in
case you're wondering.
Why aren't Progressive Web Apps
installable from Google Play?
PARISA TABRIZ: What's
your definition of fun?
CHRIS WILSON: I have a
very twisted sense of fun.
DARIN FISHER: I think there's
a lot to this question, right?
And so you can sort
of break it down
into a couple different axes.
One thing is that they
already are, right?
You can put a website
in a web view.
And so I think the
question is probably
asking something different.
So we announced Trusted
Web Activity today
which allows you
to actually launch
an activity, a component
of your application
that is powered by Chrome.
And I think it was explained
that the reason for doing that
is that you can actually share
the cookie jar with Chrome
and take advantage of Chrome's
ability to help you just fill
out forms and so on.
Those kinds of things
are in stark contrast
to the experience
you get when you just
wrap a website with a web
view, because users have
to go through the log in steps
and all that kind of stuff
or you have to go
and do a lot of work
to plumb all that
in to the web page.
So what we're doing with
Trusted Web Activities
is making that work better.
And so we sort of see
that it's important
that the developer is there
in control of the thing
that they are ultimately
uploading to the store.
So they generate an APK
and we're giving them
tools that allow them
to leverage the web,
and particularly their
investments in PWAs,
to help them build a great
application that a user would
find through the Play Store.
CHRIS WILSON: Cool.
So one final question I
think, and this one I actually
want each of you to answer.
So at Chrome Dev Summit 2027
on the leadership panel,
when asked what you're
most proud of with Chrome
in the last 10 years, what do
you think your answer will be?
What do you think the
best thing that we're
going to do in the
next 10 years will be?
I'm going to start over there
actually because that way Darin
can think about it the longest.
He's the most likely
to get me fired.
ALEX RUSSELL: The thing
I would be most proud of
is the way the investments
we're making now
have enabled the web to survive
the next form factor change.
We didn't necessarily
predict mobile.
We saw it coming from
some distance off,
but we've now, I think,
started to respond adequately
with Progressive
Web Apps as a way
to help the web
survive in mobile
and thrive and make
a great product
market fit with users
in emerging markets.
And I think if we
do our jobs right,
we will have done that
for whatever the next form
factor is too.
ALEX KOMOROSKE: I
think a lot of it
is understanding the
value of this competition
between rendering
engines and allowing that
as sort of an engine
underlying this thing.
I think it's much
easier if someone
was saying in here of like,
why can't everyone just work on
the same rendering
engine together?
And I think that one of
things I'm most proud of
is that we understand and can
help harness that competition
in a way that's really
helpful and healthy
for the ecosystem long term.
CHRIS WILSON: You
know, having started
in a very different
browser environment
during the browser wars v1,
even before that, I have to say
we've come a long way already.
And I agree though.
I think we'll do even
better in the future.
MATTHEW MCNULTY:
I think I'd like
to be proud of that we
kept the user first,
that we were like a particularly
noble and good steward
for the user and, yeah,
and kept them first.
TAL OPPENHEIMER: I guess
building off of that,
for me it would be all users
and not just the ones that
look like us or have the
background that we've
had with the internet
with browsers, et cetera,
and so making sure that
it really is for everyone.
THAO TRAN: So I'm
going to expand Chrome
just a little bit for just
thinking about the web.
And so it would be amazing
if we look back 10 years
and I'm able to publish content
or sell a pair of shoes,
and all I have to do is build
once and it works everywhere,
not have to worry about so
many different form factors
and that it will
be accommodating
across whatever comes next.
GRACE KLOBA: So for me because
I'm leading the Chrome mobile,
so looking at Chrome
from desktop to mobile,
and moving forward
another 10 years,
I imagine there's going to
be another new platform.
So I want to see Chrome
continue from desktop to mobile
to this new platform,
and always there.
PARISA TABRIZ: Yeah,
I'm pretty excited
about the cross-platform
Chrome story
and making that just easier
to access content across.
But since you've already
said that, I think--
CHRIS WILSON: Yeah, you
can't just say me too.
PARISA TABRIZ: OK, me too,
but also, or and also--
DARIN FISHER: HTTPS.
CHRIS WILSON: Oh no,
you have to go in order.
PARISA TABRIZ: Yeah,
you have to go in order.
CHRIS WILSON: You can't
take hers ahead of time.
PARISA TABRIZ:
Yeah, so yeah, HTTPS
is what I was going to say.
And because Darin
took that, I also
look forward to a more
secure and auditable PKI,
because that's actually
one of the dependencies
of secure HTTPS.
And I think we've
made a ton of progress
the past couple of years to make
it easier and cheaper and more
affordable.
But spending some time on having
confidence in that piece of it,
and other cool security
primitives that
are coming to the web
platform that I think
we've learned a lot in
native application software
development with sandboxing
and other defense in depth
that it's cool to see these
coming to the web platform
and seeing those adopted.
DARIN FISHER: Yeah, 2027, so
that means I would-- if I was--
PARISA TABRIZ: How old
are you going to be?
DARIN FISHER: Yeah.
PARISA TABRIZ: OK, sorry.
[LAUGHTER]
DARIN FISHER: And
the answer to that
was saying that if I was up here
at that time talking about it,
that would have been 21
years working on Chrome.
And I would just be damn proud
of the team that got us there.
And I would know that we
did something awesome--
even more awesome.
CHRIS WILSON: All right, I think
that's all the time we have.
So thank you very much.
[APPLAUSE]
Thanks to the panelists.
[MUSIC PLAYING]
