# Reassessing function types and visibility **URL:** \ **Category:** Aztec\ **Created:** [March 7, 2024, 2:25pm UTC](https://forum.aztec.network/t/reassessing-function-types-and-visibility/4885 "2024-03-07T14:25:14Z")\ **Posts on this page:** 1\ **Showing post:** 12
**Author:** ![spalladino](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.aztec.network/spalladino/32/32_2.png) [@spalladino](https://forum.aztec.network/u/spalladino)\ **Post date:** [March 8, 2024, 6:51pm UTC](https://forum.aztec.network/t/reassessing-function-types-and-visibility/4885/12 "2024-03-08T18:51:46Z")
> [@Mike](#): > > I have concerns that it could lead to the called contract leaking its private data to the calling contract. To be fair, we’ll already need to have some sort of authorization for the _dapp_ who’s making these “offchain” calls. So we could simply extend this permission to all txs initiated by the dapp, so if a contract in a tx calls an unconstrained function in another one, we have the PXE apply the same permission rule as if it had been the dapp making the query. Still, this doesn’t work on every case. If the dapp initiates a tx, and the tx ends up calling an unconstrained function in a contract unexpected by the dapp (which may happen, yay composability), we need to accommodate for that. I get the impression that, from a UX perspective, this can be tackled using the [simulating simulations](https://forum.aztec.network/t/simulating-simulations/2218) approach: we make an initial simulated run of the tx, we show the user a dialog explaining 1) what permissions is the tx requiring and 2) what stuff is the tx accessing, and only then we execute and return control to the calling dapp. But we’re getting derailed. I’d suggest we try picking a name for “offchain” functions that is **not** offchain, so we can name it independently of this decision. I don’t have good proposal though. --- _[View the full topic](https://forum.aztec.network/t/reassessing-function-types-and-visibility/4885)._