Originally I was using the following ugly hack to overwrite location in older versions of chrome:

function location(){}
Object.defineProperty(window,'location',{...})

But this is far from ideal since assignments to window.location=123 will not be tracked  and overwrite the custom object and this bug has been fixed in newer versions of chrome. 

I think the general idea of adding a flag for this in order to support pentesters et al is reasonable. I have no idea how deeply in the bindings/v8 this is implemented, however. CCing jochen@ and dcheng@ who might have a better feel for how much work this would be.

oh well, we might be able to do that for testing, and you get to keep all the crashes that happen due to that, but that's probably ok for you

Conceptually this wouldn't be that hard to do (we could just mask the v8::PropertyAttribute when we create the templates, and configure that mask), plus some plumbing. I suspect context snapshotting might mess this up, though (presumably it would cache a snapshot with the features being unconfigurable?).

It wouldn't be hard to modify a custom-built copy of Chromium to do this, by either removing the relevant Unforgeable entries from the .idl files, or removing the bits that add v8::DontDelete in third_party/WebKit/Source/bindings/scripts/.

Is it worthwhile for us to ship this as a built-in feature of Chrome?

Personally I do think it's worthwhile, I think a lot of people will want this flag if they are writing their own dom scanner. It would be useful for debugging too, you could use a proxy overwrite the objects and intercept all calls to host objects and log them. This would enable you to fix dom based xss issues. If it's not too much work please add this flag, you would make a security researcher very happy :)

Would this have any other uses for Chrome itself? We have a ton of flags already... While I see the utility of the proposal, I don't feel entirely comfortable shipping it in Chrome itself: that usually indicates some level of support/expectation to work, but it seems like there are likely issues with context snapshots.

[+peria, who's been working on adding Blink objects to the V8 snapshot]

I'm kind of resistant to adding another flag (as dcheng points out, we have a lot already). And to me this doesn't seem like a terrible use case for making a custom Chromium build and floating the small patch to drop the Unforgeable check.

I think the context snapshotting issue (which will only exist once Blink objects are included in the snapshot) could be resolved by changing our startup code to not load the snapshot when the flag is given. But I don't understand snapshotting well enough to know if there are other implications.

It's possible to avoid using snapshot depending on an optional flag, and this flag can be a trouble if we use snapshot. So the snapshot feature needs the hack as jbroman@ said.

Beside it, as a personal opinion, +1 to #6 and #7; not adding the flag.

It doesn't sound like there's a lot of enthusiasm for implementing this. I'm going to WontFix this (someone can reopen if they object).