Is compression “encryption” under FCC regs?












4












$begingroup$


I read this question about digital signatures and FCC prohibitions on "obscuring" messages in amateur transmissions, and it cause me to think of something: the difference between encryption and compression is small.



If I send a file in compressed form via digital radio (say, a Mesh running on firmware-modified wifi routers, to support data rates that don't make this silly), the contents are easily decompressed by anyone who receives the file in error-free form (and most compression systems include redundant error correction codes to reduce the likelihood that the file will fail decompression) -- but without attempting decompression, there's no simple way to tell whether the file is encrypted within the compressed archive.



It would obviously be a no-no to send an encrypted archive by amateur radio, I think, but where is the line drawn? Does compression itself count as "obscuring" the contents?










share|improve this question











$endgroup$

















    4












    $begingroup$


    I read this question about digital signatures and FCC prohibitions on "obscuring" messages in amateur transmissions, and it cause me to think of something: the difference between encryption and compression is small.



    If I send a file in compressed form via digital radio (say, a Mesh running on firmware-modified wifi routers, to support data rates that don't make this silly), the contents are easily decompressed by anyone who receives the file in error-free form (and most compression systems include redundant error correction codes to reduce the likelihood that the file will fail decompression) -- but without attempting decompression, there's no simple way to tell whether the file is encrypted within the compressed archive.



    It would obviously be a no-no to send an encrypted archive by amateur radio, I think, but where is the line drawn? Does compression itself count as "obscuring" the contents?










    share|improve this question











    $endgroup$















      4












      4








      4


      1



      $begingroup$


      I read this question about digital signatures and FCC prohibitions on "obscuring" messages in amateur transmissions, and it cause me to think of something: the difference between encryption and compression is small.



      If I send a file in compressed form via digital radio (say, a Mesh running on firmware-modified wifi routers, to support data rates that don't make this silly), the contents are easily decompressed by anyone who receives the file in error-free form (and most compression systems include redundant error correction codes to reduce the likelihood that the file will fail decompression) -- but without attempting decompression, there's no simple way to tell whether the file is encrypted within the compressed archive.



      It would obviously be a no-no to send an encrypted archive by amateur radio, I think, but where is the line drawn? Does compression itself count as "obscuring" the contents?










      share|improve this question











      $endgroup$




      I read this question about digital signatures and FCC prohibitions on "obscuring" messages in amateur transmissions, and it cause me to think of something: the difference between encryption and compression is small.



      If I send a file in compressed form via digital radio (say, a Mesh running on firmware-modified wifi routers, to support data rates that don't make this silly), the contents are easily decompressed by anyone who receives the file in error-free form (and most compression systems include redundant error correction codes to reduce the likelihood that the file will fail decompression) -- but without attempting decompression, there's no simple way to tell whether the file is encrypted within the compressed archive.



      It would obviously be a no-no to send an encrypted archive by amateur radio, I think, but where is the line drawn? Does compression itself count as "obscuring" the contents?







      united-states legal digital-modes encryption






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Mar 11 at 18:50









      Kevin Reid AG6YO

      16.3k33170




      16.3k33170










      asked Mar 11 at 18:48









      Zeiss IkonZeiss Ikon

      625113




      625113






















          3 Answers
          3






          active

          oldest

          votes


















          4












          $begingroup$

          For governments around the world to continue to trust that amateur radio has no nefarious purpose, it is essential that everyone that wishes to, can "listen in" to any amateur radio communications. Anything that hints at eroding this capability will likely be struck down in time through regulation.



          To pass the FCC legal hurdle regarding obfuscation, it must first be evident that the purpose is not to obscure the message. Part of this test would likely be that the technique must accomplish some useful level of compression if that is really its purpose.



          The legal second test would likely be that can anyone readily decompress the message to return it to its clear text form. This must be very easily achievable due to broad publication or acceptance of the compression method.



          Both tests are important. For example, consider a symmetric encryption scheme using an industry standard and with the encryption key widely published on the web. This will possibly pass the second test but it would fail the first test because it doesn't actually compress the message in any real sense. It is also clear that the public standard is primarily for encryption (obscuring) and not compression (reducing).



          On the other hand, FT8 makes extensive use of compression. The standard is well published so that anyone wishing to decode the bits can do so. Even though the compression "obscures" the message - it is clear the purpose of the technique is compression. Furthermore, the software to copy FT8 transmissions is readily available for free. Everyone can "listen in". So FT8 passes both tests.



          Even Morse Code uses a form of compression by using shorter symbol lengths for the more commonly used letters. Clearly it passes both tests.






          share|improve this answer









          $endgroup$













          • $begingroup$
            "Why does this rule exist at all?" Why does this rule exist at all? The same sort of rule doesn't apply to phone lines, internet, WiFi, bluetooth, or a slew of other systems.
            $endgroup$
            – Alexander
            Mar 12 at 0:41










          • $begingroup$
            @Alexander That isn't the question -- but if you want to ask that question, please do. I think it was well covered in the first paragraph of this answer, but a question explicitly about that would probably be a good thing.
            $endgroup$
            – Zeiss Ikon
            Mar 12 at 11:08










          • $begingroup$
            So, Glenn, if I send a ZIP, ARC, ARJ, RAR, TAR etc. archive, without keyword encryption, I'm fine; I'm probably fine if I send a keyword locked archive with the keyword, clearly marked (and redundant against transmission errors), in clear text along with the archive. In the latter case, however, the only sensible reason to bother is if I'm redistributing a file received in that form.
            $endgroup$
            – Zeiss Ikon
            Mar 12 at 11:13










          • $begingroup$
            @ZeissIkon The ZIP, ARC, ARJ, RAR, TAR, etc. file and stream compression formats are well documented. So if you do not apply a password or use encryption, these are fine for sending data using Amateur Radio in the USA. Personally, I would never send a password protected file or an encrypted file even when sending the password or key in plain text with the file. I would take the time to decrypt or un-password protect the file before sending it because the password or encryption has no purpose other than to obscure. The FCC has been very clear on this point.
            $endgroup$
            – Glenn W9IQ
            Mar 12 at 11:27










          • $begingroup$
            @ZeissIkon Also keep in mind that if you are passing files for other parties on your mesh network, that third party traffic rules apply as well.
            $endgroup$
            – Glenn W9IQ
            Mar 12 at 11:57



















          0












          $begingroup$

          As long as your compression uses a standard compression method, it is legal and not considered encryption.






          share|improve this answer









          $endgroup$





















            -2












            $begingroup$

            Compression is not encryption. You don't have to use a standard compression method.



            By FCC rules, even encryption is not encryption if you publish the key (and the algorithm).



            It doesn't matter how you encode the signal if you publish the method to decode it.



            However, if you spoke plain words but used special words for special meanings in ways that is not published, that would be illegal, as it obscures the meaning.






            share|improve this answer











            $endgroup$













            • $begingroup$
              How --and where-- would one "publish the key and the algorithm" so as not to break any laws?
              $endgroup$
              – Mike Waters
              Mar 12 at 2:33












            • $begingroup$
              "...even encryption is not encryption if you publish the key". It is still encryption. The publication of the key does not change that. The only purpose of encryption is obfuscation so it is illegal under part 97.
              $endgroup$
              – Glenn W9IQ
              Mar 12 at 13:00











            Your Answer





            StackExchange.ifUsing("editor", function () {
            return StackExchange.using("mathjaxEditing", function () {
            StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
            StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
            });
            });
            }, "mathjax-editing");

            StackExchange.ifUsing("editor", function () {
            return StackExchange.using("schematics", function () {
            StackExchange.schematics.init();
            });
            }, "cicuitlab");

            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "520"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            noCode: true, onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fham.stackexchange.com%2fquestions%2f13009%2fis-compression-encryption-under-fcc-regs%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            4












            $begingroup$

            For governments around the world to continue to trust that amateur radio has no nefarious purpose, it is essential that everyone that wishes to, can "listen in" to any amateur radio communications. Anything that hints at eroding this capability will likely be struck down in time through regulation.



            To pass the FCC legal hurdle regarding obfuscation, it must first be evident that the purpose is not to obscure the message. Part of this test would likely be that the technique must accomplish some useful level of compression if that is really its purpose.



            The legal second test would likely be that can anyone readily decompress the message to return it to its clear text form. This must be very easily achievable due to broad publication or acceptance of the compression method.



            Both tests are important. For example, consider a symmetric encryption scheme using an industry standard and with the encryption key widely published on the web. This will possibly pass the second test but it would fail the first test because it doesn't actually compress the message in any real sense. It is also clear that the public standard is primarily for encryption (obscuring) and not compression (reducing).



            On the other hand, FT8 makes extensive use of compression. The standard is well published so that anyone wishing to decode the bits can do so. Even though the compression "obscures" the message - it is clear the purpose of the technique is compression. Furthermore, the software to copy FT8 transmissions is readily available for free. Everyone can "listen in". So FT8 passes both tests.



            Even Morse Code uses a form of compression by using shorter symbol lengths for the more commonly used letters. Clearly it passes both tests.






            share|improve this answer









            $endgroup$













            • $begingroup$
              "Why does this rule exist at all?" Why does this rule exist at all? The same sort of rule doesn't apply to phone lines, internet, WiFi, bluetooth, or a slew of other systems.
              $endgroup$
              – Alexander
              Mar 12 at 0:41










            • $begingroup$
              @Alexander That isn't the question -- but if you want to ask that question, please do. I think it was well covered in the first paragraph of this answer, but a question explicitly about that would probably be a good thing.
              $endgroup$
              – Zeiss Ikon
              Mar 12 at 11:08










            • $begingroup$
              So, Glenn, if I send a ZIP, ARC, ARJ, RAR, TAR etc. archive, without keyword encryption, I'm fine; I'm probably fine if I send a keyword locked archive with the keyword, clearly marked (and redundant against transmission errors), in clear text along with the archive. In the latter case, however, the only sensible reason to bother is if I'm redistributing a file received in that form.
              $endgroup$
              – Zeiss Ikon
              Mar 12 at 11:13










            • $begingroup$
              @ZeissIkon The ZIP, ARC, ARJ, RAR, TAR, etc. file and stream compression formats are well documented. So if you do not apply a password or use encryption, these are fine for sending data using Amateur Radio in the USA. Personally, I would never send a password protected file or an encrypted file even when sending the password or key in plain text with the file. I would take the time to decrypt or un-password protect the file before sending it because the password or encryption has no purpose other than to obscure. The FCC has been very clear on this point.
              $endgroup$
              – Glenn W9IQ
              Mar 12 at 11:27










            • $begingroup$
              @ZeissIkon Also keep in mind that if you are passing files for other parties on your mesh network, that third party traffic rules apply as well.
              $endgroup$
              – Glenn W9IQ
              Mar 12 at 11:57
















            4












            $begingroup$

            For governments around the world to continue to trust that amateur radio has no nefarious purpose, it is essential that everyone that wishes to, can "listen in" to any amateur radio communications. Anything that hints at eroding this capability will likely be struck down in time through regulation.



            To pass the FCC legal hurdle regarding obfuscation, it must first be evident that the purpose is not to obscure the message. Part of this test would likely be that the technique must accomplish some useful level of compression if that is really its purpose.



            The legal second test would likely be that can anyone readily decompress the message to return it to its clear text form. This must be very easily achievable due to broad publication or acceptance of the compression method.



            Both tests are important. For example, consider a symmetric encryption scheme using an industry standard and with the encryption key widely published on the web. This will possibly pass the second test but it would fail the first test because it doesn't actually compress the message in any real sense. It is also clear that the public standard is primarily for encryption (obscuring) and not compression (reducing).



            On the other hand, FT8 makes extensive use of compression. The standard is well published so that anyone wishing to decode the bits can do so. Even though the compression "obscures" the message - it is clear the purpose of the technique is compression. Furthermore, the software to copy FT8 transmissions is readily available for free. Everyone can "listen in". So FT8 passes both tests.



            Even Morse Code uses a form of compression by using shorter symbol lengths for the more commonly used letters. Clearly it passes both tests.






            share|improve this answer









            $endgroup$













            • $begingroup$
              "Why does this rule exist at all?" Why does this rule exist at all? The same sort of rule doesn't apply to phone lines, internet, WiFi, bluetooth, or a slew of other systems.
              $endgroup$
              – Alexander
              Mar 12 at 0:41










            • $begingroup$
              @Alexander That isn't the question -- but if you want to ask that question, please do. I think it was well covered in the first paragraph of this answer, but a question explicitly about that would probably be a good thing.
              $endgroup$
              – Zeiss Ikon
              Mar 12 at 11:08










            • $begingroup$
              So, Glenn, if I send a ZIP, ARC, ARJ, RAR, TAR etc. archive, without keyword encryption, I'm fine; I'm probably fine if I send a keyword locked archive with the keyword, clearly marked (and redundant against transmission errors), in clear text along with the archive. In the latter case, however, the only sensible reason to bother is if I'm redistributing a file received in that form.
              $endgroup$
              – Zeiss Ikon
              Mar 12 at 11:13










            • $begingroup$
              @ZeissIkon The ZIP, ARC, ARJ, RAR, TAR, etc. file and stream compression formats are well documented. So if you do not apply a password or use encryption, these are fine for sending data using Amateur Radio in the USA. Personally, I would never send a password protected file or an encrypted file even when sending the password or key in plain text with the file. I would take the time to decrypt or un-password protect the file before sending it because the password or encryption has no purpose other than to obscure. The FCC has been very clear on this point.
              $endgroup$
              – Glenn W9IQ
              Mar 12 at 11:27










            • $begingroup$
              @ZeissIkon Also keep in mind that if you are passing files for other parties on your mesh network, that third party traffic rules apply as well.
              $endgroup$
              – Glenn W9IQ
              Mar 12 at 11:57














            4












            4








            4





            $begingroup$

            For governments around the world to continue to trust that amateur radio has no nefarious purpose, it is essential that everyone that wishes to, can "listen in" to any amateur radio communications. Anything that hints at eroding this capability will likely be struck down in time through regulation.



            To pass the FCC legal hurdle regarding obfuscation, it must first be evident that the purpose is not to obscure the message. Part of this test would likely be that the technique must accomplish some useful level of compression if that is really its purpose.



            The legal second test would likely be that can anyone readily decompress the message to return it to its clear text form. This must be very easily achievable due to broad publication or acceptance of the compression method.



            Both tests are important. For example, consider a symmetric encryption scheme using an industry standard and with the encryption key widely published on the web. This will possibly pass the second test but it would fail the first test because it doesn't actually compress the message in any real sense. It is also clear that the public standard is primarily for encryption (obscuring) and not compression (reducing).



            On the other hand, FT8 makes extensive use of compression. The standard is well published so that anyone wishing to decode the bits can do so. Even though the compression "obscures" the message - it is clear the purpose of the technique is compression. Furthermore, the software to copy FT8 transmissions is readily available for free. Everyone can "listen in". So FT8 passes both tests.



            Even Morse Code uses a form of compression by using shorter symbol lengths for the more commonly used letters. Clearly it passes both tests.






            share|improve this answer









            $endgroup$



            For governments around the world to continue to trust that amateur radio has no nefarious purpose, it is essential that everyone that wishes to, can "listen in" to any amateur radio communications. Anything that hints at eroding this capability will likely be struck down in time through regulation.



            To pass the FCC legal hurdle regarding obfuscation, it must first be evident that the purpose is not to obscure the message. Part of this test would likely be that the technique must accomplish some useful level of compression if that is really its purpose.



            The legal second test would likely be that can anyone readily decompress the message to return it to its clear text form. This must be very easily achievable due to broad publication or acceptance of the compression method.



            Both tests are important. For example, consider a symmetric encryption scheme using an industry standard and with the encryption key widely published on the web. This will possibly pass the second test but it would fail the first test because it doesn't actually compress the message in any real sense. It is also clear that the public standard is primarily for encryption (obscuring) and not compression (reducing).



            On the other hand, FT8 makes extensive use of compression. The standard is well published so that anyone wishing to decode the bits can do so. Even though the compression "obscures" the message - it is clear the purpose of the technique is compression. Furthermore, the software to copy FT8 transmissions is readily available for free. Everyone can "listen in". So FT8 passes both tests.



            Even Morse Code uses a form of compression by using shorter symbol lengths for the more commonly used letters. Clearly it passes both tests.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Mar 11 at 21:35









            Glenn W9IQGlenn W9IQ

            16.8k11148




            16.8k11148












            • $begingroup$
              "Why does this rule exist at all?" Why does this rule exist at all? The same sort of rule doesn't apply to phone lines, internet, WiFi, bluetooth, or a slew of other systems.
              $endgroup$
              – Alexander
              Mar 12 at 0:41










            • $begingroup$
              @Alexander That isn't the question -- but if you want to ask that question, please do. I think it was well covered in the first paragraph of this answer, but a question explicitly about that would probably be a good thing.
              $endgroup$
              – Zeiss Ikon
              Mar 12 at 11:08










            • $begingroup$
              So, Glenn, if I send a ZIP, ARC, ARJ, RAR, TAR etc. archive, without keyword encryption, I'm fine; I'm probably fine if I send a keyword locked archive with the keyword, clearly marked (and redundant against transmission errors), in clear text along with the archive. In the latter case, however, the only sensible reason to bother is if I'm redistributing a file received in that form.
              $endgroup$
              – Zeiss Ikon
              Mar 12 at 11:13










            • $begingroup$
              @ZeissIkon The ZIP, ARC, ARJ, RAR, TAR, etc. file and stream compression formats are well documented. So if you do not apply a password or use encryption, these are fine for sending data using Amateur Radio in the USA. Personally, I would never send a password protected file or an encrypted file even when sending the password or key in plain text with the file. I would take the time to decrypt or un-password protect the file before sending it because the password or encryption has no purpose other than to obscure. The FCC has been very clear on this point.
              $endgroup$
              – Glenn W9IQ
              Mar 12 at 11:27










            • $begingroup$
              @ZeissIkon Also keep in mind that if you are passing files for other parties on your mesh network, that third party traffic rules apply as well.
              $endgroup$
              – Glenn W9IQ
              Mar 12 at 11:57


















            • $begingroup$
              "Why does this rule exist at all?" Why does this rule exist at all? The same sort of rule doesn't apply to phone lines, internet, WiFi, bluetooth, or a slew of other systems.
              $endgroup$
              – Alexander
              Mar 12 at 0:41










            • $begingroup$
              @Alexander That isn't the question -- but if you want to ask that question, please do. I think it was well covered in the first paragraph of this answer, but a question explicitly about that would probably be a good thing.
              $endgroup$
              – Zeiss Ikon
              Mar 12 at 11:08










            • $begingroup$
              So, Glenn, if I send a ZIP, ARC, ARJ, RAR, TAR etc. archive, without keyword encryption, I'm fine; I'm probably fine if I send a keyword locked archive with the keyword, clearly marked (and redundant against transmission errors), in clear text along with the archive. In the latter case, however, the only sensible reason to bother is if I'm redistributing a file received in that form.
              $endgroup$
              – Zeiss Ikon
              Mar 12 at 11:13










            • $begingroup$
              @ZeissIkon The ZIP, ARC, ARJ, RAR, TAR, etc. file and stream compression formats are well documented. So if you do not apply a password or use encryption, these are fine for sending data using Amateur Radio in the USA. Personally, I would never send a password protected file or an encrypted file even when sending the password or key in plain text with the file. I would take the time to decrypt or un-password protect the file before sending it because the password or encryption has no purpose other than to obscure. The FCC has been very clear on this point.
              $endgroup$
              – Glenn W9IQ
              Mar 12 at 11:27










            • $begingroup$
              @ZeissIkon Also keep in mind that if you are passing files for other parties on your mesh network, that third party traffic rules apply as well.
              $endgroup$
              – Glenn W9IQ
              Mar 12 at 11:57
















            $begingroup$
            "Why does this rule exist at all?" Why does this rule exist at all? The same sort of rule doesn't apply to phone lines, internet, WiFi, bluetooth, or a slew of other systems.
            $endgroup$
            – Alexander
            Mar 12 at 0:41




            $begingroup$
            "Why does this rule exist at all?" Why does this rule exist at all? The same sort of rule doesn't apply to phone lines, internet, WiFi, bluetooth, or a slew of other systems.
            $endgroup$
            – Alexander
            Mar 12 at 0:41












            $begingroup$
            @Alexander That isn't the question -- but if you want to ask that question, please do. I think it was well covered in the first paragraph of this answer, but a question explicitly about that would probably be a good thing.
            $endgroup$
            – Zeiss Ikon
            Mar 12 at 11:08




            $begingroup$
            @Alexander That isn't the question -- but if you want to ask that question, please do. I think it was well covered in the first paragraph of this answer, but a question explicitly about that would probably be a good thing.
            $endgroup$
            – Zeiss Ikon
            Mar 12 at 11:08












            $begingroup$
            So, Glenn, if I send a ZIP, ARC, ARJ, RAR, TAR etc. archive, without keyword encryption, I'm fine; I'm probably fine if I send a keyword locked archive with the keyword, clearly marked (and redundant against transmission errors), in clear text along with the archive. In the latter case, however, the only sensible reason to bother is if I'm redistributing a file received in that form.
            $endgroup$
            – Zeiss Ikon
            Mar 12 at 11:13




            $begingroup$
            So, Glenn, if I send a ZIP, ARC, ARJ, RAR, TAR etc. archive, without keyword encryption, I'm fine; I'm probably fine if I send a keyword locked archive with the keyword, clearly marked (and redundant against transmission errors), in clear text along with the archive. In the latter case, however, the only sensible reason to bother is if I'm redistributing a file received in that form.
            $endgroup$
            – Zeiss Ikon
            Mar 12 at 11:13












            $begingroup$
            @ZeissIkon The ZIP, ARC, ARJ, RAR, TAR, etc. file and stream compression formats are well documented. So if you do not apply a password or use encryption, these are fine for sending data using Amateur Radio in the USA. Personally, I would never send a password protected file or an encrypted file even when sending the password or key in plain text with the file. I would take the time to decrypt or un-password protect the file before sending it because the password or encryption has no purpose other than to obscure. The FCC has been very clear on this point.
            $endgroup$
            – Glenn W9IQ
            Mar 12 at 11:27




            $begingroup$
            @ZeissIkon The ZIP, ARC, ARJ, RAR, TAR, etc. file and stream compression formats are well documented. So if you do not apply a password or use encryption, these are fine for sending data using Amateur Radio in the USA. Personally, I would never send a password protected file or an encrypted file even when sending the password or key in plain text with the file. I would take the time to decrypt or un-password protect the file before sending it because the password or encryption has no purpose other than to obscure. The FCC has been very clear on this point.
            $endgroup$
            – Glenn W9IQ
            Mar 12 at 11:27












            $begingroup$
            @ZeissIkon Also keep in mind that if you are passing files for other parties on your mesh network, that third party traffic rules apply as well.
            $endgroup$
            – Glenn W9IQ
            Mar 12 at 11:57




            $begingroup$
            @ZeissIkon Also keep in mind that if you are passing files for other parties on your mesh network, that third party traffic rules apply as well.
            $endgroup$
            – Glenn W9IQ
            Mar 12 at 11:57











            0












            $begingroup$

            As long as your compression uses a standard compression method, it is legal and not considered encryption.






            share|improve this answer









            $endgroup$


















              0












              $begingroup$

              As long as your compression uses a standard compression method, it is legal and not considered encryption.






              share|improve this answer









              $endgroup$
















                0












                0








                0





                $begingroup$

                As long as your compression uses a standard compression method, it is legal and not considered encryption.






                share|improve this answer









                $endgroup$



                As long as your compression uses a standard compression method, it is legal and not considered encryption.







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Mar 11 at 19:33









                Mike WatersMike Waters

                3,5642635




                3,5642635























                    -2












                    $begingroup$

                    Compression is not encryption. You don't have to use a standard compression method.



                    By FCC rules, even encryption is not encryption if you publish the key (and the algorithm).



                    It doesn't matter how you encode the signal if you publish the method to decode it.



                    However, if you spoke plain words but used special words for special meanings in ways that is not published, that would be illegal, as it obscures the meaning.






                    share|improve this answer











                    $endgroup$













                    • $begingroup$
                      How --and where-- would one "publish the key and the algorithm" so as not to break any laws?
                      $endgroup$
                      – Mike Waters
                      Mar 12 at 2:33












                    • $begingroup$
                      "...even encryption is not encryption if you publish the key". It is still encryption. The publication of the key does not change that. The only purpose of encryption is obfuscation so it is illegal under part 97.
                      $endgroup$
                      – Glenn W9IQ
                      Mar 12 at 13:00
















                    -2












                    $begingroup$

                    Compression is not encryption. You don't have to use a standard compression method.



                    By FCC rules, even encryption is not encryption if you publish the key (and the algorithm).



                    It doesn't matter how you encode the signal if you publish the method to decode it.



                    However, if you spoke plain words but used special words for special meanings in ways that is not published, that would be illegal, as it obscures the meaning.






                    share|improve this answer











                    $endgroup$













                    • $begingroup$
                      How --and where-- would one "publish the key and the algorithm" so as not to break any laws?
                      $endgroup$
                      – Mike Waters
                      Mar 12 at 2:33












                    • $begingroup$
                      "...even encryption is not encryption if you publish the key". It is still encryption. The publication of the key does not change that. The only purpose of encryption is obfuscation so it is illegal under part 97.
                      $endgroup$
                      – Glenn W9IQ
                      Mar 12 at 13:00














                    -2












                    -2








                    -2





                    $begingroup$

                    Compression is not encryption. You don't have to use a standard compression method.



                    By FCC rules, even encryption is not encryption if you publish the key (and the algorithm).



                    It doesn't matter how you encode the signal if you publish the method to decode it.



                    However, if you spoke plain words but used special words for special meanings in ways that is not published, that would be illegal, as it obscures the meaning.






                    share|improve this answer











                    $endgroup$



                    Compression is not encryption. You don't have to use a standard compression method.



                    By FCC rules, even encryption is not encryption if you publish the key (and the algorithm).



                    It doesn't matter how you encode the signal if you publish the method to decode it.



                    However, if you spoke plain words but used special words for special meanings in ways that is not published, that would be illegal, as it obscures the meaning.







                    share|improve this answer














                    share|improve this answer



                    share|improve this answer








                    edited Mar 12 at 0:45

























                    answered Mar 12 at 0:30









                    user10489user10489

                    58516




                    58516












                    • $begingroup$
                      How --and where-- would one "publish the key and the algorithm" so as not to break any laws?
                      $endgroup$
                      – Mike Waters
                      Mar 12 at 2:33












                    • $begingroup$
                      "...even encryption is not encryption if you publish the key". It is still encryption. The publication of the key does not change that. The only purpose of encryption is obfuscation so it is illegal under part 97.
                      $endgroup$
                      – Glenn W9IQ
                      Mar 12 at 13:00


















                    • $begingroup$
                      How --and where-- would one "publish the key and the algorithm" so as not to break any laws?
                      $endgroup$
                      – Mike Waters
                      Mar 12 at 2:33












                    • $begingroup$
                      "...even encryption is not encryption if you publish the key". It is still encryption. The publication of the key does not change that. The only purpose of encryption is obfuscation so it is illegal under part 97.
                      $endgroup$
                      – Glenn W9IQ
                      Mar 12 at 13:00
















                    $begingroup$
                    How --and where-- would one "publish the key and the algorithm" so as not to break any laws?
                    $endgroup$
                    – Mike Waters
                    Mar 12 at 2:33






                    $begingroup$
                    How --and where-- would one "publish the key and the algorithm" so as not to break any laws?
                    $endgroup$
                    – Mike Waters
                    Mar 12 at 2:33














                    $begingroup$
                    "...even encryption is not encryption if you publish the key". It is still encryption. The publication of the key does not change that. The only purpose of encryption is obfuscation so it is illegal under part 97.
                    $endgroup$
                    – Glenn W9IQ
                    Mar 12 at 13:00




                    $begingroup$
                    "...even encryption is not encryption if you publish the key". It is still encryption. The publication of the key does not change that. The only purpose of encryption is obfuscation so it is illegal under part 97.
                    $endgroup$
                    – Glenn W9IQ
                    Mar 12 at 13:00


















                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Amateur Radio Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    Use MathJax to format equations. MathJax reference.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fham.stackexchange.com%2fquestions%2f13009%2fis-compression-encryption-under-fcc-regs%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    How to send String Array data to Server using php in android

                    Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents

                    Is anime1.com a legal site for watching anime?