►
From YouTube: SES Meeting: February 8, 2023
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
B
B
He
proposed
finding
a
way
to
lock
down
arrayed
out
prototype
symbol.iterator
property
in
order
to
make
iteration
consumption
safe
from
interference
at
a
distance
and.
A
So
so
so
let
me
ask
what
what,
when
you
say,
talk
about
safety
and
vulnerability?
Are
you
looking
at
a
hard
context.
B
Javascript
actually
SAS
does
protect
against
this.
So
the
issue
is
that
in
in
a
normal
JavaScript
context,
any
code
can
overwrite
the
array,
prototype
symbol.iterator
property
and
when
they
do
so
anything
that
uses
iteration
protocol
to
consume
from
an
array
is
going
to
is
going
to
use
your
override,
rather
than
actually
iterating.
The
array
elements
reliably.
A
Okay,
so
what
I
don't
understand
about
this
is,
if
we're
not
if
we're
talking
about
just
normal
JavaScript
you've,
got
pervasive
vulnerability
of
everything
to
everything
anyway.
So
what's
the
threat
model
we're
addressing
this
particular
vulnerability,
while
leaving
everything
else
in
a
state
of
everything
vulnerable
to
everything?
B
D
So
I
I'm
sharing
the
screen
right
now,
and
this
is
the
argument
that
came
out
like
the
example
is
just
a
Ford
iteration
for
authorization
of
a
simple
array,
and
that
is
just
purely
using
purely
syntax
pretty
much
and
that
it
it
would
be
vulnerable
to
somebody
overriding
the
array,
prototype
symbol,
iterator,
so
I
think
the
the
level
the
distinction
here
is
the
level
of
surprise.
I
would
guess.
A
So
I
just
I'm
struggling
to
find
coherence
here.
The
there's
plenty
of
places
where,
in
normal,
unprotected
JavaScript
things
depend
on
operations
that
can
be.
You
know
that
that
JavaScript
code
to
mutate
and
so
doing
introduce
arbitrary.
You
know
not
arbitrary,
but
tremendous
number
of
surprises
the
in
general.
The
defense
that
the
spec
has
engaged
in
with
regards
to
those
things
is
to
decide
to
use
the
internal
function
rather
than
the
current
value
of
the
property.
A
For
some
things
like,
for
example,
a
weight
does
not
use
the
current
value
of
Promise
prototype,
then
it
uses
the
internal
then
method.
There's
lots
of
lots
of
things
like
that,
where
you
just
resort
to
internal
methods,
but
if
you're
polymorphic,
where
there's
not
a
single
internal
function,
but
rather
a
operation
that
depends
on
the
receiver,
then
for
normal
JavaScript,
it's
I
would
say
part
of
the
intended
semantics
of
the
language
that
it
depends
on
the
receiver
and
what
the
receiver
is
depends
on
how
the
environment
has
been
mutated.
D
Yeah
and
and
and
and
I
believe,
I
wish
in
special
case
things
like
that,
and
if
you
want
a
reliable
exhibition
environment,
the
solution
will
be
devastating
is
to
freeze
the
intrinsics.
D
So
I,
when
this
came
up,
I
I
suggested
that
we
should
instead
fix
the
the
override
mistake
instead
of
making
some
intrinsics
somehow
not
triggering
it,
and
so
basically,
I
I
was
against
like
introducing
more
exotic
behavior
in
intrinsics,
to
not
trigger
the
override
mistake
and
have
a
general
mechanism
to
not
trigger
the
overall
override
mistake
that
could.
A
D
The
behavior
of
intrinsics
Frozen
intrinsics,
as
well
as
allow
user
code
to
freeze
their
their
own
classes
and
instances
in
a
way
that
doesn't
trigger
the
override
mistake
and
and
let's
talk.
A
A
Yeah.
Are
we
talking
about
shoes
presentation?
So
let
me
say
a
little
bit
about
that,
because
I
think
there's.
This
is
a
tremendous
opportunity
for
us,
so
shoe
in
a
similar
manner,
wanted
to
introduce
what
what
he
called
a
secure
mode.
Also
I
won't
say
a
similar
matter.
A
shoe
actually
has
has
stated
a
coherent
threat
model
and
he
has
proposals
that
I
think
are,
oh,
you
know
are
coherent
with
regard
to
his
coherent
threat
model.
A
The
oh,
let
me
I'll
I'll
recount
all
of
that
in
some
details.
Let
me
jump
ahead
to
sort
of
the
the
conclusion
that
I
took
from
it,
which
is
he's
raised.
A
The
he's
proposing
a
set
of
security
mechanisms
that
include
introducing
a
explicit
new,
secure
mode
and
we've
shied
away
from
explicitly
talking
about
a
new
mode
mood
switch
in
the
implementation,
because
in
particular
we
expected
that
if
we
had
proposed
such
as
something
that
that
radical
and
with
that
much
implementation
burden,
that
Google
in
particular
would
be
the
one
to
say.
No,
so
having
Google
in
particular,
be
the
ones
who
propose
mode
switch
is
just
a
tremendous
opportunity.
A
The
specific
mechanisms
that
Chu
wants
to
hang
off
of
the
mode
switch
do
not
include
fixing
the
override
mistake,
but
if,
but
one
could
say
that
a
JavaScript
realm
in
Secure
mode
simply
didn't
suffer
from
the
override
mistake
and
then
some
of
the
things
that
he's
trying
to
address
other
means
could
be
better
addressed
by
simply
not
being
subject
to
the
override
mistake.
A
So
the
shoes
overall
threat
model
I
would
characterize
as
you've
got
inside
the
realm
no
malicious
code,
but
you've
got
fallible
code.
You've
got
code
that
might
be
non-maliciously
buggy
in
all
sorts
of
you
know,
sort
of
plausible.
A
You
know
plausible
ways
in
which
programmers
write,
buggy
code
and
you've
got
malicious
data
being
processed
by
the
allible
innocent
fallible
code,
and
then
what
he's
trying
to
address
is
some
of
the
sharp
knives
by
which
malicious
data
can
confuse
fallible
code
into
causing
execution
to
proceed
in
a
way
that
gives
an
attacker
an
opportunity
to
to
to
induce
misbehavior
in
the
attacker's
interests
and
I
said
I'm,
stating
it
in
that
general
term
terms.
A
If
this
you
know,
this
is
my
point
now
I'm
talking
from
myself,
not
for
sure
in
general,
when
you
take
a
look
at
the
threat
model
of
fallible
code
having
you
know
the
programmer,
writing
the
fallible
code,
having
made
assumptions
about.
What's
what
invariants
are
true
of
their
data?
You
know
making
tacit
assumptions,
usually
inarticulate,
just
kind
of
you
know,
assuming
it
without
thinking
too
hard
about
it,
and
then
the
malicious
data
violates
those
assumptions
causing
the
execution
to
proceed
in
ways
that
are
that
violate
the
programmers
assumptions.
A
When
they
wrote
the
code,
I
think
that
there's
no
principled
limit
that
you
can
place
on
the
misbehavior
in
general
that
malicious
data
can
induce
interfallible
code.
A
There's
no,
you
know,
there's
no
principle
that
lets
you
limit
that
misbehavior
to
anything
less
than
the
misbehavior,
that
malicious
code
could
have
engaged
it
so
that
you
know
a
A
system
that
defends
against
malicious
code
will
defend
against
the
limit
of
militia
data
processed
by
fallible
code
and
the
the
set
of
mechanisms
that
Chu
is
proposing
is
not
not
in
aggregate
simpler
than
hardened
JavaScript.
A
So
we
can
defend
against
the
stronger
threat
model
against
the
limits
of
what
is
coherent,
starting
with
his
threat
model,
and
do
it
for
about
this
amount
of
total
mechanism
and
explanation.
So
that's
why
I
think
there's
a
tremendous
opportunity
here.
The
particular
thing
that
he's
focused
on
is
prototype.
Poisoning
he's
focused
on
Prototype
poisoning
because
he's
assuming
that
primordials
do
not
get
transitively,
Frozen
or
Frozen
at
all,
and
the
reason
he's
assuming
that
primordials
don't
get
Frozen
at
all,
is
he's
assuming
that.
A
Well,
two
things:
one
is
he's,
assuming
that
the
override
mistake
deters
people
from
freezing
primordials
and
that's
better
addressed
by
just
getting
rid
of
the
override
mistake.
A
Once
we
have
the
opportunity
of
secure
mode
and
then
the
other,
the
other
reason
is
compatibility
with
shims
and
the
need
to
make
a
phase
distinction
between
when
the
shin
shims
customize
the
primordial
environment
versus
when
the
rest
of
the
application
executes
and
from
what
I've
seen
I
think
the
phase
that
phase
boundary
exists
generally
in
Practical
code
shims
that
Mo
that
mutate,
the
primordials,
are
generally
pretty
specialized
and
most
good
code
out.
There
does
not
mix
in
that
specialization
with
application
logic.
A
After
the
application
logic
starts
running
and
SES.
We
haven't
actually
done
this
yet
in
the
shin,
but
we
architected
it
so
that
there
is
a
phase
between
the
repair
step
and
the
hardening
step.
That
lockdown
is
is
actually
internally
constructed
with
two
phases.
The
repair
step
does
things
like
put
like
prevent
any
sloppy
execution,
replace
all
the
evaluators,
with
safe,
safe,
evaluators
and
a
bunch
of
other
things,
so
that
you
can
reason
about
things
using
object
capability
reasoning,
but
without
yet,
but
without
any
of
the
primordials
yet
being
hardened.
A
So
that's
the
phase
and
then
between
so
and
then
and
then
in
that
phase
you
run
what
you've
been
calling
vetted
shims,
meaning
that
you're
still
vulnerable
to
any
misbehavior
by
the
shin,
because
that
you
can
muted
anything.
But
then
afterwards,
after
the
vetted
shim
phase,
you
you
do
the
red
you
do
the
hardening
transitive
hardening
of
the
primordials
and
then
it's
only
after
that
that
you
load
untrusted
code
into
that
environment.
A
So
I
think
that
deals
with
shoes.
You
know
second
reason
for
thinking.
People
won't
freeze
the
primordials,
which
is
that
need
to
do
the
shims.
Obviously
that's
subject
to
empirical
investigation.
How
much
code
is
it
compatible
with
in
practice,
but
from
what
I've
seen
I
think
the
answer
will
be
in
our
favor
and
then
there's
some
further
things
that
that
are
part
of
his
proposal
like
not
having
navigation
to
Dunder.
A
Proto
or
to
the
Constructor
property,
the
prototypes
dot,
Constructor
property
happen
with
computed
property
lookup,
because
that's
certainly
an
opportunity
for
for
malicious
data
to
introduce
property
names
in
the
data
that
are
then
looked
up
in
a
computed
manner
by
code
thinking,
it's
just
navigating
Json
data
and
in
fact,
navigates
to
to
built-in
stuff,
and
for
that
you
know,
hardened
JavaScript
doesn't
do
much,
particularly
for
you.
A
A
Oh
and
then
to
answer
Daniel's
question:
no,
we
actually
had
not
been
talking
about
shoes
proposal
at
the
beginning.
We
were
talking
about
this
other
Integrity
issue
of
trying
to
protect
some
iter,
some
iteration
methods
on
primordials,
from
from
being
replaced
for
some
iteration
consumers
and
I
was
arguing
that
doing
that
trying
to
do
any
kind
of
Defense
there
by
itself
for
normal.
C
Yeah
I,
don't
I,
don't
disagree
with
that
or
I
mean
maybe
there's
some
coherent
story
behind
me,
but
I
haven't
heard
it
at
the
same
time,
I
I'm,
I'm
a
little
I'm,
not
sure
if
I
would
rate
so
high
the
probability
that
we
managed
to
like
shift
what
she
was
talking
about
into
getting
us
into
a
totally
frozen,
primordial
worlds.
A
Well,
the
he
was
certainly.
C
Yeah
conversations
are
great
at
some
point
in
the
presentation
it
sounded
like
you
were
saying
that
it
sounded
like
you
were
saying,
like
you,
wouldn't
want
to
see
his
proposal
go
ahead.
If
it
didn't
include,
this
didn't
include
more
SES
style
things.
A
Yeah
I
think
that
what
he's
doing
is
is
his
proposal
without
his
proposal
is
introducing
a
bunch
of
mechanisms
that
is
only
motivated
by
the
assumption
that
the
override
mistake
remains
and
if
you
fix
the
override
mistake
and
you
can
freeze
the
primordials,
then
there's
other
mechanisms
you
just
don't
need
so
I
think
that
his
proposal,
first
of
all,
I,
don't
think.
A
There's
appetite
on
the
committee
for
two
secure
modes,
I
think
we're
at
most
going
to
get
one
secure
mode
and
I
think
that
we
have
a
much
more
compared
story
of
of
a
secure
mode
that
addresses
his
threat
model
as
well
as
ours,
and
the
thing
you
know
the
thing
that
I
began.
My
presentation
just
now
with
is
a
case
I'm.
You
know,
I'm
planning
to
you
know
articulate
to
him
as
well
and
to
the
committee,
which
is
this
thing
about
the
jet.
A
C
C
The
CSP
options
do
have
plumbing
through
tc39
I
I
kind
of
worry
that
I
wouldn't
want
to
push
this
in
a
direction
where
they
just
do
something
at
the
web
level
and
like
don't
even
put
the
plumbing
through
through
the
JavaScript
specification,
then
that
would
make
it
more
difficult
to
access
like
the
full
in
practice.
Definition
of
the
language
and
I.
C
Already
have
multiple
secure
modes
in
the
way
JavaScript
is
used,
I
mean
there's
multiple
CSP
modes
and
this
has
plumbing
through
JavaScript
and
you
know,
obviously,
strict
mode
increases
security.
So
I
guess
I'm
kind
of
wondering
what
you
meant.
When
you
say
you
don't
see
appetite
on
the
committee
for
multiple
secure
modes.
B
C
A
A
The
V8
team,
in
particular,
just
felt
like
the
complexity
introduced
into
the
engine
of
having
a
having
to
support
two
modes.
Even
though
strict
mode
was
simpler
from
the
point
of
view
of
users,
the
fact
that
they
can
opt
into
brick
mode
and
program
in
a
simpler
and
more
well-behaved
language
is
great,
but
from
the
point
of
view
of
the
implementers,
they
don't
get
to
shed
any
of
the
previous
complexity.
A
If
you
introduce
a
new
mode
into
the
language
that
changes,
the
kinds
of
you
know
that
changes
things
that
the
engine
needs
to
do
in.
You
know
in
shoes
case
having
to
do
with
with
you
know,
computed
property
navigation
and,
in
our
case,
having
to
do
with
suppressing
the
override
mistake.
A
That's
additional
complexity
in
the
language
engine
that
affects
execution
and
it's
historically
anything
that
looked
like
a
new
mode
switch
where
the
language
has
multiple
modes
of
execution
was
something
that
the
committee
pushed
back
on
very
very
hard
now.
It
might
very
well
be
the
case
that
that's
that's
old
news.
A
That's
no
longer
the
case
because,
having
experienced
it
generally,
we've
held
back
on
pushing
anything
that
looks
like
a
mode
switch,
and
the
result
is
that
most
people
on
the
committee
now
probably
have
just
never
lived
through
an
era
where
implementers
were
pushing
on
it.
But
the
the
thing
that
that
stands
out
to
me
is
that
Google
was
the
main
one
saying
no
more
mode
switches
and
now
they're
saying
we
want
a
mode
switch.
A
C
Definitely
personally
sympathetic
to
the
no
mode
switches
argument,
I
think,
there's
a
little
difference
between
a
mode
switch
which
just
prohibits
things
like.
If
we
had
this
mode
that
prohibited
keyed
access
of
things
called
prototype
or
gender
Proto
and
there's
a
difference
between
that
and
a
mode
that
enables
things
like
the
fix
to
the
the
override
mistake.
C
I
think
it's
more
acceptable
for
something
to
be
kind
of
out
of
band
if
it's
just
strictly
getting
rid
of
things,
but
it
would
be
more
difficult
to
put
the
override
mistake
fix
out
of
band
because
he
may
have
a
JavaScript
module.
That
depends
on
the
face
of
the
override
mistake
and
it
just
gets
run
in
the
wrong
way
and
that
messes
things
up
as
much
as
I'm
sympathetic
to
fixing
the
override
mistake
and
like
Bloomberg,
wants
to
figure
out
how
to
fix
it,
because
we
sometimes
freeze
things.
A
So
so
I
think
I
mean
I.
Think
that's
a
good
empirical
question,
which
is
you
know
if
there
really
is
differential
and
engine
complexity
and
especially
if
the
differential
engine
complexity
results
in
a
greater
loss
of
confidence
in
engine
Integrity,
I'm.
C
Not
even
talking
about
engine
complexity
I'm
talking
about
for
for
users,
if
the
the
like
enabling
capabilities
versus
disabling
capabilities
changes,
kind
of
where
the
where
the
switch
could
live
this.
This
separate
from
the
implementation
complexity,
which
yeah
I
I'm
not.
A
A
Found
yeah
even
yeah,
and
that
you
know
with
this
empirical
investigation
of
trying
to
turn
I'm
trying
to
get
rid
of
the
override
mistake,
and
that
was
the
thing
that
that
was
the
discovery
that
caused
us
to
back
off
and
that
was
for
an
old
copy
of
low
Dash.
It
was
already
fixed
in
the
current
distributed
copy
of
low
Dash.
If
I
recall,
foreign.
E
Back
in
The,
Matrix
chat,
I
did
the
investigation
for
the
lodash
issue.
The
lettuce
issue
isn't
actually
an
issue.
It
was
that
we
were
using
a
counter
to
figure
out
if
anything
hit
the
override
mistake,
low,
Dash
trips,
that
counter,
because
it
is
using
the
override
mistake.
However,
the
function
that
does
it
continues
to
work
properly.
A
E
Yeah
I
said
this:
originally,
it
might
not
actually
be
a
web
compatibility
issue,
but
we
don't
have
a
way
of
automatically
detecting
it.
C
A
So
the
getting
so
fixing
the
override
mistake
would
would
remove
shu's
main
reason
for
skepticism
about
phrases
in
the
primordials
and
the
remaining
you
know.
The
remaining
reason
was
this
thing
about
the
faith:
separation
of
shem's
versus
application
code
and
I
think
I.
Think
there's
there's
you
know
two
I
think.
First
of
all,
shu
is
not
aware
that
cess
had
the
you
know
was
built
to
have
this
the
phase
separation
between
repair
and
hardening,
that
it
does
I.
Think
that
took
him
a
bit
by
surprise
and
the
other
one.
A
Is
that
just
you
know
our
experience
of
help
of
you
know
the
incredible
amount
of
code
not
written
to
run
under
cess
that
actually
does
run
under
cess
compatibly.
We've
been
very,
very
pleasantly
surprised
at
the
volume
of
code.
That
is,
is
of
that
character,
certainly
not
all
code,
but
it's
a
tremendous
amount
of
code.
A
And
you
know
he's
in
his
presentation,
especially
the
last
slide
of
the
presentation
explicitly
and
now
you
know
acknowledged
that
the
secure
mode
would
not
be
compatible
with
all
of
JavaScript
that
this
was
a
breaking
change.
It's
just
a
breaking
change.
That
is
that
that
you
know
he
hopes
is
compatible
with
the
tremendous
amount
of
code
and
I
think
our
our
system
is
already
demonstrating
a
degree
of
compatibility
with
all
with
tremendous
amount
of
old
code
that
he
would
find
surprising.
C
So
I
think
there
are
further
reasons
why
it
would
be
more
work
to
convince
the
Chrome
team
to
to
go
all
in
on
SES
for
solving
this
particular
kind
of
problem.
One
reason
is
because
they
see
headers
as
an
easy
to
deploy
way
to
put
in
security
measures
like
CSP
interested
types,
such
a
mode
that
that
shoe
is
demonstrating
could
be
enabled
by
headers
and
I.
C
Think
it
would
not
be
totally
inappropriate
to
do
so
or
like
uncomposable
or
things
like
that,
because
it's
just
prohibiting
constructs
as
opposed
to
enabling
things
SES.
Obviously
like
is
not
enabled
by
headers
I
guess,
maybe
it
could
have
a
trusted
type
style
API,
where
it
says,
run
this
code
before
the
lockdown
then
run
this
code
afterwards.
C
A
Okay,
so
so
what
you're
talking
about
are
specific
to
web
and
browsers,
you
know,
tc53
is
has
Oregon
in
a
Cess
Direction.
In
that
the
the
you
know,
the
the
the
portable
tc53
compliant
JavaScript
for
embedded
is
code
that
that
should
that
is
supposed
to
run
correctly
in
a
in
a
hardened
JavaScript
environment
and
models,
of
course,
has
built
their
excess
machines
so
that
the
the
normal
configuration
for
running
an
embedded
is
basically
a
a
a
SAS
machine.
A
It's
a
machine
with,
without
so
the
fact
that
we've
got
a
standards
body,
a
virtual
machine
and
and
a
bunch
and
and
several
large,
you
know,
JavaScript
systems,
especially
you
know,
metamask
the
main
JavaScript
wallet
main
browser
wallet
for
ethereum
all
using
assess
the.
A
And
that
it
does
address
shoes
problem
and
it
doesn't
do
it
in
a
way,
that's
specific
to
the
browser.
I
think
these
are
all
sets
of
powerful
arguments
and
doing
both
is
just
more
complicated.
Now
you
know
the
I
also.
You
know,
instead
of
trying
to
anticipate
all
the
all
the
shoes
possible
reactions
and
arguing
about
what
those
reactions
are.
We
should
just
take
the
conversation
to
shoe
and
try
to
make
progress.
C
A
Shrek
I
mean
the
that
incremental
progress
does
not
add
complexity
by
virtue
of
of
not
addressing
the
whole
problem.
It's
a
step
towards
addressing
the
whole
problem
that
that
bar
is
no
complexity
on
the
way
so
I'm,
all
in
favor
of
that.
D
So
I
think
my
original
idea
was
assuming
we
couldn't
fix
the
override
mistake,
just
fix
it,
and
so
should
we
expect
so
I
think
we
can't
really
explore
exploring.
D
Just
fix
the
override
mistake
is:
is
a
question
more
for
implementers,
adding
adding
an
experiment,
I
suppose.
C
D
C
D
But
I
assume
this
is
something
that
we
need
to
be
able
to
disable
with
a
experiment
fly
right.
C
D
D
How
that
kind
of
stuff
works?
To
be
honest,
so
it's
really
hard.
C
Possibility
if
we
come
up
with
a
way
to
implement
this
check
is
run
it
through
what
we
find
in
HTTP
archive,
which
will
be
kind
of
a
you
know.
We
run,
we
run
it
on
a
bunch
of
websites
and
see
if
it
triggers,
and
then
we
try
to
include
it
on
browsers
only
if
we
really
see
that
it
doesn't
trigger
in
those
kind
of
offline
tests.
C
D
I
don't
understand
it's
like
if
we're
talking
about
like
changing
the
Behavior
of
basically,
what
is
it?
I
can
never
remember
a
name.
That's
like
ordinary
sets
within
the
scripture,
I
I.
Suppose
the
the
changes
in
there
to
fall
back
to
do
a
set
only
instead
of
failing
right,
so
I
haven't
looked
at
this
in
a
while,
but
so,
if
I
I
don't
know
how
I
I
I,
who
would
be
able
to
like
meet
this
effort?
Because
that's
not
me.
C
I
can
kind
of
talk
someone
else
through
it.
The
way
that
I
did
last
time
but
didn't
follow
up
appropriately
last
time,
I
would
be
able
to
do
the
implementation
right.
C
So
maybe
for,
for
example,
it
could
be
the
same
kind
of
counter,
but
then
we
check
oh,
was
it
this
particular
version
of
low
Dash?
This
is
the
kind
of
test
that
we
could
run
not
embedded
in
browsers,
but
if
we
run
it
against
an
archive
of
websites,
we
could
you
know.
Look
at
a
few
versions.
See
like
oh
okay,
yeah,
the
surrounding
code
is
this
exact
string,
then
I
will
and
we
could
include,
like
a
bunch
of
kind
of
signatures
of
that
and.
D
C
C
So
you
would
just
see
if
the,
if
the
trigger
that
this
code
path
hit,
was
the
one
that
Caitlyn
already
implemented
was
hit
and
if
it's
not
running
that
particular
low
Dash
thing
so
wouldn't
check
for
failure.
We
check
for
for
coverage,
but
then
omitting
the
cases
that
we
can
identify
as
it's.
This
particular
loadash
thing.
D
C
D
But
is
it
also
the
case
that
if
you're
running
in
non-strict
mode,
the
assignment
would
have
failed
and
you
would
have
silently
kept
executing
and
so
another
assignments
would
succeed
and
you
would
silently
get
to
keep.
D
Your
object
with
a
different
shape
than
what
you
what
it
previously
sure.
A
All
right,
so
so
that
that
that
issue
about
the
silent
Divergence
is
a
reason
to
consider
what
bundling
a
strict,
only
mode
with
a
fixed,
override
mistake
mode,
which
of
course
it
would
be
another
step
in
the
direction
of
heart
and
JavaScript.
D
Could
we
so
would
it
be
possible
to
to
know
which
strict
mode
we're
in
when
we're,
when
we're
doing
the
ordinary
sets.
D
Like
could
we
could
we
only
basically
could
we
only
trigger
this
override
mistake
fix
if
we're
in
strict
mode.
C
Sufficient,
but
we
don't
have
enough
evidence,
we
don't
have
enough
evidence
that
that
would
be
web
compatible.
That's
the
evidence
that
we
have
to
collect,
but
okay.
D
All
right
so
in
in
strict
mode,
this
would
be
purely
going
from
a
failing
case
to
a
non-failing
case,
which
means,
unless
the
code
try
catches,
it
try
catch
and
as
a
cash
check,
other
code
would
would
have
failed
in
the
first
place.
Yeah.
C
D
C
D
D
So
what
what
would
the
analysis
look
like?
Basically,
we
triggered,
we
would
have
triggered
the
override
mistake
and
it
would
have
been
there's
a
try
catcher
on
this,
some
somewhere
like
how
do
you?
How
do
you
test
for
that.
C
So
I
keep
saying
the
the
way
we're
testing,
for
it
is
whether
it's
hit
or
not.
This
override
mistake
path.
So
it's
a
it's,
not
a
it's.
A
it's
a
sufficient
but
not
miss
I
mean
it's
a
necessary,
but
not
sufficient
condition
for
proving
the
web
incompatibility.
So
if
we
find
that
no
one's
hitting
this
at
all,
except
for
low
Dash,
then
that
would
prove
that
it's
probably
low
compatible.
C
But
if
we
do
this
process,
we
would
find
other
concrete
examples
that
we
could
look
into
okay,
so
I,
don't
I,
don't
have
a
solution
to
this
like.
Let's,
let's
find
some
automated
thing
that
will
determine
compatibility
of
everything.
No
I,
don't
I.
Don't
have
that
just
a
stronger
thing
that
we
could
check
for
and
if
that's
true,
then
we've
proven
our
point.
My.
D
My
concern
is
that
we'll
find
other
cases
of
the
path
that
would
have
been.
C
We
just
haven't
found
those
yet
so
I
feel
like
finding.
Those
would
be
the
next
step
in
the
analysis.
D
C
D
I
think
I
have
connection
issues
yeah,
so
it's
probably
not
the
worth
exploring
Alternatives
until
we
have
more
data
on
whether
fixing
your
right
mistake
is
possible
in
the
first
place.
Well,
if
it's
possible
to
fix
your
writing
mistake
without
as
explicit
opt-in.
D
My
alternative
suggestion
was
not
automatically
bundling
with
a
mode,
but
if
you,
if
you
don't
want
to
tie
it
to
us
to
a
special
mode,
it
would
be
to
have
a
basically
the
equivalent
of
a
different
Integrity
level,
which
is
like
a
super
freeze
which
wouldn't
trigger
the
override
mistake
for
objects
that
have
been
super
Frozen.
D
A
D
A
Oh
and
and
Harden,
our
hardened
would
also
use
Super
Freeze
for
each
step
in
general,
not
just
for
the
primordials.
D
And
by
the
way,
if
I
didn't
think
of
the
Super
Freeze,
that
I
had
in
mind
would
also
cache
this
Integrity
level,
so
that,
if
you
do
a
check
like
it's
frozen,
it
doesn't
explicitly.
Recheck
can
trigger
all
the
potential
proxy
traps
on
the
targets.
C
Yeah
overall
I
I
think
if
we
find
that
the
that
this
thing
of.
C
C
Better
than
having
it
be
on
a
global
mode
switch,
even
if
it's
really
unfortunate,
it
seems
like
a
per
object
property.
You
wouldn't
want
it
to
be
like
a
per
chunk
of
code
property,
because
if
it's
per
chunk
of
code,
then
you
know
you're
still
interacting
with
things
that
were
come
from
other
chunks
of
code.
You
know.
So,
if
it's
attached
to
the
data,
it
should
be.
A
I
would
I
would
be
so
first
of
all
doing
it
on
Super
Freeze
I'd
be
very
happy
for
that
solution
to
happen
if
it
were
simply
a
realm-wide
mode
switch
that
would
that
would
be
fine
with
me
as
well,
but
it
does
mean
that
it
would
be
that
that
that
it
affects
all
code
in
the
realm
having
it
be
on
a
per
modular
basis.
You
know
is
basically
scoped
to
code
rather
than
objects
or
Realms.
I
agree.
That
would
be
weird.
A
C
Wait,
I
guess,
there's
two
different
per
code:
things
one
is
the
allocation
site
triggers
which
mode
it's
in
and
then
the
other
one
is
the
assignment
site.
So
I
was
definitely
thinking
about
the
allocation
site
anyway.
I
think
we
can
agree
that
per
code
is
bad
and
that
we
okay
decision
tree
is
either.
This
is
part
of
Super
Freeze,
or
this
is
part
of
a
realm
wide
switch.