►
Description
We met again with Santiago Díaz to review and discuss mitigating data-only prototype-pollution-attacks in no-eval realms https://github.com/tc39/proposal-symbol-proto
A
B
Waldenburg
(ch-zrh-eurd,
7):
yeah,
thank
you..
Thank
you.
So
much.
again,
ii
found
our
last
conversation
really
really
useful..
So
we
started
talking
about
prototype
pollution
as
a
class
of
vulnerabilities,,
which
is
something
we
really
care.
About,,
because
there's
been
a
lot
of
work
done
to
fix.
Cross-Site
scripting
vulnerabilities
on
the
web,,
but
just
generally
like
a
lot
of
improvements
to
javascript
security.
B
Waldenburg
(ch-zrh-eurd,,
7):
and
prototype
pollution
is
an
important
class
of
books,
because
it's
the
one
example,
that
we
have
where,
from
using
those
data,
an
attacker
can
actually
get
code
execution
on
a
javascript
environment.
and
there
is
a
bit
of
a
paradigm
change
for
us,
and
I
guess
in
general,
for
web
security
and
and
javascript
as
well..
So
it's
an
interesting
area
of
work.
B
B
Waldenburg
(ch-zrh-eurd,
7):
one
being
data.
Only
prototype
pollution
attacks,
which
refers
to
this
idea
that
the
code
that
is
running
in
the
runtime
is
trusted,
and
the
things
that
are
not
trusted
are
the
data
that
flows
through
it
as
opposed
to
running
code.
That
is
untrusted..
And
then
you
know
that
has
different
consequences
and
different
requirements.,
and
so.
B
Waldenburg
(ch-zrh-eurd,
7):,
the
idea
is
to
okay.-
and
this
is
all
in
the
context
of
a
proposal
that
is
anticipatory.
9
at
the
moment,
is
in
stage
one,
and
I've
been
gathering
some
feedback
from
different..
Let's
call
them
stakeholders,
all
of
you,
included,
and
kind
of
refining.
What
the
proposal
should
look
like.
so
today,.
I
want
to
give
you
an
update
of
what
that
is..
This
should
be
very
short,.
I
guess,,
depending
on
where
the
conversation
takes
us,,
but
I
have
only
about
5,
slides
or
so.
B
B
Waldenburg
(ch-zrh-eurd,
7):,
so
yes,,
the
the
main
goal
for
this
conversation
for
me
is
to
get
your
perspective..
What
you
think
about
this.
get
any
comments
and
feedback
that
you
can
give
me
more
or
less..
I've
tried
to
include
your
perspective
of
the
of
the
problem.,
so
all
prototypes
beyond
data
only
attacks.,
and
I
really
hope
that
we
can,
that
that
is
captured
in
in
what
I'm
gonna
say.
Right.
Now.
B
B
Waldenburg
(ch-zrh-eurd,
7):,
so
hopefully,,
that's
enough
context
for
most
people
to
remember
where
we
left
off.
right..
I
think.,
as
I
said,
before,
this
is,
or,.
As
we
said
before,,
this
is
focusing
on
data-only
attacks..
So
one
of
the
really
good
realizations
I
had
from
our
conversation
last
time
is
that
this
proposal
is
really
a
complement
for
freezing
primitives
that
we
have
in
javascript.
B
B
Waldenburg
(ch-zrh-eurd,
7):.
To
some
extent
it
feels
like
freezing
all
prototypes
in
the
chain
sort
of
defeats,
the
purpose
of
security,
because
it's
at
the
expense
of
usability
right?.
We
know
that
prototypes
are
there
to
be
modified,,
and
so
wouldn't
it
be
great
if
we
had
a
solution
that
allows
us
to
have
mutable
prototypes.,
but
I
just
for
them
to
be
modified
in
a
secure.
Way.
do
you?.
C
C
C
C
Mark
s.
miller:,
but
in
all
cases,
empirically,,
it
seems
that
all
of
that
work
is
done
in
an
initialization
phase
prior
to
the
program
actually
doing
its
job,
and
that,
once
the
program
is
set
about
doing
its
job,,
there's
actually
strong
empirical
evidence
that
it
no
longer
modifies
prototypes
in
the
vast
majority
of
cases,
clearly
not
in
all
cases.
B
B
The
first
thing
is,,
you
know,
the
whole
conversation
about
the
overhead
mistake,
and
how
that
makes
freezing
sort
of
less
adoptable,,
but
kind
of
imagining
that
the
override
mistake
just
went
away..
Our
empirical
evidence
is
that
yes,,
it's
true
that
freezing
top
level
prototypes
can
go
a
long,
way,
and
in
being
compatible
with
many
applications.
B
B
Waldenburg
(ch-zrh-eurd,
7):
prototypes
or
types.
right?,
and
because
of
this,,
the
more
you
cover
in
the
chain,,
the
more
restrictions
you
add,.
This
is.
This
is
one
blocker
that
we
have
found..
A
second
blocker
is
that
we
have
found
that
what
we
call
the
freezing
point,,
which
is
this,,
I
think,
you've
referenced
it
with
shims.
B
Waldenburg
(ch-zrh-eurd,
7):
tends
to
move
over
time..
So
that
is
because
you
add
new
dependencies,
or,,
you
know,
refactor,
your
code.
things
move
around.,
and
so
it's
not
always
guaranteed
that
the
freezing
time,.
The
freezing
point
that
you
found
today
will
stay
like
that
in
the
long
run,
and
in
the
future.
It's
a
fairly
bad
developer.
Experience
in
what
we
found
empirically
to
suddenly
have
an
application
that
doesn't
work.
B
B
Waldenburg
(ch-zrh-eurd,
7):,
I
think,
okay..
Perhaps
the
last
point
that
I
will
mention
is
that
freezing
is
really
a
tool
for
experts
in
that.
as
a
regular
javascript
developer
may
be
writing
a
website,
or
you
know,.
Some
other
code
base
is
not
entirely
clear..
What
prototypes
should
I
protect?
and
when
should
I
do
that
like??
What
is
the
risk
of
finding
a
freezing
point?
that
is
very
late
or
very
early
right??
It
seems
that
freezing
is
not
a
very.
B
Waldenburg
(ch-zrh-eurd,
7):
opinionated
api,
right?
it
doesn't.
it's
really
for
experts
who
know
what
they're
doing..
They
really
know
why
they're
freezing
things
when
they're
freezing
them.
and
I
think
because
of
that,,
it's
likely
that
freeze
will
not
see
a
very
widespread
adoption,
or
if,
if
there
is
such
an
adoption,,
I
don't
think
it's
likely
to
be
complete
in
that
there
will
always
be
a
prototype
that
will
be
left
out
and
exploits
that
we
will
be
enabled
enabled
by
that.
mutability.
A
A
A
A
A
C
B
C
C
C
B
Waldenburg
(ch-zrh-eurd,
7):,
so
I'm
not
entirely
sure
whether
I
would
single
them
out..
I
think
so
absolute
agreement
on
the
idea
that
any
object
can
become
a
prototype..
When
I
talk
about
protecting
the
entire
chain,,
I
really
mean
a
chain
that
is
dynamic
where
elements
come
in
and
out
right?
and
because
of
that
they
like.
B
Waldenburg
(ch-zrh-eurd,
7):-
I
guess
that's
a
hint
to
as
to
whether
freezing
will
do
that
or
not
right,,
because
I
don't
think
we
have
a
good
solution
at
the
moment
for
being
able
to
freeze
an
object
when
it
comes
into
the
chain
and
then
unfreeze
it
when
it
goes
out..
I
don't
know
if
that's
the
sort
of
what
you're
hinting
at,,
but
really
the
tldr.
of
what
I
want
to
say
is
that.
B
B
Waldenburg
(ch-zrh-eurd,
7):,
I
see.
thank
you.
yeah,
ii,
agree
with
chris
entirely..
I
think
this
is..
This
is
what
I
meant
before
by
it's.
It's
one
of
the
realizations
that
I
had
from
our
last
talk,,
which
is
that
there
is
really
a
different.
you
know,
security
is
about
economics,
right?
and
there
is
really
a
different
price
to
pay,,
depending
on
what
kind
of
user
you
are.
I,.
The
way
I
see
it
freeze
is
a
very
good
tool
for
power
users.
B
Waldenburg
(ch-zrh-eurd,
7):,
but
there
is
certainly
a
huge
amount
of
code
bases
out
there
that
are
run
or
maintained
by
people
who
are
not
experts
in
prototype
pollution,,
and
because
of
that,
it
would
be
great
to
give
them
an
opinionated
api
that
allows
them
to
continue
working
as
usual.,
but
you
know,
being
protected..
So
this
idea
of
something
complementary
is
something
that
really
resonates
with
me
in
terms
of
whether
the.
B
B
B
Waldenburg
(ch-zrh-eurd,
7):,
which
is
talking
about
the
proposal
per
se,
right?.
So
to
summarize
the
entire
thing
in
a
single
sentence.,
I
think
what
we
want
to
say
is
that
this
is
a
feature
that
exposes
prototypes
only
to
reflection.
apis..
That's,
it
implies
that
prototypes
cannot
be
reached
via
regular
properties,,
as
they
are
right.
Now.
B
Waldenburg
(ch-zrh-eurd,
7):,
mit
ctl,
and
because
computed,
we
we
know
that
in
the
data-only
attacks
computed
property
is
what
leads
to
surprising
accesses
to
the
prototypes.
so,.
Looking
for
a
way
to
put
that
access
seems
like
a
very
promising
solution,,
because
it
really
has
nothing
to
do
with
whether
the
protes
are
mutable
or
not..
B
Waldenburg
(ch-zrh-eurd,
7):.
I
want
to
highlight
3
main
characteristics
of
this
proposal..
The
first
one
is
that
it's
absolutely
not
backward,
compatible..
That
seems
like
an
issue.
if
you
bring
a
new
feature
by
default
on
javascript,
and
because
of
that,.
This
proposal
explains
how
we
can
make
this
into
an
opt-in
feature..
We
touched
a
little
bit
on
that
previously,,
but
we
can
talk
more
about
it.
Today.
B
Waldenburg
(ch-zrh-eurd,
7):.
The
next
thing
is
that
it's
very
easy
to
adopt.,
so
there's
basically
very
minimal
changes
you
have
to
make
to
your
code
base
to
make
it
compatible
with
this
feature,
and
not
only
that,.
The
changes
you
have
to
make
are
very
machine
friendly.,
so
you
can
really
sort
of
programmatically,
apply
them
or
automate
them.
and
there's
a
little
bit
about
the
adoption
story..
I
want
to
give
a
kind
of
example
of
what
you.
B
B
B
B
Waldenburg
(ch-zrh-eurd,
7):
go
in
and
out
of
security
features
right?
for
different
reasons..
Maybe
your
your
code
base
is
compatible,,
but
you
introduce
a
new
dependency
that
is
not
compatible
anymore.,
so
you
need
to
turn
this
feature
off.,
and
this
proposal
takes
that
into
account.,
and
so
your
code,
base,,
should
a
working
code
base
or
a
compatible
code
base
will
continue
to
be
compatible
on,,
let's
say,
a
browser
or
a
js
runtime
that
doesn't
support
this
feature
at
all,
or
that,.
You
know,
doesn't
opt
into
it.
right?.
B
B
B
Kris
“cowbert”
kowal:
okay,,
that's
interesting,,
the
the
and
the
reason
being
exactly
because
of
what
you
say
about
the
the
point
at
which
you
lock
down
in
the
environment
is
a
shifting
thing.
That
is
a
concern
of
the
application
author,
and
because
of
that,
it
has
to
be
coded
in
javascript.
The
moment
where
the
environment
is
locked
in
has
to
be.
A
B
Waldenburg
(ch-zrh-eurd,
7):
yeah,,
I
empathize
with
that..
I
think
some
of
the
use
cases
we
discussed
last
time,,
where
development
tools
that
will
hot
swap
changes
in
your
javascript
files,
and
in
doing
that
they
will
modify
prototypes
sometimes,
and
because
of
that,
like,.
You
know,
this
topic
about
the
freezing
point
is,
can
really
add
some
limitations
in
terms
of
what
you
can
do
and
what
you
can't.,
but
yes,.
Thank
you
for
the
clarification..
I
did
not
know
that.
B
B
Waldenburg
(ch-zrh-eurd,
7):.
The
proposal
is
really
about
exposing
prototypes
through
reflection
apis
only
so
just
as
we
have
get
prototype
of
and
separate
type
of
day,,
which
work,
for
instance,
prototypes.
so,.
Like
donner
proto,,
we
could
add
a
new
pair
of
setters
and
getters
for
what
prototype
right,
or
for
the
prototype
property.
B
B
B
Waldenburg
(ch-zrh-eurd,
7):
because
of
that..
I
called
prototypes
after
this
proposal
on
authorable..
The
data
only
exploits
one
of
the
things
that
I
added
to
this
presentation,
because,,
just
in
case..
You
remember
our
conversation
from
last
time
is
that
we?
we
discussed
a
little
bit
the
idea
of
breaking
symmetry
between
dot,
notation
and
bracket
notation.
B
C
C
B
Waldenburg
(ch-zrh-eurd,
7):
yes,,
it's
an
important
clarification,,
so
let's
call
them..
I
don't
know
what
the
spec
language
is,,
but
so
bear
with
me,,
but
the
slots
that
contain
the
prototypes,
and
the
sort
of
infrastructure
to
build
them.
When
you
create
new
classes
and
new
objects,
and
so
on,
continues
being,.
There
is
just
that
those
slots
are
not
made
available
through
these
string
property,
keys,
right?.
B
Waldenburg
(ch-zrh-eurd,
7):,
which
avoids
the
situation
where
you
have
like
object,
square
brackets,
key,,
and
you
don't
know
what
keys
going
to
be
at
compile
time,
because
it
can
be
anything
at
runtime,
and
you
might
end
up
with
a
surprise
that
that
statement
reaches
a
prototype
right?.
So
it's
really
about
the
string
keys..
The
string
keys
are
key
because.
B
Waldenburg
(ch-zrh-eurd,
7):.
They
are
the
ones
that
have
this
surprise,
effect.,
waldenburg
(ch-zrh-eurd,,
7):
that
your
code
might
end
up
inadvertently
changing
prototypes
when
it's
meant
to
do
something
completely
different,
like
copying
properties,
over.
or,,
you
know,,
parsing,
some
json
string,
right?.
So
there's
no
prohibition
on
using
these
2
string
names
in
unrelated
context.
name
unrelated
properties.,.
B
B
B
Waldenburg
(ch-zrh-eurd,
7):.
What
would
happen
if
I
call
object
dot
property.,
I
wrote
property,,
but
it
should
be
prototype
or
object,
dot,
donder,
proto
like..
What
would
that
return?
right?
and
I
think
there
are
2
options..
The
way
I
see
it.
one
is
simply
do
nothing.,
which
means
that
you
would
return.
it
would
be
undefined..
The
property
would
be
undefined
on
whatever
you
call
it.
that
seems.
B
Waldenburg
(ch-zrh-eurd,
7):
you
know,
reasonable,,
but
I
think
it
would
be
good
if
we
could
think
about.
Maybe
returning
a
poisoned
object.
I
call
it,
that
would
throw
if
you
try
to
access
it..
When
you
opt
into
this
feature,
right?
that
would
fail
loudly,,
it
will
fail
early,
and
it
would
fail
close,
and,
I
think,
that's
fairly
attractive.
B
B
Waldenburg
(ch-zrh-eurd,
7):.
There
is
a
precedent
for
this
for
csp,.
I
think
we
touched
on
this
very
briefly
last
time
in
terms
of
how
the
eval
function
works,,
because
csp
can
disable
the
eval
function.,
and
so
I
think,
there's
a
bit
of
infrastructure
in
javascript
to
make
sure
that
you
know.
Csp
and
eval
are
kind
of
in
sync.
A
A
B
Waldenburg
(ch-zrh-eurd,
7):
yeah,,
that's
correct.,
it's
not.,
it's
not
changing
in
any
way..
You
know
how
we
walk
off
the
chain,
and
whether
we
walk
it
up
or
not..
It's
it's
not
changing..
That
at
all,
is,
is
simply
the
idea
that
the
property,
but
prototype
property
doesn't
exist.
Anymore,
and
their
proto
doesn't
exist.
Anymore.
and,
let's
say,,
I
guess
a
way
of
explaining..
It
is.
B
Waldenburg
(ch-zrh-eurd,
7):,
you
cannot
do.,
you
cannot
delete
prototype,,
but
you
can
delete
thunder
proto
right..
If
you
do
that
on
a
code
base
today,,
then
you
won't
be
able
to
say
object,
dot,
thunder,
proto,
or
you
won't
be
able
to
say,
object.
Bracket,
proto,,
thunder,,
proto
right!.
You
just
won't
be
able
to
do
that
because
the
property
is
not
there,,
but
you
can
access
the
property
anyway
by
saying,
object,,
dot
get
prototype
off.
B
Waldenburg
(ch-zrh-eurd,
7):,
so
this
is
essentially
the
same.
make
the,.
You
know,
do
what
you
guys
have
done
in
tc.
39
for
thunder
proto.,
but
do
it
also
for
prototype
that
way?
We
will
guarantee
that
if
these
2
properties
don't
exist,,
there
are
no
ways
to
reach
the
prototype
from
data.
Only
attacks.
A
A
A
A
D
C
C
C
C
A
A
A
B
Waldenburg
(ch-zrh-eurd,
7):,
so
this
is,,
I
mean,.
This
is
a
very
good
point.
to
to
stop
over
for
a
moment..
This
proposal
is
all
about
prototype,,
not
about
thunder
proto,,
because
under
proto
can
be
deleted.
Today,
you
can.,
you
can
delete
the
property,
and
essentially
essentially
polyfield.
this
right?,
we
have..
So
the
expectation
is
that,
if
you
opt
into
this
mode,
it
is
on,.
You
are
obliged
to
pro
to.
A
Kris
“cowbert”
kowal:,
the
application
is
obliged
to
delete
the
the
donder
proto
property.
so,
in
my
opinion,.
It
would
be
better
if
both
of
them
got
deleted
right.
if
you're,
if
you're,
if
you're
gonna
design
an
opinionated
api,
then
might
as
well
go
all
the
way
in
and
delete
donder
proto
and
delete
prototype..
But
I
just
wanted
to
leave
this
open,
for
you
know,
to
hear
suggestions
and
feedback
because,
you
know,.
It
is
possible
to
delete
under
proto.
but
ideally,.
I
think
we
would
like
to
delete
both
under
this
mode.
A
D
Kris
“cowbert”
kowal:,
I
in
in
my
experience,,
especially
a
lot
of
es
5
code,
relies
on
the
dot
prototype
properties
to
create
class
likes
and
access
class
license
for
that.
in
fact,.
I
think
that
one
of
the
cases
where
we
run
into
an
o,,
like
one
of
the
most
common
places
that
we
run
into
property.
override
mistake
issues,
is
in
exactly
the
same.
Code.
D
A
B
Waldenburg
(ch-zrh-eurd,
7):,
whereas
because
you
will
have
to
make
sort
of
application,
specific
changes
and
and
whatnot.,
but
so
I'm
I'm
not
entirely
sure.
I
would
100
agree
on
the
change
of
cost.
ii,
acknowledge
just
to
be
just.,
be
clear..
The
change
of
cost
is
assuming..
The
override
mistake
was
fixed.
A
Kris
“cowbert”
kowal:,
dot,
prototype,
kris
“cowbert”
kowal:
in
almost
exactly
the
same
places
that
we
find
override
mistake,
problems,
and
the
mitigation
in
both
cases
would
be
if
you
were
to
adopt
this
mode
of
mitigation
or
our
mode
for
mitigation
today?.
The
answer
is
that
you,,
as
the
application
author,
need
to
patch.
B
B
C
C
C
C
D
B
B
Waldenburg
(ch-zrh-eurd,
7):,
I
see.
yes,,
so
I
think
we.
we
come
back
to
the
the
part
of
the
conversation
before
where
you.
you
may
work
around
the
override
mistake,,
but
you
still
have
the
same
issues
we
mentioned,
which
are
being
able
to
protect
the
entire
chain,
and
not
only
a
small
set
of
prototypes,
right
being
able
to
have
a
moving,
freezing
point
without,
and
not
making
any
changes
to
your
code,
and
still
having
a
compatible
code.
Base.
B
D
Mathieu
hofman:,
it
is
best
practices
to
follow,
to
immediately
freeze
any
class
or
objects
that
you
create,
but
we
can.
we
can
get
back,,
maybe
maybe
actually,.
We
should
have
a
presentation
on
what
our
best
practices
are
when
we,
when
we
write
code
in
in
this
mode.,
yes,
exactly.
and
our
aim
with
hardened
javascript
is
for
it
to
not
be
an
expert
feature.,
but
to
just
be
very
obvious.
best
practices.
B
Waldenburg
(ch-zrh-eurd,
7):
okay,.
I
guess
we
yeah,.
Maybe
we
can
continue
the
best
practices.
conversation
I
in
terms
of
cost
and
value.
well,.
I
guess,
if
you,
if
you
get,
you
know,,
if
you
can
pay
the
same
and
get
more
value,,
then
surely
that
means
that
you've
paid
less.,
but
I
guess
that's
kind
of
philosophizing
about
the
the
analogy,
and
and
I'm
not
not
sure.
If
we
get
much
from
it.
ii,
think.
B
D
D
D
B
Waldenburg
(ch-zrh-eurd,
7):
yes,
correct.,
and
I
think
this
is
a
super
important
question,,
because
this
is
something
we've
been
working
a
lot
on.,
it's
basically
what
kinds
of
exploits.
can
I
write
practical
exploits
that
lead
to
some
actual
security
impact?.
If
I
use
this,,
which,
let's
call
it
a
constructor
pollution?.
B
B
B
B
Waldenburg
(ch-zrh-eurd,
7):
status
of
the
runtime
somewhere
in
a
completely
different
corner
of
the
runtime,,
just
by
having
access
to
a
single
object,
right?,
and
there
is
no
evidence
to
say
that
the
constructor
pollution
can
achieve
that.,
but
there's
certainly
evidence
to
say
that
prototype
pollution
can
do
that..
So
I
think
the
the
answer
to
the
question:
is,
yes,,
we
are.
the
scope
of
this
proposal-
is
solely
prototype
pollution,
and
not
this
constructor..
Let's
say
pollution.
D
D
D
B
B
Waldenburg
(ch-zrh-eurd,
7):
help,,
you
know,
have
an
idea
of
what
those
attacks
might
look
like.,
but
they
are
like
they're,
just
not
practical,
and
they're,
not
realistic..
So
one
of
the
things
you
can
do
is
reach
the
includes
function..
Let's
imagine
that
you
have
a
function
that
copies
properties
from
one.
B
B
Waldenburg
(ch-zrh-eurd,
7):,
and
that
means
that
if
you
have
a
piece
of
code
that
says,
I
don't
know.
does
the
username
include
the
word
admin.
You
could
subvert
that
logic
right?.
So
this
is
the
kind
of
theoretical
issues
that
we've
been
looking
into
and
trying
to
explode
in
exploit
in
real
code
bases..
But
there's
really
no
evidence
that
you
know
this
is
practical
in
any
of
the
places
that
we've
seen.
there's
one
book.
B
Waldenburg
(ch-zrh-eurd,
7):
that
looks,,
you
know
it's
a
real
bug,
but
doesn't
seem
very
valuable,
and
is
that
there
was
this
application
with
a
feature
where
you
can
basically
pass.
you
know,
then,
a
set
of
properties,,
and
it
will
call
it
will
fetch
a
function
from
those
properties
and
call
it
on
an
object..
So
these
people
managed
to
go
through
the
constructor
and
get
access
to
object
or
assign
2.
B
B
Waldenburg
(ch-zrh-eurd,
7):,
arguably
an
attack
against
a
specific
logic
in
an
application
that
allowed
users
to
call
arbitrary
functions
on
arbitrary
objects,,
and
that
is
really
not
what
we're
talking
about
here.
right?.
So
I
guess
maybe
those
are..
Those
are
a
couple
of
examples..
There
are
some
references
to
them
publicly,.
I
would
be
happy
to
share
that,
but
just
to
have
an
idea
of
what
instructor
pollution
would
or
could
not
do
in
the
future.
Only.
C
C
C
Waldenburg
(ch-zrh-eurd,
7)::
are
you
familiar
with
that?
I'll
if
not,
I'll
I'll
I'll
find
it
for
you.,
and
so
it
would
be
great
to
see
that.
yes,.
I
think
I
could
add
a
little
bit
of
more
context
about
why
we've
chosen
prototype.
the
original
proposal
chose
constructor..
We
do
exactly
this,,
but
on
constructor.
B
B
Waldenburg
(ch-zrh-eurd,
7):
okay,,
there's
a
few
reasons.
actually,.
The
first
one
is
that
well,
constructor
is
found
in
a
lot
more
places
than
prototype
right.,
and
just
because
of
that
is
like,.
You
know,,
as
maybe
maybe
prototype,
is
marginally
easier
to
roll
out
to
to,
you
know,
programmatically
change,,
as
we
said,
than
constructor,,
but
also
constructor..
There
were
some.
B
C
D
B
D
D
C
B
Waldenburg
(ch-zrh-eurd,
7):
oh,,
that's
interesting.,
waldenburg
(ch-zrh-eurd,
7):
yes,.
So
I
guess
we
come
back
to
the
threat
models.
Here..
I
think
this
is
the
kind
of
things
you
can
have.
when
you
have
code
execution,
but
when
you
don't
have
code,
execution,,
there's
really
no
way
to
through
a
handle
to
the
prototype.
Instantiate
new
objects.
B
B
B
Waldenburg
(ch-zrh-eurd,
7):,
the
original
proposal
discussed
a
few
different
alternatives..
I
will
not
kind
of
lead
with
them.,
I
will
just
say:
that.
there
weren't
very
many
good
alternatives,
there,
and
different
delegates
sort
of
felt
that,.
You
know
a
new
mode
is
not
necessary
like
doing
something
like.
B
Waldenburg
(ch-zrh-eurd,
7):
you
know,
object,
dot.
Enable
new
security.
feature
is
just
creates
a
bunch
of
compatibility
issues.,
so
we've
landed
on
this
idea
of
out-of-band
feature
flags
right?
and
what
that
means
is,.
Maybe
you
set
a
response.
header
that
says,
you
know,
encapsulate
my
prototype,,
or
maybe
you
set
a
flag
like
a
binary
flag
in
nodejs
that
says,
encapsulate
my
prototype..
This
is
simply
the
way
you
opt
in,
or.
B
B
B
C
B
Waldenburg
(ch-zrh-eurd,
7):
only
very
vaguely.,
I
think.
maybe,.
Does
it
make
sense??
If
we
talk
in
in
on
the
web,,
we
talk
about
browser
contexts
where
you
know
you
don't
have
these
concept
of
web
dome
web
origins,,
but
is
basically
a
collection
of
functions
that
came
from
different
places
and
all
live
within
a
single
runtime.
Is
that,
like
a
most
likely
we
can,
ii
assume
this
is
applying
basically
to
a
window
more
or
less.
C
C
C
D
B
B
Waldenburg
(ch-zrh-eurd,
7):,
we'll
figure
out
right
at
the
point
where
line
of
code
is
gonna
run.,
whether
this
code
aim
from
a
context
where
the
feature
was
enabled
or
not,,
because
that
will
imply
that
there
is
provenance
information
that
needs
to
be
kept
for
every
defined,
symbol.
right?
and
it's
very
likely
that
an
implementation
like
that
is
is
just
extremely
complex
to.
C
C
C
B
B
Waldenburg
(ch-zrh-eurd,
7):
yeah.,
waldenburg,
(ch-zrh-eurd,
7):.
Let's
say
that
you
know,,
as
as
an
initial
strawman,,
it
seems
that
being
able
to
freeze
your
browsing
context
is
a
way
in
which
you
can
reason
about
the
runtime
in
general
right?.
You
can
reason
about
the
fact
that
the
property
just
doesn't
exist
in
this,,
no
matter
where
the
scripts
came.
From,
and
I
think
there's
an
advantage
to
that.,
but
maybe
shadow
realms
have
has
some
innovations
on
top
of
this.
B
B
Waldenburg
(ch-zrh-eurd,
7):.
This
is
basically
just
giving
examples
of
what
the
refactoring
would
look
like..
So
I
think
that's
it..
The
last
function
is
vulnerable
when
the
feature
is
not
on
and
it
stops
being
vulnerable
when
the
feature
is
on
without
any
changes..
That's
that's
it.!
That's
the
end
of
that
slide.
B
Waldenburg
(ch-zrh-eurd,,
7):
and
then,,
the
very
last
one
is
basically
talking
about
like
how
the
refactoring
is
machine
friendly..
It
does
touch
a
little
bit
on
the
third
party
dependencies,
which,
or
sort
of
yeah
third
party
dependencies.
That
matthew
talked
about.
and
finally,.
I
think
an
important
part
is
that
this
proposal
is
poly
fillable.
right?.
So
this
means
that
you
can
have..
You
can
refactor
a
code
base.