►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
C
Talk
about
it
yeah,
so
we
approved
this
api
previously,
and
then
we
got
some
more
data
from
some
experts
in
the
field
saying
hey.
This
will
actually
be
really
bad
for
grpc.
We
need
this
extra
feature,
so
we
added
this
keep
alive
ping
policy,
property.
C
D
E
C
The
default
would
be
with
active
requests.
C
I
suspect
very
few
people
actually
care
about
this.
Everything
else
should
be
okay
with
always,
but
I
figure
if
grpc
is
doing
it,
we
don't
know
what
else
is
doing
that,
because.
C
So
the
feature
has
one
serious
use
case,
which
is,
if
you
have
an
outstanding
request,
that's
like
long
pulling
a
server
and
the
server
just
doesn't
have
any
data
to
send
you.
We
want
to
keep
the
connection
alive.
C
C
C
It
means
for
a
specific
connection.
There
has
to
be
an
outstanding
request
on
that
connection.
F
C
C
Because
it's
basically
impossible
for
someone
to
reason
about
if
there
is
an
active
request,
because
we
split
it
up
into
pools
with
a
lot
of
small,
weird
logic.
But
generally
people
are
using
the
same
pool
for
most
use
cases.
F
C
So
you've
made
a
request,
and
now
you
have
a
connection
being
used
for
that
request.
The
request
completes,
we
don't
close
the
connection
immediately.
We
pull
it
possibly
indefinitely,
possibly
based
on
some
lifetime
configuration,
but
we
pull
it
and
always
would
be
sending
pings.
In
that
case,
when
there
are
no
requests
on
the
connections,
it's
just
sitting
there
idle.
F
C
No,
we
have
other
settings
to
control
the
lifetime
of
a
connection
when
it's
idle,
so
that
would
control
the
lifetime.
This
would
just
say
as
long
as
you're
alive.
As
long
as
the
user
asks
you
to
be
alive,
we're
going
to
try
to
keep
you
alive.
C
C
D
C
D
Because
I
I
would
imagine
that,
if
you're
on
a
mobile
or
battery
operated
device
like
the
os
itself,
will
prohibit
you
from
having
an
always-like
policy
because
you'll
be
tombstoned
they're,
the
ones
pulsing
the
socket.
It
never
thought
it
was
idle
yeah.
But
I
I
remember,
like
we
discussed
stuff
like
this
way
back
when
and
decided
that
it
was
a
bad
idea
for
the
operating
system
at
large
to
support
it,
because
it
would
encourage
applications
to
drain
battery.
C
C
Exactly
I
should
also
note
that
grpc,
which
this
request
primarily
came
from
all
of
the
grpc
clients,
allow
this
policy
to
be
configured.
G
C
C
A
Yeah
I
mean
I
like
the
idea
of
adding
it
later,
but
I
mean
cory
made
a
competing
point.
Everybody
else
does
it,
but
when
he
said
that
I
heard
my
mom
that
said,
if
everybody
else
jumps
off
the
bridge,
do
you
also
jump
off
the
bridge?
But
okay,
I
mean
well.
C
Yeah,
I
suppose
the
primary
enabler
for
this
would
be
to
make
it
so
that
the
net
grpc
client
had
all
the
features
of
all
the
other
platform
clients
for
it.
F
C
Yeah
yeah
the
initial
proposal
that
came
to
you
left
this
out,
because
I
did
not
see
that
the
feature
was
needed
either
and
then
I
got
some
data
saying
that
the
default
option
we
chose
was
wrong
and
the
feature
was
needed.
A
Well,
yeah,
I
mean,
if
there's
compelling
reason
why
somebody
would
want
to
configure
always
I
mean,
as
jimmy
said,
the
api
looks
very
reasonable.
It's
just
it
seems
yet
another
way
where
people
can
screw
themselves,
because
I
think,
if
you
don't
know
anything
always
seems
probably
more
likely
what
people
would
pick
if
they
were
configured
manually
than
with
vector
requests.
F
F
D
C
C
Enough
mainly,
I
would
say
that
we
have
lifetime
configuration
elsewhere.
We
can
trust
our
users
to
set
that
appropriately
for
their
scenario.
Maybe.
F
I
mean
the
difference
is
like
with
this
one
it
this
is
taking
it
from
they
have
a
lifetime
management
policy
that
controls
the
resource,
consumption
on
this
system
to
their
they're
now
setting
a
property
that
they
probably
don't
understand.
That's
resource
consumption
on
a
shared
resource.
That's
some
other
system,
whether
it's
a
you
know,
a
nat
or
a
firewall,
or
or
whatever,
like
you're,
increasing
somebody's
state
table
by
doing
these
pings,
or
rather
you're,
preventing
them
from
compacting
their
state
table
and
sure.
So
it
feels
like
yeah.
F
C
A
F
A
A
A
E
So
winforms
has
got
a
text
renderer
to
draw
text,
and
you
know
it's
of
course
the
way
to
specifically
draw
text
directly,
as
opposed
to,
like
you
know,
setting
titles
and
button
text
for
that
sort
of
thing,
so
we
don't
have
any
way
to
get
in
here
with
spans.
So
the
basic
proposal
here
is
to
provide
the
span
overloads
so
that
you
can
do
this
without
allocating
a
ton.
E
You
know
for
custom
controls
and
things
like
that.
That's
actually
pretty
useful.
E
D
E
A
E
Yeah,
so
there's
in
the
in
the
text,
format
lags
there's
a
there's,
a
there's
an
there
are
options
to
specify
that
you
want.
You
know
ellipses
drawn,
so
you
want
the
system
to
cut
the
thing
down
to
fit.
There's
two
different
versions
of
that.
E
E
A
A
E
E
Okay,
that
is
that's
the
1564
link,
so
that
this
one
here,
tobias
put
in
there.
C
E
I
wouldn't
be
doing
15.
It
would
just
be
because
it's
such
a
corner
case
we'd
only
do
the
the
the
the
four
unique
ones
right.
You
know
the
the
we
can't
collapse
them
because
the
you
know
the
defaults
are
actually
not
constants
for
the
things
so
like
the
defaults
for
the
color
happens
to
be
color
empty,
which
is
actually
a
special
color.
E
That
has
no
initialized
state,
weird
stuff
like
that.
But
you
can
see
this
person's
code
that
they
did,
that
they
would
call
measure
text.
Look
for
the
look
for
the
embedded
null
and
then
copy
the
substring
out.
A
So
yeah
that
design
is
not
great.
H
E
E
E
Yeah,
the
current
plan
of
record
is
just
to
block
that
completely
and
then
come
up
with
another,
more
holistic
api.
For
that
you
know
it.
It
seems
over
complicated
to
do
it.
It
just
needs
more
thought
right
as
to
how
we
would
you
know,
allow
you
to
pass
a
buffer
in
and
how
that
would
fit
within
the
other
stuff.
So,
and
I
might,
I
might
put
a
compatibility
flag
in
that
people
can
do
that
on
the
original
ones,
but
these
new
overloads,
I
definitely
will
not
allow
it.
B
D
Because
that
could
be
coming
from
like
the
the
static
portion
of
the
loaded
image
and
modifying
it
with
actually
av.
E
A
E
E
So
it's
related
to
this
thing
and
you
know
I
don't
think
that
we
need
to
go
into
trying
to
find
a
solution
for
a
new
api.
For
that.
I
just
wanted
to
call
it
out
that
that
was
something
that
that's
another
api
behavior
change
in
this
that,
like
prefer
to
do,
because
it's
it's
dangerous
on
many
levels
right
and
particularly
with
all
the
other
potential
features
that
can
come
in.
A
It
seems
like
the
way
you
would
model
this,
though
you
would
basically
say,
there's
a
brand
new
api
like
similar
to,
like
you
know,
draw
text,
measure
text,
and
then
I
don't
know
constrain
text
or
something
whether
you're,
basically
passing
the
same
overloads
that
you
have
for
measure
text
and
that
will
just
give.
H
A
A
A
E
A
Oh,
so
modify
string
isn't
just
controlling
what
is
random
on
the
screen.
I
thought
it
modifies
the
string.
When
does
the
string
and
if
you
don't
modify
string,
then
you
don't
get
the
ellipses,
but
you're
saying
you,
you
can
say,
give
me
the
ellipses
and
not
modify
my
string,
in
which
case
it
still
renders
fine
yep.
Well,
yeah
that
seems
like
modify
string
is
really
a
bad.
A
E
No,
I
would
keep
them
there
because
it
makes
it
it's
easy
for
the
for
people
to
to
to
to
transition
their
code.
D
E
E
Yep,
which
is
why
this
and
I
call
that
out
up
at
the
top
there
is
like
it's.
You
know,
because
this
it's
unusual,
you
know
like
a
lot
of
the
windows.
32
apis
are
all
terminated,
but
this
one
in
particular-
and
I
think
it's
partially
because
of
the
modif-
I
think,
but
you
know
they-
they
actually
have
you
passing
the
length
of
the
input
string
so
which
is
which
is
great,
because
then
we
can.
Actually.
This
really
means
something
in
this
case
right
you're
not
actually
having
to
make
some
extra
buffer
step.
E
A
A
E
H
E
Than
gdi
as
one
concrete
example,
because
I've
been
working
on
caching
and
everything
for
the
for
the
gi
plus
things,
you
know
to
create
a
pen
and
dispose
of
it
in
system
drawing
which
is
mostly
inside
the
native
code
that
takes
in
the
tune
of
about
you,
know
four
microseconds
and
to
do
the
same
thing
with
a
gdi
pen.
It
takes
about
eight
nanoseconds.
E
At
home,
that's
eight
to
four
thousand.
It's
pretty
substantial.
A
E
A
A
E
A
All
right,
so
let
me
just
close
this
one.
A
Then
all
right,
so
my
favorite
topic.
Well,
hopefully,
we
don't
need
the
one
and
a
half
hours
for
this,
but
it
depends
on
how
controversial
it
ends
up
being
so
we
added
a
new
feature
in
this
release,
which
we
used
to
annotate
platform-specific
apis,
and
this
feature
was
heavily
inspired
by
how
the
android
and
ios
bindings
work.
Where
the
idea
is.
We
have
one
sdk
that
is
accumulative
over
time.
A
So
it
is
important
for
us
to
indicate
on
the
api
which
version
of
the
platform
introduced
the
api,
so
that,
when
you
say
I
want
to
run
on
ios
11,
then
we
can
give
you
warnings
if
you
are
calling
apis
if
introduced
in
ios
12.
Unless
you
have
guarded
those
calls,
that's
fine
that
works
great
for
apis
that
are
truly
platform,
specific,
like,
for
example,
ios,
bindings,
android,
bindings
or
the
windows
registry.
A
Then
later
on,
we
talked
about
how
we
would
support
blazer,
where
blazer's
challenge
is
that
it
runs
inside
the
browser
sandbox,
and
you
can't
access
many
of
the
features
that
you
can
virtually
access
anywhere
else
like
the
file
system,
threading
apis.
That
sort
of
thing,
so
we
could
of
course,
mark
those
apis
with
being
platform
specific
for
every
platform,
except
for
blazer.
So,
basically,
we
would
exclude
by
marking
the
apis
platform
specific
and
then
not
exposing
the
ones
that
are
unsupported,
but
that's
very
fragile
over
time
and
doesn't
work
very
well.
A
It
also
now
means
that
everybody
who
calls
these
apis
is
now
responsible
for
guiding
the
calls
for
all
the
other
platforms
that
have
those
apis,
which
is
also
not
what
we
want
so
long
story
short.
We
wanted
a
way
to
mark
apis
directly
as
unsupported
by
the
idea
is.
The
api
is
generally
considered
universally
applicable,
except
for
the
platforms
that
it
is
marked
for
as
not
being
supported
so
kind
of
an
exclusion
list
rather
than
an
inclusion
list.
A
If
you
will,
as
we
designed
the
feature,
it
became
very
quickly
clear
that
we
don't
really
want
to
invent
a
new
set
of
attributes
for
that,
because
they
would
have
the
exact
same
semantics
except
it
would
be.
You
know
one
minus
or
you
know,
exclusion
rather
than
basically
we
would
build.
A
denial
is
not
in
the
low
list
right,
but
we
want
the
same
semantics
when
it
comes
to
versioning
ranges
and
that
sort
of
stuff.
A
So
what
we
basically
said
is,
like
you
know,
let's,
let's
rename
the
minimum
os
platform
attribute
to
supported
platform
attribute,
and
then
we
moved
in
with
unsupported
and
what
that
basically
does
is.
We
have
basically
a
uniform
way
to
annotate
api.
So,
basically,
an
api
that
would
be
marked
as
unsupported
by
windows
would
look
like
this
in
dot
net
five
and
then,
let's
say
in
dot
net
six.
A
We
change
the
implementation
of
the
api
that
we
can
actually
mark
that
we
can
actually
make
it
work
on
windows,
but
only
on
a
specific
version
of
windows,
10
and
higher.
So
we
would
do
that
is
you
would
still
leave
it
unsupported
os
platform
windows
and
then
add
a
new
attribute
that
says
well,
it
is
supported
on
windows,
10,
point
blah.
What
this
now
means
is
that
this
api
is
considered
supported
everywhere,
except
on
windows.
A
It's
only
supported
on
10,
0,
1903
right
and
then
similar
for
the
ios
and
android
ap,
as
you
would
see,
would
just
start
with
supported
rather
than
starting
with
unsupported.
So
this
would
basically
mark
an
api
that
is
supported
on
ios
and
ipad
os,
starting
with
version
12
or
version
13
in
case
of
ipad
os.
It
was
obsoleted
in
version
13
and
was
removed
in
version
14.,
so
they
look
very
similar.
A
The
key
difference
here
is
that
the
lowest
version
starts
with
supported
in
rather
than
with
unsupported,
and
what
that
basically
means
is
that
we
that
our
analyzer
basically
will
look
at
an
api.
It
will
group
all
the
platform
attributes
by
os
platform
id
and
then
looks
at
the
lowest
version
number
and
what
attribute
that
is
if
these
attributes
are
all
supported
in
that
means,
the
api
is
considered
a
platform
specific,
and
it's
only
supported
on
the
platforms
that
are
listed.
A
If
the
minimum
version
is
unsupported
everywhere,
then
the
api
is
considered
generally
speaking,
universally
supported,
except
for
the
platforms
where
we
say
otherwise,
and
if
you
have
a
mixture
of
both
of
them,
where
basically,
the
minimum
version
is
sometimes
supported
and
sometimes
unsupported
or
analyzer
will
flag
the
definition
of
the
api
as
being
inconsistently
attributed,
because
you
didn't
make
up
your
mind
whether
you
want
to
build
an
allowance
on
or
deny
list
that's.
Basically,
the
general
idea
does
that
make
sense
to
people.
H
It
makes
yep
it
makes
sense
to
me
the
I
had
a
bit
of
trouble
wrapping
my
head
around
reading
the
spec,
but
the
examples
made
sense.
A
H
A
Be
clear
what
it
means
we
just
have
to
define
it
for
the
analyzer
so
that
we
have
sound.
F
A
Correct
okay,
like
generally
supported,
always
means
this
version
and
our
subsequent
versions,
unless
you
have
another
attribute
that
says
otherwise
for
later
version
right.
So,
for
example,
we
would
also
support
the
notion
that
we
could
say
unsupported
in
windows
11
right,
so
basically
we
can
model
pretty
much
anything
in
os
can
do
they
can
not
starting
with
an
api.
A
A
A
I
mean,
strictly
speaking,
if
we
really
wanted
to
enable
this,
given
that
all
these
things
take
strings,
we
are
principle
free
to
say,
dash,
x86
or
something,
and
then
make
that
scenario
work.
The
problem
with
that
kind
of
thing
is
that
keep
in
mind
that
everybody
who
calls
the
api
is
now
on
the
hook
for
guiding
calls.
So,
given
that
most
class
libraries
are
any
cpu,
that
might
mean
a
lot
of.
J
Yes
and
where
they
do
differ,
they're
generally
intrinsics
explicitly
called
out
much
like
our
own
hardware
intrinsics
or
they
just
return
false
on
or
zero
or
the
correct
default.
If
you
query
for
on
an
unsupported
platform.
D
D
A
Yeah,
so
somebody
in
chat
asks
where
the
strings
are
defined.
A
But
basically
the
the
they
are
basically
the
set
of
strings
that
we
allow
after
the
new
tfm
right.
So
basically
you
would
say
if
you,
if
you
do
file
new
winforms
app
or
file
new
wpf,
app
with
dot
net
five,
your
tfm
is
not
going
to
say
net
crap
five.
Oh,
it
will
say
net
five
all
dash
windows
and
then,
if
you
do
file
new
console,
app
or
file
new
class
library
or
maybe
not
class
library,
but
you
know
file
new
asp.net,
then
your
tfm
will
be
target
framework
net
500
without
a
dash
right.
A
A
The
version
numbers
are
the
ones
that
we
actually
ship
with
the
with
the
sdk
and
the
analyzer
will
generally
ensure
that
the
syntax
of
those
strings
is
legal,
but
the
analyzer
doesn't
actually
care
what
the
strings
themselves
are,
because
it
doesn't
it
just
matters
that
the
string
that
you
have
in
the
project
file
agrees
with
the
string
that
the
api
that
you
are
calling.
H
A
All
right
so
then,
I
consider
this
approved
then,
unless
somebody
says
otherwise.
Jeff
had
a
comment
on
the
bottom
of
this.
A
Okay,
I
also
think
we
have
explicit
guidelines
that
says:
don't
do
that
if
you
have,
if
you
have
an
attribute
that
is
multi,
what
do
you
call
it?
Multicast
multiplicable.
You
should
not
offer
both
choices.
You
should
make
up
your
mind
either
it's
a
single
attribute
instance,
and
then
you
can
pass
multiple
strings
or
you
just
apply
the
attribute
multiple
times
and
we
went
with
multiple
times,
because
we
need
to
support
different
operating
systems
to
begin
with
right
yeah.
A
So
I
would
not
do
the
params
one
and
then
the
runtime
versioning
one,
that's
an
interesting
one.
I
mean,
I
think,
the
reason
why
we
went
with
that.
One
was
because
we
went
where
target
framework
name
is
or
target
framework
attribute,
whatever
it's
called,
that
is
in
runtime
versioning,
and
so
that's
where
we
put
it.
I
A
Yeah
runtime
versioning
is
generally
for
that
the
compiler
generates,
so
you
should
never
have
to
interact
with
that
versus
these
ones.
You're
generally
expected
to
put
on
your
own
method,
so
you
should
it's
similar
to
the
apis,
but
you're
expected
to
actually
use
them.
So
I
think
I
agree
with
that
reasoning.
I
A
A
A
F
A
I
A
A
A
We
put
this,
and
so
that's
well.
F
A
F
I
H
A
Yeah,
the
thing
is
that
so
the
other
thing
is
so
there's
kind
of
two
kind
of
audiences
right,
there's
the
windows
audience,
and
so
the
windows
audience
basically
will
never
ever
have
to
write
an
if
check,
because
we
don't
have
any
apis
that
are
really
you
know,
introduced
after
wind.
Seven
at
this
point
right,
so
basically
everybody
who
does
a
funny
windows
app
or
a
phone
use
the
wpf
app.
They
basically
will
always
be
guaranteed
to
run
on
win,
seven
or
higher,
which
analyzer
will
know.
A
And
then,
if
you
look
at
ios
and
android,
I
mean
the
idea
there
is
that
you're
generally
on
the
cutting
edge
without
losing
reach
right.
So
that
means
you
will
generally
say.
I
run
on
an
older
version
of
ios
and
if
there's
any
new
apis
that
I
want
to
call
like
yeah,
I'm
writing
the.
If
check
for
that,
so
that
which,
which
basically
means
the
attributes
don't
help
you
there
either
because
you
are
the
caller
right
so
that
doesn't
have
really
help.
F
I
mean
this:
is
you
know?
I
don't
have
specific
strong
feelings
that
it
would
be
the
case,
but
I
know
that
we
do
have
a
lot
of
things
that
the
the
kind
of
people
who
are
decorating
things
with
attributes
and
the
kind
of
people
who
would
be
doing
the
runtime
information
checks
could
seem
like
different
people.
And
if
we
felt
that
there
was
going
to
be
a
lot
of
people
who
just
put
attributes
on
their
methods
and
never
use
the
runtime
checks,
then
then
maybe
it
would
be
in
a
more
friendly
name.
A
Now
you
don't
have
to
do
any
checks,
because
you
already
bumped
your
minimum
requirement
all
the
way
up,
but
as
soon
as
you
basically
fumble
with
these
things
individually,
you
will
most
likely
like.
If
you
use
the
attributes
directly,
you
will
most
certainly
also
use
the
methods.
I
really
have
a
hard
time,
seeing
that
any
other
way.
A
But
I
agree
with
you
that
interrupt
services
was
a
poor
choice
because
I
mean
originally,
the
motivation
for
job
services
was
well.
Why
are
you
asking
for
the
os
because
you're
p
invoking
and
now
we
have
to
like
well
or
you
call
it
os
binding
right
and
turns
out
that
they're
not
interval,
but
the
the
api
already
shipped?
So
now
it
would
be
weird
if
the
attributes
would
be
in
a
different
name
space
from
one
time
information.
I
A
But
it
is
a
bit
un
yeah.
H
A
H
I
A
Is
a
good
question
I
mean
like?
I
guess
this
one
doesn't
really
matter
like
the
only
reason
why
I
edit
this
was,
if
you're
on
the
docks
you
can
click
on
the
west
platform
for
multiple
shows.
It
shows
you
the
derived
types
and
that
seemed
useful,
but
that
one
also
doesn't
care
about
the
namespace
right,
because
links
will
work
regardless
of
what
we
do.
There.
A
I
mean
in
principle
the
base
class
itself
doesn't
really
serve
any
purpose,
except
for
the
dogs
right,
and
so
I
think
it's
logical
to
tie
them
all
together.
But
there
really
isn't
much
of
a
polymorphic
aspect
to
that.
A
Yeah,
I
think
this
one
defines
the
the
the
constructor
that
requires
that,
so
everybody
who
derives
from
it
has
to
pass
in
that
guy.
A
F
On
the
on
the
unsupported
attribute,
we're
now
accepting
a
versionless
red-like
thing
is
the
intent
to
also
support
that
on
supported
os
platform
and
obsoleted,
though
obsolete.
It
would
be
weird.
A
A
It's
not
explicitly
disallowed,
but
it
would
be
not
useful.
Yes
to
do
that.
So
basically,
what
the
spec
calls
out
is
that
absolutely
in
and
of
itself
does
not
make
any
claims
about
availability
right,
but
it
generally
doesn't
make
sense
to
apply
it
unless
you're
already
in
a
supportive
context,
which
we
could
teach
the
analyzer
about
and
say
if
you
apply
obsolete
without
being
in
without
the
platform
being
considered
supported
for
this
api,
there
would
be
an
authoring
back
on
there
on
the
api.
F
F
We
believe
it
works
in
all
versions
of
windows
that
you'll
ever
encounter,
and
we
can
raise
it
later
if
we
feel
like
it,
but
and
it's
not
supported
anywhere
else.
For
example,.
A
H
A
I
thought
about
the
two
interrupt
services
is
already
very
full,
though
it
probably
doesn't
make
a
difference.
I
mean
I'm
okay
with
leaving
it
in
system
runtime.versioning,
because
that's
already
it's
basically,
nothing
really
isn't
that
necessary
that
you
would
ever
interact
with
directly,
and
the
attribute
is
probably
in
that
category,
so
I
will
probably
just
leave
it
in
in
that
namespace.
H
A
H
H
H
H
H
Yeah
yeah,
I'm
not
I'm,
not
I'm
not
objecting
to
this
behavior.
I
just
think
we
should
be
explicit
calling
out
that
it
is
an
intentional
decision
that,
even
though
these
things
look
ex
look
exactly
like
that
portion
of
the
tfm,
they
are
not
quite
the
same
right.
H
And
yeah,
if
you
have
any
of
those
implicit
versions
at
build
time,
they
will
get
baked
into
concrete
versions
during
the
build.
F
H
No,
the
sdk
won't
keep
changing
its
minimum
version
like
net5
dash
ios
will
always
mean
ios.
So.
H
F
I
withdraw
my
concern.
H
H
F
Yeah,
so
as
far
as
the
name
space,
assuming
that
someone
gets
annoyed
by
the
show
me
all
name
spaces
and
turns
that
feature
off,
and
so
we
can
go
back
to
saying
name,
spaces
help
intellisense.
F
If
you
start
typing
os
platform,
you
probably
want
os
platform
and
not
os
platform
attribute,
because
os
platform
attribute
is
effectively
useless
so
having
it
in
a
different
name.
Space
is
actually
valuable.
F
F
So
if,
if
we're
using
namespaces
as
logical
groupings
for
intellisense,
it
does
not
belong
with
os
platform
because
you're
not
going
to
use
them
at
the
same
time,
you're
going
to
use
the
concepts
at
the
same
time,
but
not
the
types.
So
this
is
the
separating
your
type
hierarchy
based
on
you
know,
power
level.
A
A
H
I
F
And
that
was
my
question
of.
Do
we
expect
people
to
use
the
attributes
without
the
runtime
information
checks,
because
if
yes,
then
maybe
we
should
put
them
in
system
and
if,
if
they're
always
if
people
using
the
attributes
are
already
likely
to
be
talking
about
runtime
information,
then
putting
them
in
the
same
name.
Space
is
better.
H
I
think
generally
people
will
be
using
a
mixture,
but
that
mixture
might
tend
towards
one
end
or
the
other,
like.
It's
definitely
plausible
that
you
could
just
you
could
have
a
library
where
certain
apis
they're
using
have
a
higher
os
requirement
than
their
libraries
minimum
requirement,
and
they
want
to
propagate
that
requirement
to
their
api.
E
H
So
there
will
be
extremes.
I
I
would
imagine
that
a
lot
of
code
will
use
a
mixture.
F
Though,
and
it
feels
like,
if
we're
not
confident
that
the
amount
of
places
that
would
be
attribute
only
is
high,
that
reducing
the
namespace
span
on
things,
people
will
write,
has
a
certain
value.
H
H
Cases
they
probably
want
to,
for
example,
hide
that
requirement
under
a
method
with
a
lower
requirement.
That
internally
does
a
runtime
check
and
has
a
fallback
or
something.
A
That's
the
thing
that
I
don't
like,
but
the
the
really
basically
the
only
alternative
to
this
would
be.
We
would
have
to
basically
duplicate
at
least
runtime
information.
We
can
probably
get
away
with
not
duplicating
os
platform
because
really
realistically
people
will
pass
in
strings
here,
because
I
have
to
do
version
checks
anyway,
but
I
don't
like
duplicating
a
type
just
because
we
messed
up
the
namespace.
That
seems
a
fairly
expensive
fix
as
well,
but
I
don't
have
another
option.
A
I
mean
what
is
true
is
that
runtime
information
today
is
also
largely
useless
for
us,
because
it
only
has
isro's
platform,
like
all
the
actual
worker
methods.
That
actually
do
anything
useful
like
that.
Compare
version
numbers
are
all
net
new.
We
just
put
them
on
runtime
information
because
that's
where
all
their
isos
platform
already
is,
but
but
there
really
isn't.
This
is
super
super
and
the
type
also
is
not
like.
You
know
super
large
either
right,
it's
a
very
small
type,
yeah,
that's,
basically
what
the
type
has
today.
I
A
Right,
I
mean
like,
I
think
to
me:
there's
there's
two
sides
to
it
right,
so
we
could
decide,
there's
a
new
type
put
in
a
new
namespace
or
an
existing
namespace.
That
is
better
than
interrupt
services.
That's
where
the
attributes
go
and
that's
great
for
ios
and
android,
but
nothing
prevents
us
from
teaching
the
analyzer
about.
You
know
runtime
information
so
as
platform
and
and
also
have
that
as
a
as
a
you
know,
legal
guarding
call
as
well,
because
we
said
we
want
to
make-
is
os
platform,
also
legal
as
a
guard.
A
If
the
version
is
basically
zero
right
so
like
we
will
still
handle
that,
it's
just
a
question
of
like.
If
you
build
an
ios
app,
you
really
want
to
have
interrupt
services
in
pretty
much
every
file
right,
maybe
not
every
file,
but.
A
Yeah,
I
mean
that's
the
question
I
mean,
like
I
mean
honestly
like
if
we
were
to
design
it
from
scratch
right,
I
would
probably
put
methods
on
environment
rather
than
introducing
a
new
type,
because
I
mean
I
agree
with
you
like.
It
is
unfortunate,
but
if
you
compare
runtime
information
right
like
this
is
two
percent
right
compared
to
environment.
A
What
is
it
os
version
which
is
like
this
right?
So
you
could
argue
that
you
know
runtime
information
was
so
we
did
runtime
information
because
this
property
was
considered
bad.
I
mean
it
still.
Kind
of
is
bad
because
it
tells
you
the
version
number
rather
than
allowing
you
to
ask
whether
you're
compatible
right
but
like
arguably
like
this
class
is
probably
closer
to
what
people
would
search
for
in
the
first
place.
I
F
Because
what
are
your
yeah,
what
are
the
relative
sizes
for
nougat
content.
A
Right
but
like
the
so,
the
problem
with
ios
and
android
is
like
you're,
more
bleeding
edge,
whereas
this
is
a
library,
author,
you're
generally,
not
super
bleeding
edge
right.
That's.
Why
also
why
my
concern
with
ios
or
android?
Is
you
just
make
it
net
worth
for
everybody
when
everybody
is
likely
having
to
write
these
calls
right?
That's
why
I
don't
like
interweb
services,
because
interrupt
services
is
largely
a
junk
namespace
right
I
mean
not.
Everything
in
here
is
in.net
core,
but,
like
large
chunks
of
it
are
still
right.
F
A
Well,
system
runtime,
I
would
not
use
that's
the
that's
the.
What
is
the
term?
It's
the
namespace
that
christoph
used
for
the
runtime
team
and
they
came
with
mackie
apis
right.
So
it's
basically
yeah.
You
never
need
any
of
this
right.
A
How
about
this
I
will,
I
will
sit
down.
I
write
up
a
proposal
that
we
then
can
reject
with
gusto,
if
you
feel
like
it,
but
I
can
at
least
sketch
what
it
would
look
like
if
we
were
to
do
it
and
then
we
can
judge
whether
we
like
the
result
or
not,
because
I
mean
the
problem
with
namespace
forwarding
is
yes.
If
we
had
this,
I
would
use
it.
I
just
don't
think
it's
very
likely
to
ever
happen.
So
I'd
rather
not
bet
my
future
on
it.
F
Right,
the
only
forwarding
that
we
would
get
is
we
would
just
duplicate
the
type
name
in
a
new
place
and
then
just
tell
people
go
call
the
other
version
of
this
instead,
which
would
then
be
hard
on
them
if
they
needed
something
in
interop
services
already,
because
they'd
have
to
using
alias
to
get
the
correct
one,
which
would
be
unfortunate
so
yeah.
I
think
we
really
need
the
runtime
feature
before
we
remove
the
type
none
of
this
is.
A
No
like
that's,
why
I'm
that's
why
I'm
here
to
send
to
add
apis
in
5.0?
If
we,
if
we
feel
like
that's,
not
the
right
story
for
ios
and
android,
because
realistically
that's
what
they
will
have
to
use
and
he'll
like.
F
F
Then
we
would
probably
do
that
now
or
never,
and
so
I
think
that
the
question
is
applicable
to
five.
Otherwise,
we'll
say
that
the
types
too
big
and
used
by
too
many
things
and
we'd
also
have
to
move
the
attributes,
and
that
is
bad
for
anything,
doing
metadata
analysis
based
off
doing
them.
The
com
metadata
importer,
because
now
they
would
need
to
understand
namespace
aliases
as
well,
unless
the
com
library
did
it
for
them
and
everything
would
be
terrible.
A
All
right,
so
I
think
we
discussed
this
to
death
I'll,
follow
up
on
the
locations
to
make
it
a
bit
more
sexy,
but
I
think
this
is
having
legs.
I
like.
A
F
A
F
It
is
the
only
way
that
you
can
assign
the
message,
so
it
seems
okay,
like
it's
effectively
a
nullable
parameter,
but
the
one
of
the
problems
is:
if
you're
using
the
com
metadata
scrubber,
like
you,
can't
evaluate
the
two
things
to
know
what
the
difference
between
them
is.
So
you
have
to
just
tell
your
tool:
that's
using
it.
What
the
difference
between
the
two
constructors
is
and
to
analyze
them
differently.
F
Right
but
then,
but
they're
also
just
they
only
have
to
see
they
don't
have
to
compare
which
method
it's
going
against
they.
You
know
just
see
that
it's
an
invocation
of
the
type
and
it
makes
the
metadata
the
interrupt,
anal
and
interrupt
analysis
thing
a
lot
simpler,
but
if
we
think
that
the
overload's
just
we're
not
changing
the
meaning
of
platform
name,
so
it's
it's!
It's!
Okay
in
that
sense,
but
I'm
just
pointing
out
our
guidance
is
avoid
overloading
attribute
constructors
doesn't
say:
do
not
it's
a
void.
A
Yeah,
I
still
don't
quite
understand
the
guidance
like.
I
don't
understand
the
complexity,
because
for
me
logically,
what
happens
is
right.
If
you
have
a
metadata
reader,
it
tells
you
you
invoke
this
constructor
or
that
constructor.
So
you
have
a
metadata
reference
to
the
actual
constructor
and
you
basically
have
the
the
typed
arguments
that
possibly
pass
through
the
constructor
right.
So
the
like.
That's
that
that
is
true,
whether
you
have
three
overloads
or
just
a
single
method,
right
right,.
F
A
Yeah
I
mean
like
yeah,
so
the
guidance
basically
is
like
don't
rely
on
logic
in
the
constructor,
because
you
you
have
to
replicate
that
yeah.
That
makes
sense
yeah
I
can.
I
can
relate
to
that
all
right.
So
then
we're
happy
with
what
we
see
on
screen
right,
yep
cool.
Then
we
have
40
minutes
left
for
other
stuff
levi.
Do
you
want
to
talk
about
secure
string.
D
Sure
why
not?
I
enjoy
a
good
dog
pile.
D
Yeah,
so
this
is
this
is
something
we've
been
wanting
to
to
do
for
a
while
to
obsolete
the
the
secure
string,
not
necessarily
to
obsolete
the
type
but
to
obsolete
its
usage
within
the
framework
and
and
the
reason
for
that
is
twofold.
First
off,
because
secure
string
is
an
exchange
type.
We
we
generally
don't
like
obsoleting
exchange
types,
because
it
makes
it
very
noisy
in
your
code
base.
Instead,
what
we
want
to
do
is
to
obsolete
either
the
the
creation
or
consumption
of
that
exchange
type.
D
But
the
reason
that
we
wanted
to
obsolete
this
in
general
is
that
secure
string
doesn't
really
honor
many
of
the
promises
that
it
makes,
and
in
fact
we
we
document
hey.
You
can't
actually
rely
on
secure
string
to
fulfill
its.
You
know
documented
guarantees,
which
is
a
bit
unfortunate,
we've
seen
a
few
cases
in
the
past
where
people
are
using
this
type
as
a.
D
How
do
we
want
to
phrase
us
that
people
are
using
this
type
because
they
they
feel
like
they
have
an
engineering
imperative
to
do
so,
where
they're
contorting
their
code?
D
In
order
to
use
this,
because
it
has
either
because
it
has
the
word
secure
in
its
name
or
because
they
believe
it
makes
guarantees
that
it
actually
doesn't
and,
as
a
result,
the
code
that
they're
using
around
this
type
becomes
more
difficult
to
read
more
difficult
to
maintain
it's
not
the
type
of
code
that
we
think.net
consumers
should
be.
Writing
really.
D
Also.
This
type
can't
be
used
in
things
like
hipaa
compliant
environments,
for
instance
like
it
using
this
type,
doesn't
make
your
application
magically
hipaa,
compliant
or
pci
compliant,
or
anything
like
that,
whereas
a
bunch
of
our
consumers
apparently
believe
that
to
be
the
case.
So
these
are.
These
are
all
reasons
that
we
think
we
should
start
winding
down
usage
of
this
type
throughout
the
ecosystem.
D
I
had
proposed
here
a
particular
set
of
apis
that
should
be
obsoleted.
This
would
not
be
for.net
5,
it
would
be
for
netsex.
These
apis
are,
as
I
mentioned
earlier,
involved,
either
in
the
creation
of
one
of
these
things
or
in
the
consumption
of
one
of
these
things.
D
In
an
ideal
world,
we
would
no
longer
use
secure
string
to
store
credentials
at
all,
but
we
don't
live
in
an
ideal
world,
so
we
need
to
be
able
to
have
credentials
in
memory
like
symmetrics
stuff,
like
that,
what
I
had.
One
of
the
things
that
I
had
proposed
here
is
using
network
credential,
actually
as
a
wrapper
around
any
arbitrary
in-memory
or
not
in
memory
cred
that
we
might
want
to
pass
around
in
the
future.
D
For
example,
process.start
the
overloads
that
take
secure
string
should
be
obsoleted,
and
we
should
only
take
overloads
that
take
a
network
credential
if
the
overloads
need
to
take
a
credential
at
all.
That
way,
we
have
one
credential
type
that
we
pass
around
as
the
exchange
type
through
the
framework.
Does
that
kind
of
make
sense?
As
a
scenario
I
mean
layering's,
probably
all
messed
up,
but
oh
yeah,
layering
surrenders.
D
D
Yeah,
in
a
nutshell,
that's
where
all
of
this
is
going,
though,
I'm
not
proposing
changing
the
user
observed
behavior
of
secure
string,
even
though
the
apis
that
construct
or
consume
it
would
be
obsolete.
C
D
What
that
might
entail,
for
instance,
is
say
that
you
have
an
end
to
your
web
service.
You
have
a
front
end
and
a
back
end
of
the
front
end
shouldn't
be
able
to
decrypt
any
of
the
secrets
at
all
that
are
flying
across
the
secrets
should
be
encrypted
from
the
client
directly
to
the
back
end,
for
instance,
and
the
front
end
should
not
have
any
type
of
accessibility
for
that
things
along
those
lines.
F
So
corey
the
problem
space
ends
up
being
something
like
this
is
massively
paraphrasing,
of
course,
for
pci
compliance.
A
secret
must
be
erased
from
memory
as
soon
as
it
is
no.
H
F
Needed
well
most
people
who
build
secure
strings.
Do
it
wrong,
they
have
a
system.string
and
then
they
build
a
secure
string.
So
now
they've
made
a
copy.
The
original
string
won't
get
erased
because
strings.
Don't
I
mean
it'll
eventually
get
overwritten,
but
it's
not
as
soon
as
they're
done
and
then
anytime
they
ever
actually
use
the
secure
string
object.
Secure
string
is
just
an
expensive,
in-memory
encryption
and
then
the
moment
you
need
it.
F
It
gets
decrypted
copied
into
a
string
and
used,
and
many
people
do
this
with
their
own
code
of
they'll
actually
copy
it
back
to
a
system
string
to
pass
it
to
some
other
thing
which
entirely
defeated
the
purpose
and
if
it's
used
in
the
marshaller
it
does
use,
pin
memory.
So
it
does
get
to
clear
it.
So
it's
really
a
marshalling
aid,
but
people
think
that
it's
a
practical,
runtime
aid
and
there's
not
really
a
solution
we
can
provide
in
the
framework
because
they
need
to
do
their
own.
F
D
F
D
I
have
some
links
throughout
this
document
actually
of
wherein.net.
We
actually
generate
strings
from
secure
strings
and
then
never
clean
them
up
and
and
jeremy's
right
like
it's.
It's
the
natural
way
of
using
one
of
these
things,
because,
because
system
string
is
the
net
exchange
type,
it's
only
natural
that
people
would
want
to
convert
data
from
this
to
that.
But
the
problem
is,
like
jeremy
said
as
soon
as
you're
in
that
world,
like
you're
no
longer
compliant.
F
Yeah
I
feel
like
when
we
were
doing
net
core
one.
We
looked
on
github
searching
usages
of
secure
string
and
it
wasn't
until
like
page
22
that
we
found
something
that
was
not
just
going
to
or
from
a
system
string.
D
Yeah
and
that
so
so,
then
the
question
becomes
like
well:
is
this
type
just
discouraged
or
is
it
actively
harming
the
ecosystem,
and
that
is
that
is
something
that
I
actually
grappled
with,
because
there
are
apis
that
we
don't
like
but
take
a
ray
list,
for
instance
right
like
we
don't
like
it,
but
if
you
use
arraylist
like
okay,
whatever
more
power
to
you,
I
guess
in
this
particular
case
we're
seeing
that
people
are
either,
as
mentioned
earlier,
believing
that
their
code
fulfills
some
type
of
compliance
requirement
and
potentially
opening
themselves
up
to
liability
or
in
the
code
that
I've
seen
at
least
internally
people
are
introducing
security
holes
into
their
applications.
D
In
order
to
use
this
type.
One
of
the
things
that
I
discussed
on
the
document
was
there
was
code
that
I
looked
at
where
somebody
was
explicitly
trying
to
clear
system
string
instances
after
they
had
converted
the
strings
into
secure
strings,
and
the
problem
that
I
pointed
out
to
them
was
like
hey,
you're,
now
corrupting
memory
in
the
web
server,
because
asp.net
was
still
using
those
strings.
D
So
yeah,
so
the
the
op
solution
is
telling
people
like
look
stop
using
this.
Just
if
you
really,
if
you
really
need
to
just
pass
stuff
around
as
a
string
like
if
you,
if
you
really
need
to,
if
you
do
that,
and
you
need
to
make
sure
that
you
know
secrets
are
not
accessible
outside
of
this
process,
turn
off
things
like
crash
dumps,
that's
obviously
going
to
give
you
the
best
protection.
That's
not
necessarily
always
practical.
D
If
that's
not
practical,
then
jeremy
had
a
proposal
earlier
where
the
gc
could
be
put
into
a
actually.
I
could
just
let
you
talk
about
that
jeremy
since
you're
on
the
phone.
F
Fair
enough
yeah,
my
I
mean
for
things
like
the
the
comment
of
dot
net
likes
to
move
memory
around.
It's
the
make
the
gc
every
time
it
does
compaction,
because
right
now,
this
is
the
place
that
people
tend
to
get
snippy
with
us
as
they
they
run
a
test
as
part
of
a
pci
audit,
a
secret
gets
loaded
into
memory.
F
It
gets
the
point
where
it's
supposed
to
not
be
in
use
anymore,
and
then
they
take
a
manual
crash
dump
and
then
they
find
it
in
memory
and
it's
because
a
compaction
happened
in
the
middle
and
it's
now
abandoned
memory
and
as
an
optimizat
as
a
perf
optimization.
The
gc
won't
clear
that
memory
until
it
flashes
the
page
to
start
handing
data
out
of
it
again.
So
I
have
an
outstanding
request
for
the
gc
to
have
a
mode
that
says
anytime,
you
run
compaction.
F
F
If
you
had
a
bite
array
that
held
us
that
held
the
secret
that
it
it
wouldn't
have
gotten
copied
before
you
had
a
chance
to
pin
it,
and
I
honestly,
you
wouldn't
even
need
to
pin
it
at
that
point,
because
the
only
reason
you
would
pin
it
is
to
prevent
the
compaction
copy,
but
yeah
so
like
that
solves
one
aspect
of
of
the
problem,
which
is
one
of
the
problems
that
also
comes
about
with
secure
string,
but
secure
string.
Just
is
full
of
problems.
F
So
if
you
really
care
about,
if
you
need
to
pass
a
pci
audit,
the
number
one
recommendation
is
don't,
which
is:
don't
touch
credit
cards
yourself
like
use
a
service
that
is
pci
audited
and
give
them
encrypted
data,
and
you
never
get
to
see
it
and
you're
so
happy
that
you
never
had
the
the
pan
aka
the
credit
card
number,
because
the
moment
you
can
see
the
credit
card
number,
your
life
becomes
miserable.
F
So,
but
if
you
do
need
to
do
that,
then
yeah,
it's!
You
need
to
have
everything
in
pinned
memory
so
that
you
can
call
clear
on
it
before
the
gc
compacts
it
and
it's
very,
not
netty,
because
you
can't
call
anything
that
would
return
a
byte
array
that
would
have
the
secret
in
it,
because
that
could
have
been
copied
in
compaction
three
times
from
the
time.
It
was
filled
to
the
time
that
you
got
it.
I
mean
probably
because
compaction's
not
going
to
move.
F
F
F
D
No,
so
so
the
so
this
document,
this
document
has
a
few
links
inside
of
it.
The
thing
that
we
were
just
describing
was
a
mode
of
operation
that
jeremy
had
proposed
for
the
gc,
where,
whenever
the
gc
moves
something
around
in
memory,
basically
the
old
copy
of
it
gets
zeroed.
H
D
H
D
Or
three
other
copies
hanging
around
with
jeremy's
proposal.
You
will
be
clearing
the
only
remaining
copy
of
it
if
that
matters
to
you,
however,
that
doesn't
address
things
like
system.string,
because
you
can't
clear
them
with
jeremy's
proposal.
What
would
happen
is
I
believe,
once
that
memory
gets
reclaimed
and
compacted
the
memory
will
also
be
zeroed
out,
because
it's
no
longer
used
is
that
correct
jeremy.
F
I
mean
I
don't
remember
if
we
had
said
that
it
would
do
it
immediately
on
on
dead
object,
reclamation
or
if
it
would,
but
because
the
only
time
that
the
thing
that
came
up
before,
which
was
specifically
a
pci
complaint
that
someone
had
was
that
they'd
done
something
that
got
a
byte
array.
The
byte
array
got
compacted
before
they
had
a
chance
to
clear
it,
and
so
then
the
keys
still
showed
up
in
memory,
but
since
they
were
actively
calling
clear,
the
thing
we
were
investigating
was
compaction.
F
Not
simply
what
data
lifetimes
look
like,
because
I
think
that
the
gc
team
would
completely
and
utterly
flip
out
if
we
said
that
as
soon
as
an
as
soon
as
something
was
being
marked
as
available
that
they
had
to
go
actively
clear.
All
the
memory
yeah
and.
D
By
the
way,
the
this
mode
of
operation
for
the
gc
that
we
were
talking
about,
would
have
some
amount
of
overhead.
It's
something
that
applications
would
want
to
opt
into
if
they're
operating
in
such
an
environment.
We
wouldn't
want
to
turn
this
on
by
default
for
all
applications.
F
D
String
yeah,
so
one
of
the
other
things
that
this
proposal
goes
over
and
I
think
this
is
what
you
were
hinting
at.
Emo
is
a
what
would
a
replacement
for
secure
string,
look
like
and
that's
that
is
proposed
around
halfway
down
the
document?
It's
it's
not
intended
to
make
any
of
the
promises
that
secure
string
ever
pretended
to
make,
because
we
can't
make
those
promises
and
we
shouldn't
even
pretend
to
make
them.
Instead,
what
this
proposed
type
does
I
call
it
shrouded
buffer,
but
that's
a
terrible
name.
What
this
proposal
does
is.
D
It
is
a
way
to
to
wrap
a
buffer
and
mark
it
such
that
hey,
you
caller.
You
need
to
make
sure
that,
if
you're
reading
the
contents
of
this
buffer
you're
doing
so
in
an
appropriate
fashion,
where
appropriate
might
differ
depending
on
the
kind
of
application.
You're
writing,
for
example,
there's
no
way
to
actually
get
at
the
raw
backing
store
of
the
shrouded
buffer.
Instead,
the
only
thing
you
can
do
is
copy
its
contents
into
a
span
that
you
control.
D
So
that
means
that
you
could,
if,
if
you
wanted
to
copy
the
shrouded
buffer
into
pre-pinned
memory,
you
could
either
create
your
own
array
and
then
pin
it
or
create
an
array
from
the
pinned,
object,
heap
or
stack
elegant
array
or
whatever
you
need
to
do
and
then
copy
to
pass
in
the
destination
pass
in
as
the
destination.
D
D
Correct
the
everything
here
is
span
based,
which
is
intentional,
because
it
being
span
based
it
makes
it
makes
it
very
clear
that
the
caller
is
always
in
full
control
over
the
lifetime
of
these
fans.
D
That's
an
implementation
detail,
but
the
the
way
that
this
is
implemented
in
my
prototype
is
it
actually
calls
heap
create
to
create
an
entirely
new
heap
where
these
things
are
kept,
and
that's
simply
a
defense
and
depth
mechanism
to
make
sure
that
a
an
arbitrary
dangling
pointer
can't
access
the
data,
for
instance.
But
it's
not
it's
not
a
promise.
It's
just
a
defense
and
depth
mechanism.
A
So
basically,
the
the
type
does
not
claim
that
it
will
prevent
copies
from
the
gc.
D
Correctly,
the
type
makes
no
security
guarantees
whatsoever.
The
only
the
only
reason
for
the
existence
of
the
type
is
to
wrap
a
buffer
in
such
a
way
that
the
caller
is
excruciatingly,
aware
of
the
fact
that
the
buffer
contains
privileged
information
like
there's.
There's
no
way
for
this
to
accidentally
show
up
in
a
log,
for
instance
like
the.
In
order
for
this
data
to
show
up
in
a
log
the
caller
explicitly
has
to
unshroud
it.
D
Correct
correct
two:
two
string
would
not
return
a
version
of
the
string
and
and
by
the
way,
that's
it
as
much
as
we
say
like.
Oh,
you
should
just
use
string
for
all
of
your
secrets
or
I'm
sorry.
Let
me
rephrase
if
your
secret
comes
in
as
a
string,
then
you
should
just
leave
it
as
a
string
and
deal
with
it.
The
way
that
you
would
normally
deal
with
strings
like
for
most
applications,
that's
actually
okay,
but
doing
that
increases
the
risk
that
a
developer
will
inadvertently
include
it
in
a
log
somewhere
right.
D
So
this
type
is
intended
to
work
around
that
problem,
where,
if
you
as
part
of
your
app
development
process,
have
a
policy
that
you
want
to
prevent
these
things
from
showing
up
in
logs.
This
is
one
mechanism
to
try
to
enforce
that.
Throughout
your
code
base.
A
I
mean
the
only
really
good
use
was
the
powershell
example
when
they
actually
have
like
a
method
that
effectively
reads
it
from
the
console
directly,
but
it
seems
like
when
you
look
at
asp.net,
for
example,
like
everything
is
dealing
with
strings
right,
because
you
have
configuration
data
that
has
keys
to
services
and
stuff
like
that
right,
and
I
guess
we
generally
don't
care
because
you've
accessed
the
server
process,
then
you're
already
screwed
right.
So
like
what
are
examples
of
scenarios
where
the
secrets
wouldn't
matter
like?
A
F
Do
we
care
generally?
No
does
pci
care?
Yes,
so
if
you
touch
credit
card
data,
then
you
are
required
by
the
agreement
of
all
the
credit
card
companies
that
that
the
the
moment
you
no
longer
needed
the
credit
card
data
to
be
unencrypted
in
memory.
It
is
no
longer
unencrypted
in
memory
so
that
there's
only
epsilon
chance.
It
ever
appears
in
a
crash
dump.
F
Yeah
for
people
for
pci,
it's
any
cryptographic
key
for
any
purpose
anytime,
that
you
have
the
what
they
call
the
pan,
which
is
the
credit
card
number
and
then
the
the
cvv
or
cvv2
code.
All
of
those
are
considered
extraordinarily
sensitive
and
must
be
erased
the
moment
they
are
no
longer
needed.
F
C
It
seems
like
this
could
be
really
useful
with
an
analyzer
as
well
or
just
searching
your
code
base
to
to
do
code
review
on
important
buffers.
F
A
Right
so
this
is,
this
is
kind
of
what
I'm
getting
at
it's
like
to
me.
If
we
like,
by
the
way,
I'm
not
opposed
to
having
this
type,
I'm
just
saying.
If
we
do
it,
we
should
probably
think
through
what
are
the
entry
points
where
you
get
this
data
and
then
make
sure
we
actually
have
apis
that
avoid
giving
you
the
data
as
a
byte
array
or
as
a
as
a
string
in
the
first
place
and
directly
giving
it
to
you
as
a
shorter
buffer.
So.
F
Response
data
from
key
vault,
or
I
mean
we
already
have
things.
I
know
that
in
your
ideal
world
emo,
we
will
delete
the
entire
crypto
stack
and
completely
rewrite
it,
but
we
have
things
like
symmetric
algorithm.key,
which
really
should
be
if
we
had
shrouded
buffer
as
a
concept
in
net
one.
Oh
then
it
would
totally
be
one
of
hey
you'd
like
pay
attention
here,
this
thing's
secret
yeah,
and
but
we
don't
so,
there
are
already
places
that
are
data
factories
like
the
key
property
on
symmetric
algorithm.
F
A
Well,
that's
why
I'm
saying
I
mean
to
me
like:
if
we
have
a
type,
I
think
we
should
probably
walk
the
chain
right,
I
mean
you
know.
Asp.Net
configuration
mechanism
would
be
another
common
example
how
you
get
access
to
keys
right
and
just
making
sure
that
if
we
have
such
a
type
that
it's
sufficiently
recognized
by
by
our
stack
to
actually
make
it
easier
people
to
get
one
and
then
just
holding
on
to
it
and
passing
it
around
right,
I
mean
the
other
thing
with
secure
string
is
for
the
most
part.
A
You
know
if
people
would
just
have
to
pass
these
guys
around
usability,
wouldn't
be
so
bad
right.
The
problem
was
always
that
the
the
construction
side
and
the
and
the
consumption
side
almost
never
talks
in
secure
string
right,
so
you
were
continuously
forced
to
either
transform
them
or
you
know,
construct
them
from
something
else.
C
A
D
Yeah,
well,
it's
it's
not
just
the
name.
It's
the
fact
that
it's
the
fact
that
it's
promoted
as
a
first-class
citizen
throughout
the
throughout
certain
apis.
It's
the
fact
the
fact
that
it's
mutable
also
the
fact
that
creating
and
reading
them
encourage
contortion
of
call
sites
and
stuff
like
that,
for
instance,
I
have
a
sample
here,
turning
a
shrouded
buffer
of
char
into
a
string
and
it's
three
lines
of
code
and
has
no
no
unsafe
api
calls
whatsoever
in
it
like
try
doing
that
with
secure
string.
F
I
think
I've
seen
the
method
called
secure,
string,
two
string,
this
secure
string,
yeah
yeah,
and
so
you
end
up
with
you
know:
food
secure
string
to
string.
D
Yes,
and
and
honestly,
I
I
don't
actually
mind
stuff
like
that,
and
that
might
be
surprising
to
people,
but
the
reason
I
don't
mind
it
is
because
it's
very
deliberate
when
the
caller
is
doing
that.
It's
not
like
it's
not
like
I'm
passing
a
secure
string
instance
to
you,
know,
string
dot,
format
inadvertently
and
now,
all
of
a
sudden
it's
gone.
It's
gotten,
you
know
decrypted.
F
C
F
Linux
you're
limited
to
like
26
of
them
unless
your
root,
secure
string
because
of
the
where
we
were
attempting
to
meet
some
of
the
guarantees,
because
we
have
to
we
end
up
malicking
it
in
a
in
a
non-pageable
memory
section
and
there's
a
limit
on
that,
because
you
know
that's
as
a
user
you're
not
allowed
to
say
I'm
taking
all
of
the
system
memory,
and
so
it's
secure
string
like
it.
It's
just.
D
Yeah
and
and
by
the
way
the
threat
model
here
would
be
different.
I
actually
had
some
conversations
with
our
own
internal
os
security
team
and,
like
I,
I
wouldn't
mark
any
of
these
pages
as
non-pageable
because
like
if
it
gets
written
to
the
swap
file
and
an
admin
can
read
the
swap
file,
whatever
we
weren't
trying
to
hide
from
the
admin.
But
apparently
there
are
ways
in
windows
to
to
mark
a
page
as
please
don't
include
me
in
any
crash
jumps
that
you
might
have.
A
Well,
that's
my
other
question
of
like
no
matter
what
we
do
is
like.
I
think,
if
we
can't
have
a
somewhat
sound
cross-platform
solution,
it
also
seems
bad
right
because
we
don't
want
to
live
in
a
world
where
it's
secure
on
windows,
but,
like
you,
know
bad
on
linux
right,
there
would
not
be
a
winning
population.
D
A
Right,
like
I
guess,
okay,
secure
was
the
wrong
technology,
but
I
mean
I
guess
what
I'm
saying
is.
We
should
not
have
dressed
to
the
different
behaviors
that
would
make
one
environment
way
more
brazilian
to
these
things
than
others
right.
That
seems
also
bad,
which
is
kind
of
the
problem
of
secure
string
right,
because
when
I'm
saying
it's
on
linux,
we
basically
do
do
nothing
right.
A
We
just
keep
the
data,
as
is
yeah,
that's
also
bad,
because
if
you
actually
look-
and
you
read
into
it-
oh
this
behaves
some
windows
by
encryption
and
then
linux.
It
doesn't
encrypt
that
that's
a
yeah.
D
Pretty
drastic
behavior
change,
I
don't
think
there's
anything
bad
about,
following
whatever
best
hygiene
might
be
on
the
various
platforms,
and
if
that,
if
that
best
hygiene
happens,
to
be
different
on
the
different
os's,
so
be
it
that
doesn't
strike
me
as
a
bad
thing,
but
we
definitely
don't
want
to
make
guarantees
that
we
can't
fulfill.
A
Yeah,
I
guess
that's
fair.
I
mean
like
I
guess
for
me:
it's
like
it's.
So
the
problem,
the
I
mean,
on
the
one
hand,
side,
I
agree
with
the
principle
that
we
should
be
platform
native
right.
Whatever
the
behavioral
platform
is
the
most
idiomatic
should
be
the
one
we
followed.
My
concern
is
just
that
people
who
target.net
very
often
also
use
admit
as
a
way
to
abstract
away
the
operating
system,
so
they
may
not
actually
care
and
they
may
actually
just
want
like
somewhat
of
a
sound.
A
You
know
experience
across
all
operating
systems
that
don't
have
runs
on
right
and
that's
why?
If
we
have
drastically
different
behaviors
that
are
surprising,
that
might
be
bad
right.
I
mean
you
could
argue
that
you
know
you
can't
run
wind
forms
and
on
linux,
and
that
might
be
surprising
for
people,
but
I
would
argue
that
most
people
will
not
be
terribly
surprised
by
that
versus.
A
You
know
if
something
gets
zeroed
out
on
windows
all
the
time
and
never
gets
zeroed
out
on
linux.
That
might
be
surprising
right,
so
they,
I
think
we
need
to
find
some
sort
of
sport
where
we
can
reasonably
say
we
have
somewhat
of
a
sound
behavior
across
all
platforms
and
it
might
be
slightly
different
or
you
know,
might
use
different
semantics.
But
it's
it's,
as
you
said,
most
appropriate
for
every
platform.
A
D
Yeah
he
he
mentioned
linux
mechanism
and
I
I
looked
into
a
windows
one
and
there
they
do
exist
on
both
oss.
D
D
A
I'm
reading
youtube
comments
and
I'm
amused
yeah,
so
the
that
makes
sense
to
me
and
then
basically
the.
How
would
you
describe
the
the
entry
points
like
do
you?
Do
you
think
that
people
do
what
you
have
on
screen
right
now
or
do
you
think
there
will
be
high
level
methods
to
do
these
kind
of
things
like
console.?
D
But
if
they
want
to
use
it,
then
I
would
anticipate
them
wrapping
the
data
inside
of
this
losing
the
reference
to
the
original
piece
of
data
and
then
just
letting
the
gc
handle
it.
A
D
Right
that
this,
this
type
is
not
intended
to
address
the
this
type
is
not
intended
to
provide
security
guarantees.
It's
intended
to
provide
marketing.
H
D
I
I
wouldn't
say
that
I
would
just
say
that
you
you
have.
You
have
to
write
your
code
in
a
very
specific
manner
to
accomplish
it.
C
D
Have
a
front
end,
that's
doing
most
of
the
data
processing
and
maybe
can
even
access
things
like
databases,
but
it
can't
actually
decrypt
the
raw
data
and
there's
a
back-end
server
where
I've
disabled
crash
dumps
and
I'm
running
a
small
trusted,
a
small
tcb
inside
of
that
backend
service
and
that's
the
only
thing
that
can
actually
access
raw
credit
card.
A
D
Basically,
the
the
code
running
inside
of
that
back-end
process
is
as
small
as
humanly
possible
and
it's
geared
only
toward
processing
this
kind
of
stuff.
It
doesn't
have
access
to
databases,
it
doesn't
have
access
to
the
actual
request
like
it's,
not
a
typical
asp.net
app,
but
that
that
end
tier
architecture
is
how
I
would
do
it.
If
I'm
going
for
compliance.
C
C
A
And
so
like
just
to
be
clear
like
from
a
pci
standpoint
like,
is
it
not
enough,
so
what
I'm
trying
to
basically
say
is
like
how
far
could
we
push
it
if
we
cared
enough
right?
So
if
we
actually
would
have
you
know,
equivalence
methods
of
like
you
know,
reach
out
buffer
on,
you
know
the
most
common
entry
points,
you'll
get
data
from
which
aren't
managed
memory.
A
G
You
have
to
disable
the
array
pool.
So
twitter
twitter
warned
me
that
this
was
perhaps
a
review.
I
ought
to
get
involved
in
so
here
I
am
because
someone
mentioned
secure,
string,
email.
I
don't
think
we
can
ever
make
statements
about
pci
compliance
aside
from
the
fact
that
it's
a
moving
target
and
what
could
you
know
what
someone
could
say
is
pci
compliant
one
year
may
may
not
be
pci
compliant
the
next.
It's
also
quite
use
and
other
dependent
in
that
pci.
Compliance
is
a
point
in
time
thing.
G
We've
seen
an
awful
lot
of
breaches
of
systems
that,
where
that
passed,
their
pci
compliance-
and
I
really
don't
want
us
to
start
making
claims
around
the
pci
compliance
of
the
framework,
because
it's
not
just
the
programming
language,
it's
the
environment,
it's
it's
the
axles.
It's
the
tackles.
It's
everything
right.
D
Yes,
yes,
and
I
think
that's
actually
a
really
good
point
that
barry
just
mentioned,
like
I
just
like
how
we
don't
want
to
say
that
this
type
is
a
security
oriented
type.
We
don't
want
to
say
that
the
framework
itself
is
compliant.
Rather,
you
can
build
compliant
things
on
top
of
it,
but
it
itself
is
not.
F
The
pci
perspective,
like
you,
know,
you're,
accepting
a
credit
card
number
right.
So
if
you
accept
the
credit
card
number
in
the
client
sends
it
over
tls
but
plain
text
through
the
tls
channel.
So
the
server
receives
it.
If
it
receives
it
now
in
a
system.string
object,
you
are
now
not
in
compliance
unless
at
the
moment
that
request
ends
that
string
is
erased
and
we
currently
don't
have
infrastructure
for
that.
So.
H
F
Be
in
still
meeting
things
if
the
client
sends
it
encrypted
to
a
session
encryption
key
that
you've
somehow
managed,
and
you
decrypt,
that
into
memory
that
you
are
managing
that
you
can
load
it
into
it,
do
what
you
need
to
do
and
then
clear
it
before
the
request
ends.
F
But
you
know
you
end
up,
there's
a
lot
of
there's
a
lot
of
complexity
as
to
what
it
means
when
some-
and
this
is
in
fact
a
thing-
I've
even
heard
that
the
auditors
aren't
consistent
about
not
to-
thankfully
I
don't
know
any
so-
I'm
not
putting
anyone
on
the
spot.
But
what
is
it
for
a
request
to
be
over
and
so
like?
There's
ambi
there's
a
bunch
of
ambiguity
in
a
bunch
of
terms
it,
but
the
biggest
problem
to
solve.
F
D
F
Yeah
and
so
there
there
are
complexities,
but
while
we
wouldn't
say
that
we
are
building
a
thing
that
makes
it
easy
to
attain
pci
compliance
or
is
internally
pci
compatible.
We
also
won't
make
the
statement
and
in
fact
I
will
on
behalf
of
john
before
he
yells
at
me,
make
the
statement.
That.Net
does
not
officially
not
care
about
pci.
D
So
so,
like
pci
is
cited,
it
sounds
like
it
sounds
like
the
conclusion
from
this
is
that
we
don't
really
have
a
good
end-to-end
story
that
would
necessitate
this
type
being
introduced.
That's
the
feedback,
I'm
getting.
C
F
It
just
says
pay
attention
to
the
usage
of
this,
and
if
we
think
it's
valuable
as
a
signaling
device,
then
it
could
be
valuable
as
a
signaling
device.
But
it's
not
it's
not
providing
security.
It's
not
helping
in
things
other
than
it's
giving
you
a
place
to
look
to
see
if
you
were
internally
consistent
and
using
shrouded
buffer
for
crypto
keys
for
pans.
For
you
know
any
of
that
kind
of
stuff
that
as
long
as
you're
consistent,
then
it
it
gives
you
fewer
places
to
look
in
your
code
to
find
out.
J
A
I
guess
what
I'm
trying
to
get
is
like
what
I
want
to
avoid
is
that
we
built
effectively.
You
know,
secure
strings
cousin
right
with
all
the
same
problems
right,
so
they
if
we,
if
we
believe
that
you
know
we
want
to
have
as
a
primitive
for
other
people
to
build
something
on
top
of
it.
That
could
be
pci
compliant.
A
Then
the
question
is:
how
hard
is
it
actually
for
people
to
do,
and
if
you
should
have
99
of
the
of
the
exercise
left
to
the
reader,
then
the
one
percent
doesn't
do
much
for
you
anymore
right
and
then
the
question
really
is:
is
it
actually
worth
the
complexity
of
having
another
type,
having
to
explain
it
and
and
maintaining
it
or
is
it
just
better
to
just
say
sorry,
we
don't
help
you
with
that
you
do
it
yourself.
H
D
You're
on
the
line
like
does
asp.net
even
offer
the
ability
to
turn
off
its
slab
allocator.
D
If
you're
not
willing
to
then
like,
I
think
it's
valuable
anyway,
because
this
proposal
links
to
things
like
the
the
gc
mode
of
operation
that
we
talked
about
earlier,
where
things
get
zeroed
on
compaction
right
as
part
of
this
exercise,
then
we
say:
look
this
api
isn't
isn't
appropriate
without
all
these
other
things.
In
addition,
so
yeah,
then
we
just
start
building
up
a
list
of
them
right,
but
it's
a
useful
conversation.
I
think.
D
F
Yeah-
and
I
think
part
of
the
problem
will
be
that
you
know,
if
you,
if
you
look
at
you,
know
a
pci,
can
you
decrypt,
or
can
you
encrypt
some
material,
send
it
to
the
client?
Read
it
back
as
sensitive
and
decrypt
it
all
while
doing
things?
F
Let's
call
it
sensibly
for
lack
of
a
better
term
like
what
things
would
we
need
to
do
like
so
symmetric
algorithm
like
what
do
we
do
about
the
fact
that
we
already
have
the
existing
key
property
that
returns
a
bite
array
like
there
are
places
that
make
a
lot
of
things
hard?
F
And
yes,
it's
if
they
never
read
back
that
that
property,
then
they're,
probably
fine,
but
when
they
gave
us
the
thing
they
gave
us,
they
had
to
give
us
an
array
currently
and
then
we
have
to
copy
it,
and
so
we
maybe
we
can
add
a
an
overload
somewhere
to
get
this
data.
But
it's
it's
all
about
figuring
out.
F
If
we,
if
we
wanted
to
say,
make
pci
hello
world
easy,
then
then
we'd
have
to
trace
everything.
We'd
also.
H
D
D
F
G
I'm
saying
we
can't
make
it.
It
was
like
when,
when
asp.net
had,
though,
when
we
added
the
gdpr
extension
points
to
asp.net,
nowhere
did
we
ever
say
that
asp.net
was
gdpr
compliant.
It's
just
that
we
gave
you
some
extension
points
to
help.
You
meet
some
of
your
obligations
under
your
gdr
compliance
audit.
A
Yeah,
so
I'm
not
trying
to
like
come
up
with
a
you
know,
legally
passing
thing,
I'm
just
kind
of
asking
the
question
of
as
a
product
owner
like
what.
What
is
the
thing
that
we
want
to
enable
people
to
do
right
and
I
think
to
me
there's
a
kind
of
two
scenarios
you
can
either
say
we
don't
care
about
pci
compliance
in
the
sense
that
if
you
wanted,
you
built
the
code
yourself
and
you
have
to
read
the
spec.
You
have
to
understand
it,
there's
a
bunch
of
stuff.
A
You
have
to
do
for
that
or
we're
saying.
Okay,
we
give
you
building
blocks
similar
to
the
gdpr
extension
points
and
we
carefully
document
what
those
are,
what
the
behaviors
are
and
what
you
can
and
cannot
do.
But
then,
if
we
do
the
latter,
then
I
think
there
is
some
more
end
to
end
than
just
having
this
type.
I
don't
think
the.
G
G
G
Oh
I'm
sure
you
know,
I'm
sure
certain
certain
languages
and
frameworks
that
belong
to
another
large
corporation
probably
have
a
an
enormous
pay
for
offering
that
comes
with
consultancy.
That
might
help
so.
D
To
your
to
your
question,
there
are
two
solutions
that
I've
seen.
The
first
is
that
if
you
can
just
pop
in
a
different
vm
that
makes
these
guarantees
on
your
behalf,
then
do
so.
D
The
second
is
just
if,
if
your
auditors
are
concerned
about
things
like
crash
jumps
containing
secrets,
disable
crash
dumps.
F
Yeah
yeah
a
different
vm's.
F
F
The
biggest
solution
that
I've
seen
is
that
you
just
write
everything
in
c,
where
nothing
is
free
and
you
had
to
do
all
the
work
and
therefore
you
did
all
the
work
according
to
the
spec
so,
but
even
that
actually
fails
depending
on
your
auditor,
because
windows
uses
what's
the
ipc
rpc
to
send
asymmetric
key
operations
into
the
lsa
and
there's
a
shared
buffer
in
that
that
can
will
effectively
hold
whatever
the
last
thing
that
went
across
to
the
lsa
was
so
the
last
thing
that
you
encrypted
or
decrypted
is
technically
still
in
memory
somewhere
and
I've
seen
that
come
up
and
it
got
like
one
demerit
and
it's
windows
is
like.
F
D
Okay,
no,
I
think
I
think
the
the
next
steps
for
me
are
clear.
Then.
D
Yeah,
so
I
I
don't
feel
comfortable,
really
obsoleting
secure
string
unless
we
have
a
good
end-to-end
story
behind
what
people
should
use
as
a
replacement
for
it
so
yeah.
I
would.
I
would
mark
this,
as
needs
work
figure
out.
What
a
good
end-to-end
story
is
and
then
see
what
else
we're
missing
in
the
framework.
Not
just
this
api,
I
mean.
F
I
can
say
that
on,
I
feel
like
we
recently
added
api
to
x59
certificate
2
and
we
copied
oh
yeah.
It
was
the
the
spanification
of
the
the
constructors
and
we
did
not
copy
the
secure
string
ones,
so
we're
already
signaling
that
secure
string
is
not
the
way
to
go,
but
so
the
like,
marking
the
constructors
on
x,
509
certificate
2
that
take
it
as
obsolete.
Like
I
have
no
problem
with
that,
it's
just
a
question
of.
G
Even
even
I,
who
hit
secure
string
with
the
fire
of
1
000
suns
would
feel
that
we
not
that
we
can
offer
an
equivalent,
because
we
can't,
because
the
guarantees
that
secure
string
made
were
nonsense
in
a
lot
of
cases.
But
I
think
we
need
guidance,
and
you
know
the
zeroing
garbage
collector
and
a
bunch
of
other
useful
tools
to
try
and
get
people
to
wear
that
to
a
securish.
A
A
A
This
feature
can't
be
implemented
because
that's
just
not
how
our
managed
run
time
if
a
gc
can
work
realistically,
so
we're
not
going
to
solve
the
problem,
and
you
shouldn't
rely
on
this
type
to
do
it
for
you,
because
we
can't
and
here's
some
guidance
on
what
you
might
do
instead
and
that
might
just
be
write
some
unsafe
code
and
wipe
the
buffers
out
yourself
right.
That's
that
to
me
would
be
sufficient
as
a
replacement.
It
doesn't
have
to
be.
A
F
A
A
F
F
Be
weird:
if
we,
you
know
it's
one
thing
to
not
overload
the
members
fully
but
like
if
we
were
to
mark
the
secure
string,
construct,
secure
string
based
constructors
on
x59
certificate,
2
is
obsolete
now
and
then
in
the
next
version,
add
shrouded
buffer
and
add
those
constructors.
It's
weird
to
do
that
across
two
versions.
Instead
of
one,
where
we're
being
like
this
one's
bad,
this
next
one
is
less
bad,
slightly
less
yeah.
So.
A
Guidance,
I
agree
with
that,
but
I
think
the
guidance
also
can
be
dialable
right.
We
don't
have
to
solve
every
every
problem
that
secure
string
claimed
it
would
solve,
but
I
think
fundamentally
to
me
the
bigger
problem
with
secure
string
is,
let's
say
we
had
the
guidance
and
let's
say
for
a
second,
that
we
would
convince
ourselves
that
building
short
buff
or
anything
else
would
be
not
a
good
idea,
and
we
would
just
say
sorry:
there
is
no
replacement.
A
Besides
writing
native
code,
if
we
were
to
obsolete
it
now,
the
question
is
what
other
apis
are.
You
know
basically
unable
to
use
at
all,
because
the
only
way
to
use
it
right
now
would
be
via
a
secure
string
right
or
our
powershell
friends
who
use
it
throughout
the
system
right.
So
we
would
have
to
at
least
make
sure
that
you
know
when
we
obsolete
something
that
you
can
actually
use
the
framework
and
maintenance
scenarios
without
using
obsolete
technologies.
Right.
A
D
Yeah
and
powershell's
usage-
I
was
thinking
of
as
well,
even
though
I
don't
really
document
it
here.
It's
I
wouldn't
be
opposed
to
them.
First
off,
I
think
they
should
have
owner.
I
think
they
should
have
ownership
of
the
type
to
be
perfectly
honest,
but
they
would
use
it
primarily
as
a
marker
type
which
sure,
whatever
that's
you,
know,
kind
of
what
shrouded
buffer
is
too
it's
a
marker
type,
just
saying.
F
F
But
yeah,
so
I
like
in
my
opinion,
is
that
we
we
want
to
feel
comfortable
in
a
decision
which
is
either
here
are
the
parts
that
we
are
proposing
as
replacements
or
and
then
for
other
parts
saying
and
we're
not
proposing
replacing
this
part,
but
that
we
we
feel
that
we've
covered
the
aspects
of
the
usage
of
secure
string
and
we
we've
said
for
this
kind
of
thing.
This
is
what
you
might
want
to
do
for
this
kind
of
thing.
F
That's
my
only
feeling,
like
I
don't
care
that
we
solve
any
problems
just
that
we've
decided
that
we're
not
going
to
solve
them.
Instead
of
we
haven't
solved
them
and
yes,
we
can
decide
later
that
we're
going
to
solve
them,
but
we
need
to.
We
need
to
have
a
strong
belief
that
if
we're
not
going
to
have
a
you,
give
me
a
thing
and
I
will
keep
it
encrypted
in
memory
notion
then,
and
and
then
we
think
that
that's
a
user
problem,
then
that's
fine.
A
So
basically,
what
are
the
two
takeaways
one
takeaway?
Is?
We
need
to
make
a
decision
whether
or
not
the
framework
is
interested
in
providing
building
blocks
like
shorter
buffer,
in
order
to
in
order
for
customers
to
build
a
psi
compliant
solution,
and
we
think
we
should
think
through
what
obsoleting
secure
string
means
for
the
stack
given
that
some
apis
only
work
for
secure
string.
D
Yeah
and
I
I
wouldn't
really
focus
on
pci
compliance.
I
know
that
we've
been
talking
about
it
for
the
past
few
minutes,
but
I'm
I
was
looking
at
it
more
from
the
perspective
of
marking
individual
call
sites
as
like,
hey
you're,
about
to
operate
on,
potentially
privileged
data
like
make
sure
you're
being
smart
about
it.
F
Yeah,
the
some
of
the
things
like
the
gc
compact,
clear
on
compaction,
feature
came
out
of
customer
requests
that
involved
pci
compliance,
but
that's
just
a
three-letter
acronym
that
we
can
use
for
talking
about
the
same
concepts
without
getting
into
the
legal
ramifications
of
of
their
exact
rules.
Yeah.
J
F
D
F
Great,
if
that
was
a
string,
and
you
call
substring
on
it,
does
do-
does
the
substring
inherit
that
marker,
if
you
call
array.copy,
does
that
inherit
the
marker
like
it's
like,
oh
god,
effectively.
What
we
end
up
with
is
just
saying
everything
is
sensitive
and
that's
when
we
came
up
with
clear
on
compact
so
and
and
yeah,
it's
anything
that
uses
pooling
of
any
kind
is
potentially
complicated.
F
Yeah,
like
I
said
the
best
way,
if
you
care
about
pci
compliance
and
net
is
to
it
was
encrypted
the
whole
way
through
the
net
process
and
then
and
honestly,
the
best
way
for
pci
compliance
is
to
dodge
the
panel
together
and
use
services
such
as
you
know,
square,
I
think,
is
one
that
has
a
good
api,
I'm
not
promoting
them
in
any
way,
shape
or
form
or
bad
mouthing
them,
but,
like
just
don't
touch
the
credit
card
number.
D
And
then
I
and
I
would
want
somebody
to
be
able
to
write
such
a
service
on.net.
I
I
don't
know
what
they're
written
on
today.
To
be
perfectly
honest,
yeah.
F
But
it
it
is
hard
like
the
pci
dss
spec,
I
think,
is
over
700
pages.
Some
of
them
are
about
physically
securing
your
hardware.
Others
are
about
clearing
your
memory,
it's
it's
a
hard
thing
and
yeah
we
I
we
definitely
would
not
be
pursuing
a
statement
that
you
know.
If
you
use
net,
then
you
are
100
always
guaranteed
to
be
pci
compliant,
because
we
we
can't
do
that.
The
endeavor
here
would
partially
be.
Where
are
the
places
that
it's
that
we've
made
it
hard
and
can
we
make
it
easier?
F
A
Yeah,
like
I
mean
I
think
the
doc
is
great.
I
haven't
read
it
in
great
detail.
I've
read
the
introduction
to
be
honest,
but,
like
I
I
I
think
we
should
push
harder
on
this,
like
I,
like
the
idea
of
us
cleaning
up
the
house
a
little
bit
more
and
like
being
more
specific
about
what
it
is
that
we
as
a
framework
want
to
provide
and
what
we
don't
want
to
provide
like
drawing
that
boundary,
I
think,
is
very
useful
and
that
is
also
going
into
the
yeah.
F
And
yeah
this
seems
like
a
reasonable
high
level
summary
of
what
we
concluded.
D
A
Alrighty
then
this
is
it
for
today
and
then
I
see
you
guys
on.
I
think
thursday
right.
D
Awesome
I'll
I'm
going
to
to
write
a
small
comment
after
what
you
did
just
saying
that
we
don't
always
have
to
have
a
replacement
for
everything,
sometimes
docking.
Please
don't
do.
This
is
good
enough.
A
D
F
F
A
Yeah
I
mean
one
way
to
look
at
this
is
obsoletion
is
basically
a
means
to
actually
promote
that
guidance
right
yeah
like
sometimes
the
purpose
of
obsoletion
is
to
pull
people
towards
the
replacement
tech,
and
sometimes
it's
just
telling
people
like
the
thing
you're
using
is
not
doing
what
you
think
it
does
stop
doing
it
right,
like
that's,
they're,
not
mutually
exclusive,
and
I
think
they,
you
know
sometimes
obsoleting
with
don't
hold
it.
This
way
is
the
only
thing
you
can
do,
because
you
can't
just
build
the
thing
that
you
thought
you
can
build.
G
A
All
right,
then,
yeah
see
you
guys
later.