[HamWAN PSDR] Encryption on HamWAN
stevewa206 at gmail.com
Sat Jul 20 17:29:34 PDT 2019
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.
On Sat, Jul 20, 2019 at 5:25 PM Mark Anderson <halpilot at 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 at 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 at gmail.com>
> >>> 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 at hamwan.org
> >>> http://mail.hamwan.net/mailman/listinfo/psdr
> >> _______________________________________________
> >> PSDR mailing list
> >> PSDR at hamwan.org
> >> http://mail.hamwan.net/mailman/listinfo/psdr
> > _______________________________________________
> > PSDR mailing list
> > PSDR at hamwan.org
> > http://mail.hamwan.net/mailman/listinfo/psdr
> PSDR mailing list
> PSDR at hamwan.org
Pardon the brevity, sent from a mobile device. So there.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the PSDR