►
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).
A
Okay,
we're
live
so
welcome
to
the
node.js
next
10
mini
summit
on
wasm
and
security
model
and
related
things
like
profile,
security
policies
and
so
forth.
We
had
an
agenda
in
the
the
issue,
which
was
you
know.
The
first
90
minutes
to
look
at
wasm.
Have
a
break
then
go
into
the
permissions.
Paul
security
model
for
90
minutes
have
a
break
and
then
sort
of
wrap
up
and
capture
next
steps.
A
A
B
A
Okay
thanks,
elise,
ulysses.
C
Yep,
hello,
yeah,
I'm
I'm
lisa,
I'm!
I
have
been
the
last
couple
of
years
working
on
some
open
source
tools
and
events,
a
lesson
about
security
and
working
close
to
the
security
working
group.
So
my
interest
in
the
meeting
as
well
will
be
a
lot
around
the
permissions
and
the
security
model,
and
all
of
that.
A
Sounds
good
luke
wagner.
D
Hello
mc
wagner,
I
work
at
fastly
on
webassembly
standards
and
evolution
interested
in
the
javascript
api,
esm
integration
and
I
work
on
things
like
interface
types
and
the
component
model.
Thanks.
E
Okay
thanks
thomas
hi,
so
thomas
I'm
working,
I'm
part
of
a
security
working
group
and
yeah
working
with
not
yet
since
eight
years-
and
I
like
you
this
I'm
following
closely
the
work
around
the
security
so
yeah,
my
main
interest
is
our
own
permission
and
security
model.
E
Okay,
thanks
richard.
F
Hi,
I'm
richard.
I
work
for
red
hat,
I'm
on
the
no
tsc
release
and
build
working
groups,
and
I'm
I'm
attending
to
just
get
a
general
feel
of
discussions
and
see.
What's
sort
of
coming.
Next
sounds
good.
Rodney.
G
I'm
rodney
russ.
I
work
at
red
hat
as
well,
and
I'm
I'm.
I
have
a
general
interest
similar
to
richard
to
see
what's
coming
up
in
both
walls
and
then
on
the
security
side.
H
I
F
A
Okay,
chensal.
A
J
A
Okay
sounds
good
and
so
and
janjong
mentioned,
I
guess
it
sounds
like
he
can't
the
might
have
been
working
or
something
like
that.
So
people
can
keep
an
eye
for
his
comments
in
the
chat
we
can
hopefully
relay
them
across.
A
I
think
that's
everybody,
I'm
michael
dawson
active
in
in
the
community
and
in
the
next
10
efforts.
So
I
have
an
interest
in
helping,
or
you
know
hoping
that
you
know
we
can
come
up
with
what's
important
for
us
as
a
project
on
the
wasm
and
on
the
permission,
security
models
to
ensure
our
future
success
so
interested
in
both
of
them
from
that
perspective.
A
Okay,
so,
let's
start
out
with
wasm.
We
pretty
much
have
a
blank
slate
here.
Does
anybody
have
any
suggestions
or
things
that
you
know?
Maybe
we
should
should
kick
off
with
in
terms
of
what
we
should
discuss
on
that
front.
A
I
guess
one
area
we
could
touch
on
is
like
the
wasm
support
within
node
itself,
how
we
think
that
fits
in
with
the
rest
of
the
ecosystem,
and
you
know
where
we
would
see
people
running.
You
know
yeah.
I
guess
where
it
fits
into
that
ecosystem.
I
I've
seen
at
least
one
tweet.
Where
somebody
took
a
look
at
it
and
said:
hey,
you
know
the
implement.
The
the
supporting
node
is
good
enough.
If
you're
going
to
run
wasm,
you
might
as
well
just
run
it
on
node
we
could
figure
out
like.
A
J
So
I
haven't
run
wide
of
a
node
for
a
while,
but
usually
it
always
came
down
to
what
are
the
capabilities
of
the
platform
when
I
compile
anything
from
wasm
to
javascript,
so
I
hit
the
wall
with
threads.
I
hit
the
wall
with
cisco's
and,
as
I
said,
I'm
highly
ignorant
of
the
latest
updates
on
that,
but
I
guess
one
goal
would
be.
How
can
you
take
any
code
base
and
be
confident
that
you,
you
can
run
that
and
node
over
wasm
without
banging
your
head
on
the
wall?
J
D
What
it
doesn't
give
you,
but
we
kind
of
know
we
need,
and
everyone
wants
it's
just
a
matter
of
kind
of
motivating
the
core
spec
work
is
an
actual
instruction
inside
of
corwasm
to
actually
fork
a
thread
directly,
just
giving
it
a
funk
graph
a
function
reference,
it's
like
a
function
pointer.
So
that
way
you
didn't
need
to
explicitly
create
this
worker,
which
is
a
whole
separate,
js
environment
and
then,
like
do
all
this
coordination,
which
is
painful
in
many
many
dimensions,
so
we
know
that's
necessary.
D
Nobody's
currently
stepped
up
to
do
that
work.
It
has
some
challenges
like
when
I
spawn
this
thread.
Can
it
you
know
these
these
threads,
that
aren't
the
original
main
thread.
They
clearly
can't
just
call
the
same
javascript
imports
that
the
main
thread
can
because
then
you'd
have
multi-threaded
javascript.
So
what
do
you
do?
What
what
it?
What
does
it?
What
can
these
threads
do?
D
Can
they
call
nothing
and
so
there's
there's
some
interesting
design
work
there
and
that's
why
it's
like
it's
a
daunting
task
that
we
know
we
need
to
do
but
nobody's
really
kind
of
dove
into
it
just
yet,
but
I
think
it's
just
a
matter
of
time
before
that
does
right
rise
to
the
top
of
the
priority
cube
I'd
be
curious
to
ask
is
if
you
can
do
threading
now
in
node.js,
is
it
by
creating
like
a
node
worker
and
then
post
messaging,
a
shared
array
buffer
to
it
and
then
basically
doing
likewise,
what
you
do
in
a
browser.
I
Yeah
yeah,
that's
the
same.
That's
essentially
the
only
way
right.
So
one
thing
I'd
be
excited
for
is.
I
know
that
v8
has
an
experimental
stack,
switching
implementation,
so
we
could
so
I've
done
a
bunch
of
implementations
where
you
can
either
have
a
web
assembly
per
thread
which
is
well
terribly
slow
in
the
end
and
you
kind
of
waste
the
entire
the
entire
model
behind
node
and
javascript
in
general,
is
doing
as
much
work
in
a
single
thread
as
possible,
which
currently
with
web
assembly.
I
J
I
Of
course,
which
rewrites
your
module
to
yeah
do
async
work,
but
it
does
all
these
stack
unwinding
and
all
that
in
web
assembly.
So
it's
terribly
slow
by
a
large
factor
depending
on
your
stack
size
and
all
that,
and
it
takes
a
bunch
of
additional
memory
and
if
you
don't
use
it
without
scripting,
you
have
to
write
all
the
little
level
handling
yourself.
I
So
if
we
can
get
some
like
stack,
unwinding
or
stack
switching
into
node
in
a
way
that's
exposed
to
the
application
or
maybe
not
exposed
and
somehow
usable,
that
would
probably
be
a
huge
benefit
without
having
to
create
threats
explicitly.
I
D
D
And
then
the
follow
on
would
be
to
add
these
stack
switching
primitives
into
core
wasn't
so
you
could
do
finer
grain
like
kind
of
co-routine
like
if
your
language
needs
that
but
javascript
doesn't
so
so
do
if
y'all
have
any
direct
feedback
channels
to
the
v8
team
and
say
yes,
we
really
want
this,
like,
I
think,
it'd
be
helped
them.
You
know
increase
prioritization
of
this.
It's
work
is
ongoing
and
I
even
think
there's
a
prototype.
That
sort
of
works
maybe
doesn't
hit
performance
objectives,
but
it's
definitely
in
progress
yeah.
D
I
Yeah,
that
would
be
super
helpful,
super
valuable
for
node
and
most
platforms,
probably
but
especially
for
node,
where
we
have
to
try
to
as
much
work
in
a
thread
as
possible
and
then
the
other
part
where
we
can
that
kind
of
works.
Well
with
that,
where
we
have
to
do
more
node
side
is
the
other
part,
is
you
can
do
all
the?
Even
if
you
can't
do
it
in
a
synchronous
or
in
an
async
way,
regardless?
I
You
still
have
to
copy
a
bunch
of
data
between
the
web
assembly,
linear
memory,
section
and
node
memory
or
like
any
javascript
memory,
so
the
more
apis
we
have
that
can
write
to
a
given
buffer
or
array
buffer
or
a
human
eight
array
or
any
data
view
anytime.
They
were
real.
That
would
be
very
helpful
and
that's
something
that
node
can
actively
improve
upon
so
yeah,
not
always
returning
a
buffer,
but
instead
allowing
apis
to
access
buffers.
D
I've
been
kind
of
thinking
about
this
more
recently
is
streaming
into
or
out
of
webassembly
memory,
like
a
major
use
case,
are
streams
a
big
part
of
this,
or
are
we
talking
about
other
kinds
of
apis
that
aren't
streaming
like?
I
don't
know
well
browse
you
have
canvases,
but
probably
not
node,.
I
It's
I
I
haven't
seen
many
use
cases,
streams,
processing,
implementing
that
on
webassembly
should
be
possible
and
especially
then
copying
data
would
be
a
major
performance
drawback,
so
it
would
be
super
helpful
to
have
like
a
zero
copy
approach.
There
then
again,
most
of
these
streams.
We
have
either
very
much
I
o
bones,
so
we
don't
really
care
much
about
copying
or
they
are
cpu
bound
like
the
crypto
streams
and
all
that
which
we
don't
implement
in
web
assemblies
so
but
yeah.
It
would
certainly
help
for
enabling
streaming
to
have
zero
copy
operations.
D
So
have
you
seen
that
this
byob
reader
proposal,
the
idea
there
is
the
boa
b's
for
bringing
your
own
buffer?
So
at
the
moment
it's
it's.
It
was
proposed
in
a
pre-shared
array,
buffer
world.
You
give
it
an
array
buffer
and
it
detaches
it.
So
it
can
take
it
off
thread
and
right
into
it
from
some
other
network
thread,
and
then
it
gives
you
roughly
the
same
memory
but
in
the
wrapped,
with
a
new
array
buffer
object
back
and
then
you
kind
of
do
this
double
buffering
thing.
D
Then
this
byob
buffer,
the
boby
reader,
could
take
a
view
to
a
shared
array
buffer
and
then
just
write
into
it
racially
from
the
network
thread,
and
so
that
way
I
can
just
like.
Have
my
linear
memory
and
just
pass
basically
a
pointer
into
it
and
it
gets
written
to
from
whatever
network
thread.
Ideally
as
it
goes
from
kernel
space
into
user
space,
it
goes
directly
into
linear
memory,
and
so
we're
like
doing
no
worse
than
like.
D
You
know
in
the
ideal
case,
so
so
that
that's
a
particular
if
you
want,
I
can
drop
a
link
to
that
proposal
in
the
github
issue
and
repo
we'll
be
ready
to
find
that
yeah.
A
So
so
I
guess
you
know
if
you
mention,
if
we're
mentioning
tobias,
that
the
the
like
copying
from
wisem
memory
to
node
memory
is
that
something
we
need
to
do
work
in
node?
Or
is
that
something
that
you
know
we
get
through
the
the
v8
implementation
and
current
need
to
encourage
them?
To
add
something
like
that.
I
That
direction
getting
data
from
webassembly
to
node
is
usually
simple
since
most
node
apis
don't
work
on
array
buffers,
but
on
buffers
or
you
and
8
arrays.
So
we
can
already
just
create
a
typed
area
which
would
use
a
part
of
web
assembly
memory.
Now
the
tricky
part
with
that
is
that
web
assembly
does
detach
array
buffers
whenever
you
resize
your
memory.
So
that
is
a
super
tricky
part.
I
So
I
believe
that's
something
I
came
across
in
the
past,
maybe
being
able
to
create
a
view
of
memory
that
is
valid
as
long
as
that
part
of
memory
isn't
deallocated
so
right
now,
even
if
you
increase
the
size
of
your
web
assembly
memory,
the
entire
array
buffer
that
represents
the
web
assembly
memory
is
detached.
So
you
cannot
access
any
data
view
as
soon
as
you
detach
as.
J
I
I
Assembly-
and
that
can
happen
by
a
single
cpu
instruction
within
your
web
assembly
code.
So
as
soon
as
the
dynamic
allocation,
for
example,
that's
added
by
your
ellipse
or
whichever
runtime
you
use
and
as
soon
as
it
increases
the
size
of
your
web
assembly
instance.
The
and
all
pointers,
essentially
that
you
have
from
javascript
become
invalid.
I
So
that's
the
major
issue
with
passing
pointers
into
that
to
any
node
apis,
which
is
something
that
we
can't
do
much
about,
which
is
something
that
webassign
you
would
have
to
do
something
about,
but
that
is
still
the
simpler
part.
The
more
complex
part
is
getting
data
from
node
apis
into
webassembly
without
having
to
copy,
so
that
would
require
node
apis
to
accept
a
buffer
where
to
write
data
which
some
do
like
the
file
io
stuff.
I
That
does
support
that,
but
many
other
apis,
don't
so
many
apis
and
it's
very
non
javascript
to
allow
these
low-level
memory
routines.
Essentially,
for
example,
like
all
the
web
standards,
except
from
the
bringing
our
buffer
implementations.
Now
all
the
other
apis
always
allocate
new
memory
and
return
new
array
buffers
not
even
views
just
array
buffers
which
are
terrible
for
yeah.
They
make
it
impossible
essentially
to
implement
zero
copy
and
loop.
Maybe
you
have
some
idea
about
the
about
having
persistent
views
on
web
assembly
memory
that
don't
get
detached.
D
The
the
root
issue
there
is
with
a
normal
memory
the
memory.grow
can
reallocate,
and
there
tends
to
be
this
baked
in
assumption
that
the
pointer
doesn't
move
over
time.
You
know
I
hand
out
a
pointer.
You
know
you
have
to
worry
about
a
lot
more.
You
know
use
after
free,
like
you
know,
deep
security
problems.
So
that's
why
it
does
this
eager
detach.
D
However,
a
workaround
is,
if
you
make
the
memory
shared,
but
don't
actually
share
it,
just
make
it
shared
what
the
engine
does
anyways
is
it
does
a
max
it
tries
to
allocate
as
much
as
it
can
from
the
maximum
size
of
the
memory
and
it
doesn't
map
in
it.
You
know
it
unmaps
most
of
it
and
then
it
only
maps
in
like
the
section
that
you've
grown.
So
when
you
grow
it
just
maps
in
more
memory,
it
never
re-alex,
because
realic
in
a
multi-thread
scenario
would
be
crazy
anyway.
D
I
That's
my
solution.
It
still
makes
a
lot
of
sense.
The
other
problem
I
usually
face
is
as
soon
as
you
try
to
cross,
compile
some
c
code,
some
library,
some
application
to
web
assembly
and
then
run
that
in
the
browser
or
a
node
on
any
runtime.
You
usually
have
to
allocate
some
memory.
You
can
expose
the
malloc
function.
I
You
can
do
all
the
memory
in
javascript,
but
then
you
kind
of
have
the
discrepancy
between
the
javascript
garbage
collection
and
the
low-level
memory
management
and
yeah
dc
implementation,
essentially
in
your
web
assembly
module,
so
it
would
be
like.
Ideally,
it
might
be
good
to
have
like
a
memory
type
array,
some
view
some
view
of
your
weapons
on
your
memory,
whose
garbage
collector
kind
of
calls
back.
I
D
Yeah,
the
wasm
dc
will
help
for
the
languages
that
can
target
wasm
gc
because
they
just
integrate
with
the
gc,
but
even
with
linear
memory,
languages
there's,
I
think,
now
standard
and,
I
think,
even
implement
v8
there's
this
finalization.
I
think
it's
called
what
in
a
thing
called
group.
So
this
is
a
thing:
you'd
want
to
use
like
a
glue
code
generator
to
do
for
you,
but
you
can,
when
you
hand
out
an
object.
That
is
like
a
view
onto
webassembly
memory.
I
A
So
I
guess
I'm
I'm
wondering
maybe
like
we
get
our.
Maybe
we
should
like.
We
can
start
by
talking
about
some
of
the
or
we
can.
We
can
talk
about
some
of
the
fundamental
questions.
Like
you
know,
one.
A
A
I
I
Still
web
standards,
especially
with
web
assembly,
it's
probably
important
for
note
to
try
to
influence
wazi
specifically
to
make
sure
it
also
works
for
server
runtimes,
because
we've
seen
so
many
standards
that
work
great
in
browsers,
but
not
really
a
node
or
any
server
on
time.
So
we
should
probably
try
to
actively
see
that
whilst
it
develops
into
a
direction
that
we
can
support
a
node
and
that
doesn't
just
work
in
browsers.
A
Okay,
that's
a
good
point.
So
not
only
is
an
important
area,
but
it's
an
important
area
that
we
actually
try
and
influence
and
stay
on
top
of
and
okay,
any
any
other
bits
like
additional
standards
or
specs
or
something
that
you
know
are
like
that
that
we
should
have
on
our
radar
and
should
be
thinking
about.
D
Well,
if
I
may
plug
my
own
thing
that
I'm
working
on
there's
a
set
a
little
cluster
of
standards
that
have
kind
of
been
renamed
over
time
and
also
recently,
two
of
them
just
got
merged
previously,
you
might
have
heard
of
interface
types
and
module
linking
they've,
recently
kind
of
been
fused
into
into
one
kind
of
new
proposal,
which
is
a
layered
spec.
That's
like
on
top
of
wasm.
D
So
it's
it's
not
changing
core
wasn't
but
adding
a
thing
on
top
called
the
component
model
and
the
idea
is
to
try
to
be
able
to
give
wasm
high
level
type
signatures
instead
of
kind
of
this
low
level
thing.
That's
all
like
arrays
of
bytes
and
i32s,
but
kind
of
describe
high-level
types
like
lists
of
strings.
D
The
idea
is
it's
polyfillable
in
terms
of
chorosim,
so
you
can
take
a
component
binary
and
spit
out
a
core
module:
that's
wrapped
with
js
glue
code
or
python
glue
code
or
whatever
language
glue
code.
So
that
would
be
like
the
initial
kind
of
way
people
would
practically
use
it.
But
the
idea
is
that
both
you
know,
js
engines
could
natively
implement
components
and
then,
just
in
the
way
that
today,
wasm
models
have
an
automatic
js
binding.
D
It's
like
a
low
level,
one
of
like
numbers
get
course
to
i32s
and,
like
big
ends,
get
conversed
converted
to
i64s
and
back
that
same
js.
Api
could
also
understand
these
high
level
types
of
components
and
so
do
coercions
between
like
a
javascript
string
and
the
interface
type
string,
there
go
back
and
forth,
and
what
that
would
do
is
automatically
copy
into
and
out
of
the
linear
memory
in
kind
of
an
optimized
sort
of
way
so
yeah
initially,
it
would
be
implemented
by
polyfill
and
even
some
folks
already
have
working
kind
of
js
polyfills.
D
If
you've
seen
rust's
wasm
bind
gen
it
currently,
you
know
lets
you
use
high
level
rust
types
and
it
generates
js
glue
code
wrapper
that
ultimately
wraps
up
your
wasm
as
an
esm,
so
you
can
just
import
it.
The
goal
is
that
it
could,
in
the
future,
spit
out
a
component,
and
you
would
write
the
same
import
statement
and
it
would
just
work
so
there's
a
native
implementation
of
the
bindings
with
for
components
and
also
esm
integration
for
components
to
make
them
kind
of
feel.
D
Like
yes,
modules,
but
without
the
glue
code,
it
would
just
be
I'm
just
directly
importing
that
that
module.
So
that's
you
know
we're
actively
kind
of
prototyping
this
in
in
in
wasm
time
and
in
in
the
polyfills
and
and
a
bunch
of
related
tools
for
producing
and
consuming
and
polyfilling
them.
But
as
it
moves
a
little
farther
along
this
year,
it
it
might
be
interesting
to
look
at
maybe
having
maybe
taking
just
even
the
proto
the
polyfills
and
using
that
to
implement
prototype
support.
D
Experimental
prototype
sport,
you
know,
would
be
maybe
an
interesting
thing,
but
hopefully
would
make
the
job
the
the
experience
of
using
wasm
from
javascript.
You
know
just
a
whole
lot
easier
and
less.
You
know
less
glue
code
and
less
machinery
to
worry
about.
A
I,
I
guess,
does
that
bring
us
we've
had
long
long
time
discussion.
I
don't
know
it
could
be
it's
like
more
than
five
years
about
wasm
and
native
add-ons,
and
you
know.
Typically,
the
challenge
has
been
around
the
types
and
that
you
know
you
with
only
the
basic
types
there's
only
so
much
you
can
do
so
there
isn't,
they
haven't
been
wasn't
hasn't
been
like
okay,
we
write
our
add-ons
and
wasn't.
D
Yeah
yeah.
I
think
that
that
that's
a
great
point
that
I
have
totally
forgot
about
yeah.
This
would
be
yeah
using
wasm
to
avoid
kind
of
the
challenges
of
native
modules.
All
the
native
code
challenges
yeah,
so
these
components
could
be
thought
of
as
kind
of
native
modules,
but
but
not
like
kind
of
nest.
Node
specific
you
could
take
one
and
drop
it
also
in
a
browser,
so
you
know
in
in
any
case
you
take
this
whatever
c
code,
compile
it
down
to
a
component
and
then
just
import
it,
and
it's
just
an
import
statement.
D
D
Maybe
they
they
wanted
to
replace
use
it
in
python
or
they
wanted
to
use
it,
and
you
know
javascript
or
lua
or
so
so
in
theory,
you
have
more
people
producing
these
things
than
just
exclusively
targeting
you
know,
node
native
modules,
so
it
can
maybe
access
a
wider
set
of
compiled
code.
A
Right
and
and
does
it,
handle
the
like,
there's
sort
of
the
two
two
aspects
of
that
one
is
the
I
want
to
make
a
call
and
then
sometimes
the
code.
That's
right,
the
native
code.
That's
running,
wants
to
interact
with
javascript.
The
other
way
is
it
does
it
have.
Does
it
does
have
something
on
that
front
as
well
or
yeah.
D
Yeah,
that's
right,
so
these
components
like
wasm
modules,
have
imports,
and
so
you
could
import
a
function
from
javascript
and
then
call
it
like
as
a
callback
effectively.
D
The
high
level
types
currently
they
were
sketching
would
include
both
future
and
stream
types
that
would,
by
design,
binds
to
promise
and
readable
stream
and
and
be
with
this
byob
stream
I
was
mentioning
earlier,
would
also
integrate.
So
when
you
import
one
of
these
components
and
it
returns
a
future
in
its
kind
of
abstract,
high-level
type,
you
would
just
get
a
promise
that
popped
out,
so
you
could
just
await
it
without
any
extra
glue
code.
D
I
An
interesting
one
to
keep
an
eye
on
since
you
brought
up
comparing
it
to
native
add-ons,
which
of
course
is
a
huge
topic.
Since
there
are,
I
guess,
kind
of
certain
categories
that
native
add-ons
fall
into
it
or
and
whether
one
has
been
a
great
replacement
where
it's
essentially
just
about
porting
c
code
that
you
want
to
use
a
node
or
some
rust
code
or
some
other
language
that
you
can
compile.
I
The
other
parts
were
performance
matters
and
then
usually
native
add-ons,
of
course,
still
beat
webassembly
in
many
cases,
by
a
small
or
large
margin,
depending
on
what
you're
doing
and
then
again,
the
other
part
of
native
add-ons
that
we
see
are
essentially
exposing
hardware
features
or
certain
operating
system
features
which
we
don't
expect
to
see
in
webassembly.
I
So
really,
the
main
use
case
has
been
on
performance
critical
code,
making
it
at
least
faster
than
javascript,
even
if
not
faster
than
a
native
add-on,
which
is
very
slow
to
call
into
by
the
way.
So
if
you
call
into
a
native
add-on
that
call
alone
takes
up
so
much
time
that
sometimes
even
if
a
web
assembly
itself
slower,
you
can
still
call
it
webassembly
much
faster
than
into
the
native
add-on.
I
So
for
small
operations,
webassembly
is
still
much
faster,
and
so
there
are
some
native
villains
that
we
don't
expect
to
replace,
especially
in
like
the
close
to
a
hardware
or
anything,
however
accelerated.
I
know
we
do
have
like
these
sim
proposals
and
all
that
that
have
been
merged.
I
believe
so.
There
there's
definitely
a
path
forward
for
that,
and
maybe
even
for
like
crypto,
there
was
a
wasabi
proposal
to
use
hardware
acceleration
there,
and
maybe
maybe
we'll
have
constant
time
web
assembly
in
the
future.
I
At
some
point,
so
we
can
implement
other
cryptographic,
algorithms.
From
the
other
point
of
from
the
other
side,
when,
when
a
package
author
wants
to
publish
a
native
add-on,
they
essentially
have
to
write
a
configuration
file
that
tiles
node
how
to
or
tells
npm
how
to
compile
their
package
locally
on
the
machine
of
the
user.
Whereas
with
web
assemblies
and
supportable,
we
have
a
huge
advantage
that
the
author
can
just
compile
it
once
when
they
publish
it,
and
so
the
web
assembly
module
is
uploaded
to
npm
in
a
compiled
format.
I
And
then
your
runtime
takes
it
and
just
compiles
it
for
your
local
cpu
and
operating
system,
and
maybe
that's
something
where
node
could
look.
If
we
can
make
any
improvements,
we
have
integra,
we
have
integrated
most
of
the.
We
have
good
tutorials
on
the
node
add-on
api
and
how
to
use
it
to
compile
your
native
add-ons
as
an
author
as
a
package
author,
and
maybe
we
can
try
to
ramp
up
on
the
web
assembly
side
of
that.
I
A
I
D
Out
of
curiosity,
what
right
now
is
the
state
of
the
art
for
how
you
physically,
like
if
you
want,
if
you
have
some
glue
code
that
wraps
the
wasm,
as
is
usually
the
case,
if
you're
publishing
a
package,
how
does
that
js
glue
code
get
the
wasm
module?
I've
heard
people
like
base64,
encode
them
in
strings
and
then
there's
that
route?
Is
it
or
is
there
or
did
it
or
is
there
something
else.
I
Yeah,
the
base64
thing,
I
believe,
is
mostly
browsers
forward
for
not
having
a
proper
way
of
including
other
files.
So
in
a
node
you
can
of
course
load
it
through
the
file
system.
Apis.
If
you
have
it
as
a
separate
file,
you
can
fetch
it
from
an
online
resource,
whatever
you'd
like
to
do,
and
there
is
also
there
are
some
efforts
on
integrating
it
with
the
es
modules.
So
you
can
import.
I
Yeah,
so
that's
certainly
important.
It
might
just
make
the
requirements.
It
kind
of
does
depend
on
yc
being
properly
set
up.
If
you,
if
you
assume
your
application,
can
do
anything
so
with
es
modules.
From
my
point
of
view,
the
main
issues
imports
two
web
assemblies.
So
if
that's
something
non-standard,
that
becomes
a
huge
issue
and
I
have
no
idea,
if
notice,
in
a
position
to
do
anything
about
that
or.
J
I
Is
a
problem
but
to
answer
your
original
question,
I
believe
the
base64
encoding
is
mostly
because
of
browsers
and
now
we'll
fetch
umbrella,
some
in
web
pages,
I
usually
just
use
fetch
and
then
instantiate
streaming.
I
am
not
sure
if
we
even
have
the
streaming
interfaces
yet,
and
that
is
a
major
issue
in
node.
D
Cool
you
mentioned
when
you're
talking
about
esm
integration.
Did
you
did
I
hear
right?
They
were
saying
like
how
the
imports,
when
you
use
zsm
integration,
how
the
imports
of
that
was
a
module.
Get
satisfied
is,
is,
and
is
it
because
normally
wasm
imports
are
like
these
low
level
again,
i32
is
all
over
the
place.
You
need
this
wrapper,
and
so
you
have
to
somehow
inject
the
wrapper
around
whatever
other
functionality
it
might
have
wanted
to
import
and
that's
a
problem.
I
D
Yeah,
I
think
that
is
a
real
problem,
so
I
I
would
agree,
and
so
there's
a
a
variation
on
the
esm
original
esm
integration
proposal
from
guy
bedford
and
someone
else
he's
working
with
where
the
thing
you're
importing
isn't
the
fully
instantiated
module,
which
means
that,
where
the
imports
have
already
been
satisfied
by
the
asm
loader,
which
is
where
things
get
kind
of
harder,
when
you
need
to
inject
this
glue
code,
but
rather
what
you
import
is
you
get
a
webassembly.module
object,
which
is
the
uninstantiated
code?
D
So
what
you're,
using
the
esm
loader
is
to
find
that
file
and
get
it
for
you
and
let
that
process
be
kind
of
declarative
and
using
the
normally
asm
machinery.
But
then
you
get
to
instantiate
it
yourself
from
your
wrapper
script.
So
usually,
if
you
have
web
selling
modules
now
you
have
all
the
power
to
like
call
website,
instantiate
and
precisely
assemble
that
import
object.
D
That
does
all
the
wrapping,
and
so
this
this
variation
on
esm
integration,
I
think,
is
perhaps
the
more
valuable
in
the
short
term
one
because
it
lets
you
take
avoid
the
fetch,
slash,
base64,
slash
all
that
kind
of
goo,
which
is
like
none
of
them
seem
like
the
optimal
answer,
especially
if
you're
trying
to
write
isomorphic
other
ones,
both
in
the
browser
and
and
node
and
say:
okay,
we'll
just
use
esm
for
that,
the
fetching
of
it
and
the
the
coding
and
the
compiling,
but
the
instantiation,
still
gets
to
be
done
kind
of
via
the
imperative
javascript
api.
I
That
so
I
might
be
wrongfully
concerned
that
it
seems
kind
of
inconsistent
with
the
way
we
import
javascript.
Since
then
the
instances
are
local
to
the
module.
That's
requiring
that's
importing
it
right,
whereas
with
es
modules
you
kind
of
global
state,
regardless
of
your
opinion
on
global
state,
you
can
have
global
state
and
you
only
have
one
instance
of
that
module
similar
to
like
require
a
node,
also
caches
your
module.
I
So
you
don't
have
multiple
instances,
so
it
just
seems
somewhat
inconsistent,
but
also
like
a
good
solution
as
compared
to
importing
the
entire
instance.
D
Yeah,
I
think
the
current
proposal,
which
I'll
link
in
the
minutes,
let's
put
here
and
figure
out
exactly
put
it
in
a
sec-
requires
actually
a
different
syntactic
annotation
and,
like
you
know
that
curly
brace
import
assertion
thing
so
you're
you're
kind
of
opting
into
this
different
behavior
is
one
part,
and
then
the
caching
mechanism
would
cache
the
web
semi.module.
So
it
is
caching
a
thing,
but
it's
caching
is
this
immutable
code,
as
opposed
to
like
the
live,
like
instance,
with
all
the
memory
so
yeah
yeah.
That's.
D
J
I
Yeah,
that
is
probably
something
that
node
itself
can't
do
a
lot
about,
so
we'll
just
have
to
wait
for
the
es
integration
spec
to
move
forward.
A
Right
so
we
were,
we
were
kind
of
talking
about
apis.
I
wonder
if
we
could
put
together
a
list
of
like
you
know
the
the
key
apis
that
we
current,
maybe
current
view
of
like
key
apis
today
for
node
to
be
implementing
both
you
know
ones
we
have
or
haven't.
So
I
you
know
I
think
wazi
is
is
one
that
I'm
aware
of.
I
think
luke
you've
now
mentioned
this.
What
would
I
call
this
component
api
component.
D
I
Here
are
the
streaming
apis
for
webassembly.
Now
that
we
have
web
streams
and
fetch,
I
think
it
makes
sense
to
have
those
which
are
mostly
provided
by
v8.
We
just
have
to
kind
of
enable
embedded
support
for
streams
so
that
well
so,
then
we
sorry
v8
will
automatically
expose
these
streaming
apis
as
soon
as
we
do
that.
I
A
A
A
And
I
don't
think,
there's
anything
we
need
to
do
on
that
like
on
that
front,
we
just,
I
guess,
wait
to
maybe
there's
there's
some
things.
We
would
want
to
influence
to
prioritize
there,
but
otherwise
it's
like
you
know
we
get
the
new
laws
and
features
we'll
have
a
great
implementation
of
wasm
through
that
channel
across
our
platforms.
A
A
A
The
next
part
would
be
like
then
key
api
support,
and
under
that
we've
got
that
list
of
you
know
we
need
to
so.
It's
kind
of,
like
enable
part
of
the
strategy
part
is
like
enable
key
apis
that
are
not
part
of
the
base,
as
it
was
it
to
say
is.
Are
they
like
on
top
of
wasm
like
is?
Is
wasian
on
top
of
or
supporting?
What's
the
right
terminology
for
that.
A
Then
it
seems
to
me,
like
some
of
the
discussion
has
been
around
how
we
load
webassembly
like
and-
and
I
guess
you
know,
one
of
the
the
make
it
is
it
kind
of
like
part
of
our
strategy
would
be
make
it
as
easy
as
possible
to
load
webassembly.
A
Because
that
seems
like
something
that
we
don't
get
for
free
right
like
it's,
that
need
that's
part
of
what
the
platform
has
to
help.
Is
that
is
that
right
or
is
it
or
is
it
just
that
you
know
we
need
to
document
the
standard
ways
of
doing
that
and
they're
the
same
for
other
places.
Just
you
know
how
to
some
documentation
on
how
you
would
do
that
in
node
is
helpful.
A
A
I
think
things
like
I,
you
know
the
the
build
process.
The
compile
process
is
there
anything
that
that
we
need
to
do
in
node,
or
is
that
strictly
like
we
use
the
core
apis
that
come
from?
You
know
the
implementation
we
get
in
v8
and
just
say:
okay,
we've
got
the
string
of
bytes,
let's
load
it,
you
know,
is
there
anything
that
we
need
or
have
done
around
like
caching
or.
I
Regarding
compilation,
I
think
one
thing
that's
not
necessarily
clear
is
if
you
write
your
package.json
file,
how
to
best
integrate
web
assembly
compilation
into
that,
so
as
like
a
pre-published
step
or
as
a
separate,
build
step
or
something
you
might
want.
So
that
might
be
useful
to
have
at
least
examples
of
not
a
tutorial
for
properly
setting
that
up.
Then
again,
since
we
don't
really
have
a
web
assembly
workflow.
I
So
we
have
our
own
tool
our
for
compiling
native
modules
and
we
don't
really
have
our
own
tools
for
web
assembly,
which
isn't
the
problem,
I'm
all
in
favor,
of
using
standard
tools,
I'm
not
building
our
own
for
note
again
or
adopting
a
tool.
That's
gonna,
be
abandoned
by
google
again,
but
the
important
part.
There
is
probably
that
at
least
I
end
up
or
I
usually
end
up-
writing
a
make
file
that
runs
on
linux,
to
compile
the
web
assembly
code.
And
then
I
invoke
that
from
my
package.json,
which
isn't
really
a
platform.
A
I
Right,
yeah,
you
it's
not
as
important
for
somebody
as
it
is
for
native
add-ons,
since
only
the
package
author
has
to
do
it
before
publishing
it,
but
still
helping
people
get
started
with
that.
So
again,
at
least
documentation
or
tutorial
would
be
good
with
precise
build
steps
and
our
with
webassembly
I
feel
like
always.
There
are
ten
options
and
seven
are
bad
for
non-obvious
reasons,
and
it
would
be
great
to
have
some
best
practices.
A
A
I
wonder
one
thing
that's
come
up
for
us.
Is
you
know,
open
source,
a
lot
of
distributions,
it's
important
to
have
the
source
code,
so
just
bundling
in
a
you
know,
a
hex
encoded
or
a
an
encoded
blob
runs
a
foul
of
some
of
those.
So
I
don't
know
if
that's
something
that
there's
been
any
discussion
on
like
how
you
integrate
it
into
your
your
other
repos,
to
address
those
kinds
of
concerns.
A
To
source
code
right,
like
you
know,
several,
we
had
at
least
one
comment
in
the
in
the
when
we
we
pulled
in
in
indici
which
uses
webassembly,
and
it
was
like
it's
just
an
opaque,
encoded,
wasm
and
you
know
the
requirements
I
think
it
was
for
for
who's.
He
who
the
person
was
from
was
like.
We
need
to
have
the
source
code
as
part
of
what
we
ship
versus
like
it.
I
think
it
comes
back
to
like
it
needs
to
be
the
preferred
editable
source.
A
So
you
know
whatever
you're
going
to
go
and
make
a
change
in
you
need
to
have,
along
with
what
you're
actually
going
to
run
and
that's
what
needs
to
be
distributed.
So,
if
they're
going
to
you
know,
for
example,
if
we
pull
it
into
node
and
in
a
distro
linux,
distro
wants
to
ship
node,
they're
likely
going
to
have
to
figure
out
well,
okay,
how
do
I
rebuild
that
webassembly
and
if
I
want
to
make
changes
in
that
web
assembly?
How
would
I
do
that
and
all
you
know
what's
the
process
for
doing
that.
A
So
I
I
I
wonder
if
that's
something
that
other
people
are
sort
of
seeing,
because
I
I
my
take
is
we're
going
to
see
me
and
more
and
more
of,
like
you
know,
tortillas,
as
mentioned
like
say,
for
performance,
you
want
to
take
a
little
bit
of
code.
You
want
to
put
into
webassembly
you
avoid
the
crossing
boundaries.
A
I
I
think
it's
also
not
an
issue.
That's
specific
to
webassembly,
even
for
javascript
we've
had,
I
feel,
like
decades
of
people
minifying
their
javascript,
amplifying
it
just
to
make
it
a
bit
smaller.
So
it
takes
a
bit
less
space,
it
loads
a
little
bit
faster.
So
we
have
had
the
same
problem
even
with
javascript.
I
believe
right,
yeah,
that's.
That
is
true.
A
Okay,
so
let's
look
back
to
just
the
general
like
if
we
have
a
strat,
you
know
if
we
had
a
wasm
strategy,
I
think
it'd
be
nice
to
to
write
that
down
in
our
contributing
guidelines,
and
so
the
components
we've
got
so
far
is
like
we
get.
Our
base
was
in
functionality
through
v8
great.
We
just
you
know,
need
to
continue
to
update,
because
that'll
give
us
newer
versions.
A
We
need
to
implement
key
apis,
which
we
can
keep
a
list
of.
We've
got
the
wazi
component
model
and
streaming
apis
as
the
ones
that
that
people
have
mentioned
that
are
probably
most
important
now
and
then
the
next
part
would
be.
You
know
around
loading.
We
need
to
do
something
to
make
it
as
easy
as
possible
to
load
and
use
wasm,
and
I
guess
so
far
there
we
kind
of
have
the
we
should
have
some
getting
started.
A
A
I
The
only
other
thing
that
comes
to
mind
is
the
es
modules
integration,
but
that's
really
fast
to
implement,
but
not
for
us
to
specify,
since
there
is
standard
work
around
that,
I
believe
luke,
so
they're
really
just
supposed
to
implement.
I
I
believe
we've
made
some
progress
on
that,
I'm
not
quite
sure
what
this
status
is,
but
yeah
for
us
to
implement,
not
for
us
to
design.
I
I
I
think
it's
more,
it's
not
a
separate
api,
it's
more
or
less
a
language
feature
I'd,
say
being
able
to
import
web
assembly,
so
it
kind
of
falls
into
the
low
version.
Okay.
So
but
maybe.
A
I
It
might
solve
the
problem
that
luke
was
talking
about
about
embedding
base64
encoded
web
assembly
into
your
javascript
file.
So
if
you
can
import
them
in
node
and
in
browsers,
we
are
kind
of
going
to
get
rid
of
that
and
actually
decrease
the
size,
since
it
can
just
be
a
binary
file
right.
I
I
I'm
not
so
sure
about
that.
Maybe
we
I
I
mean,
if
you're
willing
to
use
not
specific
things
like
require,
you
can
also
load
it
through
fs,
since
you're
not
really
gonna
benefit
much
from
using
require,
I
believe,
aside
from
maybe
caching
it
but
v8
internally
also
caches
our
compiled
web
assembly
modules.
So
we
aren't
too
concerned
about
compilation
times
if
we
don't
cache
it
yeah.
So
maybe
we
might
want
to
have
an
equivalent
for
require,
but
I
don't
think
it's
it's
a
version.
A
Okay,
I'm
just
thinking
like
strategy
wise.
You
know
what
we,
what
would
we
want
to
say?
Certainly
you're
saying
the
yes
one
is
the
top
priority
right,
yeah,
yeah,
alright,
so,
okay
and
so
va
in
terms
of
the
the
the
loading
time
or
the
the
compilation
time
for
when
you
load
the
module.
The
first
time
is
that
anything
node
should
be
doing
anything
about
or
or
like
you
know,
caching
and
all
that
kind
of
stuff
fits
in
the
back
in
the.
I
Yeah
yeah,
you
know,
michael.
I
worked
on
that
for
a
while
and
we
we
could
certainly
implement
some
kind
of
caching
for
web
assembly
code
beyond
the
current,
so
v8
will
catch
it
within
your
process
but
for,
like
large
scale,
server
setups.
That
might
not
be
enough,
so
we
could
definitely
go
beyond
that
and
cache
code
beyond
that
which
v8
will
facilitate
for
us
in
some
ways
as
soon
as
we
use
streaming
apis,
so
v8
kind
of
caches
only
a
few
streaming
apis.
H
I
Course,
the
only
question
is
essentially:
where
would
be
stock
compiled
code?
It's
a
security
concern,
of
course,
storing
any
form
of
compiled
code.
We
could
also
cache
compile
javascript
code.
Theoretically,
there
is
academic
work
on
that,
and
it
would
definitely
help
with
startup
times.
But
again,
the
main
question
is:
where
would
we
put
compiled
code
in
a
way
that
we
can
trust
and
order.
A
I
Times
it's
not
a
terribly
big
concern,
since,
even
if
you
use
it
in
different
threads,
it
should
be
cached
already.
But
if
you
are
trying
to
go
into
like
a
server-less
environment,
if
you
try
to
do
anything
like
that
using
node,
then
you
might
run
into
situations
where
the
startup
time
I've.
I
Modules
in
a
while
that
are
dozens
of
megabytes
of
code
and
loading,
those
at
the
startup
time
is
going
to
be
affected
in
terrible
ways
and
yeah
again,
this
streaming
compilation
might
help
with
that,
especially
since
the
way
we
add
composite
code,
your
startup
time
mostly
depends
on
v8
tiering
up
compilation.
So
if
you
try
to
just
synchronously
compile
your
code,
v8
will
tear
up
differently
than
if
you
use
these
streaming
apis,
for
example.
A
I
It's
a
small
concern.
There
are,
of
course,
huge
benefits
here,
at
least
theoretical
benefits
or
theoreticals.
There
are
guaranteed
benefits
from
caching
code,
but
these
security
risks
are
difficult
to
mitigate
for
us
as
a
platform.
It's
much
easier
for
the
actual
users,
the
actual
developers
to
define
their
own
caching
mechanisms,
probably
and
yeah
it's
something
we
can
facilitate.
We
can
make
it
simpler
for
people
to
benefit
from
that,
but
it's
99
of
it
is
done
in
v8,
right,
okay,.
A
A
I
One
thing
that
should
be
on
our
list,
I
believe,
is
making
sure
that
note
our
own
apis
are
compatible
with
the
web
assembly,
so
they
can
be
called
efficiently
and
async
functions
are
probably
gonna,
be
solved
by
the
web
assembly
specs
the
work
that
luke
talked
about
earlier,
so
that
we
can
use
deck
switching
and
all
those
fancy
techniques
to
efficiently
call
async
functions,
but
we
also
have
all
the
copying
around.
I
I
I
It
might
since
again
it's
not
very.
It
doesn't
feel
very
javascripty
to
do
all
that
low-level
memory
stuff,
allowing
people
to
pass
in
their
own
pointers.
Essentially,
so
it's
not
something
that
many
node
apis
provide,
except
a
few
that
are
very
critical
for
performance.
I
We
could
definitely
revisit
most
apis
that
deal
with
data
input
and
output
and
see
if
we
can
allow
buffers
to
be
passed
in
or
any
type
error
really
yeah,
there's
really
not
much
beyond
going
through
all
of
our
apis
and
seeing
if
we
can
improve
them.
A
Right
so
it's
basically,
I
think,
like
it's
reviewing
the
apis
and
maybe
identifying
like
what
are
the
key
ones.
We
think
are
would
be
most
likely
to
be
used
in
wasm
and
then
for
those
it's
like
considering
like.
Then
it's
like
additions
to
allow
a
pre-existing
buffer
or
handle
to
a
buffer
or
something.
I
Yeah,
that's
the
main
concern
of
copying
around
data.
I
believe
all
the
other
data
type
conversions
are
kind
of
covered
by
the
interface
types
proposal
like
string
to
web
assembly
memory,
for
example.
Maybe
I'm
misremembering,
but
I
believe,
that's
covered
by
existing
proposals.
I
A
Okay,
so
that's
that's
a
good
one,
it's
sort
of
like
it,
it's
a.
If
again,
if
we
sort
of
document
that
that's
something
we
think
would
be
strategic,
it
could
at
least
give
some
people
some
backing
to
say
I
you
know
this
is
useful
work
and
if
there's
prs
that
do
that
have
a
you
know
the
background
as
to
why
they
make
sense.
A
E
D
D
A
A
A
A
I
think
we've
had
enough
of
a
discussion
that,
like
I,
can
write
up
a
doc
for
our
contributing,
like
we
have
a
contributor,
doc
contributor
section
and
we
could
have
like
a
maintaining
wasm
section
and
we
can
put
this
strategy
in
there
and
sort
of
build
on
it
and
add
some
more
stuff.
But
this
is:
we've
had
a
good
enough
discussion
to
sort
of
lay
that
out.
I
think
which
is
good.
A
A
A
A
No,
I
see
somebody
has
their
hand
up.
Let
me
flip
back
to
there
so
you'll
see.
C
Yeah,
I
I
have
done
some
checks
per
the
meeting
in
terms
of
looking
the
previous
records
about
the
topic
and
some
pull
requests
made
in
the
past.
So
maybe
I
can
provide
some
context,
but
maybe
I'm
not
the
most
updated
one.
So
I
don't
know
if
anyone
else
has
a
sure.
C
Okay,
so
yeah.
C
Okay,
so
you're
taking
the
checking
the
prior
meetings.
I
think
the
the
first,
or
at
least
the
first
mission
that
I
know
about
the
security
policies
in
terms
of
for
this
meeting
was
in
in
august
this
summer.
So,
I
think,
was
a
long
discussion
with
with
some
tcc
members
about
the
objective
for
the
next
10
years.
Right
and
one
of
them
is,
this
is
one
of
the
security
policies.
C
I
think
the
agreement
on
that
meeting
was
more
or
less
to
go
ahead
with
the
idea
of
you
know
deploy
some
kind
of
policies.
I
think
the
big
question
there
is
how
this
should
be.
You
know
how
the
system
might
look
like
in
terms
of
how
this
is
going
to
be
approachable
for
the
users.
If
it's
going
to
be
a
breaking
change
or
not
all
of
that
big
concerns,
I
think
also
tierney
as
well
has
some
had
some
concerns
on
the
time
regarding
on
how
this
might
affect
as
well
the
distributions
of
node.js.
C
You
know
if
we
need
to
have
a
special
distribution
with
this
kind
of
policies
enabled
by
default
or
not
so
in
terms
of
that,
I
think
is
going
to
be
like
the
kickoff
for
this
meeting
in
terms
of
what
happened
just
having
a
more
open
view.
C
The
last
years,
I
think
we
had
a
deno
as
a
reference,
maybe
that
we
can
start
to
to
look
for
maybe
a
policy
system
in
place
that
can
be
maybe
similar,
the
one
that
we
might
build
at
the
end
and
what
they
have
in
scope.
I
think
in
terms
of
what
they
control
with
the
policy.
I.
C
Variables,
the
file
system,
you
know
how
you
manage
the
if
you
allow
not
to
run
into
processes,
you
know
and
also
a
lot
regarding
the
network
accesses.
I
think
they
have
also
some
specific
to
deno,
but
I'm
not
very
sure
on
that
and
as
well.
I
think
the
there's
a
lot
of
work
done
by
the
community
before
and
and
also
by
some
of
the
core
contributors
of
node,
especially
from
from
anna,
I
think,
and
henning
henningsen.
C
I
think
she
created
a
pull
request
time
ago
with
some
kind
of
a
proposal
for
the
security
model,
and
then
I
think
I
there
is
also
a
very
interesting
blog
by
james
who
could
not
join
the
meeting
at
the
end
he
put
on
the
notes,
but
with
a
lot
of
research.
You
know
on
this
topic,
so
we
might
also
use
that
as
part
of
the
kickoff.
C
You
know
discussion
which,
as
well
as
a
proposal
in
terms
of
pull
requests,
I
will
put
also
the
links
on
the
on
the
meeting
notes,
but
the
one
of
the
things
they
he
was
mentioning.
The
blog,
which
I
think
is
interesting,
is
we
in
most
of
the
cases
you
know
a
lot
of
people
use
node.js
in
the
context
of
containers.
You
know
like
kubernetes
and
docker
environment
and
all
that,
so
that
way
you
can
have
a
lot
of
control
of.
C
What's
going
on,
you
know
with
the
application,
but
maybe
not
if
you
are
using
electron
or
maybe
not.
If
you
are
using,
you
know
just
a
simple
server
with
node.js
running
so
for
those
kind
of
a
scenario
this
policy
might
have
a
lot
of
sense.
So
that's
that's
fully.
Okay,
also,
I
think
it's
important
to
control
third
party
modules.
C
You
know,
have
a
lot
of
node
modules,
normally
that
we
include
that
they
have
full
access
to
many
things
that
maybe
we
don't
want
to
so
that
can
be
one
of
the
key
things
but
yeah
it's
true
that
we
can
have
a
lot
of
breaking
changes.
Potentially
you
know
that
may
affect
the
way
how
we
use
node
as
end
users.
You
know
in
terms
of
creating
applications
and
all
that
and
and
yeah.
I
think
also.
We
need
to
have
a
very,
very
long.
Well,
maybe
not
very
long,
but
really
conceived
discussion
about.
C
What's
going
to
be,
for
example,
the
way
to
you
know
deal
with
the
granularity:
do
we
want
to
have
like
enable
access,
remove
access
or
when
to
have
more
granular?
We
want
to
split
between
the
application
process
itself
and
the
node
modules,
or
when
to
have
a
more
advanced,
more
simple
system.
You
know,
so
I
think
it's
going
to
be
for
me,
it's
like
three
different
things
to
around
this
topic.
C
One
is
like
having
a
good
discussion
on
what
is
going
to
be
the
architectural
approach,
and,
what's
going
to
be
like
the
decisions
to
be
made,
you
know
in
terms
of
granularity,
how
to
deal
with
dependencies.
All
of
that
having
a
good
plan
that
everybody
more
or
less
in
abstract,
light
and
lighting
like
is
like
it
and
then
we
can
move
ahead.
You
know
in
terms
of
how
feasible
is
that
in
terms
of
the
node.js
score,
because
I
think
it's
going
to
be
a
big
change.
C
So
obviously,
it's
good
that
this
part
of
the
you
know
tensions
pure
strategy,
because
it's
going
to
take
a
while
until
it's
in
production
and
as
well
as
a
side
thing
that
we
can
do
in
the
meantime,
maybe
potentially
you
know,
is
maybe
documenting
or
providing
some
advice.
You
know
to
node.js
users
on
how
to
you
know
properly
dockerize,
and
you
know
con
put
control
boundaries
in
terms
of
file
system
networking,
and
all
of
that
in
you
know,
cover
letters,
environments
or
any
other
environment.
C
So
the
people
in
the
meantime
can
have
you
know
growing
the
feeling,
insecurity
of
noticed
it
to
be
a
very
secure
system,
although
we
don't
have
yet
this.
You
know
security
system
in
place
which
they
might
be
looking
in
comparison
with,
then,
which
was
the
I
think
the
original
kickoff
of
the
of
the
last
discussion.
A
I
think
I
think
that
that
gives
a
lot
of
the
the
history
you
know
I
can
a
couple
two
cents
I'll
add
in
is
that
you
know
there
has
been
some
work
that
that
that
has
gone
in.
A
A
Well,
can
you,
if
you
it
usually
came
down
to
like
well,
there's
some
way
to
get
around
that
or
you
end
up
having
to
turn
them
all
on
or
so
it's
the
is
it
does.
It
need
to
be
perfect
to
be
useful,
and
if
it
needs
to
be
perfect,
there
were
lots
of
people
who
would
argue?
Well,
it's
not
perfect.
So
therefore
we
shouldn't
do
it
at
all,
and-
and
so
it's
kind
of,
I
think
one
of
the
key
things
that
should
be
in
that
discussion
is
like
you
know,
is
it?
A
Is
it
useful
to
provide
something?
We
know
isn't
perfect
and
if
the
answer
could
be
yes
like
it's
like
okay
for
people
who
want
to
turn
this
on,
there's
limitations,
but
it's
sort
of
like
well,
I
put
my
seatbelt
on
in
addition
to
having
an
airbag
or
do
we
have
you
know:
do
we
have
to
have
something
which
is
like
you
know?
If
we
provide
it,
it's
got
to
be
bulletproof.
A
A
A
A
J
I
remember
a
few
years
ago
we
had
discussions
about
that
and
we
could
not
really
agree
on
the
threat
and
attacker
model
that's
at
stake
and
that,
in
my
opinion,
usually
should
be.
The
the
first
step
of
designing
a
security
system
is:
what
are
we
trying
to
prevent
as
an
attack?
We?
What
is
the
attacker
doing,
that
we
want
to
make
impossible
and
what
are
the
trade-off
acceptable?
Because
sandboxes
are
great?
Usually
they
come
with
performance
costs
which
can
be
totally
acceptable
if
they
are
well
documented
and
benchmarked
by
the
end
user.
J
But
really
the
question
is:
are
we
fighting
something?
That's
really
useful
to
fight?
I
was
reading
a
blog
post
about
dino
in
production
this
morning
and
they
highlighted
that
they
end
up
having
all
authorization
in
past,
because
when
building
a
web
server,
you
need
file
system
access.
You
need
network
access,
which
is
totally
fair
because
I
don't
think
that's
what
the
security
model
of
this
permission
system
is
fighting.
J
It's
mostly
fighting
supply
chain
attack
and
rogue
code,
doing
arbitrary
stuff
on
the
on
the
server,
so
that
maybe
that
the
security
as
the
ex
security
consultant
talking.
But
I
really
want,
I
really
prefer
to
see
what
are
we
trying
to
fight
and
how,
rather
than
hey,
we
can
have
those
security
features,
working
which
is
great,
and
the
nerd
in
me
loves
them.
I
I
just
want
to
bring
up
policies
that
you
can
create
already,
but
there's
very
little
tooling
around
that
and
that's
maybe
something
that
we
can
improve
on
like
creating
policies,
auditing
them
and
yeah.
That's
just
something
I
feel
like
tooling
could
really
have
a
massive.
A
A
So
maybe
we
can,
you
know
I
I
kind
of
agree
with
vladimir
that
like
starting
with
this,
like,
I
think,
writing
some
thoughts
on
the
security
model
and
then
possibly
like
getting
into
that
like
that,
may
lead
to
the
threats,
and
attackers
and
stuff
is
a
good
place
to
start
the
discussion,
and
I
don't
think
we
can
get
through
like
defining
our
security
model
or
any
of
this.
A
M
One,
if
I
might
just
add
one
thing,
that's
a
little
bit
tricky
sorry.
I've
got
an
echo,
I'm
busy
furnishing
this
department,
but
one
thing:
that's
a
little
bit
tricky
about
trying
to
define
the
security
model.
Is
that
there's
so
many
different
approaches
to
it?
So
it's
not
like
there's
one
model
and-
and
then
you
also
brought
up
that
great
point
earlier,
michael,
that
there
there
is
the
sense
that,
like
because
security
is
an
all
or
nothing
thing
when
it
comes
to
next
steps,
it's
difficult
to
say.
M
We
can
definitely
go
in
this
direction
when
there
is
a
lot
of
uncertainty.
So
a
lot
of
dealing
with
the
security
as
a
project
is
how
do
you,
research,
potentially
completely
different
security
directions
and
and
allow
the
project
to
explore
those
directions
and
and
actually
come
up
with
solutions,
even
if
they
might
not
end
up
being
comprehensive,
but
but
at
the
same
time
you
that
shouldn't
hinder
the
ability
for
the
project
to
to
really
explore
some
of
these
spaces
where
there's
a
lot
of
interesting
possibilities.
M
A
M
Know,
or
even
just
like,
there
are
a
bunch
of
different
use
cases
and
they
might
have
completely
different
technical
solutions
and
then
just
kind
of
break
it
down,
and
that's
maybe
where
the
web
assembly
focus
is
really
great
actually
because,
instead
of
having
to
sort
of
broadly
think
about
node.js
security,
you
could
just
say
if
you
have
wasm
using
yz,
and
you
want
to
restrict
the
capability
of
that
bit
of
webassembly
dependency.
M
You
know
that
that's
a
sort
of
a
technical
question
on
its
own.
How
do
you
create
some
guarantees
around
that
web
assembly
when
it's
when
it's
using
wazi,
which
potentially
has
access
to
everything?
So
it's
it's
a
fine-grained
policy
at
the
most
wisely
level
and
so
yeah,
maybe
splitting
out
some
use
cases
around
various
user
scenarios
or
things
like
that.
It
could
make
sense
as
well.
A
M
Sure
yeah
or
for
listing
different
scenarios
and
and
then
prioritizing
them.
That
sounds
like.
A
Yeah
and
it
could
just
be
like
yeah,
it's
like
and,
and
it
comes
down
to
like,
are
there
people
willing
to
actively
investigate
them
or
not,
but
it's
still
a
value
for
the
us
having
looked
at
them
and
saying
well,
if
somebody
does
have
time,
this
looks
interesting
or
well.
No,
we
just
don't
think
this
fits
for
some
reason
right.
A
Try
and
promote
stephen
again,
oh
okay,
so
he
says
just
right,
so
I
think
on
the
security
model,
one
of
the
key
things
maybe
to
think
about
or
to
start
out
the
discussion.
Correct
me
if
other
people
have
better
ideas
is
like
what
would
we
use
it.
A
Some
of
those
are,
you
know
we
end
up
closing
because
they
don't
fit
what
we
have
in
our
mind
as
a
security
model
and
having
that
well
documented
and
published,
I
think,
would
help
like
either
in
terms
of
us
being
able
to
point
to
the
security
model
to
say:
hey,
this
doesn't
fall
under
that
or
you
know
helping
to
avoid
them
being
submitted
in
the
first
place.
A
J
J
That
said
that,
because
there
was
a
need
in
the
way
urla
passed
when
there
was
an
arab
as
an
act
inside
someone
claimed
that
could
lead
to
a
user,
spoofing
or
authentication
bypass
which
doesn't
make
sense,
because
we
don't
provide
any
authentication
primitives,
it
would
make
sense
in
a
food
stack
project
that
would
rely
on
that
to
identify
the
user,
maybe,
and
so
the
other
things
that
are
extremely
clear
can
be
part
of
our
security
model.
J
Like
there's
a
problem
in
in
crypto
that
has
a
bypassing
some
cryptographic
method,
we're
using
weak
cryptographic
algorithm.
Those
are
ones
are
industry
standards,
and
I
think
it's
pretty
fair
for
us
to
to
be
able
to
consider
them,
as
as
as
first
class
targets
for
pen
tests
for
anything
that
is
higher
in
the
in
the
abstraction
layers
in
the
application
layers.
J
A
L
Yeah,
it's
a
good
thought,
any
other
thoughts.
M
So
I
mean
I,
I
would
add
a
few
things
to
kind
of
like
lists
of
things
to
explore,
but
I
don't
know
how
appropriate
they
are
for
for
this
kind
of
context,
but
so
it
could
be
worth
exploring.
You
know
stronger,
stronger,
sandboxing
primitives
do
things
like
shadow
realms?
Can
they
are
there
entire
use
cases
around
them
in
node.js?
You
can
still
have
third-party
dependencies
or
you
know,
can
you
use
them
in
a
real
app
to
solve
a
real
sandboxing
problem?
M
Thinking
about,
as
I
said
at
the
beginning,
a
wazi
virtualization.
If
you
wanted
to
load
like
some
arbitrary
wasm
and
you
wanted
to
have
guarantees
that
it's
only
going
to
have
access
to
one
folder
on
the
on
the
file
system
is
there
can
can?
Can
one
have
a
strong
way
because
at
the
moment,
it's
all
in
js
and
it's
just
convention?
M
Is
there
a
strong
way
to
or
even
just
think
about
it
from
a
security
perspective,
and
then
currently,
policies
do
control,
dependency,
locking
and
and
that's
a
sort
of
a
security
guarantee?
Is
it
possible
to
strengthen
the
security
guarantee
that
the
current
node.js
policies
already
provide
and
what
could
be
done
to
strengthen
those
guarantees
and-
and
that's
also
coming
out
from
a
direction
of
like
it's,
not
solving
everything,
but
it
can
start
to.
M
It
can
start
to
to
provide
more
clear
boundaries
and
it
can
start
to
make
things
that
would
be
very
easy
harder.
It's
much
harder
to
ship
a
dependency
that
suddenly
is
going
to
be
importing
fs
when
you've
got
a
policy
that
locks
down
that
that
package
doesn't
have
access
to
fs,
and
that
is
a
workflow
that
can
be
used
today.
M
M
So
you
can
have
sort
of
dependency,
customization,
and
but
that's
also
getting
back
into
this
kind
of
very
fine-grained
and
and
those
fine-grained
models
are
entirely
dependent
on
on
a
lot
of
lockdown
primitives
like
frozen
intrinsics
and
process.dl,
open
being
deprecated
as
well,
which
is
one
of
the
biggest
hindrances
to
that
kind
of
workflow.
M
At
the
moment,
and-
and
I
know
that's
always
a
tricky
discussion-
those
kind
of
models,
but
especially
in
light
of
the
fact
that
often
it
does
end
up
in
dino
that
it's
easier
just
to
add
a
dash
capital,
a
or
whatever
it
is
flag
that
that,
maybe
that
these
models
do
get
put
under
under
a
light
for
exploration,
again
yeah
and
defecating
process.dl
open,
is
definitely
an
important
consideration.
Amongst
those.
M
Open
yeah,
because
there's
no
way
to
control
that
all
code
will
always
be
able
to
execute
any
arbitrary
binary
on
the
whole
system.
So
then
there's
no
way
to
control
that.
So
no
matter
what
other
security
guarantees
you
have,
any
any
module
or
any
piece
of
executing
code
can
always
just
use
process
dot,
deal
open
to
do
anything
and
so
that
that's
that's
a
simple
one
to
lock
down.
Potentially,
but
again
it's
it's!
M
It's
a
as
I
say
it's
a
it's
a
super
tough
direction
to
go
in
because
it's
very
easy
to
argue
against,
but
but
if
there
are
small
things
that
could
make
it
harder
to
do
bad
things,
then
surely
that's
a
good
thing.
A
Like
in
that
context,
I
I
always
wonder
what
is
the
minimum
that
would
need
to
be
in
node
itself
versus
you
know
that
node
taking
on
the
attempt
to
provide
these
right
like
so,
for
example,
if
there's
a
flag
that
says
you
know,
disable
run
securely
or
whatever
you
want
to
call
it,
and
it
it.
You
know,
has
a
limited
to
no
overhead
and
disables
a
few
things.
A
M
Definitely
so
maybe
package
some
of
these
things
up
and
have
a
kind
of
a
call
it
an
experimental
security.
You
know
and-
and
the
fact
is
it's
it's
not
solving
it.
It's
not
giving
you
a
comprehensive
security
model,
but
it's
it's
making
it
a
little
bit
more
difficult
for
people
to
do
bad
stuff
and-
and
maybe
there
is
a
way
that
that
those
things
can
be
explored
further.
If
there's,
if
there
is
progress
there
and
people
are
interested
in
working
on
that
and
exploring
them.
A
Yeah,
it
could
kind
of
come
back
to
like
our
strategy
is
that
we
want
to
we're
not
looking
to
wholesale
implement
these
things
as
a
project
yet,
but
we
want
to
encourage
experimentation,
and
so
you
know
the
kind
of
things
that
we
should
be
looking
to
do
are
to
you
know:
do
these
smaller
low
overhead
things
that
you
know
on
their
own,
maybe
people
would
argue
like
why?
Are
you
doing
that?
M
And
yeah,
and
maybe
people
don't
know
about
flags
like
frozen
intrinsics
and
having
some
kind
of
sort
of
documented
security
effort
or
or
efforts
that
that
kind
of
start
to
bring
these
whole
workflows
together,
where
that's
just
a
piece
that's
used
and
then
with
policies
and
things
like
that,
it
can
start
to
explore
working
up
to
bigger
picture
security
stuff
in
an
experimental
way
but
yeah
as
long
as
it's
it's
clear
that
it's
experimental
and
it's,
as
you
say,
just
working
working
towards
these,
these
things
and
there's
there's
a
huge
amount
of.
M
I
mean
they're,
really
interesting
things
to
work
on.
I
always
wanted
to
mess
around
with
this
stuff
more
so,
but
it
also
yeah.
It
depends
on
people
being
interested
in
doing
that
and
that
as
one
effort
and
then
sandboxing
and
then
other
other
types
of
models.
Also,
I
think
so
it's
there's
not
a
single
kind
of
direction.
A
I
mean
I'm
just
looking
under
strategy
like
we
can
write
a
few
things
that
you
know
from
at
least
from
this
discussion.
We
could
propose
as
a
strategy
you
know
like
our
strategy
is
like
we
want
to
support
experimentation.
Things
like
experimental
overhead
editions
are
good.
I
don't
know
if
other
people
have
thoughts
of
other
things,
we'd
add
into
the
list,
based
on
on
what
you
think.
A
And
we
may
even
try
and
like
I'm
just
thinking
out
loud
like
we
can
start
out
with.
I
think
it's
you
know
my
take
in
and
and
understanding
is
like
today.
We're
not
you
know
the
the
goal
of
the
project
is
not
to
provide
a
sandbox
if
we
documented
a
model.
I
think
it
would
be
pretty
clear
that,
like
even
things
like
the,
I
think
the
vm
module
like
it's
not
intended
to
be
a
sandbox
we're
not
going
to
take
vulnerability
reports.
So,
like
our
current
support,
our
current
security
model
is
is
x.
A
We
bound
it
like
this,
and
that
would
be
like
we're,
not
a
security
mo
we're
not
a
sandbox
blah
blah
blah,
but
the
second
part
of
our
strategy
could
be.
But
you
know
we
we
we
understand
that
you
know
sandboxes
are
interested
to
people
policies.
A
You
know
we're
not,
maybe
not
at
the
point
in
the
project
to
say
that
we've
come
to
that.
We
don't
have
the
the
the
full
like
hear
the
attacks.
Here's
the
protection.
Can
we
actually
make
them
work,
but
we
do
want.
We
do
respect
that
they're,
an
interesting
area
of
exploration
and
here's
what
we
want
to
do
to
support
that
exploration
right,
because
that's
where
you
know
and
it
and
then
and
it's
so
that's
where
we
can
discuss
like
where
do
we
want
to
sort
of
draw
that
in
that
in
what
we
say?
A
A
We
should
do
this,
there's
going
to
be
a
hugely
long
discussion
on
any
one
of
them,
but
it
may
be
easier
to
say
you
know
it's
important
as
a
project
to
our
future
success
that
we
don't
just
block
things
like
block
experimentation
and
when
somebody
does
figure
out
how
to
do
it
properly.
Well,
they've
done
it
somewhere
else
right.
A
A
A
It
was
kind
of
like
pointing
out
that
there's
different
use
cases
so
even
like
some
documentation
around
like
if
you're
running
in
containers,
this
may
or
may
you
know,
we
don't
see
this
as
an
issue,
but
if
you're
running
in
these
other
situations,
maybe
it
is
an
issue
and
therefore
it's
more
interesting.
Some
some
work
around
that
would
kind
of
be
interesting
too.
J
I
don't
know
if
we
are
saying
that
publicly,
but
that's
that's
at
least
what
we
deliver
as
a
as
a
runtime,
whether
this
is
javascript
or
or
native
native
modules.
L
A
So
that
yeah,
so
I
think
that
yeah,
that's,
I
don't
know
that
this
part
of
like
we
could
be.
We
should
dock.
You
know,
one
of
the
priorities
is
to
document
a
security
model.
That
says
that
is
our
you
know.
Where
are
we
today
and
and
that
fits
into
the
like
in
terms
of
vulnerability,
reports
and
stuff?
What
would
we
would
use
it
for.
A
A
So
we
trust
that
code.
We
trust
the
code,
that's
run.
So
if
you
ask
us
to
run
that
arbitrary
code
and
it
does
something
well,
that's
just
understood
that
can
change
in
the
future
because
of
today
yeah
right,
any
other.
I
think
you
know.
Let
me
we're
pointing
out
a
few
things
like
we.
We.
A
You
know
in
in
things
like
dependencies
and
stuff,
we
don't
think
their
vulnerabilities
if
they
don't
impact.
I
don't
know
how
to
write
that
like
but
like
they
don't
affect
things
that
we
don't
provide
ourselves
kind
of
thing
right
is
that
you
know
like
it's.
I
guess
it's
clear
like
if
it's
a
problem,
if,
if
the
crypto
algorithm
is
you
know
incorrect
or
something
like
that,
like
it's,
but
it
still
comes
back
to
like
what's
a
bug
versus,
what's
the
vulnerability,
do
we
have
any
other
sort
of
things
we
should
write
down
on
that
front.
J
You
should
not
use
md5
for
anything
critical,
but
maybe
you
just
want
to
have
a
fast
way
of
checking
if
two
things
are
similar
and
the
likelihood
of
md5
having
collisions
is
so
low
or
useless
in
your
use
case,
so
that
that's
really
opinionated
like
if
we
had
a
method
safely
hash
that
and
that
would
be
md5.
That
would
be
a
problem.
So
I
guess
my
my
my
my
point
here
is:
how
do
we
make
sure
that
people
know
what
trends
in
their
application?
J
J
A
A
A
J
Really,
that's
why
it's
a
bit-
it's
a
bit
cowardly
from
me
to
say
that
we
should
even
maybe
find
a
cwe
that
fits
it,
and
if
we
agree
that
the
impact
on
a
publicly
documented
cwe,
like
a
secret
injection
authentication
bypass,
isn't
disputable.
A
J
For
instance,
when
we
had
the
first
report
of
prototype
pollution,
we
saw
a
bug.
We
were
not
exactly
100
clear
on
the
real
implication.
We
I
mean.
I
at
this
point
thought:
okay,
it
can
at
least
crash
applications
by
changing
globals.
So
I
will
consider
that
as
a
vulnerability
with
denial
of
service
impacts,
then
two
years
later,
someone
used
that
to
get
a
remote
code
injection
in
kibana
exploitation
in
cubana,
and
I
did
not
see
that
coming
and
I
did
not
have
that
in
my
thread
model
back
then.
So,
I'm
happy.
J
A
J
A
A
J
A
We
do
check
certificates,
so
when
you
connect
to
to
a
website,
we
will
authenticate
the
certificate
until
you
know
it
wasn't
so
that's
a
forum,
I
think
of
that.
I
know
yeah.
I
guess
I
mean,
and
I
don't
want
to.
We
can't
spend
all
of
our
time,
but
maybe
a
little
bit
more
time
is
still
good.
A
J
Yeah,
I
agree.
It's
kinda.
J
We
won't
say
that
know
the
low
arbitrary
file
system
reading
that's
definitely
higher
level
code
that
that
can
be
miswritten
and
allow
anyone
to
browse
the
local
file
system
of
a
web
server,
so
it
in
a
way
it
comes
down
to
the
feature
we
we
provide
and
we
want
this
feature
to
work.
Well,
I
I
think
I'm
rephrasing
what
you
just
said
in
a
way.
So
I'm
sorry
for
that,
but
yeah
we
maybe
being
extra
clear
on
what
features
we
provide
and
what
yeah.
A
Right
so
maybe
we
maybe
our
model
is
like
we
expect
vulnerabilities
to
be
manifested
with
just
node
apis
right,
like
if
you
can't,
if
you
got
to
have
a
bunch
of
other
stuff
on
top
of
it,
to
cause
a
problem,
then
you
know
if
it's.
If
it's
like
yeah
node
does
something
slightly
off,
but
then
three
other
things
have
to
do
the
wrong
thing.
J
C
I
think
can
we,
I
think,
can
be
confused.
I
think
a
lot
of
a
lot
of
that
depends
on
on
on
the
reporter's
level.
Right
I
mean
if,
if
you
are
not
dealing
with
a
very
experienced
one,
I
think
when
the
people
have
a
lot
of
experience
reporting,
they
do
a
lot
of
these
projects.
You
know
their
own,
but
when
you
are
dealing
with
people
which
doesn't
have
a
lot
of
experience,
then
it's
like.
C
Oh,
I
see
a
prototype
pollution,
not
very
sure
about
how
this
might
impact
anything,
and
then
it's
like
they
try
to
delegate
you
know
like
raising
the
hand
I
see
this,
but
no
idea
if
this
become
a
real
problem
or
not
at
all,
you
know
so
yeah.
I
think
it's
hard.
Maybe
we
can
provide
some.
You
know
basic
context
for
those
kind
of
reporters
in
a
way
like
saying
like
these
are
the
top
10
most
typical.
C
We
like
reports-
and
this
is
the
common
known
things
that
we
you
know
reports
that
we
don't
doesn't
work
due
this
reason,
so
people
have
a
better
context
of
why
authentication
is
not
in
scope.
Why
this
kind
of
process
by
third
level
is
not
in
scope
and
of
that,
so
they
can
have
a
better
clear
idea,
because
I
think
it's
the
idea
you
know
from
coders
try
to
finding
bugs
rather
than
security
researchers.
So
there
is
this
jump
line.
I
mean.
J
C
A
C
Yeah,
it's
like
more
to
identify
like
bad
practices
right
from
the
people,
so
something
that,
to
suppose
not
to
do
or
that's
not
the
way
that
it's
supposed
to
be.
You
know
like
try
to.
I
think
it's
catching
the
the
point
of
lightning,
as
well
of
you
know
like
trying
to
be
opinionated,
although
we
are
not,
you
know,
and
those
kind
of
things
like
please
don't
use
md5
for
this
context.
You
know
these
kind
of
things.
C
You
know
like
really
really
putting
people
in
context,
and
also,
I
think,
makes
sense
also
to
you
know,
collect
those
kind
of
things
and
put
it
in
one
place.
So
people
can
know
like
good
things
to
do
and
bad
things
to
do
as
well
might
give
a
lot
of
context
for
many
people.
J
And
you
agree:
we
need
to
be
clear
on
being
open-minded
about
new
new
strategies
and
new
mechanisms.
There
are
so
many
upcoming
attacker
models
right,
keep
an
eye
on
what's
happening
outside
and
how
they
solve.
Certain
problems
is
a
is
a
must
do
for
us.
A
The
attack
would
you
call
that,
like
attack
models
or
red
model
attack
model,
anything
usually
okay,
documenting
threat
models
and
current
state-of-the-art
of
the
art
right,
because
that
would
be
another
part
of
like
a
high-level
strategy.
Is
that
we
think
it's
good
to
document
these
thread
threat
models
and
the
current
state-of-the-art?
A
You
know
it's
it's
like
okay,
say
you're
in
I
don't
know
you're
deploying
in
containers
the
current
state
of
the
artist.
While
you
use
the
container
approaches
to
you
know.
If
you
want
to
shut
off
being
able
to
go
to
the
network,
you
use
that
right
and
then
in
a
def
in
a
desktop
threat
model.
That
might
be
a
different
case
right
and
the
current
model
is
well.
J
That,
I
think,
that's
that's
a
very
important
point
and
I
really
like
what
you
just
said
that
we
need
to
also
think
the
desktop
model
as
a
first-class
citizen
as
well
as
the
docker
model.
J
I
am
because
that's
a
a
gets
feeling
that
I,
I
think
most
of
node.js
daily
users
use
node.js
to
build
front-end
stuff
on
their
desktop
more
than
at
least
in
terms
of
humans,
maybe
not
in
terms
of
machines.
C
Yeah
clies
and
all
of
that
as
well
yeah,
there's
a
lot
of
white
applications
out
there.
Yeah
do
we
went
including
this
documentation
as
well
the
state
of
the
art
regarding
attacks,
for
you
know
third-party
modules,
like
I
don't
know,
type
of
scripting
attacks.
You
know
this
kind
of
very,
very
you
know
close
to
where
our
ecosystem,
these
kind
of
things
or
we
want
to
focus
only
on
the
on
node.js
core
as
much
as
much
as
possible.
A
I
think
what
makes
sense,
in
my
mind,
is
to
document
just
enough
so
that
we
can
say
this
is
what
we
think
node
core
should
be
doing
or
not
doing,
to
solve
the
problem
like
here's,
the
threat
model,
here's
the
context
you
know
in
this
model,
the
assumption
is,
your
protection
is
going
to
come
from
this
other
component,
we're
not
doing
anything
in
node,
then
the
next
one
could
be
on
this
model.
A
This
is
our
assumptions
in
terms
of
you
know
where
we
think
and
then
we
can
say
like,
and
it's
therefore,
we
think
it's
critical
that
no
provide
x
in
that
context
would
make
would
be
a
useful
resource
to
have,
because
it
would
let
you
clearly
say
like
okay,
you
know,
even
if
we're
not
there,
we
could
say
we
think
for
our
future
success.
It's
important
that
we
work
towards
this
or
something.
A
You
know,
I
think
the
two
things
we
had
is
it's
not
a
sandbox.
We
assume
the
user
trusts
the
code,
it's
running,
that's
both
js
native
code
and
it
must
be
able
to
manifest
with
just
the
node
apis,
but
maybe
I
think
I
had
a
better
description
of
that
because
I'm
probably
writing
this
multiple
places.
N
I,
like
the
other
text
yeah
just
maker,
could
you
maybe
promote
stefan
yeah
I've
tried
to
to
promote
him
a
few
times.
Let
me
do
it
again.
Oh.
A
H
Sorry,
yeah
also
link
to
the
strategy,
because
I
think
some
people
don't
really
need
that
part,
or
at
least
they
maybe
use
other
tools,
or
they
have
some
other
kind
of
way
to
mitigate
security
issue
in
the
code
of
solution.
H
H
A
J
Yeah,
that's
a
product
question
on
the
end
user
experience
and
we
can.
We
have
multiple
situations.
As
john
said,
we
have
the
visual
studio
solution
where
we've
got
different,
different
vision
of
the
same
product
or
we
can
have
a
single
binary,
but
a
global
configuration
that
says:
hey,
that's
a
desktop
configuration
so
give
me
the
default
desktop
configuration
or
that's
a
web
server.
I
don't
need
any
of
that.
A
A
You
know
we're
kind
of
that.
Lately
we
want
to
enable
experimentation,
but
until
it
gets
to
the
point
where
like
we
can,
it
would
be,
it
would
be
an
extra
step.
I
think,
to
make
the
case
that
says:
hey
it's
worth,
taking
significant
performance
to
turn
one
of
these
on
by
default
right
in
terms
of
our
current
strategy,
not
to
say
that
that
couldn't
change
at
some
point
or.
A
A
A
A
We
do
want
to
help
code
avoid
making
mistakes,
but
we
don't
consider
that
a
vulnerability
in
node
not
currently
planning
to
provide
sandbox
functionality
but
want
to
support
experimentation
in
term
when
I
say
sandbox
functionalities
all
these
things
that
people
talk
about
experimenting
with
fall
into
that
category,
or
there
are
several
other
categories
too.
A
Okay,
we
can
kind
of
leave
that
in
there
unless
other,
and
then
you
know,
documenting
threat
models
and
current
state
of
the
art
for
each
of
the
different
environments
is,
would
it's
part
of
our
strategy
we'd
like
to
do
that,
because
then
it'll
help
explain
like
the
story
that
says
well.
Why
aren't
we
worried
about
this?
Well
because
in
this
docker
environment,
these
things
you
know,
we
don't
think
there
is
a
risk
and
we
exp,
because
we
expect
you're
going
to
get
it
from
these
other
things
we
got
today.
A
A
C
Okay,
sorry,
okay,
so
I
think
it
will
be
nice.
Also
to
you
know,
as
we
are
planting,
I
think
in
the
long
term
it's
going
to
be
a
lot
of
changes.
You
know
that
might
affect
quite
a
lot
to
note.
Maybe
it's
okay!
If
we
can
start
to
do
you
know
little
changes
and
ask
for
validations
so
that
way
later
on,
we
can
have
more
people
involved.
C
You
know,
instead
of
having
like
a
super,
huge
big
change
in
terms
of
policy,
so
in
terms
of
how
know
it
is
going
to
behave
for
the
users,
you
know,
and
we
need
and
flags
to
be
running
and
all
of
that
we
can
just
go
with
little
ideas
validate
against
some,
maybe
core
members
and
see,
if
everybody's
happy
and
in
the
same
path-
and
we
can
get
feedback
super
fast,
so
we
can
iterate
over
the
ideas.
C
C
If
we
are
happy
with
the
pieces
that
make
the
whole
puzzle
a
good
thing,
that
may
be
a
good
study
in
terms
of
you
know,
speed
up
the
process,
iterate
a
lot
and
do
not
try
to
collect
a
lot
of
feedback,
but
not
very
sure
you
know
seems
like
for
me
seems
like
a
big
change,
but
maybe
right
now
there
are
more
more
things
in
the
scope
I
mean
for
other
working
groups
that
are
having
a
different
study
that
works
better,
but
maybe
have
something
like
that
can
be
a
good
option
for
now.
A
A
C
Yep
yeah,
I
think
that's,
okay
and
as
experimental
when
we
consolidated
you
know,
then
we
can
have
a
final
idea
with
you
know,
just
having
all
under
one
single
flag
or
whatever.
So
you
know
it
give
us
a
lot
of
freedom
of
iteration.
You
know
because
everybody
expect
to
be
experimental
and
not
solid,
so
that
gives
us
a
lot
of
freedom.
J
Maybe
that's
a
bit
of
topic,
but
is
there
any
opportunity
with
the
node.js
certification
curriculum
in
terms
of
reviewing
the
security
impacts
and
making
sure
that
people
who
get
the
certification
have
all
the
understanding
of
the
node
security
model
as
it
is
or
and
can
answer
for
these
questions
at
least
are
clear
on
what
we
do
and
what
we
don't
do.
J
I
I
guess
there
is
the
question
of:
is
there
a
security
sandbox
and
making
sure
that
everyone
we
certify
knows
it's
not
a
security
sandbox?
That
would
probably
save
a
lot
of
people
right
yeah
and
I
I
don't
really
know
the
curriculum
for
the
certification.
I
just
checked
a
training
course
and
making
sure
that
basics
of
crypto
might
be
understood
and
understanding.
H
Yeah,
because,
right
now
you
have
nothing
about
security
on
the
certification
part,
if
I
remember
right,
maybe
just
on
the
service
developer,
which
is
the
one
around
web
services
and
api
and
website,
and
if
I
remember
for
talking
about
about
it
with
someone,
it's
mostly
about
basic
security
like
handling
errors
and
hiding
which
kind
of
server
is
returning
the
information
or
so
not
really,
security.
Let's
say
mostly
best
practices.
H
So
yeah
yeah
is
that
protecting
against
malicious
input
and
attack
mitigation
yeah,
so
quite
basic,
and
not
really
around
security
for
node.js,
but
most
security
for
just
an
api.
H
Yeah,
because
we
are
currently
we,
we
do
have
a
lot
of
resources
about
using
node.js
or
doing
stuff.
The
certification
is
also
around
that
both
of
them
and
we
don't
have
but
pretty
much
like
every
other
languages,
runtime
or
everything.
We
don't
really
really
have
a
lot
of
stuff
around
doing
how
someone
can
be
sure
about
the
security
of
their
application.
What
should
they
should
they
check
on
a
let's
say,
daily
basis
and
for
a
lot
of
people
and
for
a
lot
of
companies?
H
We
don't
really
have
a
security
team
or,
let's
say
a
security
team
which
is
able
to
deep
dive
into
the
code
and
be
able
to
understand
what
issue
can
be
can
be
present.
So
maybe
it
can
be
like
you
said
it
can
be
something
interesting
to
provide
a
way
to
enlighten
people
to
to
be
aware
of
security
issue
on
their
application.
H
E
That's
something
that,
on
my
side,
we
are
we're
not
discreting
about
corey,
but
we
are
working
on
this
on
the
on
one
of
the
project
I
work
on,
and
one
of
the
things
we
do
is
is
reporting
a
lot
of
information
on
what
node.js
module
is
used
and
what
functionality
is
in
use,
and
so
I
guess
we
we
go
in
in
this
way
of
trying
to
help
and
educate.
Like
vladimir
said,
it's
one
of
the
biggest
and
hardest
things,
because
you
know
securities
are
then
even
on
feature
like
vm
and
people.
A
I
think
that
whole
part
is
like
that's
a
whole
huge
topic
on
its
own.
That's,
I
would
say
it's
a
different
topic
right
like
that,
and
and
there
is
a
collaboration
space-
that's
going
to
spin
up
under
the
open,
js
foundation,
and
I
think
that
would
be
a
good
place
to
discuss
like
what
kind
of
resources
can
be
put
in
place
to
help
projects,
and
you
know
standard,
what's
security
reporting
process
that
a
project
should
have
and
then
even
like
then,
and
on
to
the
end
users.
A
A
A
A
A
Any
other
things
like
that,
like
part
of
the
you
know,
we
should
say
the
core
project
itself
in
terms
of
the
strategy.
You
know
what
do
we?
What
do
we
think
is
important
that
we're
working
on
and
sort
of
in
what
context
are
we
work
working
on
it?
Right,
like
you
know,
is
there
anything
that
like
people
would
advocate?
A
Oh,
we
we
have
to
have
x,
or
you
know,
10
years
from
now
and
node's
going
to
be
irrelevant
right,
and
we
need
to
do
that
this
year,
or
you
know
like
or
is
what
we've
got
in
terms
of
like
gay.
We
just
want
to
support
experimentation,
so
if
something
does
become
important,
we've
not
stopped
it
from
being
explored.
A
J
A
I
think
I
kind
of
I
agree.
It
may
not
come
in
the
securities.
I
wouldn't
have
put
it
in
the
security
strategy
we
haven't.
We
have
diagnostics
and
observability
is
one
of
our
top
technical
strategies,
so
I
would
have
defer.
I
would
have
put
it
under
that
in
terms
of
like
what
should
our
strategy
be?
What
should
we
do?
A
J
J
A
Right
yeah,
it's
it's
like.
If
there
wasn't
going
to
be
a
deep
dive
on
diagnostics,
then
maybe
we
would
want
to
cover
it
under
security.
So
it's
good.
I
think
it's
good
to
list
it
explicitly
in
the
strategy
that
says
yep.
This
is
this
is
something
but
should
be
adequately
covered
if
we
had
a
good
diagnostic
story
for
all
the
different
reasons,
right.
K
Well,
it's
it's
just
a
generic
data
channel
so
like
what
you
choose
to
do
with
it.
It's
up
to
you.
We
can.
We
can
use
that
for
like
observability
stuff,
but
like
observability
in
a
lot
of
ways
like
overlaps,
like
we're
going
to
see
like
if
we
look
at
the
http
start
and
end
we're
going
to
see
like
what
routes
are
people
requesting
and
like
there's
stuff
in
that
data
that
we
could
potentially
look
at
to
identify
like
malicious
traffic
and
things
like
that.
A
A
A
A
L
H
Do
we
want
to
add
something
on
the
part,
let's
say:
node.js
application,
I'm
thinking
about
about
xa
or
pcg.
C
Maybe
maybe
it's
not
pendeles,
but
just
suggesting
maybe
building
packages.
You
know
like
third-party
modules,
that
later
on
you
push
to
npm,
so
maybe
that
have
specific
threads
or
not
so
I'm
not
very
sure
it
should
be
in
the
list
or
not
so
just
raising
the
question.
A
So
like
when
node
is
used
in
the
ci
cd
pipeline
right,
yeah
yeah,
that's
an
interesting
one,
because
that's
like
can
it
inject,
could
it
be,
you
know,
is
there
certain
ways
where
it
could
be
used
to
inject?
You
know
vulnerabilities
or
whatever,
and
is
there
something
that
you
could
do
to
to
address
that.
J
A
A
A
If
we
basically
had
a
resource
to
say,
go
off
and
focus
on
this,
what
would
we?
What
would
it
be
that
they
would
ask?
We
would
ask
like
this,
the
documenting
the
strategy
I'll
volunteer,
to
do
that,
based
on
what
we
discussed
today,
the
security
model.
I
am
hoping
that
maybe,
when
we
get
some
external
security
resources,
they
could.
That
would
be
a
really
good
starting
point
for
them.
E
A
I
see
at
least
one
head
nodding.
That
makes
a
lot
of
sense
to
me,
because
that
would
give
us
the
context
like.
If
we
can
get
agreement
on
that,
then
it
may
be
more.
It
may
be
easier
to
then
say
well,
should
we
prioritize
one
of
these
versus
another
and
like?
Is
it
actually
holding
us
back
or
not,
or
you
know.
N
Any
any
other
options.
A
I
think
that's
a
that's
a
decent
start.
I
guess
my
question
would
be
like.
Is
there
anything
on
in
this
area
that
we
haven't
discussed
that
we
should,
or
you
know
we
got
some
gap
that
we
didn't
in
all
the
discussion
we
didn't
sort
of
cover
or
that
we
should
dive
into
a
little
bit
see
if
there's
any
other
ideas
come
out
of
that.
J
A
A
J
But,
yes,
saying
within
a
runtime,
hey
module,
x
or
http
endpoint
y
can't
access
a
file
system
altogether
is
something
that's
discussed
around
security
models
and
questions
and,
as
far
as
I
know,
there's
no
much
priority
on
that
or
I'm
not
aware
of
any
solution
that
has
been
widely
adopted.
That
provide
this
feature
for
the
reason
I
exposed
the
bitonia.
A
Right
there's
been
some,
I
think.
Like
you
know,
in
core,
there
was
some
experimentation
with
policies
and
stuff
along
those
lines,
but
yeah
like
I
don't
think,
we've
come
to
come
to
something
where
it's
like.
A
A
A
J
A
Yeah,
I
kind
of
remember,
like
you
know,
pros
and
intrinsics
and
stuff
like
that.
I
know:
there's
been
some
work
on
that
front
and-
and
I
think
bradley
bradley
is-
is
off
on
with
a
new
a
new
child,
so
he
might
have
had
some
views
to
add
into
that
and
maybe
we'll
we
can
pull
that
feedback
in
a
little
bit
later.
But
I
haven't
heard
or
seen
the
hay
here.
A
A
This
is
the
threat
model,
and
then
you
can
talk
about
specifically
what
things
help
or
not,
and
that
seems
useful
to
me
in
that
it's
not
just
like
yeah.
Okay
policies
can
help
us
in
abstract
right.
It's
like
okay
in
this
particular
context,
you
can
make
the
call
of.
Does
it
really
give
you?
Does
it
help
you
or
not
right
and-
and
I
think
it
you
know-
it's
a
good
discussion,
pat
well,
you
know,
we
know
what
we
have
locks
on
our
doors.
A
We
know
that
if
somebody
is
a
good
thief
there,
that's
not
going
to
make
any
difference
at
all,
but
we
still
do
it
because
it
helps
in
a
lot
of
cases.
Maybe
there's
a
similar
discussion
here
as
long
as
it's
cast
as
that
kind
of
thing
right
like
and
can
we
can
we
work
with
that?
Like
you
know,
can
our
security
model
be?
We
provide
this,
but
we
don't
consider
it
not
working
a
vulnerability
right.
A
A
A
Okay,
well,
if,
if
not,
then
I
think
you
know,
we've
we've
had
a
good
discussion
and
you
know
I
think
we've
got
some
action
priorities
which
we
can
document
and
I
would
use
this
discussion
to
kind
of
like
we
do
get
some
resources
to
say
here
are
some
of
the
things
as
a
project
we've
looked
at
that
we'd
want
to
do.
A
So,
thanks
with
that,
I
will
close
out
the
call
and
we'll
hopefully
see
everybody
in
github.
Just
before
I
go,
I
think
it's
worth
mentioning
that
we
do
have
another
mini
summit
planned
for
opengs
world,
which
is
in
june
we're
hoping
to
do
that
in
person.
I
assume
we'll.
Maybe
can
also
have
people
come
in
remote
as
well,
but
we
are
planning
to
go
into.
Let
me
find
that.
A
A
A
You
know,
I
know,
there's
lots
of
work
going
on
in
the
project.
The
goal
there
is
just
to
say
like
are
we
doing
everything
that
we
should
be
doing
documented
priorities
and
maybe
the
yes,
some
team
will
just
say:
yeah
here's
the
plan,
it's
all
done.
We
won't
have
to
do
anything,
but
those
are
kind
of
like
the
two
next
highest
priority
ones.
We
thought
that
we'd
dive
into
also
a
good
time
to
give
a
bit
of
a
pitch
for
the
collaborator
summit.
It's
going
to
be
the
two
days
after
opengs
world
we're
planning.
A
You
know
two
days
of
node
topics,
the
the
there
is
in
our
summit,
repo
information
about
submitting
topics.
So
we,
you
know
anybody
can
go
in
there
submit
topics
that
we
want
to
have
clairvers
talk
about,
and
now
is
the
time
to
start
going
in
and
submitting
those,
because
we
need
to
put
that
together
in
the
next
couple
months.