[webkit-dev] Regarding SecurityOrigin API usage

[Adam Barth]

On Thu, Jan 6, 2011 at 10:17 PM, Pushparajan V <vprajan at gmail.com> wrote:
> On Fri, Jan 7, 2011 at 1:18 AM, Adam Barth <abarth at webkit.org> wrote:
>> On Thu, Jan 6, 2011 at 6:27 AM, Pushparajan V <vprajan at gmail.com> wrote:
>>> I have a query regarding addOriginAccessWhitelistEntry API in
>>> SecurityOrigin.cpp. Is there any special requirement in the
>>> sourceOrigin argument of this API when the scheme of the sourceOrigin
>>> is already added to the localScheme list?
>>
>> There's a long-standing issue here that some of the checks for
>> whitelisting and being local are backwards.  I tried to fix this
>> recently, but that caused a performance regression because the
>> canDisplay method is apparently very hot in the page load test.  I
>> need to circle back and give it another shot.
>>
>>> Because if the sourceOrigin is localScheme and the URI doesn't have a
>>> path, this API fails miserably without any warning or asserts.
>>
>> Sorry.  :(
>>
>>> For example, if widget is a local scheme and the source origin URI is
>>> widget://884889/ for which i need to whitelist some destination URLs,
>>> the below statement returns null.
>>>
>>>    String sourceString = sourceOrigin.toString();
>>
>> That behavior is actually correct.  By default, we treat local origins
>> as if the were sandboxed with the unique origin bit.  What's your
>> motivation for marking widget as a local origin?
>
> Since widget accesses files in local filesystem, this marking is done.
> As you said, this new unique origin bit used for sandboxing is the
> reason behind null getting returned by toString.

Hum...  I'm not really sure what a widget is, but allowing access to
the local filesystem is very dangerous.

>> The same change I mentioned above is mostly concerned with
>> crystalizing out the two properties we have tied up in "localness,"
>> which are blocking navigation to local URLs and special access status
>> for them (historically universal access, more recently sandboxed
>> access).
>
> There is a fear of losing compatibility with the latest HTML5
> localSchemes like data://, sandbox:// etc. That's the reason widget
> scheme wanted to be kept as local.

data isn't a local scheme in HTML5.  We need to charge some
architectural things in WebKit to be able to implement data URLs as
specified in HTML5.  I've never heard of a sandbox URL scheme.

>>> After debugging more, found that all local schemes are treated as
>>> file:// schemes and directory access is not allowed for any
>>> localScheme.
>>
>> Yeah, I think that's what I meant above by "sandboxed" but I could be
>> misunderstanding.
>>
>>> Does that mean securityOrigin's should be created always with full URLs?
>>
>> You can't round-trip SecurityOrigin objects via toString.  There are
>> several things that aren't represented in the string version,
>> including document.domain and the HTML5 sandbox bits.
>>
>> I'm not 100% sure I answered your question, but I suspect the solution
>> might be to avoid marking widget as a local scheme.
>
> Yeah that would be the perfect fix. Moreover, this is what tried out
> recently and working well.

Great.  That should make things less magical for you.

> But the only problem suspected with this is blocking of
> navigation/access with other internal localSchemes (like file, data).
> Need to test and study that flow as well to come with a conclusion.

Data URLs should be no problem.  Blocking navigation to file URLs is
likely a benefit.  :)

> Thanks Adam. It answered many of my questions in one shot. :)

Good luck!

Adam