Stuff like this often isn't completely deterministic. The attack vectors will move around and new ones will be discovered but since the syntax Sara is proposing is completely valid JSON it gives people another tool. Documenting specific attack vectors is useful too, of course, but a secondary concern in my mind.
I'm not talking about attack vectors and full security analysis. For me, it is a primary concern having some security oriented feature to know *what exactly* it does and when you should and should not use it. We were burned repeatedly by implementing various cool features that were misused for doing things that they weren't meant to do and then we were blamed for it - so I think we need to have clear understanding of when and why this feature is useful and explicitly document it. Otherwise what would happen is that people would use this option, pass JS data through it, stick it into DOM, get XSS and start blogging about "huge XSS in supposedly secure json_encode() function in PHP".
Or, not seeing how it can help them, won't use it at all. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
