The general form for scp when you're copying locally to remote is:
scp localfile username@remotehost:/some/remote/directory
In this case, you're telling scp you want to login as
username on the remote system, and that's the username the write will ocurr with. Most likely in your example, you used userB when you were scp'ing the file to computer B.
If you were copying a remote file to a localhost, e.g.:
scp username@remotehost:/some/remote/file /some/local/directory
In this case, you login as
username to the remote system, and then write it locally as the user you're running the scp command as. This example will copy the file from the remotehost to the system you're running on, as the user you're currently logged in as (since the write will be performed by the currently logged in user). This will not affect anything on the remotehost, as you're only reading the file from there, and copying it to the localhost. Since you're able to read the remote file, the local file has to have write permissions for you, as you're writing the file locally.
Put another way - the owner of the file will generally match the writer of the file. So, if you're logged in as userA, and write a file, the owner will be userA. A simpler example might be something like this:
user@server:~$ ls -l /var/log/syslog
-rw-r----- 1 syslog adm 6615 Apr 9 17:09 /var/log/syslog
Note that this file is owned by syslog but that it's readable by anyone in the adm group, which user happens to belong to. Then if we copy the file to user's home directory (~/):
user@server:~$ cp /var/log/syslog ~/
user@server:~$ ls -l ./syslog
-rw-r----- 1 user user 6615 Apr 9 17:10 ./syslog
Note that the copied version of the file is now owned by
scp is doing the same thing, except the source or destination may involve logging in as a different user to a different system.
Note that permissions are tracked with the user id, a numeric represenation of the user. You can see your current UID with the
id command. In general, for individual systems, UIDs will not be the same system to system as the accounts are not shared (unless you're using LDAP or similar). I believe that traditionally, 0 is root, UIDs less than 1000 are reserved for system accounts (e.g. mail, news, bin, daemon, etc), and that regular users start at 1000. As far as I know, regular user UIDs are assigned sequentially, so if you created three accounts, they would likely be 1000, 1001, and 1002.
Back to your original question of how to send a read-only file, you have to ensure that the reader on the remote system does not have the same UID as the owner of the file. i.e. if you (userA) were preparing a file for userB, you could do something like:
scp localfile userA@remotehost:/some/remote/directory
In this case, the owner of the file will end up being userA, (and we know userA exists on the remote system as that's who we're logged in as), and userB would not have write permissions (assuming the file was originally 755). Edit: you may need a -p to preserve the permissions?
Of course, if userB has root or sudo permissions, they'll be able to make the file writeable no matter what you do.