29 Sep
2022
29 Sep
'22
3:38 p.m.
Hi Antonios!!
So good to hear from you :)
I'm going to let the TAC / Chris speak to some of your questions, but
I'll share my thoughts on some of the below.
On 9/28/22 2:44 PM, Antonios Chariton (daknob) via 44net wrote:
> 3. Regarding the ticketing system, perhaps
it’s worth to explore
> integrating with an existing one for some of the use cases to not
> reinvent the wheel?
Yes, that is also something that we've considered, though this portion
has already been built. We will review it against the features outlined
and determine if an out-of-the-box solution better suits our needs.
> 4. I would like to see WebAuthn for
Security Keys with support of
> multiple, e.g. 8-16 keys, and not single-key only like some services.
> The web also seems to be moving to a passwordless future, with support
> for Passkeys already landed in browsers and OSes in desktop + mobile.
> Integrating WebAuthn for 2FA and Passkeys for passwordless login is very
> similar. My colleague Adam has written a very good technical post on how
> to implement these standards securely in case you’re interested:
> https://www.imperialviolet.org/2022/09/22/passkeys.html
> <https://www.imperialviolet.org/2022/09/22/passkeys.html> . I would also
> try to avoid any insecure practices like security questions to recover
> an account. I don’t know if I would pick SMS 2FA for a new project,
> although it’s better than nothing. Just make sure you don’t fall back to
> SMS e.g. if Security Keys / TOTP doesn’t work. I think with e-mail 2FA
> support the SMS option isn’t needed. People without a smartphone would
> still need e-mail access to login, so I don’t think it is excluding
> people if you do not offer it. Just be careful with WebAuthn: it is
> domain dependent. The blog post I link to explains this well, and also
> what happens if the domain of the Portal changes.
Thanks, this is noted. Ideally we provide multiple options for 2FA.
> 5. I agree with the other e-mails about
the maidenhead. I know it’s
> currently a part of the old Portal, but is it really required? I would
> make it optional personally unless there’s a specific use case. We
> should practice data minimization and only collect what’s really needed
> now, and not require fields “just in case they’re useful in the future”.
> That way you’ll have to convince users they get some value out of
> supplying you with this information ;) It also makes the Portal more
> generic: networks like guifi that are not related to amateur radio can
> also use the software since it’s generic enough.
> 9. Can you not delegate $callsign.ampr.org
<http://callsign.ampr.org> to
> your own servers anymore? Or is this still done manually via a ticket?
The items described in the feature requirements doc are not live, so
please continue to use existing processes until we make the transition
to the new Portal. Ideally this process of transitioning to the new
portal, led by our forthcoming Technical Director, will not be abrupt
and have sufficient warning for changes. I do not see any major release
for the new portal happening until 2023 (ideally early 2023, but no
promises + more scoping needed.)
> 13. I would like to see IPv6 support
explicitly mentioned as a
> requirement, both for the software, as well as the service. The
> functionality (assignments, allocations) depends on what the plans and
> needs of ARDC are, but being able to use the Portal fully in an
> IPv6-only network is something I believe should be there regardless.
This may be a whole second project, combined with a longer discussion
around whether ARDC should actually manage an IPV6 block. We see cases
for and against it, but ultimately, we need to make sure that our
existing address space is better managed and utilized before taking on
more. That said - your comments are noted.
If TAC / Chris / Board members have additional thoughts to share here,
please do.
> That’s all, looking forward to the
continuing of the development!
Thanks, Antonis! Us too. Very grateful for so much forward movement here.
All the best,
Rosy
Rosy Schechter - KJ7RYV
Executive Director
Amateur Radio Digital Communications (ARDC)
ampr.org
Great work Chris & TAC! Glad to see this document
delivered! I see many
great points throughout the document and I am really happy they made it
there.
Thank you :)
Just some comments and questions that may be helpful from me, in
case you’re interested:
1. Why did you pick GPLv3 as the license? Is this an ARDC requirement or
a decision independently made for the Portal? Is there any chance to
reconsider and pick a license like MIT, BSD, or Apache 2? I feel like
the restrictions that GPL (especially v3) imposes are unnecessary.
We're open to different open source licenses. Why would you choose MIT,
BSD, or Apache 2 over GPL?