User Tools

Site Tools


blog:2019-09-07:monitoring_winlink_messages

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision
Previous revision
blog:2019-09-07:monitoring_winlink_messages [2019/09/07 23:10] – created ve7hzfblog:2019-09-07:monitoring_winlink_messages [2021/06/06 10:31] (current) va7fi
Line 1: Line 1:
-====== Monitoring Winlink Messages ====== +====== Monitoring Winlink Traffic (UPDATE) ====== 
-To over simplify things a bit, there's a debate right now about Winlink with respect to our inability to monitor traffic between other parties.  While you can see some information in the clear like the callsigns involved and the subject line of messagesthe body of the message is gibberish compressed mess.  The petition to the FCC asks in part that it "should require all digital codes to use protocols that 'can be monitored in entirety by third parties with freely available, open-source software.'"(([[https://spectrum.ieee.org/tech-talk/telecom/wireless/is-ham-radio-a-hobby-a-utilityor-both-a-battle-over-spectrum-heats-up |Is Ham Radio a Hobby, a Utility... or Both? A Battle Over Spectrum Heats Up]])) + 
 +See [[#Oct_17_Update |update below]]. 
 + 
 +To over simplify things a bit, there's a debate right now about Winlink with respect to our inability to monitor traffic between other parties.((See: this [[https://spectrum.ieee.org/tech-talk/telecom/wireless/is-ham-radio-a-hobby-a-utilityor-both-a-battle-over-spectrum-heats-up |IEEE Spectrum post]]))  When someone sends you a message over the air, you receive it in your inbox, but other hams watching the exchange will only be able to see the callsigns involvedthe subject line, and a few other things.  The body of the message, though, will appear to them as a compressed mess of gibberish. 
 + 
 +Winlink has a document that: 
 +<QUOTE>[C]larifies details of implementation of the B2F protocol so that Winlink stations' compliance with US FCC rules is clear. Using technical information here will allow an individual with development skills to create programs to clearly monitor intercepted on-air transmissions.(([[https://winlink.org/B2F |Open B2F -- Winlink Message Structure and B2 Forwarding Protocol]], February, 2018))</QUOTE> 
 + 
 +Interestingly, Winlink's position is that only individual with "development skills" should be able to do this.  They also have an online [[https://winlink.org/content/us_amateur_radio_message_viewer |Message Viewer]] but it only works for US callsigns, and it's not really what the debate is about anyways.  And so, the petition to the FCC asks in part that
 + 
 +<QUOTE>The FCC should require all digital codes to use protocols that 'can be monitored in entirety by third parties with freely available, open-source software.'(([[https://spectrum.ieee.org/tech-talk/telecom/wireless/is-ham-radio-a-hobby-a-utilityor-both-a-battle-over-spectrum-heats-up |Is Ham Radio a Hobby, a Utility... or Both? A Battle Over Spectrum Heats Up]], July 8, 2019))</QUOTE> 
 + 
 +That sounds very reasonable.  In principle, you can imagine that if a program like Winlink can easily decompress a message for one recipient, it could just as easily decompress all the messages it hears.  It would simply be a matter of managing these messages in a way that is easy for the user to filter what is theirs and what isn't. 
 + 
 +Well, it seems that there's been some progress in decoding over-the-air messages recently: 
 + 
 +<QUOTE>This is a reasonable step forward as proof of concept. [...] I hope to further the work to yield a functioning monitoring tool for those with interest in monitoring the Winlink system. [...] It’s clear to me this capability will be warmly received by all parties in the debate [...] 
 + 
 +The Winlink monitorability nut is cracked. Privacy on radio Winlink no longer exists... and that’s a very good thing for all parties.(({{https://ecfsapi.fcc.gov/file/108140794324824/KX4O_Demonstration_OTA_Decoding_Addendum.pdf |Re: Addendum to previous exhibit1 demonstrating off the air (OTA) monitoring of a Winlink email exchange}}, August 13, 2019))</QUOTE> 
 + 
 +It's pretty cool that someone managed to reverse engineer the compression algorithm and packetization scheme, but again, I think Winlink should be forced to offer this feature in their program so that everyone can monitor every winlink message they can hear on the air.((This is my personal option and doesn't represent the Club's view  --- //[[ve7hzf@rbox.me|Patrick, VE7HZF]] 2019/09/07 23:22//)) 
 + 
 +Check out [[https://forums.qrz.com/index.php?threads/decode-off-the-air-winlink-message-request-for-programming-help.668470/page-10 |this thread]] to follow the ongoing development. 
 + 
 +===== Oct 17 Update ===== 
 + 
 +From [[https://qrznow.com/pactor-developer-scs-announces-monitoring-software/ |qrznow.com]]: 
 + 
 +<QUOTE>SCS, the company that created PACTOR, has [[https://www.p4dragon.com/en/PMON.html |unveiled software]] that offers the ability to monitor the content of PACTOR 1, 2, and 3 transmissions over the air. The free PMON software runs under the Linux operating system. A software version to monitor PACTOR 4 is scheduled to become available next year. 
 + 
 +[...] 
 + 
 +According to SCS, only minimal hardware is required to use PMON. The equipment complement includes a Raspberry Pi 3 Model B+ (minimum) computer and a USB sound device. [...] The German company says PMON now makes this possible without a modem and adds the ability to decode B2F/LZHUF-compressed messages -- Winlink email and others.</QUOTE> 
 + 
 +Again, my personal view is that it's pretty cool that third parties are finally addressing this issue, but Winlink should be forced to offer this feature in their program so that everyone can monitor every winlink message they can hear on the air right out of the box.  --- //[[ve7hzf@rbox.me|Patrick, VE7HZF]] 2019/10/17 07:23//
  
blog/2019-09-07/monitoring_winlink_messages.1567923010.txt.gz · Last modified: 2019/09/07 23:10 by ve7hzf