What are the options for a dapp on the IC that needs to conform to the OFAC list (Office of Foreign Assets Control’s list of individuals, entities, and organizations that are subject to sanctions imposed by the U.S. government)?
If a dapp needs to block users from these countries, how should it go about that? Are there specific subnets that should be used, or boundary node affinity that can be specific, or some other approach that’s supported by IC infrastructure?
This seems like a pretty big and necessary thing, so I’d hope to see some native support for this on the IC.
Thanks in advance, anyone who’s in the know and willing to share their knowledge
I have seen your post, was thinking about it and completely forgot to reply. Sorry! Also, I don’t have a good answer, but just some thoughts on the topic:
Blocking at the boundary nodes/HTTP gateway
The boundary nodes currently do not allow a way for dapp developers to block access from certain geographies. We do block access based on the code of conduct, but that is mostly to protect ic0.app/icp0.io.
However, I don’t think the boundary nodes or the HTTP gateways in the decentralized architecture are the right place to block access. The API endpoints are all open and anyone is able to spin up another HTTP gateway without any restrictions. At the moment, a dapp developer has no way of specifying through which HTTP gateways, their dapp should be served. Hence, a dapp developer would have to make sure that each HTTP gateway is blocking access.
Hence, I think the blocking should happen at the dapp-level and not at the boundary nodes/HTTP gateways.
Blocking at the dapp level
If a dapp needs to block users from these countries, how should it go about that?
To me, it is not clear what “blocking” means: Do they have to be completely blocked from even loading the dapp or is it enough to prevent these users from making a “transaction” (e.g., participating in an airdrop).
For the SNS framework some restrictions for the swap participation had to be implemented.
Back then, the boundary nodes were also part of the discussions, but in the end, the chosen solution is independent of the boundary nodes.
That’s all for now @Lorimer do you have any thoughts on that and do you have a particular use-case in mind?
Thanks @rbirkner, that’s really helpful info. I think blocking at the dapp level makes sense. The restriction for SNS swap participation is also interesting. Does support for this restriction extend beyond the swap period? i.e. assume an SNS has now launched, the restriction was applied during the swap, but do the built in SNS canisters provide a convenient way for the SNS dapp to block/restrict the same users that would have been blocked during the SNS swap, or is this something that each SNS dapp would need to implement themself?
Are you able to shed some light on this topic?