Trevor Jim wrote:
> Regarding putting the onus on browser developers, I don't think we should
> put the complete responsibility on them. Our idea is that the
> responsibility
> has to be shared between browser developers and web app writers. I don't
> think I can anticipate just what policies we
Trevor Jim wrote:
>> It started out as a hash of something, but it ended up a key. I'll
>> update my latest slides, which I'll be publishing soon. Thanks,
>>
>> /be
>
> Nor is it a key, e.g., you are not encrypting anything.
Touche' -- not sure what to call it, other than "id".
> An additional p
Trevor Jim wrote:
> On Apr 10, 2007, at 6:15 AM, Gervase Markham wrote:
>
>>> To be foolproof, the proposal does need to scan the untrusted
>>> content to ensure that the "hash" is not in the content, this is
>>> slightly
>>> more involved than the HTML/JavaScript escaping our proposal requires.
Gervase Markham wrote:
> Ka-Ping Yee wrote:
>> Is it actually a hash of anything? It looks to me more like a key.
>> If so, it should be called a key.
>
> From my reading, I don't think it is, no. BICBW.
>
> Gerv
It started out as a hash of something, but it ended up a key. I'll
update my lat
I've urged over and over to separate the literally unfixable problem of
protecting sites such as MySpace and LiveJournal from improperly
sanitized or sandboxed user-generated content, and us fixing our own
codebase to track javascript: subject principals. So I'm good with
making progress, even if
Ka-Ping Yee wrote:
We should scrap all this and do something better.
I'm really glad to see that there's interest in a new and better
design.
Me too.
One thought I had the other week is to enable privileges implicitly
based on "latent trust": site has good CA-signed cert, you've connected
Brendan Eich wrote:
2. SpiderMonkey reflects __proto__ and __parent__ for all objects,
again using per-property getter and (for __parent__) setter
Oops, I meant "(for __proto__)" before "setter" above -- __parent__ is
read-only.
This informal write-up cont
Fritz Schneider wrote:
This direction of access (untrusted is handed a "trusted" object by
trusted code) is not safe.
Then it sounds like it is the case that there is no possible way to
safely expose an interface to code in a sandbox?
We *think* we've secured the paths in t
Fritz Schneider wrote:
BTW, with respect to this statement:
This direction of access (untrusted is handed a "trusted" object by
trusted code) is not safe.
Is this due to bugs or policy? That is, in the absence of bugs in this
area, would this direction be safe?
There are a few
Boris Zbarsky wrote:
Brendan Eich wrote:
One thought I had the other week is to enable privileges implicitly
based on "latent trust": site has good CA-signed cert, you've
connected with SSL, you've got a password saved for this site, you are
logged in.
Such a site cou
Boris Zbarsky wrote:
In this case, I think we do have an answer, though: "Someone found a
situation where an object and its __proto__ were in different trust
domains, and our policy is to not allow access to things from a
different trust domain, so we need to check when getting the
__proto__.
Boris Zbarsky wrote:
It looks like this list might actually work for security discussion, so
here goes... ;)
At the moment, our expanded-capability architecture suffers from four
issues:
At least four!
1) It's only possible to expand capabilities for a JS stack frame, not
for a web page
Boris Zbarsky wrote:
Fritz Schneider wrote:
If I understand this correctly, if I give an unprotected script a
reference to a trusted object, that script has full access to the
object?
There are some security checks, but they're done by XPConnect. Brendan
or Blake might know more about whethe
13 matches
Mail list logo
