DavidBruant

// Requires a native Function.prototype.bind (IE9+, FF4+, Chrome, Opera 12, no Safari)

function newOperator(constructor, args) {
    var params = [undefined].concat(args)
    var cst = Function.prototype.bind.apply(constructor, params);
    
    return new cst();
}

DavidBruant

function makeProxyWhichCallOnDelete(farg){
    var target = {}; // Important: the constructor was not initialized with the target

    return new Proxy(target, {
        delete: function(target, name){
            farg(target); // no access to the proxy identity!
        }
    });
}

DavidBruant

PART 1: The same feature?

When looked abstractly, both private name and weak maps propose an equivalent feature: a mapping between 2 unforgeable references and a value. Both allow to share a secret with someone assuming the knowledge of 2 unforgeable entities. Both have the interesting property of symmetric non-discoverability:

• Given an object, you can't list all private names
• Given a private name, you can't list all objects which have this name as a property
• Given a weak map, you can't list all objects used as keys

DavidBruant

Introduction

We've seen in the thread "Are Private name and Weak Map the same feature? and the Assoc API" that .public was here to prevent proxies from having access to a private name. This constructs results in a bigger efforts to use private names in coordination with proxies (need to access the public part and a map to retrieve the private name with the remaining danger of sharing the map with the wrong entities).

Sam Tobin-Hochstadt gave an example of a simple program we may not expect to leak a private name but would if private names passed through proxies and the program was used with a malicious proxy. I answered that we should consider changing the way we write program and I admit that I am myself a bit annoyed by this statement.

So here is a proposal where I think I can make both parties (those who don't want to write complicated programs to protec

DavidBruant

"use strict";

(function(){

    var cache = new WeakMap();
    
    Object.prototype.boundTo = function(fct){
        var obj = this;
        
        var objMap = cache.get(fct);

DavidBruant

var ogopn = Object.getOwnPropertyNames;

var iframe = document.createElement('iframe');
iframe.src = location;
document.body.appendChild(iframe);

console.log(iframe.src);

var iframeOgopn = iframe.contentWindow.Object.getOwnPropertyNames;
console.log(ogopn, iframeOgopn)

DavidBruant

  function getHiddenRecord(key) {
    if (key !== Object(key)) {
      throw new TypeError('Not an object: ' + key);
    }
    var hiddenRecord = key[HIDDEN_NAME];
    if (hiddenRecord && hop.call(key, HIDDEN_NAME)) { return hiddenRecord; }
    if (!originalProps.isExtensible(key)) {
      // Weak map must brute force, as explained in doc-comment above.
      return void 0; 
    }

DavidBruant

// Boilerplate code to make the above work
var readyDef = new $.Deferred();
var readyP = readyDef.promise();
$(function(){ readyDef.resolve() }); 


$.when($.get('rss.xml'), readyP).then(function(rss){
    // second argument purposefully ignored since I only care about synchronization

    // build a document fragment

DavidBruant

var d = new Person('David');
console.log('d.name:', d.name);
setTimeout(function(){
    console.log('d age', d.getAge());
}, 500);
console.log('d instanceof Person', d instanceof Person);
console.log('d instanceof ComputerSavvyPerson', d instanceof ComputerSavvyPerson);

var db = new ComputerSavvyPerson('David Bruant', 'JavaScript');
console.log('db.name:', db.name);

DavidBruant

"An entire class of security vulnerabilities (buffer overruns, use-after-free, stack overflow) basically cease
to exist for programs running in a garbage-collected environment (to be replaced by exciting new security
vulnerabilities such as SQL injection, but that’s another story)."
=> SQL injections are unrelated to how memory is managed. SQL injections mostly come from denying the structure
of an SQL query by representing it as a string.
As a consequence, SQL injections could exist in C-memory-model languages. Think of a bash program that would accept
constants and append it to a prepared string (in C). The program would be vulnerable to SQL injections as well.

"The problem with garbage collection is that, now that memory management isn’t explicit (i.e. that when to recycle
memory can’t be statically known by the compiler anymore), lifetimes have to be discovered at runtime"