first part of the screenshot (next to public/the globe):
it’s quite simple.
You can control the API access here. In this case for public/none account bound api requests. You are also able to create user groups and assign user to these groups and then set dedicated ACLs for the groups you created.
So for your (first) screenshot:
“edit collection” => a none-user bound api request (without any access token) can modify the collection its self. So a unauthorized api request is able to alter the collection and for example add fields, rename fields, delete fields and so on…
“view entries” => for data within the collection only (not the collection its self): a none-user bound api request (without any access token) can VIEW/GET ANY ENTRIES of this collection without any restriction
“edit entries” => " " : a none-user bound api request (without any access token) can UPDATE ANY ENTRIES of this collection without any restriction
“create entreis” => guess it? ;D
I suggest you create a fresh new user group for a also fresh new user, grab the users API token and keep the public access completely denied (as it is in you screenshot).
If you then use a serverside language like PHP in order to fetch data from the API, your communication is half way safe if only PHP knows the api token.
second part of the screenshot (that one with the green “create”, blue “read” …):
these switches are used to modify the create, read, update and delete ACLs using PHP.
For exaple if you put this:
$context->options['fields'] = [
'title'=>false // disable the title field for the current ACL type
to the the code field appearing when you switch on “read”, a user logged into cockput won’t see the “title” field of the collection when he creates or edits an entry within the according collection.
You have to investigate the cockpit code in order to understand what you have to do here / what you even can do here.
This is some kind advanced but brings some major controlling to data flows.