[Development] Controlling QML Imports

[Alan Alpert]

On Tue, Dec 11, 2012 at 7:52 AM, Thiago Macieira <thiago at kde.org> wrote:
> On terça-feira, 11 de dezembro de 2012 15.44.37, Aaron J. Seigo wrote:
>> > > > loading of native plugins from the application?
>>
>> Yes, but not native plugins installed by the QML applications. In such a
>> situation we need to be able to ensure that applications which say "I will
>> access this list of plugins" only do so.
>>
>> Is this realistic? It is precisely what we've been doing for a number of
>> years  in Plasma.
>>
>> > > I tend to agree with Thiago. How does restricting this help for native
>> > > apps? It's anyway the app itself setting the restrictions.
>>
>> Well, yes, it doesn't help for "native" apps. That's not the point, is it?
>> Because some kinds of applications will not benefit from this does not mean
>> that those which would should not have a facility to use to accomplish it.
>
> It seemed to me that it was as well.
>
> I'm not doubting the benefit of this for controlling what a plugin in QML does.
> I was just questioning the use of this feature to enforce device and platform
> security. It's the wrong level.

Correct, this is not a complete device and platform solution. The idea
though is that this could be used when implementing a complete device
and platform solution, because that complete solution on a lower level
may need to have an answer for QML too. If your runtime runs qml
directly you may want to restrict its ability to call native code
(because everything QML does is exposed native code). Here are a
couple of examples to clarify when this might be used:

A) Creating a mobile platform that can have native executables
deployed to it. Here you need a lower level security control anyways,
you probably won't use this.
B) Creating a mobile platform that is locked-down and does not allow
3rd party executables. All 3rd party applications must be QML files.
Here you might be able to use import control to prevent loading of 3rd
party executables entirely.
C) Creating an application platform that accepts QML scripting for
part of the UI or data. QML is a great language for your usecase, but
you only want 3rd party scripts to render graphics within their little
box and call application specific functionality. You do not want it to
create new windows, you do not want it to have access to the command
line arguments, and you do not want to let it draw particles (because
that would really show up your UI ;) ). In this case this kind of API
would be exactly what you need in order to have a powerful embedded
scripting engine without endangering your app.

--
Alan Alpert