►
From YouTube: Digital Identity Attestation WG (February 3, 2021)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
We're
east
coast-ish
out
in
michigan.
I
definitely
didn't
get
the
stuff
that
the
east
east
coast
did,
but
definitely
to
shovel
the
driveway.
A
Cool
all
right:
well,
we
can
get
started.
The
first
thing
is
just
a
quick
little
plug.
I
wrote
up
a
roundup
post
with
the
help
of
all
the
presenters
for
a
lot
of
the
presentations
we've
had
in
this
working
group.
So
far,
so
if
you
haven't
been
able
to
make
one
of
them
or
curious
like
take
a
look
at
that
and
you
can
kind
of
just
see
a
quick
summary,
I
think
it's
been
really
really
awesome
to
have
all
these.
A
So
I
put
that
out
there
I
think
the
debian
one
is
is
missing.
I
couldn't
find
the
recording,
but
we
could
add
that
I'm
in
another
point
people
are
for,
if
enrico,
is
interested
in
helping
me
do
that
so
yeah.
So
that's
just
a
quick
plug
for
that
and
then
today
I
think
jacob
is
going
to
be
presenting
to
us
about.
I
have
no
idea
how
to
pronounce
the
name
of
that.
B
You
are
not
alone
there.
One
of
my
my
biggest
regrets
is
is
the
name
of
this
tool.
It
is
excavator
or
cr
excavator.
I
have
this
combo
every
time.
I
I
talk
about
this
very.
A
B
B
Great
yeah
I've
got
a
slide
deck
here.
I'm
gonna.
B
B
B
Yeah
hey
so
so
thank
you
for
for
having
me
today.
I
I'm
gonna
be
talking
a
bit
about
a
a
tool
we
created
called
seer
excavator
zack
steinler
is
a
colleague
of
mine
and
attended
your
your
last
meeting
and
thought
how
duo
tackled
our
our
like
trust
issue
with
with
chrome,
extensions
and
and
how
we
think
about
like
trusts
and
and
risk
scores
in
the
context
of
this
tool,
might
be
useful
for
for
this
group
and
dan
thought
so
as
well.
B
So
I'm
happy
to
to
talk
to
y'all
today
cool,
so
my
name's
jacob
rickard,
I'm
a
senior
security
engineer
at
duo,
cisco,
former
amazon
security
engineer,
and
you
all
can
follow
me
on
twitter
at
cr
expert.
I
got
a
thing
for
that
name.
Unfortunately.
B
Well,
so
this
is
the
first
meeting
I've
been
able
to
to
attend
from
from
this
group,
but
I
did
watch
the
the
last
meeting
with
michael
talking
a
lot
about
federation
and
I
checked
out
the
github
and
I
think,
where
I'm
gonna
be
able
to
provide
the
most
value
today
is
talking
about
risk
and
and
trust
from
the
perspective
of
of
a
consumer
who
had
a
a
problem
with,
with
with
needing
to
evaluate
the
the
trustworthiness,
the
the
risk
that
browser
extensions
had
throughout
their
their
org
and
the
solutions
we
we
came
up
with,
and
I
know
browser
extensions
aren't
exactly
open
source
software,
but
I
think
they
they
can
have
a
lot
of
the
same
risks
and
I
think
y'all
will
be
able
to
to
get
some
value
out
of
this
today
cool.
B
So
I
adapted
this
talk
from
from
one.
I
gave
shortly,
pre-covered
I'm
gonna
breeze
through
a
number
of
these
sections
and
focus
more
a
bit
about
risk
from
browser
extensions
and
the
trouble
with
with
risk
scores.
I'm
not
trying
to
sell
you
anything
today.
Don't
worry
crux
creator
is
free.
You
can
buy
it
if
you
wanted
use
it,
don't
use
it.
It
doesn't
really
matter
too
much,
but
I'm
going
to
go
a
bit
about
how
browser
extensions
work.
How
we
think
about
browser
extensions,
a
bit
of
some
research
findings.
B
B
So
every
time
I
give
a
talk
about
browser
extensions,
I
like
to
add
some
some
headlines
here,
and
these
are
very
fun
and
fear-mongery,
but
you
know,
as
as
we
do
more
in
in
the
browser
these
days
between,
you
know:
consumers
doing
banking
and
email
to
organizations
managing
production
infrastructure
in
the
browser.
Browser
extensions
are
often
a
forgotten
attack
surface
here
and
you
can
see
like
you
know.
B
B
B
You
know
page
or
production
infrastructure,
and
I
thought
this
one
was
particularly
interesting
for
this
group,
because
in
the
last
talk
michael,
the
presenter
was
very
into
the
idea
of
of
digital
identities
should
be
linked
back
to
real
world
person
identities,
and
I
think
I
I
agree
with
his
assessment
there-
and
I
know
this
group
is
talking
about
having
the
the
concept
of
having
a
digital
identity
separate
from
a
a
real
world
identity.
B
But
when
that
identity
can
potentially
be
bought
and
sold
and
and
change
hands,
there
can
become
these
scenarios,
where
the
great
suspender,
for
example,
was
a
recent
extension
that
was
sold,
I
believe
in
in
june,
and
there's
nothing
stating
that
you
know
extension
developers
have
to
disclose
when
they
sell
their
their
extensions.
They
can
just
hand
over
their
their
google
account
if
they
really
want,
and
when
that
happens,
that
that
new
owner
took
the
extension
pushed
push
an
update
that
started.
B
B
That
was
like
pretending
to
be
a
certain
analytic
software,
but
but
was
was
actually
something
else
and
and
a
lot
more
sketchy
stuff
happening
there,
and
at
duo
we've
seen
when
we've
had
incidents
around
browser
extensions
they're,
often
when
a
a
previously
good
and
trusted
extension
turned
malicious,
either
through
being
sold
or
the
other
example
here
when
that
extension
is
forcibly
taken
over
and
a
real
life
example,
this
one
was
mega
a
couple
years
ago,
the
the
mega
extension,
a
developer
account
was
was
hacked
and
malicious
actors
push
an
update
to
the
extension
that
started
stealing
usernames
and
passwords,
and
I
even
think
some
bitcoin
wallet,
keys
and
stuff
and
that
that
was
a
number
of
users
that
that
were
unsuspectingly
affected
and
one
of
the
issues
with
with
browser
extension
specifically,
is
that
there's
no
easy
way
to
version
pin
extensions.
B
So
if,
if
there's
a
new
update,
the
extension
will
automatically
be
updated,
silently
without
the
user
knowing
and
yes,
technically,
if
they
add
a
new
warnable
permission,
the
extension
will
be
disabled
and
the
user
will
have
to
re-enable
the
extension
but
often
times
if
they
buy
an
extension.
That
already
has
a
lot
of
access.
B
So
I'm
going
to
quickly
go
over
what
what
is
a
chrome
extension
so
so
this
group
has
some
baseline
knowledge
to
to
help
understand
the
rest
of
the
talk
today.
I
can
give
a
whole
talk
on
this,
but
we
don't
have
that
kind
of
time
today.
B
But
basically,
all
you
need
to
know
is
that
a
browser
extension
has
this
manifest.json
file,
which
is
kind
of
the
the
heart
and
soul
of
of
the
extension
and
there's
many
more
keys
than
than
this.
But
some
of
the
most
important
ones
are
permissions
which
can
define
what
an
extension
is
allowed
to
to
do
and
what
it
can
access
optional
permissions,
which
are
the
same
as
permissions.
But
the
only
difference
is
that
they
require
a
user
to
click.
B
It
can
also
pass
messages
between
these
these
scripts,
because
each
script
has
a
different
level
of
of
permissions
that
they're
allowed
to
to
use
and
content
security
policies
which
can
limit
where
an
extension
is
allowed
to
make
calls
to,
or
or
load
resources
from,
here's
a
quick
example
of
of
what
permissions
look
like
at
the
top
there
stuff,
like
all
all
urls,
you
know
like
three
stars,
https
sorry
gdp
star,
google
will
will
warn
on
these
permissions
with
read
and
change
all
all
your
data
on
the
websites
you
visit.
B
If
you've
ever
installed
a
browser
extension,
you
might
have
seen
a
a
little
pop-up
that
that
warns
on
what
the
extension
can
do
and
these
permissions
directly
affect
what
warnings
will
appear
there.
Also,
you
know
you've
got
a
history
permission
which
can
read
and
change
your
browsing
history,
privacy,
which
can
change
your
privacy
related
settings,
and
there
are
dozens
more.
B
I
I
like
to
show
this
example
too.
Whenever
I
talk
about
browser
extensions,
because
I'm
a
reddit
user
and
on
the
aws
subreddit
a
while
ago,
I
saw
a
a
post
where
someone
said
I
made
a
chrome
extension
to
color
the
console
header
depending
on
the
region.
Do
you
find
this
idea
interesting?
And
this
is
kind
of
the
exact
problem
that
we
try
to
tackle
with
with
browser
extensions
right
where
this
is
a
legitimately
useful
idea?
Right?
B
If
you
ever
use
the
a
aws
console,
you
can
sometimes
lose
track
of
what
region
you're
on
and
it
seemed
like
a
lot
of
other
people
agreed
with
this.
It's
got
a
high
number
of
upvotes,
it's
got
gold,
it's
got
silver
and
this
is
legitimately
a
good
idea,
but
I
would
never
trust
a
this
browser
extension
in
in
my
org,
and
you
know,
a
lot
of
people
on
reddit
are
smart
tm,
and
somebody
commented
something
similar
being
like.
B
B
But
then
another
smart,
reddit
user
commented
on
that
comment,
saying
hey!
Well,
actually
I
review
the
source
code
of
all
extensions
that
that
I
install,
and
I
reviewed
this
one
and
it
it
was
fine.
It
was
only
25
lines
of
of
javascript
and
it
didn't
steal
any
of
my
data
and
that's
where
the
kind
of
the
conversation
fizzled
out
there,
but
oh
got
a
quick
question,
feel
free
to
un
unmute
yourself
and
interrupt
me
if,
if
you've
got
questions
as
well,
I
might
have
missed
them
earlier.
B
One
second
is
this:
for
a
simple
user
script
rather
than
a
complete
extension,
would
make
more
sense,
yeah
something
like
this.
You
could,
if,
if
you've
got
something
like
like
grease
monkey
assuming
you
you
trust
this
or
you,
you
could
write
your
own
simple
thing
to
to
to
do
this
no
worries
at
all,
but
yeah.
There
there's
often
simpler
solutions
to
a
lot
of
the
problems.
B
People
try
to
solve
with
these,
but
users
often
go
for
convenience
over
having
to
go
the
more
secure
route,
and
I
assume
this
extension
would
be
popular
if
it
was
released,
but
anyways.
This
exam
like
this
is
a
perfect
example
of
of
something
that
a
threat
actor
might
want
to
purchase.
B
If,
if
a
number
of
users
have
this
installed
and
is
having
access
to
to
production
data
right
and
without
users,
knowing
it,
it
could
be
purchased,
it
could
change,
hands,
push
a
new
update
and
start
running
a
muck
with
their
production
infrastructure.
B
So
that's
kind
of
the
the
wrong
window.
That's
some
of
the
problems
that
browser
extensions
can
can
face
right,
but
once
upon
a
time
at
duo,
users
were
allowed
to
install
whatever
extensions
they
they
wanted
and-
and
we
didn't
track
browser
extension
risk
as
as
much
and
we
later
decided
that
that
that
was
a
problem
and
we
needed
need
to
get
a
handle
on
this.
So
we
gathered
every
extension
that
was
currently
installed
across
any
endpoint
throughout
duo,
and
we
made
a
explicit
allow
list
quick
side.
B
Note
I'm
going
to
be
using
terms
like
explicit
allowance
and
allow
us
in
this
presentation
to
replace
less
inclusive
terms
like
whitelist
and
blacklist.
You
might
still
see
screenshots
with
that
terminology
and
in
the
tool
we
are
working
on
and
moving
to
more
inclusive
language
shortly,
but
we
we
wanted
to
create
a
explicit
allowance.
B
So
we
collected
every
extension
and
froze
that
in
time
and
said
this
is,
is
the
the
list
today
that
that
wasn't
very
disruptive
for
for
users,
since
any
extension
that
they
already
had
was
still
allowed,
but
any
new
extensions
had
to
be
reviewed
by
our
secops
team
and
over
time
we
would
tackle
the
currently
allowed
lists
and
trim
it
down
to
something
we
are
more
comfortable
with.
B
But
then
we
had
a
new
problem
right.
How?
How
do
you
assess
the
the
risk
that
a
extension
provides
or
can
contribute
to
to
your
org?
How
do
you
like
trust
this
extension-
and
you
know-
extensions-
are
really
just
html
and
javascript,
mostly
javascript,
and
not
everyone
on
our
secops
team
was
javascript
security
experts
and
even
if
they
were
have
fun
going
through
six
megabytes
of
minified
javascript
and
doing
that
multiple
times.
B
So
so
we
needed
a
different
solution
and
when
we
reviewed
extensions,
we
we
wanted
to
ensure
that
they
didn't
have
any
high-risk
permissions
that
they
didn't
need,
that
they
did
not
connect
anything
suspicious
or
unordinary.
They
didn't
talk
to
any
external
services.
These
last
two
are
important
because
any
extensions
well
found
a
lot
of
extensions
are
really
just
interfaces
for
a
sas
service,
and
if
we
use
a
sas
service
at
duo,
it
has
to
go
through
a
vendor
review
process.
B
So
craigslist
can
help
us
determine
that
that
doesn't
use
any
any
libraries
that
contain
known
vulnerabilities,
it
doesn't
incorporate,
incorporate
any
externally
hosted
javascript,
because
then
the
javascript
could
be
changed
without
pushing
a
new
update
to
the
extension
and
then
affect
the
behavior
of
the
extension.
I
have
several
hundred
four
or
five
star
reviews.
B
This
is
a
lot
less
important,
especially
since
we
learned
that
there's
a
lot
of
fake
reviews
on
extensions,
but
it's
it's
still
nice
to
see
has
a
privacy
policy
and
developer
information
is
listed
on
the
web
store
and
there's
not
already
a
related
extension
that
can
accomplish
the
same
task:
that's
less
risky.
B
So
how
can
we
determine
this?
Well
in
came
krexcavator,
so
krexcavator
is
a
a
tool
we
made
that
started
off
as
a
internal
solution
to
programmatically
determine
the
the
risk
that
a
extension
provides.
B
Now
it
was
useful
enough
for
us
that
we
decided
to
release
it
publicly
and
we've
been
operating
it
for
about
two
years
now
with
a
fair
amount
of
interest,
and
when
we
released
it,
we
we
did
some
some
research
into
the
the
chrome
web
store,
and
these
are
sets
from
from
two
two
years
ago,
so
they're
not
accurate
as
of
today,
but
when
we
did
this,
we
found
that
you
know
85
percent
of
extensions
didn't
have
a
privacy
policy,
you
know,
three-fourths
didn't
have
a
support
site.
B
B
This
paints
a
bleak
picture,
but
I
want
to
give
credit
to
to
google,
not
just
because
there
are
googlers
on
this
call
google's
been
moving
in
the
right
direction,
with
with
browser
extensions
with
stuff
like
manifest
v3
having
stricter
review
policies
having
its
data
protection,
bug,
bounty,
which
I've
been
able
to
collect
a
few
dollars
from
which
is
neat,
and
you
know,
requiring
more
extension
side,
privacy
policies
and
requiring
extensions
to
list
why
they
they
need
permissions,
which
is
great
to
see
and
there's
definitely
still
a
long
ways
to
go,
but
they're
moving
in
the
right
direction.
B
So
next
I'm
going
to
go
into
the
solution.
We
actually
built
to
tackle
this.
This
trust
and
risk
issue
here.
B
This
will
look
pretty
similar
if,
if
you've
ever
used,
some
some
like
scanning
service
before
you
can
view
recent
scans
for
for
extensions
that
people
have
made
or
search
and
extension
by
a
name
or
extension
id
here
and
when
you
search
an
extension
at
the
top
you'll
see
a
overview
of
the
extension
and
in
in
browser
extension.
Security
context
matters
a
lot,
because
an
extension
can
have
access
to
read
your
data
on
on
all
sites
and
if
it's
your
password
manager,
that
probably
makes
sense
right.
B
It
needs
to
fill
in
your
your
your,
your
passwords
and
and
there's
a
number
of
extensions
where
something
like
that
would
make
sense.
However,
if
it's
a
justin
bieber
wallpaper
and
it
has
that
same
same
amount
of
permissions-
it's
maybe
cause
for
concern
and
you
need.
I
need
to
dig
in
deeper
and
unfortunately,
it's
very
difficult
to
programmatically
determine
what
an
extension
is
supposed
to
do
and
adjust
your
determination
based
on
that.
B
So
we
still
need
human
eyes
on
this
now,
but
at
the
top
we
can
see
a
short
description
of
the
extension
you
can
see
who
it's
offered
by
contact
info.
If
the
developer
lists
it
number
of
active
users,
a
website
privacy
policy,
support
site,
you
can
view
the
extension
source
right
in
the
browser.
B
If,
if
you
would
like,
you
can
check
out
old
old
versions
as
well
and
when
evaluating
browser
extensions,
we
also
look
a
lot
at
like
good
faith
from
from
developers
where
they
don't
need
to
list
contact
information
on
the
the
web
store.
But
if
they
do
it's
just
another
data
point
for
us
to
be
like:
maybe
they
are,
they
are
doing
the
right
thing
and,
and
we
can
trust
them
a
bit
more.
B
Oh
also,
really
quick
with
privacy
policy.
It's
it's
not
enough
that
that
an
extension
has
one.
Although
it's
it's
really
great
to
see.
You
also
need
somebody
to
to
look
at
the
privacy
policy.
I'm
not
saying
a
lawyer
needs
to
spend
three
months
reviewing
it,
but
I've
I've
seen
malicious
extensions
that
have
privacy
policies
that
are
either
boilerplate
or
they
say
they're
they're
good
about
things
and
just
aren't,
or
they
straight
up
say
like
we're
going
to
be
sending
your
data
somewhere
and
without
looking
at
that,
you,
you
wouldn't
know
all
right.
B
So
next
is
one
of
the
most
controversial
parts
of
of
cruxcavator,
and
that's
that
we
take
a
stab
at
assigning
a
quantitative
risk
score
to
each
extension
and
we
break
it
down
by
different
sections,
and
these
aren't
only
the
these
sections
that
that
can
be
scored
on
and
I'm
going
to
be
going
in
a
lot
deeper
on
risk
scoring
towards
the
end
of
this
presentation.
B
But
we
we
take
a
stab
at
assigning
these
these
risk
scores
and
and
chart
them
here
and
even
provide
small
descriptions
of
like
oh,
like
it's
one
point
of
risk,
because
the
email
is
missing
from
the
web
store
but
where
I
think
it's
a
bit
more
more
useful
is
the
risk
over
time
section
here.
So
when
you
have
this,
this
number,
you
can
plot
it
across
all
the
different
versions
and
kind
of
see
where
the
extension
is
is
trending
and
you
can
see
at
the
beginning.
B
Lastpass
had
had
a
big
drop
in
in
risk
or
which
I'll
go
over
in
a
little
bit.
But
if
you're
looking
at
this-
and
you
see
a
big
spike,
it
could
maybe
mean
that
the
extension
has
has
changed.
Hands
or
there's
a
new
update
and
it
can
access
more
data
which
you
might
want
to
look
into,
because
this
is
not
really
a
good
way
to
know
when
it's
when
an
extension
has
a
new
update
or
if
it's
trending
down,
it's
usually
a
a
good
sign
that
the
developer
is
taking
security
a
bit
more
seriously.
B
Next,
we
we
have
the
permission
section,
so
we
show
some
of
those
permission
warnings
I
was
talking
about
a
bit
earlier,
but
we
also
show
all
the
individual
permissions
and
sort
them
by
by
risk.
We
determine
this
the
risk
of
these
extensions.
Other
people
might
have
different
thoughts
on
on
what's
more
more
risky
and
what's
not
that's
part
of
the
problem
that
I'll
talk
about
a
bit
later,
but
we
can
see
in
lastpass
can
can
interact
with
your
web
requests
and
modify
them.
It
can
read
your
data
on
all
sites
pretty
much.
B
It
can
read
your
tabs
and
do
a
lot
of
other
stuff,
but
next
is
optional
permissions.
So
I
mentioned
earlier
earlier
that
optional
permissions
are
the
same
as
permissions,
but
a
user
has
to
click
yes
or
no,
but
we
actually
score
these
risk-wise
the
same
as
normal
permissions,
even
though
these
are
technically
like
it's.
B
It's
better
security
hygiene
to
to
to
have
these
here
and
that's
because,
in
the
context
of
allowing
an
extension
for
for
our
org,
it's
really
all
or
nothing,
and
we
can't
allow
lastpass,
for
example,
and
say:
hey
users
like
this
is
fine,
but
if
it
ever
asks
to
read
your
cookies,
you
have
to
say
no,
that's
just
unreasonable
ask
for
for
users
and
that's
why
we
score
these
the
same.
But
you
might
not
know
that.
I
think
this
has
changed,
but
older
versions
of
lastpass
could,
if
it
asks,
read
your
cookies.
B
Your
browsing
history
change
your
privacy
settings
and
communicate
with
with
native
applications.
B
Next
is
the
retire.js
vulnerability
scan
that
we
show
here
we
run
retire.js,
which
finds
vulnerabilities
and
third-party
libraries
and
and
surface
them
as
well.
I
want
to
point
out
that
lastpass
is
no
longer
does
not
include
these
vulnerable
libraries
anymore.
This
is
on
an
older
version.
We
actually
scanned
lastpass.
What
was
the
very
first
extension
we
scanned
with
excavator
and
before
it
was
publicly
released.
We
we
found
these.
B
We
talked
to
lastpass
and
we
were
able
to
have
a
conversation
with
them
because,
because
their
event,
a
vendor
of
of
ours
and
like
hey,
we
found
these
vulnerabilities.
Are
you
vulnerable
to
them?
What's
what's
the
deal
and-
and
they
said
you
know-
we-
we
know
about
these
they're
included
in
an
old
version
of
of
the
ui-
that's
still
bundled
with
the
extension
but
isn't
used,
we're
we're
not
vulnerable
and
now
that
they
were
removing
them
shortly
and
sure
enough.
We
were
able
to
verify
the
excavator
that
they
did.
B
I
want
to
note,
though,
that,
with
with
browser
extensions,
when
there
are
vulnerabilities
in
the
the
libraries
that
they
use
it's
more
often
the
case.
Well,
it's
it's
not
so
much
that
the
extensions
are
exploitable
with
these
vulnerabilities,
it's
more
the
case
that
they
don't
have
great
security
hygiene
of
updating
these
these
libraries.
B
Next,
we
have
the
content
security
policy
so
with
with
browser
extensions,
we
often
want
to
know
well
in
a
perfect
world.
We
we
want
to
know
what
they
are
actually
doing,
but
unfortunately
that's
very
hard
to
determine.
So
we
take
the
next
best
thing
and
determine
what
they
can
do,
what
they
have
permissions
to
to
to
do
and
assume
the
the
worst
but
oftentimes
permission
or
extensions
have
way
too
many
permissions,
but
there's
still
a
valid
business
use
case
for
them.
B
So
we
need
to
try
to
gain
some
some
more
confidence
in
in
that
extension
and
content.
Security
policy
can
help
with
this,
because
it's
not
required
for
an
extension
to
to
have
one
of
these,
but
but
if
they
add
one
and
voluntarily
restrict
where
they're
allowed
to
send
data
or
or
load
resources
from
it
can
help.
I
won't
also
point
out
it's
it's
out
of
scope
from
this
talk,
but
extensions
can
potentially
get
around
some
of
the
content
security
policy
restrictions.
B
So
it's
not
the
the
end-all
be-all
if
if
they
can
only
send
data
or
have
only
one
entry
in
here,
but
it's
still
good
to
see,
we
also
use
a
section
to
determine
if,
if
this
is
really
just
communicating
with
some
sas
service
somewhere-
and
if
I
didn't
know
anything
about
lastpass-
I
would
say
yes,
this
is
communicating
with
this
lastpass.com
excuse
me
and
likely
need
to
to
reach
out
to
them
and
sort
of
end
a
review
process.
B
Additionally,
we
we
scan
these
entries
through
virustotal
if
you
have
a
virus
total
key
and
thread
exchange
keys.
Added
to
to
your
group
incorrect
in
incorrect
excavator,
but,
like
I
said,
unfortunately,
extensions
aren't
required
to
define
these,
and
if
they
don't,
we
still
want
to
know
what
it
might
be
communicating
with,
and
that's
where
the
potential
external
communication
section
comes
in.
B
So
potential
external
communication
takes
a
stab
at
assessing
what
the
extension
might
be
talking
to
by
searching
for
http
or
https
wrapped
in
quotes
in
in
the
javascript
we're
working
on
a
v2
of
this
that
does
true
ast
parsing
and
and
does
a
better
job
of
trying
to
you
know
compute,
where
it's
sending
like
what
the
actual
url
that
it's
sending
to
is
and
we're
going
to
run
those
through
thread
intel.
But
I
I
don't
have
a
good
good
date
on
that.
D
B
Yeah,
100
and
and
that's
kind
of
what
what
we're
looking
to
to
solve
with
that,
and
we
have
some
preliminary
beta
code
working,
but
it's
a
bit
more
compute
intensive
than
than
we
originally
planned.
So
we
have
to
do
some
fun
stuff
there,
oh
yeah,
I'm
sorry
did.
Did
you
have
more?
B
Oh
okay!
So
let's
say
we
still
didn't
know
anything
about
lastpass
and
and
the
content
security
security
policy.
Wasn't
there
we
can
see
at
the
top
there
there's
this
like
ui
prod
service,
so
it
might
be
communicating
with
that.
We
also
see
lastpass
appear
a
lot
here
as
well.
We
see
log
me
in
which
is
either
the
current
or
former
owner
of
of
lastpass.
B
B
The
next
section
is
the
manifest
where
you
can
dig
in
deeper
here.
If
you
fully
want
to
explore
that,
we
also
have
related
extensions.
So
maybe
you
weren't
happy
with
lastpass
and
want
to
look
up
something
else
and
if
you're
signed
in
and
added
your
your,
your
orgs
allowed
extensions.
It'll
also
show
you
allowed
related
extensions,
so
maybe,
instead
of
telling
the
user
well
instead
of
allowing
lastpass,
you
can
just
tell
the
user
to
use
like
one
password
instead,
if
it's
already
allowed
in
in
your
org
okay.
B
So
I
just
talked
a
lot
about
what
the
correct
creator
risk
report
looks
like
I'm,
going
to
go
a
lot
quicker
through
the
the
enterprise
section
here,
because
I'm
not
trying
to
convince
y'all
to
deploy
crackscrater
throughout
your
your
orgs.
But
I
think
it's
still
worth
seeing
to
speak
to
the
the
last
goal.
You'll
have
of
kind
of
determining
the
providence
of
of
for
free
all
open
source
libraries,
but
for
us
chrome,
extensions
throughout
our
or
org
kirk's
feeders
api.
B
B
B
You
can
use
risk
score
as
as
a
priority
mechanism
to
determine
what
extensions
you
should
look
at
first
and
potentially
remove
and
we
sort
those
by
risk
there
on
high
risk
and
also
recently
updated,
sends
extensions
will
automatically
update.
B
You
can
look
at
this
to
know
when
there
was
a
new
update
and
what
the
change
in
risk
is,
and
you
can
see
grammarly
shout
out
to
them.
They
they
really
restricted
their
csp
in
that
update.
But
if
it
was
read
and
it
added
you
know,
300
points
risk
or
something.
Maybe
you
should
dig
into
that
and
see
if
you
should
still
allow
it
next,
we
have
extension
user
statistics,
so
we
actually
have
a
helper
chrome
extension
called
cracks.
B
You
can
see
who
had
that
installed
and
maybe
see
it's
only
five
users
and
none
of
them
had
production
access,
and
you
can.
You
can
feel
a
bit
safer,
knowing
that
that
things
could
have
been
worse,
but
if
you
know
what
extensions
people
are
are
using.
You
also
know
what
they're
not
using
so
you
can.
These
are
extensions
that
were
previously
allowed
and
and
in
in
use,
but
nobody
currently
has
them
installed.
Maybe
a
user
left
the
company,
maybe
there's
no
longer
a
valid
use
case
for
it.
B
Finally,
on
on
the
dashboard,
we
have
the
extension
request
section,
so
we
we
like
to
make
things
as
easy
as
possible
on
our
users
at
duo,
and
we
don't
want
them
to
always
have
to
email
us
to
to
allow
an
extension.
So
our
helper
browser
extension
can
detect
when
you
are,
are
viewing
a
extension
install
page
that
is
not
currently
allowed
in
in
your
org
and
throw
this
notification.
B
If
you
click
it,
this
pops
up
and
you
can
type
in
a
business
justification
and
request
approval,
and
then
this
is
where
web
hooks
come
in,
because
you
might
not
want
to
live
on
this
table
here
and
you
can
have
it
like
automatically
create
a
zendesk
ticket
or
something,
and
then
users
can
easily
request
it.
B
That
way,
it's
worth
noting
too,
I
think
google
is,
is
adding
or
or
has
already,
added,
official
support
for
this
in
in
chrome,
which
is
cool
to
see,
as
well
as
adding
more
apis
around
browser
extensions
for
for
g
suite,
okay
whew.
So
I
I
sped
through
the
the
correct
squeeze
report
and
and
some
of
the
more
enterprising
features
that
that
craigslist
has.
B
But
now
I
want
to
spend
some
time
talking
about
the
the
challenges
that
we
found
with
trying
to
assess,
risk
and
trust
in
this
way
and
by
far
the
the
biggest
one.
Is
this?
What's
a
good
risk
score?
This
is
the
the
number
one
question
I've
gotten
since
we've
launched
excavator
and
there's
not
really
a
good
answer
to
this,
and
that's
because
in
in
this
context
the
the
question
slash,
the
underlying
framework
is
is
is
flawed,
where,
like
even
day
day
one
when
we
released
crackscrater
somebody
tweeted
at
us
like
hey.
B
This
is
awesome
good
to
see
like
I
I
just
scanned
some
some
privacy
news
app
and
I
take
a
rating
of
425
is
not
good
and
they're.
They're
right
in
thinking
like
like
you
know,
is
425
good.
Is
it
bad?
It
seems
high,
but
we
don't
give
them
any
scale
to
to
assess
that,
and
that's
because,
when
I
talked
about
earlier
that
the
context
of
of
the
extension
matters,
where
is
it?
B
Is
it
supposed
to
read
all
my
data,
or
is
it
not
supposed
to
there
there's
a
few
more
challenges
which
I'm
going
to
go
over
in
a
sec,
but
we
we
see
orgs
like
really
like
the
fact
that
there
is
some
numeric
risk
score,
because
when
they
have
a
number
they're
able
to
to
do
so,
many
things
they're
able
to
you
know
create
reports,
write
automation,
you
know,
have
some
charts
and
graphs
and
and
have
this,
this
control
over
this
problem
that
they
didn't
necessarily
have
before,
but
because
of
some
of
the
flaws
with
the
risk
score,
you
should
not
write
some
system
where
any
extension
over
425
is
not
allowed
anything
under
well
over
200
as
manual
review
and
anything
under
200
is
allowed.
B
But
but
we
see
orgs
want
to
do
this
and
that's
because
that's
kind
of
intuitive
and
if
I
didn't
know
better
I'd,
probably
write
something
similar
myself
and
that
comes
into
the
the
problem,
with
assigning
numerical
risk
to
something
that
is
more
qualitative
or
opinion-based,
because
even
just
looking
within
the
permissions
category
here,
how
do
you
assess
the
risk
from
one
permission
to
another?
How
do
you
compare
the
the
risk
you
get
from
being
able
to
send
the
user
a
notification
versus
being
able
to
read
the
user's
history?
B
Everyone
would
have
a
different
opinion
and
different
thoughts
on
it,
and
you
know
jubo's
risk
score
was
was
created
a
a
while
ago
and
it
worked
internally
for
us,
but
when
we
released
this
publicly
and
more
people
started
using
it,
we
found
it
it's
tough
to
provide
all
the
context
that
we
have
around
risk
scores
to
all
of
our
users,
and
even
if
you
look
beyond
just
a
single
category
like
how
do
you
compare
the
risk
from
permissions
to
content
security
policy
and
content
security
policy
is
one
of
the
examples
here
on
what
can
kind
of
go
wrong
with
with
risk
scoring
and
with
the
community
where
the
content
security
policy
has
an
interesting
story
on
how
it's
scored
the
way
it
does
essentially
there's
so
many
different
knobs.
B
B
There
is
some
certainty
you
can
say
behind
like
what
c
like
this
csp
is
more
secure
than
this
csp
based
on
the
number
of
entries
and
what's
restricted,
and
that's
why
the
this,
the
the
algorithm
for
csp
risk
scoring
is
fairly
complex,
where
every
entry
in
any
section
of
csp
gets
one
point
of
risk,
but
if
there's
a
star
in
the
entry,
it
gets
five
points
of
risk
an
example.
This
is
like.
Let's
say
you
have
api.lastpass.com:
well
that's
more
secure
than
having
star.lastpass.com,
but
then
what
happens?
B
Well,
then
you
get
into
the
scenario
where
it's
technically
more
secure
for
you
to
list
each
one
individually,
but
it
you're
you're
penalized
via
the
risk
score
by
by
having
more
than
five
entries
there,
and
maybe,
if
you're,
trying
to
optimize
for
risk
score.
You
just
put
the
star
entry,
also
with
with
the
default
or
sorry
with
with
a
miss
with
a
missing
section
of
the
csp
you'll
get
25
points
of
risk,
but
what,
if
you
have
more
than
25
entries
in
there
or
what?
B
But
in
order
to
be
this,
this
granular
we
we
had
to
increase
the
the
like
maximum
amount
of
risk.
The
csp
can
can
give
and
that's
why
it
if
you
forget
a
csp
you'll,
get
377
points
of
risk,
because
it's
25
times
15,
which
is
the
number
of
sections
in
the
csp
plus
plus
a
few
extra
first
for
some
default
stuff.
B
But
the
way
we
score
permissions,
which
is
arguably
much
much,
has
a
much
higher
impact
on
the
security
of
an
extension.
You
know
kind
of
like
how
somebody
can
win
the
electoral
college,
which
is
25
percent
of
the
the
the
the
vote
technically
right.
B
Well,
maybe
we
start
adding
zeros
to
the
risks
that
that
permissions
give
right
instead
of
15,
it's
150
or
it's
1500,
but
then
we
start
getting
into
positions
where
extensions
have
a
risk.
Score
of
you
know
you
you're,
comparing
54
000
of
47,
000
and
and
risk
scores
start
to
have
even
less
meaning,
and
we've
wanted
to
be
very
careful
on
how
we
we
change
the
the
risk
score.
B
We
we've
changed,
risk
score
twice
since
we've,
since
we've
released
our
excavator
and
it's
been
either
improving
the
csp
risk
scoring
or
removing
risk
scoring
on
on
that
potential
external
potential
external
communication
section,
and
we
don't
want
to
keep
changing
something
and
and
seeing
if,
if
that's
better,
because
users
have
already
implemented
flows
with
this
and
and
we
want
to
be
careful
how
how
quickly
we
we
change
things
since
it's
not
just
duo
anymore.
D
B
But
you
you
have
this
trade-off
between
trying
to
pressure
developers
into
doing
the
the
right
thing
and
rewarding
them
for
having
csps
and
and
we've
seen
examples
of
developers
who
wanted
to
lower
risk
scores.
And
if
you
look
up
cruxcavator
on
on
github
for
for
people,
including
the
word
crackscrater
in
in
in
comments
and
merge
requests,
you
can
see.
People
have
used
craigslist
reports
to
encourage
extension
developers
to
you,
know,
add
csps
and
and
do
stuff
like
this
there's
there's
an
example
I
can't
share,
but.
B
B
But
anyway,
we've
we've
considered
a
few
other
approaches
like
multiplicative
risk
scores,
like
maybe
extensions.
The
the
permissions
multiply
the
risk
from
other
sections
because
it
amplifies
like
what
the
risk
might
be,
or
even
vice
versa,
but
this
was
just
getting
too
hand
wavy
and
arbitrary.
B
B
You
could
switch
to
letter
grades,
but
that's
just
a
reskinned
like
risk
score.
Essentially
you
could
let
or.
D
Worse,
actually,
because
if
I
didn't
get
an
a,
I
would
not
expect
lastpass
to
have
no
risk
yeah.
That
would
be
silly.
I
mean
fundamentally
what
it's,
what
access
it
needs
is
much
stronger.
I
have
to
trust
it
in
a
way
that
I
would
not
trust
joe
average
extension
and
that's
okay.
B
Yeah
and-
and
you
know,
we've
we've
lastpass
shouldn't,
have
zero
points
of
risk
and
and
there's
a
reason.
We've
been
using
risk
scoring
and
users
still
think
risk
equals,
like
maliciousness,
they're
thinking
more
of
us
as
virus
total,
good
bad
versus
risk
and
we've
even
considered
making
it
potential
risk
like
trying
to
add
more
fluff
to
like
have
users
see.
B
Let's
you
know
see
that
this
is
like
a
a
high
risk.
Score,
isn't
inherently
bad,
but
just
because
we
have
users,
I've
I've
had
I've
had
librarians
cc
me,
while
sending
a
krexcavator
report
to
extension
developers
asking
me
to
tell
their
their
developers
to
lower
their
their
risk
score
when
it's
really
not
like.
B
So
being
that,
like
authority
to
assign
these
these
risk
scores
has
created
problems,
and
you
know
that's
why
we've
considered
letting
orgs
define
their
their
own
risk
and
we
this
functionality
isn't
like
technically
supported
in
the
ui,
but
because
cracksville
is
api.
First-
and
you
know,
people
are
smart,
they
could
easily
fetch
a
report
and
then
just
change
change.
B
The
risk
scores
based
on
the
data
we
we
provide,
or
we
even
consider
just
dropping
risk,
scores
all
together,
because
the
answer
we
give
to
what's
a
good
risk
score
is
that
depends,
and
you
really
have
to
look
at
why
the
extension
is
getting
the
the
risk
that
it
does
and
and
what
the
extension
is
supposed
to
do
and
make
a
determine
based
on
or
make
a
determination
based
on
your
orgs
risk
profile
early
and-
and
that
leads
me
to
the
the
end
of
the
prez
here
and
hopefully
I
was
able
to
provide
some
some
context
for
for
for
y'all
on,
on
the
the
mind
of
a
consumer
who
had
a
problem
with
with,
in
this
case,
chrome
extensions.
B
I
forget
the
name
of
it,
but
we
we
had
a
problem
with
being
able
to
to
trust
these,
and
this
was
the
solution
we
we
created
and
we've
seen
a
lot
of
interest
from
many
organizations
and
we've
we're
we're
happy
with
the
change
that
we
were
able
to
affect,
and
it's
provided
a
lot
of
value
for
us,
but
there's
definitely
been
a
lot
of
road
bumps
along
the
way
and
we're
still
learning
every
day.
B
So
with
that,
if
you
all
have
any
questions
happy
to
answer
them
or
if
you
think
of
anything
later
and
want
to
chat,
you
can
email
me
at
jrickard
cisco.com
and
I'm
always
happy
to
nerd
out
about
browser
extensions,
anytime
cool.
So
so
thank
you
there
any
questions
I
can
answer.
A
Thank
you,
jacob,
just
quick
question:
do
you
have
contacts
on
the
google
side,
for
you
don't
to
give
out
names
or
anything,
but
if
there's
anything
that
I
could
help
support
you
with
and
you
know
pushing
people
feel
free
to
shoot
me
an
email
or
something.
A
You
know,
there's
stuff
that
you're
dying
to
get
implemented
or
something
I
could.
I
could
nudge
and
see
what
I
can
do
from
my
side
and
then
more
of
a
comment
than
a
question.
I
think
this
is
really
interesting.
It's
got
a
lot
of
overlap
with
some
of
the
things
that
we've
been
doing,
not
only
in
this
working
group,
but
we
have
the
scorecard
project.
A
I
think,
is
the
one
you're
referring
to
where
we've
shied
away
from
giving
a
numerical
risk,
and
it's
more
of
like
a
true
fault
of
objective
data
and
like
take
it,
what
you
will
you
know,
sort
of
a
thing,
so
thank
you
again
for
presenting
and
feel
free
to
reach
out.
If
I
can
be
of
help
for
anything.
Oh
I
do.
I
guess
I
do
have
a
question.
Is
you
said
this
is
open?
Is
it
open
source
like?
Is
there
is
there
help?
A
Well,
I'm
not
sure
how
we
you
know,
there's
things
that
we
could
help
from
the
from
the
community
side.
Like
you
know,
the
scorecard
is
kind
of
interesting
if
you
wanted
to
use
it
to
look
at
dependencies
that
way,
and
it
gives
you
you
know
more
information
about
dependencies
that
these
extensions
are
taking
in,
but.
B
Yeah
so,
unfortunately,
correct
creator
is
not
open
source.
I
know
it's
cardinals
in
presenting
to
the
group
here:
it's
it's
free,
but
not
open
source.
We
we
host
it.
There's
there's
a
number
of
reasons.
Why
that
I
can't
necessarily
go
into
fully
on
this
recorded
time
but
yeah.
If,
if
there's
any
real
interest
in
in
changing
something
in
in
increxivator
or
learning
more
about
it,
we're
always
open
to
two
discussions
there
and
yeah.
B
I
I
think
I'm
definitely
gonna
look
into
the
security
scorecard
project
you
all
have
because
we're
always
looking
to
add
more
widgets
into
crackscreen
to
help
give
people
more
more
data
points.
So
thank
you.
B
A
E
Cool
yeah:
this
is
just
a
quick
fyi
in
the
best
practices
working
group.
I
noticed
that
we've
got
a
whole
bunch
of
different
things.
Now
that
recommend
people
cryptographically
sign
and
release
artifacts,
and
every
time
I've
talked
to
a
project
that
isn't
doing
this
about
doing
it.
E
They
start
asking
how
and
what
they
should
use
and
there's
kind
of
an
overwhelming
number
of
choices
on
this,
and
it
seems
like
none
of
them
are
good,
and
so
I
just
trying
to
see
if
anybody's
interested
in
actually
trying
to
put
together
a
you
know,
guide
of
if
you're,
just
trying
to
publish
a
binary
on
github
and
want
to
sign
it.
E
Here's
what
you
should
do,
here's
how
you
should
here's
a
way
you
can
do
it
if
anybody
wants
to
do
anything
more
powerful
and
I'm
probably
not
going
to
ask
those
questions,
but
just
some
kind
of
just
minimal,
viable
best
practice
on
that
I'll
share
I'll
forward
that
email
over
to
here
too,
and
we
can
just
see
if
anybody's
interested
in
working
on
that.
D
Yeah,
yes,
I'd
be
I'd,
be
interested,
I'm
not
sure.
I
wanted
to
sign
up
to
start
it,
but
I
want
some
once
there's
something
written.
I
can
start
convincing
cool
yeah
my
name's.
Definitely
in
the
hat.
E
D
A
D
Yeah,
and
also,
I
don't
think
everybody
on
the
call
now
was
on
at
the
beginning,
so
the
first
bullet
on
the
agenda.
Let
me
replug
the
awesome
stuff
that
kim
did
of
summarizing
the
last
number
of
meetings.
So,
if
you
haven't
read
it,
please
do
yeah.