The ID3 frames are entirely different than the iTunes generated atoms.

The 'Clear Private Information' action clears what could contain private information that has been mapped from the low level audio files. Yate is taking care of the mappings for you.

The Copyright and Copyright URL fields (ID3) typically will contain as the names suggest copyright information but nothing pointing directly to you.

A General Encapsulated Object can contain anything. (ID3 only...not iTunes). It's included in the action because it can contain anything. I've never seen one in the wild.

Identification can contain personal identification information that iTunes places into an m4a file completely outside of the tagging information. The tricky thing here is that it is outside the area that any tagger or audio player typically looks. Due to the nature of the information's location, Yate will never create this field.....so if there was no 'identification' information setting a value will do nothing.

Owner, is an ID3 field which can contain various ownership information including your name. Oddly enough, I've never seen it used in an mp3 file. Yate maps the m4a apID atom into Owner. In the past I've seen that iTunes places either your email address or name to this field. It seems that 'newer' purchases place the email in the field. It also seems as if they are now optionally placing your name into an ownr atom. In v3.7 Yate maps the ownr atom into the Owner field (along with the apID field if present). Clearing the Owner field in Yate will clear out both 'personal' atoms in the file (if they were present). Prior to v3.7, clearing the Owner field would not clear the ownr atom. I only found the atom recently in a new purchase.

Payment (ID3) could contain how much you've paid for the file but once again I've never seen it set (at least on purchased content).

Private Information is another ID3 field where anything can be placed. I've seen personal information embedded there in a few of my Amazon purchases although rarely.

Seller and Terms of Use (ID3) are typically benign as far as personal information goes.

COMR is an ID3 Commercial Information frame. Yate does not directly process this as it is a somewhat redundant frame which largely covers stuff available in other atoms. I've seen one or two in older mp3 files but they did not contain anything meaningful. However due to its name I figured what the heck....shoot it if present.

I have no idea what PINF is.

To summarize, to the best of my knowledge, running this action (in v3.7) will leave no atoms/frames with your name or email address in the file. Prior to v3.7 I am not mapping the m4a ownr atom. If the owner atom is not visible on the Unhandled editing panel, it's not in the file. It can be removed by a Clear Unhandled statement and this can be added to the action. ....and they could add new atoms at any time. As said I only recently found the ownr atom.

Update: v3.7 has been released and the action removes all private information as far as we know. Users who initially install on v3.7 will find the Clear Private information action in a Preloaded Action folder in the Action manager.

My brain must be deteriorating faster than I thought. 🙂

'pinf' is the node in the hierarchy under which we find the Identification and AAC Kind information. It is the out of bounds information I was talking about.

As for the script....

apid handled via the action.

atID is the iTunes artist-track ID which is labelled as such in the unhandled metadata. I don't consider this personal but you can always remove it via:
Clear Unhanded 'atID'

cnID iTunes catalog id. Not really private information. Can be removed by Clear Unhanded 'cnID'

geID iTunes genre id. Not really private information. Can be removed by Clear Unhanded 'geID'

plID iTunes playlist id. Not really private information. Can be removed by Clear Unhanded 'plID'

sfID iTunes store country code. Simply references which country it was purchased in. Can be removed by Clear Unhanded 'sfID'

cprt copyright. handled by the action.

flvr never heard of it. Can be removed by Clear Unhanded 'flvr'

purd purchase date. Not really private. I use Purchase Date in my tagging. Can be removed by adding Purchase Date to the Clear list.

ring Yate's Content Advisory field. A much asked for feature request. Can be removed by adding Content Advisory to the Clear List.

soul Sort Album field. Not sure why they include this???

stik iTunes media type which optionally gets mapped to Yate's Media Type field. Anther feature request. Can be removed by making sure the Audio-m4a option to map stif is off and by a Clear Unhanded 'stik'

xid mapps to a UDTI named 'iTunes Vendor xID'. It is a sort of 'label' field and mapping it was a feature request. Can be removed by a User Defined statement removing 'iTunes Vendor xID'.

I pretty much think that the script you linked to is over-wiping data but that's just a personal opinion. The Clear Personal Information action should do the trick. Most people are concerned with 'names' and 'email addresses'. As I don't know what 'flvr' is you could always add that to the action.

Most of the other atoms listed above provide simple metadata such as country, artist and label information. The type of stuff that people are typically looking for from Discogs and MusicBrainz.

If you add 'Unhanded' to the Clear list, all unhandled data will be removed.

After reading this fabulously detailed write-up, and looking at that shell script myself, I mostly agree. Everyone would have a different level of comfort. It's my personal opinion that plID, sfID, flvr (playlist id, what store it was purchased from, and whatever-it-is flvr) should each also be removed using "Clear Unhandled for Type". Personally I would also add Purchase Date to the "Clear" list.

I have made such a super-action which suits my level of comfort, but I can't see it would have any general purpose.

That's the way to go. The preloaded actions are simply samples. As I pointed out before, some of the stuff removed is benign. As an aside, I set purchase date on all my music as I frequently use the tag as an 'when acquired' field when searching for recent stuff.

Just for further clarity, note you did not use the phrase "out of bounds information" above. Please confirm that you are here stating (as I'm rather sure you are) that it is removed by the Clear function when "Identification" is a checked destination field (as it is by default in this action).

Yep, clearing Identification removes the portion of the out of bounds hierarchy that contains your personal information.

The confusion here does suggest the need to eventually document these destination fields.

All of the underlying locations of Yate's metadata is documented in the Frame Mapping Table which can be accessed under references on the main help page.

Also, what does any of this have to do with "AAC Kind Information" which presumably should be kept? Is that info then removed by this action or not?.

Nope AAC Kind is not removed unless you check it off. I was only mentioning it because it is also out of bounds data found in the pinf heirarchy.

But that's a "scorched earth" approach right? If you do that, the action would remove all the info you argue above could be useful and would be overkill to remove, correct?

Yes. I wouldn't do it. However I do know of people who do as they don't like anything in their files that they cannot easily see and manipulate.

Finally, what function(s) would you suggest would be the best way to log everything that was present in those fields/atoms before the script and after?

You don't have to write an action. You can do a Log>Text on the file before you do anything. Save the log file. Run your super-action. Do another Log>text (before or after you save). You should see that the fields are no longer present. Empty fields are not displayed.

Log could be made into a function. I'll put it on the stuff to think about list.

If you want to know differences before you save the files, Log>Changes is far more convenient. I wasn't sure if you wanted to verify that the files had changed as opposed to the in memory metadata.

All the log functions work on the loaded files. If you want to see stuff before and after a Save you have to do it the way I initially described. Once you Save, there will be no changes to log.