An historic vote is taking place in 24 hours at the ARRL Board meeting- Some directors want to expand effectively encrypted email into all of the HF RTTY/CW subbands, and don't want to admit the need for open, transparent "over the air" data in ham radio. Please spread the word today, and let ARRL directors know tonight about the confessions below, and that you don't want additional wideband encrypted email in ham radio. ARRL directors emails are found here:http://www.wirelessgirl.net/ARRL_officers.html The use of ARQ and Proprietary compression and FEC together make it virtually impossible for hams to intercept the over the air signals for meaning. This is a violation of Part 97.113(a)4 and enables many more violations, Including illegal 3rd party messages from "non-hams to hams" and vice versa. This is not just about Pactor 4, it's about *any* mode that cannot be intercepted for meaning. AMBE and Fusion are easily decoded using an available chip, Winlink data modes cannot be intercepted for meaning over the air. Period. Even given what they have published and claim is documented. Read this to learn more, and see how even if a compression scheme is fully publicly known, the use of ARQ with FEC and compression provides an illegal "security by obscurity". It's like knowing how a "zip file" works is public, but missing just one bit makes it impossible to open the zip file for a 3rd party observer, while the lone secret recipient has the knowledge of that one missing bit, and recovers the secret file. That's how Winlink data transmissions work in ham radio. See this confession, and let all of Hamdom and ARRL board members know about this. Here's the entire email thread of Winlink programmers and users discussing "getting around FCC rules," and how hard it is to decode for meaning ARQ with compression, minus the re-quoted messages. See how Winlink ARSFI board member Tom Whiteside wants to change the topic and End the Thread! Is this what we want for ham radio? Is this an open use of the spectrum? Let your ARRL board members and the FCC ECFS today know that you support RM-11831 and the requiment of only open, transparent data for over the air copy, and urge rejection of WT 16-239. “Security by obscurity” is mentioned here. These are emails from yahoo groups in 2016. Spread rhe word--hams need to see this confession and inform ARRL board members and the FCC about such this activity in ham radio. 73, ted N9NB > Subject: > [Winlink_Programs_Group] Digest Number 2817 > Date: > 5 Sep 2016 02:29:46 -0000 > From: > Winlink_Programs_Group@yahoogroups.com > Reply-To: > No Reply > To: > Winlink_Programs_Group@yahoogroups.com > > > > 3 > Monitoring WINMOR traffic? > Sun Sep 4, 2016 11:31 am (PDT) . Posted by: > steve_k6eta > Is there a way to directly monitor/decode WINMOR traffic heard on the air? Can a terminal or chat program connect to 127.0.0.1 port 8500 on a machine running an instance of the WINMOR TNC similar to the ARDOP Chat situation? > > Thanks, > Steve K6ETA > > 2a > Re: Monitoring WINMOR traffic? > Tue Sep 6, 2016 9:56 am (PDT) . Posted by: > steve_k6eta > I hear crickets chirping... heh. > > I would presume we get around the §97.113 (4) edict to that prohibits "messages encoded for the purpose of obscuring their meaning" by allowing a sysop to monitor his/her relayed traffic? > > It would be nice to provide a way to allow the larger amateur community to decode and monitor WINMOR transmissions. I imagine this opens up a can of worms with PACTOR, but at least anyone who wants to spend big $$$ on a PACTOR modem should be able to monitor?? > > Aside from wishing to monitor other WINMOR traffic to better understand propagation and QTH of stations, it would also be nice to assure that the system isn't being used for prohibited transmissions (information for pecuniary interest, re-transmission of programs, etc.) > > I suppose it could be argued that §97.219 (b) covers the potential abuses and lays all of the enforcement responsibilities on the shoulders of the sysop. If would be nice, however, if other stations could help in this regard by providing a way for wider monitoring... just a thought. > Reply to sender . Reply to group . Reply via Web Post . All Messages (5) . Top ^ > > > > 2b Re: Monitoring WINMOR traffic? > Tue Sep 6, 2016 11:24 am (PDT) . Posted by: > "Hal" hal_merritt > 97.113 (4) does not apply since there is nothing being encoded for the > purpose of obscuring meaning. The encoding is for the purposes of speed and > accuracy. And possibly for testing purposes. > > The ways to monitor PACTOR traffic involve licensed technology. If you want > to use the technology, then you must pay for it. Nothing illegal there. > Anyone who wants to monitor WINMOR / ARDOP is free to write the software. > The waveform specs are published. That said, *I think* that the terms of > the WINMOR license prohibit commercial use, so no one can build and sell a > decoding device/software. They would have to give it away or at least share > the proceeds. I think. > > SYSOPs can monitor all the traffic if they wish, and many do. > > hal kd5hw > > 2c Re: Monitoring WINMOR traffic? > Tue Sep 6, 2016 1:30 pm (PDT) . Posted by: > la7um > As I see it, this is based on the principle of F6FBB which was used in packet radio BBSs from the 80/90ies. Compression for the sake of speed and accuracy, protocoll published, and sysops could read all. > 73 de LA7UM Finn > > 2d Re: Monitoring WINMOR traffic? > Tue Sep 6, 2016 6:51 pm (PDT) . Posted by: > "Matthew Pitts" daywalker_blade_2004 > Finn, > > Yes, F6FBB was involved with the development, but you can't get certain folks in the US outside of Winlink to understand that the data compression used by Winlink is the same as what's used by pretty much every packet BBS out there because they do not want to believe anything of the sort. Just like they refuse to accept that a majority of whatever interference they experience is simply a matter of the infamous "hidden transmitter effect" where one side of a QSO can be heard and triggers the busy channel detection, but when the other station transmits, the ACDS station thinks the channel is clear and transmits in reply to a connect request. > > Matthew Pitts > N8OHU > > 1a Re: Monitoring WINMOR traffic? > Wed Sep 7, 2016 2:49 am (PDT) . Posted by: > daveskolnick > > ---In Winlink_Programs_Group@yahoogroups.com, wrote : > > > I would presume we get around the §97.113 (4) edict that prohibits "messages > > encoded for the purpose of obscuring their meaning" by allowing a sysop to > > monitor his/her relayed traffic? > > It doesn't apply so we aren't getting around anything. > > > It would be nice to provide a way to allow the larger amateur community to > > decode and monitor WINMOR transmissions. > > Other commenters have missed an important point. The protocol retransmits packets not received by the intended receiver. There is no guarantee that a monitor will get all the packets. That makes reassembly of the entire message problematic. A monitor can get most of the message but may well not get all of it. This is the case with any ARQ protocol including PACTOR and packet. > > 73 es sail fast de dave KO4MI > S/V Auspicious > > > 1b Re: Monitoring WINMOR traffic? > Wed Sep 7, 2016 5:11 am (PDT) . Posted by: > "Christopher Story" radionerds > All, > > I've kinda held back on this one as I'm new to the forum, but I think I can > contribute here.. > > I've written many parsers for networking and application protocols for > capture applications like wireshark. In a few cases there were lots of > pushback on doing so because it was felt that the complexity of the > protocol, sequences, structure and compression contributed to its security > (security by obscurity) even though it was fully documented. > > What we have are people who want to "see all" without having to do a > protocol analysis. They want someone else to do the heavy lifting and make > it easy. > > Part 97 says nothing about easy, just that the meaning isn't intentionally > being encrypted. > > Additionally it also doesn't say that it needs to be "readable" by all > hams, really that it just needs to be readable by the fcc. If the fcc > wanted to monitor winmor they can do so, it's documented > > Chris > K6RWJ > > 1c Re: Monitoring WINMOR traffic? > Wed Sep 7, 2016 8:51 am (PDT) . Posted by: > "W6IDS" w6ids2003 > AHHH! Some fresh air. . . . .. thank you Sir. > > Howard W6IDS > Richmond, IN > > 2 Re: Monitoring WINMOR traffic? END OF THREAD please > Wed Sep 7, 2016 5:30 am (PDT) . Posted by: > "Tom Whiteside" n5tw > Thanks for the comments on this but let’s move on to other topics. END OF THREAD. > > Tom N5TW > > 2a Re: Monitoring WINMOR traffic? > Sat Sep 10, 2016 10:23 pm (PDT) . Posted by: > steve_k6eta > Thanks and understood. > > OK, so if we read Part 97 to mean that the FCC, not all hams and SWL stations, should be able to monitor the traffic, I can see how the burden is lifted for encoding software (binary, PACTOR, WINMOR, etc) to provide a general means for monitoring. It's published and the FCC could monitor if they wish. I agree with this logic. > > So then my request becomes something more like, "gee, it sure would be nice to have someone write software that could be used to monitor such traffic..." and again, I agree that is simply a request thrown out there. > > But what I hope is obvious is that this isn't just a personal request for the convenience of just a one or a few stations. Hopefully everyone can see how this would benefit the quality and security of our allocated band spectra in an era where the FCC is scaling back on enforcement? > > Thanks everyone, > Steve K6ETA > > > 1a > Re: Monitoring WINMOR traffic? > Sun Sep 11, 2016 1:14 am (PDT) . Posted by: > "Rick Muething" kn6kb > Steve (K6ETA), > > The problem of monitoring ARQ transmissions is a technical one...not > just software. If two stations are connected in an ARQ session > forwarding messages each has the ability to request a repeat of a data > frame (through the ARQ mechanism) until it gets a proper frame decode. > This is the basic mechanism that all ARQ systems (and BBSs that use ARQ) > work. It applies to Pactor, WINMOR, the new ARDOP in development etc. > > Also Winlink and other BBS systems often use binary encoded compression. > This takes a simple text message (or attached text or other file) and > compressed it (something like ZIP) for transmission. This can save > typically 50% on text messages and more (or less) on other file types. > But if just one byte of the compressed message is not received correctly > it is impossible (well at least VERY difficult) to decompress the > message and get the original text or compressed files. A station > monitoring such a transmission would have to receive EVERY ARQ frame > perfectly without being able to request a repeat from the sending > station. (ARQ occurs only between the TWO connected > stations...monitoring stations can't request a repeat) > > So while it is technically feasible to monitor and decode (there is no > encryption of the message ...that is illegal on ham frequencies) it is > extremely difficult to recover a message completely by just monitoring. > With a lot of work and fancy software it might be possible to recover > parts of a message that is compressed but that is not very practical and > would require some tricky software (decompression with missing data) to > get anything. > > Hope this clears things up a bit. > > 73, > Rick Muething, KN6KB Winlink developer and author of WINMOR and ARDOP > > > 3a Re: Monitoring WINMOR traffic? > Fri Oct 21, 2016 3:19 pm (PDT) . Posted by: > steve_k6eta > Hi Rick, > > Understood. As with any monitoring process, some info will certainly be lost due to condx. I wasn't hoping to reconstruct partially rx'd frames, just the ability to decode fully copied ones... > > Again, many thanks for your development efforts - I'm enjoying ARDOP Chat and can't wait to see ARDOP released on Winlink Express! My RMS will finally be 100% low-power once I can get rid of the Windows hogs! Even the Windows tablet I have for WINMOR (everything else is RPi) is a drag on my solar powered batteries... > > ARDOP is a godsend! > > -Steve K6ETA > > > 3b Re: Monitoring WINMOR traffic? > Fri Oct 21, 2016 3:54 pm (PDT) . Posted by: > "Christopher Story" radionerds > Rick is quite right regarding the difficulty is assembling error correcting > transmissions.. about 20 years ago i wrote a "man in the middle" monitoring > application for a proprietary data transfer protocol. > > It was difficult to say the least and we were using perfect capture files, > where data fidelity is 100% from the monitoring applications perspective. > > With an over the air protocol you have that plus transmission path issues. > > I shutter thinking about re-assembling that. > > Someone would need to open their checkbook with at least a 50% deposit to > start.. > > Chris STORY > K6RWJ > > 3c Re: Monitoring WINMOR traffic? > Fri Oct 21, 2016 6:50 pm (PDT) . Posted by: > "Matthew Pitts" daywalker_blade_2004 > Plus, with an ARQ protocol, you have to know or be able to figure out the actual data rate including any FEC, and operating bandwidth, on the fly while trying to decode it. Even having every aspect of it published it's not going to be an easy task. > Matthew PittsN8OHUCo-developer of ARDOP > > >>