Ideally there would be some way for the "caller" to opt out of providing any
sort of identity built into javascript, isn't this a flaw in wrappers that
such information could possibly get through?  If the engine knows who is
calling the function shouldn't any wrapper be blacklisted and the caller an
empty object or an object that would pretend to be any empty function that
was requested?  There must be a list of wrappers that exist somewhere that
could be utilized on a low level to block that information by indexed
references.  I don't think there is any useful functionality to worry about
breaking, though it might render some functions un-callable from GM unless
the fake "caller" would respond to any request with an empty string or
simply the correct type of return value for the real function within the
wrapper?  Ideally you could specify from your script what any of your fake
callers functions would return in case the script were to try to detect
whether or not you were exposed.  I don't know for sure but can't GM also
look at the caller and deny access to it's own functions?  Caller is
misleading if a page function can pretend that the scope called it's own
function, there must be some way to see where the chain was initiated
without getting a reference to it, but even just a boolean that indicates if
the origin of or the implicit this of the line of code being executed before
it returns was within the scope of your current wrapper or not?  The value
would be notScope or something to that effect, I don't think this should be
available to the page scope or else it could be used to block GM from
calling functions.  When a wrapper is calling a function notScope could be
undefined or otherwise the test not performed.  Doesn't the engine have a
reference to it's current scope's root to compare with the function's
root scope at the time it parses a function being called on any page script?
 Do I have to complete firefox to find out?  I mean it's really important I
think that the user owns their web browser, why would you ever provide any
information to the page?  I would rather run the page in a sandbox than the
userscript.

On Sun, Feb 28, 2010 at 9:36 AM, Anthony Lieuallen <[email protected]>wrote:

> On 2/28/2010 3:57 AM, esquifit wrote:
>
>> The exploit shown in this thread has been fixed since then.  This
>> means that the page doesn't have access to the privileged GM_* api
>> anymore, at least in this way.  I still don't know whether this makes
>> unsafeWindow actually safe..
>>
>
> Well said.  The unsafeWindow is unsafe specifically because Javascript is
> so powerful and flexible.  A blessing and a curse.  In short, there are
> plenty of good ways to interact with the content page, if that's really what
> you want to do:
>
> http://wiki.greasespot.net/Category:Coding_Tips:Interacting_With_The_Page
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "greasemonkey-users" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<greasemonkey-users%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/greasemonkey-users?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"greasemonkey-users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/greasemonkey-users?hl=en.

Reply via email to