From: Erik Arvidsson [erik.arvids...@gmail.com]
We went through the exercise of only having private symbols but it lead to
some issues. Here is one that we identified.
Lets assume we use a private symbol for the @@iterator. The symbol can still
be checked because anyone that has access to
On 8/2/2013 1:02 PM, Domenic Denicola wrote:
I know the answer will be obvious when I see it, but I can't quite
remember ... why is it important that `O[privateSymbol]` not invoke
the proxy?
That would leak the Symbol to the Proxy and then private Symbols
wouldn't carry a guarantee of
From: Brandon Benvie [bben...@mozilla.com]
That would leak the Symbol to the Proxy and then private Symbols wouldn't
carry a guarantee of security. That's the only difference between private
Symbols and unique Symbols.
Right, I thought about that, but I am still not quite clear on what the
Practically speaking, given dynamic-this-binding by default in JS, it's
too easy to access a foreign object with an important name (private
symbol in the hypothesis). It will happen. You will leak it. It can then
be used to attack you.
/be
Domenic Denicola wrote:
From: Brandon Benvie
On Fri, Aug 2, 2013 at 1:15 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
From: Brandon Benvie [bben...@mozilla.com]
That would leak the Symbol to the Proxy and then private Symbols wouldn't
carry a guarantee of security. That's the only difference between private
Symbols and
On 8/2/2013 1:15 PM, Domenic Denicola wrote:
From: Brandon Benvie [bben...@mozilla.com]
That would leak the Symbol to the Proxy and then private Symbols wouldn't carry
a guarantee of security. That's the only difference between private Symbols and
unique Symbols.
Right, I thought about
Le 02/08/2013 22:18, Brendan Eich a écrit :
Practically speaking, given dynamic-this-binding by default in JS,
it's too easy to access a foreign object with an important name
(private symbol in the hypothesis). It will happen. You will leak it.
It can then be used to attack you.
Sketched a
On Fri, Aug 2, 2013 at 4:02 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
I know the answer will be obvious when I see it, but I can't quite remember
... why is it important that `O[privateSymbol]` not invoke the proxy?
We don't want to leak the privateSymbol to a proxy.
module
Thanks Brandon. As I expected, obvious once you see it. Hopefully my learning
experience was helpful to other observers too :).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
David Bruant wrote:
Probably not perfect, but seems like it could work.
We 3 perfect is enemy of good as admonition. Also Pascal's I would
have written a shorter letter if I had more time.
However, leak hazard likelihood is never close enough to zero. This
means we can't add more
On Jul 31, 2013 1:39 AM, Mark S. Miller erig...@google.com wrote:
Only useful for instance-private instance variables, in which case you
may as well use lexically captured per-instance state.
Also useful for methods where different subclasses needs to specialize the
behavior.
We've tripped on
Aside from this confinement issue, all other the advantages that unique
symbols have over unique-ish strings seem minor to me. The biggest is
default non-enumerability, when we're getting away (admittedly slowly) from
enumerability being significant anyway. IMO, if the only advantages of
On Wed, Jul 31, 2013 at 8:50 AM, Kevin Smith zenpars...@gmail.com wrote:
Aside from this confinement issue, all other the advantages that unique
symbols have over unique-ish strings seem minor to me. The biggest is
default non-enumerability, when we're getting away (admittedly slowly) from
On Wed, Jul 31, 2013 at 10:38 AM, Mark S. Miller erig...@google.com wrote:
Only useful for instance-private instance variables, in which case you
may as well use lexically captured per-instance state.
Also useful for methods where different subclasses needs to specialize the
behavior.
Mark S. Miller wrote:
Only useful for instance-private instance variables, in which
case you may as well use lexically captured per-instance state.
No, friend is shared between two classes, no way to make a
closure per instance extending over both constructors. Pretend
Mark S. Miller wrote:
Don't ever use MAC addresses, dates, times, positions, etc, as sources
of uniqueness.
uuidgen implementations have used MAC addresses in the past, which I
believe led to a public collision.
What a collision resistant string? Use 128 bits of entropy. You'll get
an
Erik Arvidsson wrote:
On Wed, Jul 31, 2013 at 10:38 AM, Mark S. Millererig...@google.com wrote:
Only useful for instance-private instance variables, in which case you
may as well use lexically captured per-instance state.
Also useful for methods where different subclasses needs to specialize
On 7/31/13 at 8:35 AM, bren...@mozilla.com (Brendan Eich) wrote:
uuidgen implementations have used MAC addresses in the past, which I believe
led to a public collision.
In 1998 we (Electric Communities) discovered that people using
AOL software to access the internet were all assigned the
On Wed, Jul 31, 2013 at 10:50 AM, Mark S. Miller erig...@google.com wrote:
On Wed, Jul 31, 2013 at 6:24 AM, Dean Landolt d...@deanlandolt.comwrote:
On Wed, Jul 31, 2013 at 8:50 AM, Kevin Smith zenpars...@gmail.comwrote:
Aside from this confinement issue, all other the advantages that
Mark S. Miller wrote:
On Wed, Jul 31, 2013 at 8:35 AM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Mark S. Miller wrote:
Don't ever use MAC addresses, dates, times, positions, etc, as
sources of uniqueness.
uuidgen implementations have used MAC
Brendan Eich wrote:
Gathering entropy enough to make a UUID is work. A crypto module's
RBG should be up to it. Browsers have those, but we haven't yet
required any such thing in ECMA-262, and I expect some
implementations will be crypto-module-free and cheese out on the
On Wed, Jul 31, 2013 at 6:21 PM, Dean Landolt d...@deanlandolt.com wrote:
That leaves default non-enumerability. Consider the fact that object
literal methods are enumerable. Why should choosing a unique name as
opposed to an identifier for a method have any bearing on enumerability?
I
Agreed -- I was mostly joking. But there's a reason the proposal called
for a string prefix -- they will be reflected in the raw. Unlike Math.PI,
this raw value is meaningless.
Yes - a minor issue with unique strings is that you will see distractingly
ugly property names in your debugger.
On Mon, Jul 29, 2013 at 1:21 PM, Brendan Eich bren...@mozilla.com wrote:
This seems to neatly separate concerns, but Arv pointed out that for some
proxy cases it won't work. I forget what he said exactly, though. Cc'ing
him.
We went through the exercise of only having private symbols but it
Yes. See
https://mail.mozilla.org/pipermail/es-discuss/2013-July/032339.html for
more along these lines.
On Tue, Jul 30, 2013 at 11:27 AM, Erik Arvidsson
erik.arvids...@gmail.comwrote:
On Mon, Jul 29, 2013 at 1:21 PM, Brendan Eich bren...@mozilla.com wrote:
This seems to neatly separate
Yes, thanks. This is a fine pickle!
We need two things. I'd rather have unique symbols and private fields
(whatever they are under the hood is unobservable). One can still
confine a uniique symbol to keep it private, if it is used to index
objects one creates (and not proxies from outside).
On Jul 30, 2013, at 7:02 PM, Brendan Eich wrote:
Yes, thanks. This is a fine pickle!
We need two things. I'd rather have unique symbols and private fields
(whatever they are under the hood is unobservable). One can still confine a
uniique symbol to keep it private, if it is used to index
Mark S. Miller wrote:
Aside from this confinement issue, all other the advantages that
unique symbols have over unique-ish strings seem minor to me. The
biggest is default non-enumerability, when we're getting away
(admittedly slowly) from enumerability being significant anyway. IMO,
if the
Mark Miller wrote:
On Tue, Jul 30, 2013 at 8:36 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Mark S. Miller wrote:
Aside from this confinement issue, all other the advantages
that unique symbols have over unique-ish strings seem minor to
Mark S. Miller wrote:
On Tue, Jul 30, 2013 at 9:19 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Mark Miller wrote:
On Tue, Jul 30, 2013 at 8:36 PM, Brendan Eich
bren...@mozilla.com mailto:bren...@mozilla.com
mailto:bren...@mozilla.com
Domenic Denicola wrote:
Reading through [the meeting notes][1]:
YK: You don't need unique symbols when you can just expose private symbols.
BE: Why can't we just have (private) Symbols
BE: Can we unwind the split between private and unique?
These struck a chord with me. Thus, in the
Reading through [the meeting notes][1]:
YK: You don't need unique symbols when you can just expose private symbols.
+1. I've been wondering this for a long time but thought that there was too
much consensus around unique symbols to question it. I'm glad these questions
are being asked. I
32 matches
Mail list logo
