<div dir="ltr">Hi Rosa<div><br></div><div>Thanks for this. Indeed, Lova and I are already thinking along these lines with adding various tags for security, maintainership, compliance and adding LLM declarations (e.g. completely vibe coded, vibe coded with human review, ai completion assisted, no LLM used).  Probably better we also use explicit terminology (LLM vs AI).  Then you are also raising another issue which is upstream services used (and whether they are used with permission, if I understand you right). I'm CC'ing in Lova who is our miracle worker on the backend.</div><div><br></div><div>Regards</div><div><br></div><div>Tim</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Jun 17, 2026 at 3:10 PM Régis Haubourg via QGIS-PSC <<a href="mailto:qgis-psc@lists.osgeo.org">qgis-psc@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Rosa, thanks a lot for raising this issue.<br>
<br>
I agree that such plugins can be an issue with data privacy and probably <br>
security.<br>
<br>
I had a look at how Mozilla handles extensions [0] and I agree that we <br>
should aim toward more explicit consent and authorization model.<br>
<br>
Generally speaking, I think we should embrass privacy statements for our <br>
plugin repository. All data collection should be opt-in, so <br>
qgis-geo-knowledge-ai would then be not conformed with its default <br>
permissions.<br>
Ideally a permission system should block a plugin sending data without <br>
explicit permissions.<br>
<br>
Any other thoughts?<br>
<br>
[0] <br>
<a href="https://extensionworkshop.com/documentation/publish/add-on-policies/#data-collection-and-transmission-disclosure-and-control" rel="noreferrer" target="_blank">https://extensionworkshop.com/documentation/publish/add-on-policies/#data-collection-and-transmission-disclosure-and-control</a><br>
<br>
Best regards,<br>
<br>
Régis Haubourg<br>
Elected member at the Program Steering Comitee of QGIS.org.<br>
<br>
<br>
Best regards,<br>
<br>
Régis Haubourg<br>
Elected member at the Program Steering Comitee of QGIS.org.<br>
-<br>
<br>
On 17/06/2026 09:08, Aguilar Bolivar, Rosa (UT-ITC) via QGIS-PSC wrote:<br>
><br>
> Dear PSC,<br>
><br>
> First, I would like to express my appreciation for the continuous <br>
> efforts invested in maintaining QGIS as a reliable and high-quality <br>
> platform.<br>
><br>
> I would like to draw your attention to the growing presence of <br>
> AI-related plugins within the QGIS ecosystem.<br>
><br>
> In my view, it is essential to ensure transparency for end users <br>
> regarding which large language models (LLMs) are being utilized, as <br>
> well as how user data may be processed, transmitted, or stored.<br>
><br>
> As a specific example, I recently reviewed the Geo Knowledge AI plugin <br>
> (<a href="https://github.com/robert6757/qgis-geo-knowledge-ai" rel="noreferrer" target="_blank">https://github.com/robert6757/qgis-geo-knowledge-ai</a>) and observed <br>
> that no API key is required for its operation. Upon further inspection <br>
> of the code, it appears that requests are routed to a remote server <br>
> (as indicated in: <br>
> <a href="https://github.com/robert6757/qgis-geo-knowledge-ai/blob/main/global_defs.py" rel="noreferrer" target="_blank">https://github.com/robert6757/qgis-geo-knowledge-ai/blob/main/global_defs.py</a>).<br>
><br>
> While I am not certain of the best mechanism to address this, one <br>
> potential approach could be the introduction of a developer <br>
> declaration or compliance option (e.g., a checkbox or metadata field). <br>
> This could require plugin developers to explicitly disclose key <br>
> aspects such as the underlying AI model in use and the nature of any <br>
> data collection, transmission, or processing. Such measures would <br>
> enhance transparency and support users in making informed decisions.<br>
><br>
> Best regards,<br>
><br>
> Rosa<br>
><br>
><br>
_______________________________________________<br>
QGIS-PSC mailing list<br>
<a href="mailto:QGIS-PSC@lists.osgeo.org" target="_blank">QGIS-PSC@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><img src="https://ci3.googleusercontent.com/mail-sig/AIorK4w8P1tDzlLwlGFBARg1twcOLqcDfLRRv0hL-5nevML2byVSSmdSsh4pgh_BfPNUz45fy3dnFtgaQ_e7KqXxIlo2cipZeq_NMk8nRW1JxYWA2zo"><br><div><br></div><div><br></div><div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><b>Tim Sutton</b></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">QGIS Project Steering Committee</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><a href="mailto:tim@qgis.org" target="_blank">tim@qgis.org</a></div></div></div></div>