QRZ address data in log files

If using QRZ PoLo exports all information to ADI file.

We got few feedbacks from our local log manager on this related to increasing log sizes (this I don’t see much a big problem as logs are still some ten kilobytes). This information then might be stored in commercial services such as Google, gmail etc. which is probably not good in terms of privacy, as this information might contain full addresses of hunters.

Could there be option to disable this export information when creating ADI files?

Do you mean the QTH field value?
If so, then this is not really an OPs address. It’s no more accurate than the gridsquare and is publicly available on the QRZ page anyway.
Are we talking about the same thing?
Alan

Yup, QTH-tag. Some of the lines contain full address on my logs but yes most of are just postal codes + cities. The NAME-tag is also filled with QRZ data. This info is not fully publicly available, you need to log in or use the API to get that information.

They both are a bit redundant / unnecessary information in most of the cases.

If it was an option - do you think everyone would turn it on?
If most people did not turn it on, then it would serve no real purpose, no?
Alan

It’s an interesting “dilemma” if you like.
You and I and everyone else on QRZ, are each in control of what information is retrieved from QRZ and subsequently stored and passed on from ours and our contacts’ logging activity.
If we wish to have that information remain obfuscated, then we go to our QRZ account and edit it to something we are happy yo have passed on and stored.
After that (which is in our control), the information so retrieved, passed on and stored by others in whatever medium it is disposed to, is totally out of our control. If not PoLo then some other logging platform or even paper storage system.
To have an option like this in a logging application to be likely used at random (at best) by users of the application and consider this a protective mechanism for my privacy seems a little bit of a leap to me. I’d rather remind people that they are always in control themselves of what QTH information they publicise by exercising their editing skills on the QRZ record.
And I think that being a HAM for even a little while, you are already aware of the control you have over this information.
Alan
just my 2c on the topic.

A very good question. Probably answer is no.

But let me have a question for you: if this information export would be an option to turn on, would anyone turn it on?

My point is that this is unecessary information and steps a bit on privacy side too, still.

I know that QRZ information can be edited but how many of those who’s data have been exported from QRZ to logfiles would like it, allow it or … how many do actually know about that you can get the data from QRZ? Some, but not all for sure.

And also, in what cases this information is useful in? If needed, this information can be later fetched from QRZ - and is more accurate at that time.

Very good discussion and thoughts!

This is a tricky question.

Contemporaneous QRZ info (meaning “captured at the time of the QSO”) might be more accurate than a later update, for example. People move, callsigns get reassigned, etc.

I don’t believe PoLo is grabbing full addresses from QRZ.com, unless the user entered that on the City field, for example. We limit it to name, grid, city, and state.

But like you’ve pointed out, the whole world of Amateur Radio logging is a privacy minefield. And maybe giving the user the option to not include any of this in ADIF exports can give you a tool to control how your own data processing impacts others’ privacy.

Now, the question is, would you make this a setting to discard names and addresses when exporting? or to discard them even from PoLo’s internal storage? When using these settings, would you still use QRZ.com for lookups during operations?

Inside PoLo and inside cache is just fine, I think.

Maybe add checkbox to the export “include QRZ names and addresses in the log” and leave by default to off. Easy to tick on if needed - it’s still a bit hazy for me why we would need names/addresses in the all log files.

I always pull my log into HRD on my desktop. I did the same when I used Log4OM.
Having the names there already saves another operation of importing details for all my QSOs once they are imported into my logging desktop. Which is possible but would just add another (unnecessary) process to my workflow.

I have many tens of thousands of QSOs in my desktop. They all have names and details as per auto lookup which both HRD and Log4OM and many other similar apps do by automation after you enter the callsign.

So if these details were missing, I would add them anyway.
Whatever info is there is accurate at the time of the QSO.
Alan

I look at it this way. Is anything really private? Especially when it comes to ham radio? I tend not to sweat the small stuff.

1 Like

This might vary from country to country, but for example in Finland HAM hobby is pretty private. All radioamateur information are private. It’s a bit slippery slope argument and I have heard before “your QSOs are basically public so the rest of is”. It is not.

Today’s problems with PoLo:

  • my friend was activating: same problem continued - wrong calls were shown on screen. This might have something to do with that he didn’t have network connection so PoLo probably resolved the names incorrectly from memory. Newest PoLo version.
  • me: I signed off from QRZ and used local call+name file. Result: my exported log contains the QRZ information for all calls. So it has resolved these from it’s cache without even using QRZ. The log window did NOT show QRZ based information at all while I was logging.

So the bug is still there and also I think there is now new issue: data is written to log which was not logged (resolving name+address from offline cache).

When you say “data written to the log that was not logged”, how do you see this being different when the data comes from a QRZ lookup online, vs when looking at past log data? (ignoring the fact that the previous bug might have caused the log to have incorrect data)

Do you mean you had a Call Notes file with names in it? Or loaded a historical ADIF data?

With “data that was not logged” I mean, PoLo inserted the addresses+names from the cache - a data that was not any part of the actual logging (=not visible during the logging). Does it matter? No, but it was a bit strange to find the addresses in the ADI file even I had disabled QRZ integration (for a reason).

Sorry, a bit vague term. Yes, I mean Call Notes - I created a file for myself which contains the common hunter callsigns + first names. This data was not exported to the ADI file. Callsigns+names worked fine during the activation because of using only Call Notes file and not QRZ.

I think the caching of QRZ data is a key player here - my friend had the original bug in newest version and I think it appeared because he didn’t have network connection available. PoLo perhaps looks up the callsign too early from local cache - before the full callsign has been typed in fully and uses the first “match” rather than the full callsign.