SPEAKER 1: So we edit the
comments for YouTube videos for the series. SPEAKER 2: Well, yeah we do. SPEAKER 1: I think I should
have said moderate, shouldn't I? SPEAKER 2: Yeah. SPEAKER 1: Should I try that-- SPEAKER 2: We don't edit them. We don't go in and it me
say something different. SPEAKER 1: Should
I try that again? SPEAKER 2: That would
be good if you could go, this is the greatest
show I have ever seen. These people should get a raise. SPEAKER 1: Just messing
it up straightaway. [MUSIC PLAYING] SPEAKER 2: We are building
the Chrome Dev Summit website. SPEAKER 1: Yes, we are. SPEAKER 2: And we are looking
into using push notifications because we are trying not
to be annoying about them. SPEAKER 1: Yeah If
there's one thing that everyone loves on the
web, it's push notifications. Every site-- SPEAKER 2: Everyone loves it. SPEAKER 1: I can't stop
myself from hitting allow. And I'm just like--
oh, I'm just-- curiosity has gotten
the best of me. SPEAKER 2: My lock screen
is full of notifications. SPEAKER 1: I don't know
what your website's about. But you have asked me
if I want notifications. And my answer is always yes. Of course it is. SPEAKER 2: I hate it
when you got to a website for the first-- it's like,
hey, would you like-- I don't even know what for. What are you doing? Who approved this? Either way, we actually think
we have a legit use case, namely that-- SPEAKER 1: This is
what everyone says. But OK. Yes, we think we do. SPEAKER 2: Because this
conference is something that you can not
only have in person, but obviously, also
watch with a livestream from home, which might mean
that you are in a different time zone. SPEAKER 1: Yes. SPEAKER 2: So what we want
to do is that you can say, this session is
interesting to let. Let me know 10
minutes ahead of time before it's about to start. SPEAKER 1: We'll be asking
for permission at a good time. SPEAKER 2: Yeah, once they
click, notify me, we will say, well then we would need your
permission to notify you. SPEAKER 1: And that seems
like a reasonable time to ask. SPEAKER 2: Yes. SPEAKER 1: Yes, I agree. SPEAKER 2: Just as a context
why did I look into Web Push. And I did. And I was actually
kind of scared because I had never done it. I've never used Web Push. And I know that back in the
day, Google Cloud Messaging had their own proprietary API. And that was a competitor. And it was incompatible
with anything else. And I was like, I
don't want to do this. And I looked into it. And it's so much better. It's actually-- I would
say it's enjoyable now. SPEAKER 1: So is all
documentation for this still written by Maunty Gaunty? SPEAKER 2: The
out-of-date documentation is written by Maunty Gaunty. SPEAKER 1: Yeah. So we should say this
is someone who was on the team a few years ago. SPEAKER 2: And
then bailed on us. SPEAKER 1: And he bailed on us. But we called him
Maunty Gaunty because-- SPEAKER 2: Or some, Maunt Gaunt. SPEAKER 1: Maunt
Gaunt If we can-- hopefully we can get this
footage to display now. SPEAKER 2: It's from the PWA
Summit in Amsterdam, 2016, I want to SPEAKER 1: Or
something like that, and it was-- so his
name, Matt Gaunt. But while he was
talking to camera-- SPEAKER 2: The editors
just call him Maunt Gaunt. [LAUGHS] SPEAKER 1: Maunt Gaunt. It was like, I like his surname
so much, we'll put it twice. So that was it. That was his-- SPEAKER 2: And
that's-- his name gone. SPEAKER 1: I think
that's why he had to leave the team because
it was just like, all right, Maunty, how's it going? SPEAKER 2: Yes. So he was our push person. SPEAKER 1: Push person. SPEAKER 2: And he left. And things changed. And we had nobody
update the document. SPEAKER 1: Good. Excellent. SPEAKER 2: This is how we work. Either way, moving on. SPEAKER 1: All right. SPEAKER 2: Web Push. SPEAKER 1: Good. SPEAKER 2: Let's
talk about this. So it is now an open protocol
standardized by the IETF. All the browsers
that do implement it, implement that
specific protocol. And that is pretty much every
browser apart from Safari. SPEAKER 1: Yes, Safari doesn't
have support for Web Push. SPEAKER 2: Let's
take a look at this. So the first thing that you
need for push notifications is to have a push handler
in your service worker. And this may just be to show
a notification irrespective of push. But you need to
show a notification. So what you do is you just add
an event listener for push. And then it's usually a good
idea to check if you actually ever got permission from
the user because otherwise, the [? notification ?]
call will [? throw. ?] SPEAKER 1: So it's
interesting that actually-- as far as I'm
aware-- every browser will bundle the push
notification permission and the notification permission. Push permission and
notification permission become the same thing. SPEAKER 2: Yes. If they ask for a
subscribe later on, the user will get
asked for permission. But it doesn't mean that
you couldn't get a push event without the
user ever having consented to notifications. SPEAKER 1: Not in Chrome. SPEAKER 2: Really? SPEAKER 1: Yeah. When you subscribe for push, the
permission you get there that says, do you want push or not? If you say allow, it will give
you notification permission as well [INAUDIBLE]. SPEAKER 2: But I can
still get a push event without the user ever having
been asked for permission, I think. At least you could trigger
it by dev tools, for example. SPEAKER 1: Maybe. But I would say-- [LAUGHTER] I would say otherwise,
I'm pretty sure not-- SPEAKER 2: Potentially. SPEAKER 1: It's
definitely not in Chrome. SPEAKER 2: It's
definitely not a bad thing to check before so
the code doesn't throw because throwing is usually-- SPEAKER 1: It's
definitely possible that other browsers may
diverge those two things. SPEAKER 2: Or you could
still get a push event, but the user has since
then rejected your-- or has removed your permission
to show notifications, also, I think, a thing that
could be happening. I'm not too sure about that. Either way, I'm just
trying to justify-- just do a check. That's all I'm saying. SPEAKER 1: No, that's good. SPEAKER 2: So what happens in
a push event, you get an event. And then the event
has a dot data added, which works very similar
to a fetch response. And then you can do unmarked
lists, text, JSON array buffer, and that's what you get. And then you can use the
show notification API to actually show a
notification on the system. On an Android, it
will be a notification on the notification bar. On Mac OS, Windows,
[INAUDIBLE] will be one of these on-screen
display notifications. They're there for a
couple of seconds. There you go. This is pretty much the
notification part of Web Push. That's done. Let's talk about the
interesting thing. And in this part, we're going
to talk about cryptography. SPEAKER 1: Cryptography. SPEAKER 2: Well, actually,
we're not going to talk about it because one of the
golden rules, I think-- and everybody knows this-- don't roll your own crypto. The spec is out there. And it's actually very readable. How do you need to encrypt
which data to actually be compatible to the protocol? But pretty much every language
has a Web Push library that encapsulates all of that logic. So I would recommend
not doing it yourself. Use libraries, and
you will actually have a very pleasant experience
of just making it work. SPEAKER 1: Yeah, I remember
the days when this was speced. And there was a lot of-- so the reason that
we use crypto here is for the body of
the push, right? SPEAKER 2: Well, not
only that, but also just for being allowed to
push in the first place, that you can actually
prove the user has granted you permission. But-- SPEAKER 1: Right, interesting. SPEAKER 2: That's
multiple levels here. SPEAKER 1: But part of the
reason that it came about was the service delivering the
push messages-- be it Chrome, maybe eventually Apple
one day, or Telefonica, who I think certainly used to
do this stuff for Firefox-- they don't want to
see your messages. SPEAKER 2: We don't want them
to see our messages, right? SPEAKER 1: Yes, we don't. And they didn't either. It was, let's reach this
mutual understanding that as we are just
delivering these messages, we don't wan the ability to-- SPEAKER 2: For them
it's just binary blobs. And it should stay that way. SPEAKER 1: Yes, we
don't want Michael to know that-- we
don't want to know that Michael has a new baby
boy or something like that. It's just, we're
not not interested. It's just we just want to
marshal, let data around. But yes, we knew it was going
to be slightly more effort for developers. SPEAKER 2: But to be fair, the
libraries that came out of it-- I've been looking
at the Web Push NPM package, which is written by one
of the engineers from Mozilla. And it's not only
very well written-- as in you can actually go and
read the code to understand what's going on-- but the API is super simple. So you can actually get
started quite quickly. SPEAKER 1: So this is on the-- SPEAKER 2: This is actually-- SPEAKER 1: So this is
on the surface, right? SPEAKER 2: It might be surface. It could actually be
locally doing development. Just generate-- you need a
private key and a public key. And so there is a function
called-- this whole process is called vapid. That's the name for
the algorithm, I guess. It's voluntary
something, something. I don't remember. It doesn't even
matter that much. But basically, you need this
private key and the public key. The private key is obviously
private, so keep it safe. The public key,
you can publicize. Put it in your
front end anywhere. But you will need the private
key on your server side later. So make sure you get
it there because that's what you need to sign with
to actually be able to push the message to the provider. SPEAKER 1: But the public
key will go to the client to do the decoding? SPEAKER 2: To client side, yes. SPEAKER 1: Right, I see. SPEAKER 2: So yeah, this is
basically the first call. You just import the Web
Push library [INAUDIBLE] to generate your [? keeper. ?]
And that's the first step done. So once you have those in place,
we are now on the client side. So in there, I need to
somehow get my public key. So you could bundle it
with your [? web app ?] via Webpack or Rollup. You could fetch it from
your server as a resource. It doesn't really matter. You just need to get it. And it's public, so you can
just put it on the internet. Nobody cares. SPEAKER 1: The public key
is unique to your site not per user. Is that correct? SPEAKER 2: No, it's
unique to site. Yeah. SPEAKER 1: I see. SPEAKER 2: Technically,
you can even have multiple, but it doesn't quite make sense. But it's up to you. You can generate those. It's free. SPEAKER 1: OK. SPEAKER 2: Once I
have the public key, I will then wait for
my service worker to be ready, available,
and running because that is the one that takes
care of anything it has to with that push. And then I can use
the push and enter property on the service worker
to ask for a subscription. And as it is asking the
user just to subscribe, basically implies the
permission for notifications. So this will pop up
the permission dialog and wait for it to response. And actually, user visible
only has to be true. Currently, on the
web we don't allow push notifications that don't
trigger visual notifications. So maybe at some
point in the future that would be possible to
do a background sync thing. Don't know yet. For now, only with a permission. SPEAKER 1: Yeah. Well, one of the things that
we would like to do with user visible kind of-- [LAUGHTER] So here's a situation. Say I deliver a push message
to your phone to say, there's a new chat message. But I know that you-- by your user ID-- have just checked that message
on your desktop machine. The ideal thing would be then
to hide the push message-- SPEAKER 2: That's [INAUDIBLE]. SPEAKER 1: --on your mobile. But then that is no longer
a user visible thing because if you
granted the ability to do that, then you've
granted the ability to do invisible push work
because you would just show a notification, hide
notification, job done, who cares? So that's one of the things
where there's a really good use case there for it. SPEAKER 2: And the
reason we don't just want to allow notifications
without any visual effect is what? SPEAKER 1: It would
give you the ability to just send a push
message every 10 seconds, attract the user through
the different IP-- you're running a service
worker in the background. Why not do some bitcoin mining? SPEAKER 2:
[INAUDIBLE] basically? SPEAKER 1: Privacy, battery-- SPEAKER 2: Exploitation,
all kinds of things. SPEAKER 1: All of
the bad things. SPEAKER 2: As
always, [INAUDIBLE] to think about these things. SPEAKER 1: Yes. SPEAKER 2: So, basically,
what a pattern is like-- I'm going to promise I'm always
going to show notification. And if you don't, Chrome
will show one for you. So it's not like you
can get around it. And we provide our public key. So that way, we can use a
private key to sign things. And the clients then can check
it actually came from us. SPEAKER 1: And this is how it's
also going to decode the body? SPEAKER 2: Yeah. SPEAKER 1: Right. Gotcha. SPEAKER 2: So now we get back
once the user actually presses allow, you can show me-- you can send me
push notifications-- we will get a subscription. And I find this interesting
because it's actually very little data in there. There is the endpoint that the
server side later on will use to send push notifications out. And so in Chrome, it will
be Firebase Cloud Messaging dot Google APIs dot com. In Mozilla, will be
on a Mozilla server. I'm pretty sure
[INAUDIBLE] is going to use a Microsoft server. I'm not sure about that. And Safari, as I said,
it doesn't have it yet. There's an expiration time. And there's the
keys, which are for the Diffie-Hellman handshake. But it doesn't really
matter right now. But basically, there is no
other personal data in here. It's not like there's a
lot of leakage happening about what the user is doing
or what they're subscribing to. It's literally just
the cryptographic keys that are needed to make this
whole thing happen securely on a zero-knowledge approach. So we get this back. And then what we
do, as I said, we need to send this
to our server side. So one way to do
that would be a fetch that we just posted to
my serverless function, wherever you're running. You need to store this
subscription thing as a stringify JSON
blob on the server side because you need it to actually
send a notification later on. SPEAKER 1: And this is going
to be unique to that user. So this is something
that you would-- SPEAKER 2: It is very
unique to that user. For every user, you will get a
different kind of subscription blob that you need. So now on the server side,
we are now at the point where maybe at some
point in the future we want to send a
push notification. So we know we have our
keys on the server side. We know we have subscriptions
for a user on the server side. So basically, we need
to find all the users that we want to send something
to, loop over them, and now do something. And again, Web Push-- the library makes it quite
easy because we get our keys. We get our subscription
for that particular user. You set our vapid details,
which is the public key and the private key. They also demand a contact
email or multiple contact emails in case
something goes wrong, you just want to have a point
of contact to send [INAUDIBLE].. SPEAKER 1: Make sense. SPEAKER 2: And then you
just send the notification. So basically, we turn the
push subscription back into a JSON blob. Put our body there. It can be string. It can be another stringified
JSON object, whatever. That will take care
of the inscription. And hit that end point
from the inscription, and send it to the user. SPEAKER 1: And that's it? SPEAKER 2: And that's it. That's all. That's how you do
push notifications. I was quite amazed because
I literally just ran through this
library, wrote it up, and it worked on the first try. And that never happens. SPEAKER 1: So this is
the thing because I've-- I know bits about the service
worker outside of Push because we were doing spec
work around that time. But I've never done
the service side of it because it's like,
oh, it involves keys. It's probably going
to be hard and I'm not going to touch until
I really need to. This is all right. SPEAKER 2: It's pretty
approachable, isn't it? So we now have this on a branch
in our Chrome [INAUDIBLE].. We still have some tuning,
some edge cases and stuff to work out and allow
people to unsubscribe if they don't want
notifications anymore because we want to be nice about this. But other than that,
we're up and running. SPEAKER 1: We look forward
to spamming everyone with pointless stuff. SPEAKER 2: Subscribe to
this YouTube channel. SPEAKER 1: We moderate the
comments for YouTube stuff. SPEAKER 2: Yes. SPEAKER 1: A couple
of episodes ago, there was a guy posting a comment. And he was saying,
I think you could have edited out to the
disgusting flatulence noise at 1-- did you see this
comment [INAUDIBLE]?? SPEAKER 2: I did
see the comments. SPEAKER 1: Did you
go and listen to what the actual time stamp it was? SPEAKER 2: I think it
was me going, [GASPS].. SPEAKER 1: Well, I
thought it was me. But it was one of us doing that. That was just-- because I said,
have a look at that [GASPS].. And that guy posted 15 comments. SPEAKER 2: Really? SPEAKER 1: It was 15 of just
variations on that theme. He was so angry about that. SPEAKER 2: But is that what
his flatulence sounds like? SPEAKER 1: Yes. SPEAKER 2: Because that's-- SPEAKER 1: You gasping. [LAUGHTER]
