Followup on the eValid Same Origin Policy thread

[PercyR]

Afternoon.

I'm intrigued with a forum post i read earlier on this technology forum thread.

Why does eValid's architecture avoids conflict with the "same origin" policy?

Thanks

[eValid]

Afternoon.

I'm intrigued with a forum post i read earlier on this technology forum thread.

Why does eValid's architecture avoids conflict with the "same origin" policy?

Thanks

Thanks for asking PercyR

On this we have to be careful not to reveal some of the proprietary details of the eValid solution, but up to those limits here is the story.

eValid actually binds a complete browser in a kind of "control wrapper" for which the constraints of the same-origin policy don't apply because commands executed by evalid, and run by the browser API, don't have to check whether the requested action originated from the same website as the script parent.

Further, this is not a COM interface, which would make eValid executions dependent on each browser face having space on the Windows DeskTop.

We think of this as "direct execution of API commands" whereas excuting JavaScript is "implicit execution" and from the Desktops as "indirect execution".

Some of this same kind of thinking is incorporated in the forthcoming WebDrive W3C standard interface.

-- eValid Support