Nigel, Thanks for the reminder, I'm not one to argue that, but it does bring up a question. There is not much of the web left that is not HTTPS, I'm thinking particularly of emergency management sites such as WebEOC. Is this violation likely to be excused when providing communications support in a real public emergency? Thanks, Thom Wescott KI7EFG
Thom, This is something we’ve thought about as well. The FCC is explicitly permissive in the case of a real emergency, though that doesn’t really cover the use case during the rest of the time. This is one of a number of reasons why we (the network admins) have specifically avoided blocking anything but blatant abuse (mostly virus type stuff). We want to leave the possibility open in terms of the network for these sorts of cases, but that comes with users needing to take on the responsibility to maintain their own compliance. The team is discussing ways we can help with this, while leaving things as flexible as possible. One of the current front running ideas is adding instructions to the client node configuration page that everyone uses to set up their modems, to block HTTPS at your modem. That leaves you the option to disable it if required (unlike if we implemented the block on the network side), but helps to maintain compliance during regular activities. It’s still very much an active discussion at this point, but if folks have ideas we’ll certainly welcome them. Thanks, Nigel
On Jul 19, 2019, at 12:17, Thom Wescott <thom.wescott@gmail.com> wrote:
Nigel,
Thanks for the reminder, I'm not one to argue that, but it does bring up a question. There is not much of the web left that is not HTTPS, I'm thinking particularly of emergency management sites such as WebEOC. Is this violation likely to be excused when providing communications support in a real public emergency?
Thanks,
Thom Wescott KI7EFG _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
I think it's important to recognize that the Internet has changed significantly since the project's inception in 2012. Two very important things came to pass, that impact the HamWAN use case arguments in 2012: 1) HTTPS became universally deployed, instead of being reserved for specific pages. 2) Browsers have removed support for null-cipher HTTPS. Even the use case of surfing Wikipedia can't be done on HamWAN these days. Heck, you can't even do a Google search for anything. Is there a point to powering a network that's so useless? As Thom points out, it can't even be used for WebEOC emcomm either. People need to regularly test + practice emcomm tools for them to be usable in a real emergency. This is not allowed right now. Part97 is incompatible with modern computing life, and we might be better off having a smaller footprint that offers actual utility. Or we can just wait a couple years for StarLink / OneWeb. --Bart On 7/19/2019 12:27 PM, Nigel Vander Houwen wrote:
Thom,
This is something we’ve thought about as well. The FCC is explicitly permissive in the case of a real emergency, though that doesn’t really cover the use case during the rest of the time. This is one of a number of reasons why we (the network admins) have specifically avoided blocking anything but blatant abuse (mostly virus type stuff). We want to leave the possibility open in terms of the network for these sorts of cases, but that comes with users needing to take on the responsibility to maintain their own compliance.
The team is discussing ways we can help with this, while leaving things as flexible as possible. One of the current front running ideas is adding instructions to the client node configuration page that everyone uses to set up their modems, to block HTTPS at your modem. That leaves you the option to disable it if required (unlike if we implemented the block on the network side), but helps to maintain compliance during regular activities. It’s still very much an active discussion at this point, but if folks have ideas we’ll certainly welcome them.
Thanks, Nigel
On Jul 19, 2019, at 12:17, Thom Wescott <thom.wescott@gmail.com> wrote:
Nigel,
Thanks for the reminder, I'm not one to argue that, but it does bring up a question. There is not much of the web left that is not HTTPS, I'm thinking particularly of emergency management sites such as WebEOC. Is this violation likely to be excused when providing communications support in a real public emergency?
Thanks,
Thom Wescott KI7EFG _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
What would it take to keep from running afoul of the Part 97 encryption restrictions? Everyone put on their thinking caps. Would it be feasible to set up some sort of proxy after the RF stage but before the internet that keeps the HTTPS stuff unencrypted over the Part 97 RF. Like Thom said, there is not much left on the web that is HTTP. The goal is zero HTTP. I can't even go to weather.gov to check my forecast, or to the FCC to check my license status (https://wireless2.fcc.gov/UlsApp/UlsSearch/searchLicense.jsp), without running afoul of the HTTPS issues. This seems to me a classic case where the Rule and the Reason have diverged, and it needs addressing. Personal beef: I can't see how PACTOR, and now VARA, can steer clear of the Part 97 rules when they are "encrypyted" and clearly derive a pecuniary benefit by charging for their "compression/encryption". I do not want to get into a debate about this, BUT, can such exemption be parlayed into something similar as an exemption for HTTPS. Remember, thinking caps, not debate. I can live with PACTOR et al, I don't have to like it, it's just the way it is. Can this help HTTPS? Bernard KE7FEQ -----Original Message----- From: PSDR <psdr-bounces@hamwan.org> On Behalf Of Bart Kus Sent: Friday, July 19, 2019 12:55 To: Puget Sound Data Ring <psdr@hamwan.org>; Nigel Vander Houwen <nigel@nigelvh.com> Subject: Re: [HamWAN PSDR] Encryption on HamWAN I think it's important to recognize that the Internet has changed significantly since the project's inception in 2012. Two very important things came to pass, that impact the HamWAN use case arguments in 2012: 1) HTTPS became universally deployed, instead of being reserved for specific pages. 2) Browsers have removed support for null-cipher HTTPS. Even the use case of surfing Wikipedia can't be done on HamWAN these days. Heck, you can't even do a Google search for anything. Is there a point to powering a network that's so useless? As Thom points out, it can't even be used for WebEOC emcomm either. People need to regularly test + practice emcomm tools for them to be usable in a real emergency. This is not allowed right now. Part97 is incompatible with modern computing life, and we might be better off having a smaller footprint that offers actual utility. Or we can just wait a couple years for StarLink / OneWeb. --Bart On 7/19/2019 12:27 PM, Nigel Vander Houwen wrote:
Thom,
This is something we’ve thought about as well. The FCC is explicitly permissive in the case of a real emergency, though that doesn’t really cover the use case during the rest of the time. This is one of a number of reasons why we (the network admins) have specifically avoided blocking anything but blatant abuse (mostly virus type stuff). We want to leave the possibility open in terms of the network for these sorts of cases, but that comes with users needing to take on the responsibility to maintain their own compliance.
The team is discussing ways we can help with this, while leaving things as flexible as possible. One of the current front running ideas is adding instructions to the client node configuration page that everyone uses to set up their modems, to block HTTPS at your modem. That leaves you the option to disable it if required (unlike if we implemented the block on the network side), but helps to maintain compliance during regular activities. It’s still very much an active discussion at this point, but if folks have ideas we’ll certainly welcome them.
Thanks, Nigel
On Jul 19, 2019, at 12:17, Thom Wescott <thom.wescott@gmail.com> wrote:
Nigel,
Thanks for the reminder, I'm not one to argue that, but it does bring up a question. There is not much of the web left that is not HTTPS, I'm thinking particularly of emergency management sites such as WebEOC. Is this violation likely to be excused when providing communications support in a real public emergency?
Thanks,
Thom Wescott KI7EFG _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
I'll add more data for those wishing to think about these things: 1) HamWAN only relies on Part 97 spectrum for the very last hop (the sectors). Everything before that can be considered P15 or ISM, and can run crypto. 2) If the FCC passed U-NII-4 rules, our tiny sliver of P97 space would become usable for crypto, without changing frequencies. 3) The EOCs and repeater sites on HamWAN are typically fed directly from the backbone (P15/ISM) and not from sectors, so they're fine to use crypto. I often wonder if HamWAN should have been defined as "Created by hams, for hammy + emcomm purposes, but on freqs not exclusively P97 licensed." We'd probably lose access to a site or 2 if we did that switch, but perhaps the project overall would offer more utility. --Bart On 7/19/2019 12:56 PM, Bernard Littau wrote:
What would it take to keep from running afoul of the Part 97 encryption restrictions? Everyone put on their thinking caps. Would it be feasible to set up some sort of proxy after the RF stage but before the internet that keeps the HTTPS stuff unencrypted over the Part 97 RF. Like Thom said, there is not much left on the web that is HTTP. The goal is zero HTTP. I can't even go to weather.gov to check my forecast, or to the FCC to check my license status (https://wireless2.fcc.gov/UlsApp/UlsSearch/searchLicense.jsp), without running afoul of the HTTPS issues.
This seems to me a classic case where the Rule and the Reason have diverged, and it needs addressing.
Personal beef: I can't see how PACTOR, and now VARA, can steer clear of the Part 97 rules when they are "encrypyted" and clearly derive a pecuniary benefit by charging for their "compression/encryption". I do not want to get into a debate about this, BUT, can such exemption be parlayed into something similar as an exemption for HTTPS. Remember, thinking caps, not debate. I can live with PACTOR et al, I don't have to like it, it's just the way it is. Can this help HTTPS?
Bernard KE7FEQ
-----Original Message----- From: PSDR <psdr-bounces@hamwan.org> On Behalf Of Bart Kus Sent: Friday, July 19, 2019 12:55 To: Puget Sound Data Ring <psdr@hamwan.org>; Nigel Vander Houwen <nigel@nigelvh.com> Subject: Re: [HamWAN PSDR] Encryption on HamWAN
I think it's important to recognize that the Internet has changed significantly since the project's inception in 2012. Two very important things came to pass, that impact the HamWAN use case arguments in 2012:
1) HTTPS became universally deployed, instead of being reserved for specific pages. 2) Browsers have removed support for null-cipher HTTPS.
Even the use case of surfing Wikipedia can't be done on HamWAN these days. Heck, you can't even do a Google search for anything.
Is there a point to powering a network that's so useless? As Thom points out, it can't even be used for WebEOC emcomm either. People need to regularly test + practice emcomm tools for them to be usable in a real emergency. This is not allowed right now.
Part97 is incompatible with modern computing life, and we might be better off having a smaller footprint that offers actual utility.
Or we can just wait a couple years for StarLink / OneWeb.
--Bart
On 7/19/2019 12:27 PM, Nigel Vander Houwen wrote:
Thom,
This is something we’ve thought about as well. The FCC is explicitly permissive in the case of a real emergency, though that doesn’t really cover the use case during the rest of the time. This is one of a number of reasons why we (the network admins) have specifically avoided blocking anything but blatant abuse (mostly virus type stuff). We want to leave the possibility open in terms of the network for these sorts of cases, but that comes with users needing to take on the responsibility to maintain their own compliance.
The team is discussing ways we can help with this, while leaving things as flexible as possible. One of the current front running ideas is adding instructions to the client node configuration page that everyone uses to set up their modems, to block HTTPS at your modem. That leaves you the option to disable it if required (unlike if we implemented the block on the network side), but helps to maintain compliance during regular activities. It’s still very much an active discussion at this point, but if folks have ideas we’ll certainly welcome them.
Thanks, Nigel
On Jul 19, 2019, at 12:17, Thom Wescott <thom.wescott@gmail.com> wrote:
Nigel,
Thanks for the reminder, I'm not one to argue that, but it does bring up a question. There is not much of the web left that is not HTTPS, I'm thinking particularly of emergency management sites such as WebEOC. Is this violation likely to be excused when providing communications support in a real public emergency?
Thanks,
Thom Wescott KI7EFG _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
So another thought, or two... Winlink appears to avoid this issue with PACTOR and VARA by enabling individuals to read all email traffic on the Winlink network. See: https://www.winlink.org/content/us_amateur_radio_message_viewer So one possible solution for HAMWAN would be to do some sort of man-in-the-middle decrypt, log, and re-encrypt of HTTPS traffic after the RF stage (the sectors), and make that log available to the "public". This would mean it would be stupid to use a credit card on HAMWAN, but not so for weather or fcc. Would this be acceptable to HAMWAN users? Clearly, this is the de facto case for Winlink. Bernard KE7FEQ -----Original Message----- From: Bart Kus <me@bartk.us> Sent: Friday, July 19, 2019 13:21 To: Puget Sound Data Ring <psdr@hamwan.org>; Bernard Littau <bernard@littau.org>; Nigel Vander Houwen <nigel@nigelvh.com> Subject: Re: [HamWAN PSDR] Encryption on HamWAN I'll add more data for those wishing to think about these things: 1) HamWAN only relies on Part 97 spectrum for the very last hop (the sectors). Everything before that can be considered P15 or ISM, and can run crypto. 2) If the FCC passed U-NII-4 rules, our tiny sliver of P97 space would become usable for crypto, without changing frequencies. 3) The EOCs and repeater sites on HamWAN are typically fed directly from the backbone (P15/ISM) and not from sectors, so they're fine to use crypto. I often wonder if HamWAN should have been defined as "Created by hams, for hammy + emcomm purposes, but on freqs not exclusively P97 licensed." We'd probably lose access to a site or 2 if we did that switch, but perhaps the project overall would offer more utility. --Bart On 7/19/2019 12:56 PM, Bernard Littau wrote:
What would it take to keep from running afoul of the Part 97 encryption restrictions? Everyone put on their thinking caps. Would it be feasible to set up some sort of proxy after the RF stage but before the internet that keeps the HTTPS stuff unencrypted over the Part 97 RF. Like Thom said, there is not much left on the web that is HTTP. The goal is zero HTTP. I can't even go to weather.gov to check my forecast, or to the FCC to check my license status (https://wireless2.fcc.gov/UlsApp/UlsSearch/searchLicense.jsp), without running afoul of the HTTPS issues.
This seems to me a classic case where the Rule and the Reason have diverged, and it needs addressing.
Personal beef: I can't see how PACTOR, and now VARA, can steer clear of the Part 97 rules when they are "encrypyted" and clearly derive a pecuniary benefit by charging for their "compression/encryption". I do not want to get into a debate about this, BUT, can such exemption be parlayed into something similar as an exemption for HTTPS. Remember, thinking caps, not debate. I can live with PACTOR et al, I don't have to like it, it's just the way it is. Can this help HTTPS?
Bernard KE7FEQ
-----Original Message----- From: PSDR <psdr-bounces@hamwan.org> On Behalf Of Bart Kus Sent: Friday, July 19, 2019 12:55 To: Puget Sound Data Ring <psdr@hamwan.org>; Nigel Vander Houwen <nigel@nigelvh.com> Subject: Re: [HamWAN PSDR] Encryption on HamWAN
I think it's important to recognize that the Internet has changed significantly since the project's inception in 2012. Two very important things came to pass, that impact the HamWAN use case arguments in 2012:
1) HTTPS became universally deployed, instead of being reserved for specific pages. 2) Browsers have removed support for null-cipher HTTPS.
Even the use case of surfing Wikipedia can't be done on HamWAN these days. Heck, you can't even do a Google search for anything.
Is there a point to powering a network that's so useless? As Thom points out, it can't even be used for WebEOC emcomm either. People need to regularly test + practice emcomm tools for them to be usable in a real emergency. This is not allowed right now.
Part97 is incompatible with modern computing life, and we might be better off having a smaller footprint that offers actual utility.
Or we can just wait a couple years for StarLink / OneWeb.
--Bart
On 7/19/2019 12:27 PM, Nigel Vander Houwen wrote:
Thom,
This is something we’ve thought about as well. The FCC is explicitly permissive in the case of a real emergency, though that doesn’t really cover the use case during the rest of the time. This is one of a number of reasons why we (the network admins) have specifically avoided blocking anything but blatant abuse (mostly virus type stuff). We want to leave the possibility open in terms of the network for these sorts of cases, but that comes with users needing to take on the responsibility to maintain their own compliance.
The team is discussing ways we can help with this, while leaving things as flexible as possible. One of the current front running ideas is adding instructions to the client node configuration page that everyone uses to set up their modems, to block HTTPS at your modem. That leaves you the option to disable it if required (unlike if we implemented the block on the network side), but helps to maintain compliance during regular activities. It’s still very much an active discussion at this point, but if folks have ideas we’ll certainly welcome them.
Thanks, Nigel
On Jul 19, 2019, at 12:17, Thom Wescott <thom.wescott@gmail.com> wrote:
Nigel,
Thanks for the reminder, I'm not one to argue that, but it does bring up a question. There is not much of the web left that is not HTTPS, I'm thinking particularly of emergency management sites such as WebEOC. Is this violation likely to be excused when providing communications support in a real public emergency?
Thanks,
Thom Wescott KI7EFG _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
Why isn’t HughsNet or ViaSat not mentioned as an an option here? I run a Hybrid gateway off of HughsNet with no issues and full internet access to the QTH when terrestrial ISP fails. If adopted by EOCs, WebEOC remains operational during critical terrestrial ISP outages? Sent from my iPhone
On Jul 19, 2019, at 12:54 PM, Bart Kus <me@bartk.us> wrote:
I think it's important to recognize that the Internet has changed significantly since the project's inception in 2012. Two very important things came to pass, that impact the HamWAN use case arguments in 2012:
1) HTTPS became universally deployed, instead of being reserved for specific pages. 2) Browsers have removed support for null-cipher HTTPS.
Even the use case of surfing Wikipedia can't be done on HamWAN these days. Heck, you can't even do a Google search for anything.
Is there a point to powering a network that's so useless? As Thom points out, it can't even be used for WebEOC emcomm either. People need to regularly test + practice emcomm tools for them to be usable in a real emergency. This is not allowed right now.
Part97 is incompatible with modern computing life, and we might be better off having a smaller footprint that offers actual utility.
Or we can just wait a couple years for StarLink / OneWeb.
--Bart
On 7/19/2019 12:27 PM, Nigel Vander Houwen wrote: Thom,
This is something we’ve thought about as well. The FCC is explicitly permissive in the case of a real emergency, though that doesn’t really cover the use case during the rest of the time. This is one of a number of reasons why we (the network admins) have specifically avoided blocking anything but blatant abuse (mostly virus type stuff). We want to leave the possibility open in terms of the network for these sorts of cases, but that comes with users needing to take on the responsibility to maintain their own compliance.
The team is discussing ways we can help with this, while leaving things as flexible as possible. One of the current front running ideas is adding instructions to the client node configuration page that everyone uses to set up their modems, to block HTTPS at your modem. That leaves you the option to disable it if required (unlike if we implemented the block on the network side), but helps to maintain compliance during regular activities. It’s still very much an active discussion at this point, but if folks have ideas we’ll certainly welcome them.
Thanks, Nigel
On Jul 19, 2019, at 12:17, Thom Wescott <thom.wescott@gmail.com> wrote:
Nigel,
Thanks for the reminder, I'm not one to argue that, but it does bring up a question. There is not much of the web left that is not HTTPS, I'm thinking particularly of emergency management sites such as WebEOC. Is this violation likely to be excused when providing communications support in a real public emergency?
Thanks,
Thom Wescott KI7EFG _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
The Seattle EOC even has the infrastructure for a dish for that in mind, but as far as I know never implemented it. Hughesnet has an entire system for doing what you said. Steve N0FPF On Sat, Jul 20, 2019 at 5:25 PM Mark Anderson <halpilot@comcast.net> wrote:
Why isn’t HughsNet or ViaSat not mentioned as an an option here? I run a Hybrid gateway off of HughsNet with no issues and full internet access to the QTH when terrestrial ISP fails. If adopted by EOCs, WebEOC remains operational during critical terrestrial ISP outages?
Sent from my iPhone
On Jul 19, 2019, at 12:54 PM, Bart Kus <me@bartk.us> wrote:
I think it's important to recognize that the Internet has changed significantly since the project's inception in 2012. Two very important things came to pass, that impact the HamWAN use case arguments in 2012:
1) HTTPS became universally deployed, instead of being reserved for specific pages. 2) Browsers have removed support for null-cipher HTTPS.
Even the use case of surfing Wikipedia can't be done on HamWAN these days. Heck, you can't even do a Google search for anything.
Is there a point to powering a network that's so useless? As Thom points out, it can't even be used for WebEOC emcomm either. People need to regularly test + practice emcomm tools for them to be usable in a real emergency. This is not allowed right now.
Part97 is incompatible with modern computing life, and we might be better off having a smaller footprint that offers actual utility.
Or we can just wait a couple years for StarLink / OneWeb.
--Bart
On 7/19/2019 12:27 PM, Nigel Vander Houwen wrote: Thom,
This is something we’ve thought about as well. The FCC is explicitly permissive in the case of a real emergency, though that doesn’t really cover the use case during the rest of the time. This is one of a number of reasons why we (the network admins) have specifically avoided blocking anything but blatant abuse (mostly virus type stuff). We want to leave the possibility open in terms of the network for these sorts of cases, but that comes with users needing to take on the responsibility to maintain their own compliance.
The team is discussing ways we can help with this, while leaving things as flexible as possible. One of the current front running ideas is adding instructions to the client node configuration page that everyone uses to set up their modems, to block HTTPS at your modem. That leaves you the option to disable it if required (unlike if we implemented the block on the network side), but helps to maintain compliance during regular activities. It’s still very much an active discussion at this point, but if folks have ideas we’ll certainly welcome them.
Thanks, Nigel
On Jul 19, 2019, at 12:17, Thom Wescott <thom.wescott@gmail.com> wrote:
Nigel,
Thanks for the reminder, I'm not one to argue that, but it does bring up a question. There is not much of the web left that is not HTTPS, I'm thinking particularly of emergency management sites such as WebEOC. Is this violation likely to be excused when providing communications support in a real public emergency?
Thanks,
Thom Wescott KI7EFG _______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
-- Pardon the brevity, sent from a mobile device. So there.
This would be like PACTOR 4 use, The FCC would have to grant a exception for that indecent like they did with PACTOR 4 in Hurricane Maria, Could we just do it - NO. On 7/19/2019 12:17, Thom Wescott wrote:
Nigel,
Thanks for the reminder, I'm not one to argue that, but it does bring up a question. There is not much of the web left that is not HTTPS, I'm thinking particularly of emergency management sites such as WebEOC. Is this violation likely to be excused when providing communications support in a real public emergency?
Thanks,
Thom Wescott KI7EFG
_______________________________________________ PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
-- Kevin Fox KU0L Amateur Radio WQWZ237 GMRS Oregon Section Traffic Manager CFD1 CERT Communications Group Lead Clackamas County ARES ARRL Certified Instructor ARRL Volunteer Examiner W5IY Volunteer Examiner Laurel Volunteer Examiner w0kcf@winlink.org www.w0kcf.com 503-908-4587 (Google Voice) 971-716-3832 (Cell) --- This email has been checked for viruses by AVG. https://www.avg.com
It seems a lot of hams confuse encoding and encryption, lumping some encoding methods in with encryption. https://www.geeksforgeeks.org/encryption-encoding-hashing/ -- John D. Hays Kingston, WA K7VE
And don't forget authentication (such as IPSec with AH but no ESP), that really confuses people! :) Where encoding gets fuzzy I think is proprietary license-encumbered encoding (AMBE comes to mind). It is not designed to obscure the meaning of the message, but unless you pay a fee to the patent holder then you are not able to decode it (legally in the US anyway). On Sat, Jul 27, 2019, at 16:28, John D. Hays wrote:
It seems a lot of hams confuse encoding and encryption, lumping some encoding methods in with encryption.
Back to the proxy comment, can someone think about a feasible way to unencrypt the HTTPS data at the tower side and then send HTTP over the RF? I’d like to experiment with something that could do that. On Sun, Jul 28, 2019 at 2:27 PM Nick Kartsioukas <nick@explodinglemur.org> wrote:
And don't forget authentication (such as IPSec with AH but no ESP), that really confuses people! :) Where encoding gets fuzzy I think is proprietary license-encumbered encoding (AMBE comes to mind). It is not designed to obscure the meaning of the message, but unless you pay a fee to the patent holder then you are not able to decode it (legally in the US anyway).
On Sat, Jul 27, 2019, at 16:28, John D. Hays wrote:
It seems a lot of hams confuse encoding and encryption, lumping some encoding methods in with encryption.
PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
Same was true with FM and SSB. Paying a license fee is not encryption. On Sun, Jul 28, 2019, 13:27 Nick Kartsioukas <nick@explodinglemur.org> wrote:
And don't forget authentication (such as IPSec with AH but no ESP), that really confuses people! :) Where encoding gets fuzzy I think is proprietary license-encumbered encoding (AMBE comes to mind). It is not designed to obscure the meaning of the message, but unless you pay a fee to the patent holder then you are not able to decode it (legally in the US anyway).
On Sat, Jul 27, 2019, at 16:28, John D. Hays wrote:
It seems a lot of hams confuse encoding and encryption, lumping some encoding methods in with encryption.
PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
Perhaps I wasn't clear, as I did not intend to directly or indirectly state that license-fee-encumbered encoding algorithms such as AMBE are encryption, merely that such closed encoding algorithms get mixed up in the various interpretations of 97.113(a)(4). The requirement to license the codec from DVSI to legally encode/decode it is not an intent to obscure the meaning of a message, but the end effect is the same for those unwilling or unable to pay the fee, or just looking to experiment with their own hardware/software solution in the spirit of amateur radio. As for FM and SSB, I may be missing something in their history, was there a time when an amateur radio operator was legally prohibited from developing their own SSB or FM modulator or demodulator without paying a licensing fee to some entity?
On Jul 28, 2019, at 15:58, John D. Hays <john@hays.org> wrote:
Same was true with FM and SSB. Paying a license fee is not encryption.
On Sun, Jul 28, 2019, 13:27 Nick Kartsioukas <nick@explodinglemur.org> wrote: And don't forget authentication (such as IPSec with AH but no ESP), that really confuses people! :) Where encoding gets fuzzy I think is proprietary license-encumbered encoding (AMBE comes to mind). It is not designed to obscure the meaning of the message, but unless you pay a fee to the patent holder then you are not able to decode it (legally in the US anyway).
On Sat, Jul 27, 2019, at 16:28, John D. Hays wrote:
It seems a lot of hams confuse encoding and encryption, lumping some encoding methods in with encryption.
PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
PSDR mailing list PSDR@hamwan.org http://mail.hamwan.net/mailman/listinfo/psdr
Yes, both were patented technologies. Most every modern radio has a lot of licensed intellectual property, from microprocessors to modulator circuits to displays ... On Sun, Jul 28, 2019, 21:09 Nick Kartsioukas <nick@explodinglemur.org> wrote:
As for FM and SSB, I may be missing something in their history, was there a time when an amateur radio operator was legally prohibited from developing their own SSB or FM modulator or demodulator without paying a licensing fee to some entity?
On 7/19/19 3:17 PM, Thom Wescott wrote:
Nigel,
Thanks for the reminder, I'm not one to argue that, but it does bring up a question. There is not much of the web left that is not HTTPS, I'm thinking particularly of emergency management sites such as WebEOC. Is this violation likely to be excused when providing communications support in a real public emergency?
I take a much different view of it. 97.113 (a)4 says "messages encoded for the purpose of obscuring their meaning" 97.311 (a) says "SS emission transmissions must not be used for the purpose of obscuring the meaning of any communication" Note that encryption is not called out by name here. It simply states the intent must not be to obscure the communication. Based on this my view is that having a link layer encryption in the amateur service (ie on the radios) is not permitted, authentication is, and encryption with a well published key used only for authentication is permitted. As we get higher up in the stack, L4 HTTPS is forced upon you by the server. It's not the end users intent to encrypt it, and certainly you're not intending to obscure it. Since your intent is not to obscure the meaning, it's not in violation of part 97. This hasn't been a problem so the FCC has not clarified this. I take the view that some https traffic is permitted on the ham band. If it's that much of a concern, run it part 15, but you lose out on 3.4 GHz which is the only good option for backhaul in many areas. 73's -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net
participants (11)
-
Bart Kus -
Bernard Littau -
Bryan Fields -
John D. Hays -
Kevin Fox -
Mark Anderson -
Nick Kartsioukas -
Nigel Vander Houwen -
Skyler F -
Steve -
Thom Wescott