cordova-dev mailing list archives

TBH I'm still unsure of the entire whitelist thing. It feels like
we've spent a great deal of time on a feature that is essentially just
a talking point for security checklists. Our community is otherwise
uninterested if not outright frustrated by it!
I know the whitelist is pretty tied up to our internals so making it a
plugin is probably not realistic. Regardless the behavior should be
normalized across the platforms. I like the Chrome spec.
We should contrast this with the WebAPI [1] stuff Moz is doing and the
restricted by default Sys Apps thinking [2].
[1] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/Security/Security_model
[2] http://runtime.sysapps.org/#csp-policy
On Fri, Jul 5, 2013 at 12:00 PM, Andrew Grieve <agrieve@chromium.org> wrote:
> As another point of reference, here's the white-listing scheme that Chrome
> extensions use:
>
> http://developer.chrome.com/extensions/match_patterns.html
>
> It uses * for wildcards, but adds some restrictions as to where the * may
> appear and what schemes are valid.
>
> It's not a goal for Cordova to be runnable within Widget containers, so I
> don't think conforming to the widget spec is meaningful, except that it
> saves us from writing our own spec. I think the white-list patterns from
> Chrome Extensions make sense (aside from specifying "chrome-extension" as a
> valid scheme).
>
>
>
> On Fri, Jul 5, 2013 at 2:27 PM, Andrew Grieve <agrieve@chromium.org> wrote:
>
>> We've had several requests for finer-grain whitelist. The main ask is a
>> way to allow images.
>>
>> I think a simple step towards this would be to allow the whitelist to
>> specify patterns that match against the full URL, and not just the domain.
>>
>> e.g. <access origin="*.google.com/images/*" />
>>
>>
>>
>>
>>
>> On Fri, Jul 5, 2013 at 2:05 PM, Ian Clelland <iclelland@chromium.org>wrote:
>>
>>> There seem to be two competing methods for whitelisting domains with
>>> subdomains, and support for each varies by platform.
>>>
>>> <access origin="*.example.com" />
>>>
>>> - is supported on ios
>>> - is supported on android as of CB-3854
>>> - is backwards-compatible with previous versions of cordova
>>> - is supported by cordova-cli
>>>
>>> <access origin="example.com" subdomains="true" />
>>>
>>> - is supported on android
>>> - is supported on BB10
>>> - may not be backwards-compatible
>>> - is the only method defined in the W3 widgets-access spec
>>> - is not supported by cordova-cli*
>>>
>>> This situation makes it difficult to create a config.xml for a project
>>> which will successfully work on all platforms.
>>>
>>> *(cordova-mobile-spec, for instance, contains <access origin="apache.org"
>>> subdomains="true" /> in its config.xml, which gets translated as <access
>>> origin="apache.org" /> in the platform config files, and subsequently
>>> fails
>>> everywhere.)
>>>
>>> I think that the subdomains attribute is the right way forward, as it is
>>> endorsed by the W3C, and I believe that we are ostensibly trying to
>>> conform
>>> to the widgets spec for our config.xml files.
>>>
>>> To that end, I'd like to make the subdomains attribute work on all
>>> platforms (I'll take care of iOS; I don't know if any others need fixing)
>>> and also make it work in CLI. I don't think we should remove support for
>>> the wildcard domains, for backwards compatibility, but then again, maybe
>>> 3.0 is the right time and place for that.
>>>
>>> If there are no objections, I'll create the issues and start implementing
>>> this (with as much backwards compatibility as I can manage)
>>>
>>> Ian
>>>
>>
>>