The browser of the user who is loading the page and requesting the content is the literal client that's performing the action. It's also responsible for executing any client scripts, UI scripts, client-side UI actions, processing the UI policies and applying UI policy actions. This includes controlling whether fields are mandatory, read-only, or indeed visible at all.

This can seem like an effective means of protecting content; for example, by hiding a field if the user doesn't have the appropriate permissions, or even setting it as read-only using a client script or UI policy. However, it's important to realize that any client-side measures can be overridden by the user!

Anything which really needs to be secured so the user can't see or modify it should be secured using ACLs (security rules). Data policies are another option, and can be used as UI policies on the client as well. This way, data policies can back up their client-side component, making them more secure and effective. However, ACLs work client-side as well, and data policies cannot be scripted like ACLs can, so complex conditions are more difficult to implement.

As a general rule, you should use ACLs to secure tables and fields for specific roles, and use UI/data policies to secure them against specific conditions. For example, if only users with the ITIL role should be able to modify a given field, then you should use an ACL. However, if users should only be able to modify the State field when the Active field is set to true, then you might want to use a data policy.