Implement a tool to query ORAssistant

[palaniappan-r]

Implemented the askbot and set_bothost commands under the ora tool. They can be used to make queries to ORAssistant, a LLM based conversational assistant for OpenROAD

askbot

This command takes an argument and passes it as a query to the hosted ORAssistant backend, by making a POST request using the libcurl library.

ora_init

The ora_init command sets up user consent for using the ORAssistant and configures the host URL (if a local version is preferred).

[rovinski]

Why can't this run locally as an add-on rather than sending requests over the internet?

[palaniappan-r]

Why can't this run locally as an add-on rather than sending requests over the internet?

If the user chooses to the application locally, they'll have to follow instructions on ORAssistant's README, spin the backend server up, and use the set_bothost command to have the askbot command query the local server instead.

Currently, askbot queries a hosted version of ORAssistant by default, but I can change this if necessary.

[rovinski]

Is there a data control plan or disclaimer if users are sending data over the internet? GDPR may even come into play here.

[palaniappan-r]

Is there a data control plan or disclaimer if users are sending data over the internet? GDPR may even come into play here.

The only data being transmitted over the internet is the query entered by the user.

Currently, there is no formal disclaimer in place. I could draft a suitable disclaimer to address this and ensure compliance with relevant regulations such as GDPR.

[luarss]

@palaniappan-r no further comments from me, pending @maliberty and @vvbandeira review.

[luarss]

On second thought, I think we need to mark this as draft because the permalink is not available. I will discuss more with @dralabeing and @vvbandeira.

[rovinski]

The request for consent is a bit better than the state before, but there are still a few things I would want to see change:

1. Default to a locally hosted copy first, or at least explicitly ask the user if it's okay to use the web-hosted version
2. Make it explicit that only the data the user types will be sent outside the application, no other user or design data.
3. Point to directions on how to set up a locally hosted copy on first use
4. Don't require consent for anything other than the web-hosted copy (not only because it's not needed, but because safety guarantees can't be provided)
5. There needs to be some kind of versioning for the consent. If there were to be a new version in the future which has a different kind of privacy policy, then you can't rely on an old consent file with a new version of OpenROAD.

[palaniappan-r]

The request for consent is a bit better than the state before, but there are still a few things I would want to see change:

1. Default to a locally hosted copy first, or at least explicitly ask the user if it's okay to use the web-hosted version

2. Make it explicit that only the data the user types will be sent outside the application, no other user or design data.

3. Point to directions on how to set up a locally hosted copy on first use

4. Don't require consent for anything other than the web-hosted copy (not only because it's not needed, but because safety guarantees can't be provided)

5. There needs to be some kind of versioning for the consent. If there were to be a new version in the future which has a different kind of privacy policy, then you can't rely on an old consent file with a new version of OpenROAD.

The askbot command now requires a (y/n) consent, where y is for the web-hosted version and n is for the locally hosted version. Both the consent and the local host URL can be configured using the ora_init command.

[rovinski]

That doesn't really make sense - it shouldn't need to ask for consent if not connecting to the OpenROAD web-hosted version. It could be connected to another web-hosted version, in which case, it shouldn't display the message. Not only because the user wouldn't need to consent, but also the other web-hosted version may not have a privacy policy and so the consent message shouldn't claim so.

What about the other concerns?

[palaniappan-r]

That doesn't really make sense - it shouldn't need to ask for consent if not connecting to the OpenROAD web-hosted version. It could be connected to another web-hosted version, in which case, it shouldn't display the message. Not only because the user wouldn't need to consent, but also the other web-hosted version may not have a privacy policy and so the consent message shouldn't claim so.

What about the other concerns?

When the askbot command is run for the first time, it displays instructions pointing to a setting up a local version. It then checks if a local url has been provided, subsequent pointing to the ora_init command to configure this. If my earlier comment wasn't clear, only this message is displayed for askbot's first use, not the consent message.

As for the consent management, it is being handed with the ora_init command, with y required for using the official web hosted version (the consent message is only displayed for this). The same command is used to connect the app to a local version. This currently requires the consent to be explicitly set to n, but I can make this automatic if need be.

I've explicitly mentioned that only the data typed-in will be sent outside the application in the consent message as well. I hope this clears your concerns, please let know if there's anything else to be addressed.

[rovinski]

Ok thanks, that's much clearer. I don't think using a local copy should require consent to be set to "n". If a user wants to switch between web and local they should be able to without having to constantly grant and revoke consent.

My only other concern would be a version number for the consent to make sure that in the future if the requirements ever change, the user can be reprompted. Something like

version=1
consent=y

then if version 2 comes along which requires different permissions, the user will need to re-consent.

[palaniappan-r]

Ok thanks, that's much clearer. I don't think using a local copy should require consent to be set to "n". If a user wants to switch between web and local they should be able to without having to constantly grant and revoke consent.

My only other concern would be a version number for the consent to make sure that in the future if the requirements ever change, the user can be reprompted. Something like

version=1
consent=y

then if version 2 comes along which requires different permissions, the user will need to re-consent.

I've updated the consent management system to track the version for which consent was provided. If the version changes, the user will need to provide consent again.

Users can now switch between the local and cloud versions without needing to provide or revoke consent. To use the cloud version, running ora_init cloud y grants consent and tracks the version. For the local version, running ora_init local hostUrl will do, with no need to revoke consent, if it was previously provided.

Please let me know if any further modifications are needed.