The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

[Hunter Fuller <hf0002 AT uah.edu>]

Hey Paul,

I definitely appreciate the hard work on the app. But I think it is
counterintuitive to suggest that it was announced on this list.

I found these threads:

[[cat-users]] Multiple CA - Android
We do not need multiple CA right now, we already bit the bullet and
made everyone re-run CAT to get our long-lived root installed. So I
did not read this thread.

[[cat-users]] Screen lock not recognized by Android 10 on Samsung Galaxy A51
We have had no user reports of this problem, so I did not read this thread.

It seems if I did not read these two threads in full, there was no
mention of geteduroam on this list.

In fact, the state of eduroam onboarding on Android has been a source
of many tickets at UAH. If we had known there was an alternative to
eduroam CAT, even available for beta testing, we would have leapt on
this. But I also do not have the bandwidth to subscribe to a
high-traffic development list when I have no intention or time
(unfortunately) to do development on the app. Is that really the only
way we could have learned about it? I know the NROs were informed but,
... here we are.

I don't intend to undermine the contributions of all who have created
the new app, it looks great and we will be creating screenshots for
our help desk during the next couple of weeks - very excited about
that. It's truly just a matter of communication - I have no critique
of the app at all - and thank you for all your efforts there.

--
Hunter Fuller (they)
Router Jockey
VBH Annex B-5
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering

On Thu, Feb 25, 2021 at 7:14 AM Paul Dekkers <paul.dekkers AT surf.nl> wrote:
>
> Hi,
>
> On 25/02/2021 11:06, Daniele Albrizio wrote:
>
> > I agree on almost anything you (Stefan Winter) pinpointed in your
> > analysis. And I thank you for the quite exhaustive essay that is very
> > useful for us, local administrators, to understand the vision of the
> > project and the choices taken.
> >
> > I'm indeed glad to evolve to geteduroam.
>
> I'm happy to hear that. (We've been working on geteduroam for over a
> year, given our diverse community and ecosystem and the strong will to
> make an eduroam client for all and not just a few use-cases or
> institutions (as you see more of in the stores). And fully aligned with
> CAT, but with an additional feature of the pseudo-accounts that helps so
> many institutions with eg. Cloud IdPs.)
>
> > I'm also strongly convinced that eduroam is not a monolithic private
> > project, but is backed and used by a huge scientific and education
> > community. The list of names inside geteduroam effort (NORDUnet, DeiC,
> > SURF, Uninett) is a vigorous evidence of this.
> >
> > That said, I'm a bit less in line with the observations of Paul Dekkers
> > about the minor issue of changing icons visible inside phonebook.
> >
> > It's normal that this is seen as a minor issue by developers and NRENs
> > just because they do not have or have few END USERS.
>
> Maybe you didn't mean to, but I feel offended by the implication we
> didn't consider end users. (The capitalization didn't help.)
>
> We carefully included end-users in testing the Apps and workflow; with a
> couple of institutions in (at least 3) different countries, where we
> studied the way they used apps (without interfering/instructions), and
> get their feedback about usability (some also with questionnaires).
>
> But also outside of these structured tests, we received feedback from a
> few institutions that they had a significant reduction in helpdesk calls
> in contrast to their previous workflow. (This is actually with users
> also using geteduroam for eg. iPhones, but also with geteduroam as
> Android app replacement.) That really made us confident.
>
> And for instance the feedback on older and slower devices, as Guy
> mentioned, we needed to consider devices in developing economies too. I
> really appreciated Guy testing this with us, and it improved the clients
> I think as much as we could - back in September 2020.
>
> We learn every time we get feedback from users, and we definitely
> considered this during the development process. And this feedback came
> from various angles.
>
> At this stage, I'm wondering why you apparently stumbled upon some
> issues with the Android App, but didn't help us with this feedback. We
> were aware of this issue, and changed strategies in late November for
> future releases. (As Stefan explained, not for Android <=10.)
>
> > So becomes vitally important that choices and guidelines get shared in
> > advance within the community to collect possible criticalities and
> > suggestions in advance.
>
> I didn't search or want to go through a lot of archives. But in October
> 2020 it was already shared within the NRO community that the "plan is to
> use geteduroam app instead of current android app for CAT" (quoted).
>
> At least December 4, 2020 it was mentioned here on the CAT list, "The
> plan is to suggest geteduroam for Android 8+ instead of the existing
> eduroam CAT app"
>
> And in more words on December 7 it was shared with some more words in a
> different thread even:
> "The current plan is to suggest from the eduroam CAT pages to use the
> geteduroam App on Android 8+, since geteduroam doesn’t do anything
> below. The geteduroam Apps do receive more development and updates, so
> in case we see problems we may be able to fix that in the future. (In
> particular on Android 11 up, we need an entirely new way of configuring
> networks via the API/SDK than what is done in the current eduroam CAT App.)"
>
> At the same time, problems were identified with the Android CAT App,
> that didn't occur with the geteduroam Android App. (Like the multiple
> CAs that don't work well with the old eduroam CAT app, which is
> problematic for some.)
>
> > Medium, big and huge universities have tens or hundred of thousands
> > users that perceive those weird icons as a major problem if not as a
> > device tampering. Furthermore they refer to eduroamCAT or geteduroam as
> > an app of the university, not a third party one (despite all disclaimers
> > that nobody reads). So, if something goes wrong, our institution, not
> > Geant, not Surfnet, goes in the (bad) news. (we can file a disclaimer
> > but it would be too late)
>
> I fully understand this. And also, people scream "eduroam is broken", if
> something doesn't work well that may not even be related to "eduroam" as
> the blueprint and infrastructure that it is. It may be WiFi or ISP
> network issues.
>
> Because there was a big change in the December update of Android, we
> actually communited this within the SURF community (in 4 different
> groups/presentations) in November and December, emphasizing that Android
> would no longer accept not verifying server certificates: which is a
> good thing, but may lead to problems if people didn't consider this.
>
> Because of this (and the positive feedback alltogether), we campaigned
> that geteduroam is a good idea to promote on the campus.
>
> This aligned with the communication that we did in various groups except
> CAT perhaps, but the CAT community already knows about the importance of
> configuring eduroam properly and does so. We wanted more CAT (and
> geteduroam) users to do things right!
>
> > This change affects user's workflow towards several different
> > applications. Usually when I have to communicate with a contact of mine,
> > I start from phonebook, I rapidly scroll which is the best method to use
> > that is available also to the other side and I choose this to communicate.
> > It's part of the main communication workflow when we use a smartphone.
> > The list of channels is growing rapidly with technology including fast
> > payments, different level of privacy chats, video, file sending, etc.....
> >
> > I don't see this as a minor problem. It's indeed not a bug, is a bad
> > choice. Normally we don't share eduroam profiles using whatsapp or
> > Signal, but we publish them on well known websites.
>
> I believe it was also with some OEM-based browsers. It was an example.
>
> There is an upside and downside to a lot of decisions. And some users /
> institutions do A, other do B.
>
> This is in part what you get with software that is being developed,
> sometimes you make a good choice sometimes you don't.
>
> > So, even knowing we are late with Android 10 and 11 support, would it be
> > possible to DELAY geteduroam adoption after the removal of the
> > responsible mime type?
> >
> > User complaints on this general and widely adopted things has to be
> > handled with a certain helpdesk effort and if "glitches" can be avoided
> > it should be done in advance.
>
> I equally have users that I had to explain to "why geteduroam still
> wasn't suggested from CAT". And helpdesks that tell me about their
> reduced load since they suggest geteduroam.
>
> > Sorry for complicating your already hard work, I'm open to discussion or
> > adverse opinions.
>
> I'm glad you share it, but also I hope you understand why I feel a bit
> sad now. The reply from Stefan is already very complete, but this made
> me feel I had to reply myself, also since you mentioned me.
>
> Paul
>
>
> > Daniele
> >
> > On 25/02/2021 08:28, Stefan Winter wrote:
> >> Good morning!
> >>
> >> After belatedly (list issues...) seeing the thread triggered by the
> >> mention of geteduroam, I would like to provide some background on that
> >> app, our choices, etc.
> >>
> >> First of all, the only thing that is going to change with our
> >> deployment is the advice which app to download from Play Store. That's
> >> a sentence of prose in the product configuration, not a code change.
> >> This means we could easily not do the change and continue pointing to
> >> the eduroamCAT app as usual, if we think that that is the better idea.
> >>
> >> I do not think that that is the better idea.
> >>
> >> First, some background.
> >>
> >> Android has undergone a rather drastic change of its Wi-Fi
> >> configuration APIs. The eduroamCAT app has only ever supported what is
> >> now the old-style, deprecated WifiEnterprise API. That API became
> >> fully usable from Android 4.3 (hence the minimum OS required to run
> >> the app is just that) until Android 9. On Android 10, it exists, but
> >> is deprecated. With Android 11, it's gone. I have had to deal with
> >> support questions of the eduroamCAT app on multiple devices with
> >> Android 10 where it already didn't work properly.
> >>
> >> I understand the confusion around geteduroam, as the term is used for
> >> two largely independent things. The part we care about here is
> >> "geteduroam the Android app". It is a full-featured replacement for
> >> all things eduroamCAT has been doing, with a nice UI, and with
> >> awareness of the API changes. Yes, it supports all EAP types. No, you
> >> do not have to abandon CAT or change anything in the configuration. It
> >> is simply a drop-in replacement for the old app. It supports only
> >> Android versions from 8 upwards, including 11 and future versions.
> >>
> >> ("geteduroam" is also the term used for a system that provisions
> >> EAP-TLS based 'pseudo-credentials' to users logging into a portal with
> >> their SAML/OIDC credentials, with the aim that eduroam logins are
> >> decoupled from SSO usernames/passwords. When using that system it also
> >> uses the same geteduroam app to configure /those/ credentials, but
> >> that does not mean the app requires this pseudo-credentialing in any
> >> way; nor that app support is limited to EAP-TLS. This conflict in
> >> naming is unfortunate and I'm very sorry if that led to confusion over
> >> the purpose or workflow of the app. In fact, during the design of the
> >> geteduroam app it was given substantial attention to the requirement
> >> that it integrates and supports "normal" CAT and password-based EAP
> >> types just as well as the "special" credentials; it also uses the CAT
> >> APIs for institution and profile listing, etc.)
> >>
> >> Now, what to do.
> >>
> >> The history of API levels and app support above alludes to why the
> >> download button consolidation for Android Tomasz wrote about yielded
> >> three distinct buttons:
> >>
> >> - Android <8 - only eduroamCAT supports these API levels. The only
> >> support option is to suggest users to install the eduroamCAT app. That
> >> is what the button does (and its per-version predecessor buttons did)
> >> - Android 11 - only geteduroam supports these API levels. The only
> >> support option is to suggest users to install the geteduroam app. That
> >> is what the new Android 11+ button does, and there are no alternatives.
> >> - Android 8 to 10 - this is the only space where there is leeway of
> >> decision. We can point to any of the two apps, and both should work.
> >> Since I know cases where Android 10 with eduroamCAT does not work (and
> >> all of those resolved successfully when suggesting the use of
> >> geteduroam instead), I believe pointing to geteduroam is the better
> >> choice.
> >>
> >> I use geteduroam myself since earlier days and don't see drastic
> >> problems with it that (in my personal opinion) warrant sticking to
> >> eduroamCAT for Android 8-10. If people think we should anyway, then it
> >> is certainly a possibility. But when thinking about this, keep in mind
> >> that geteduroam is not a question of "yes" or "no". The options are
> >> "now" or "soon" - it will gain momentum all by itself as Android
> >> versions advance, and the old app experiences more breakages over time
> >> with OS updates that potentially treat the old APIs as a step child.
> >>
> >> Greetings,
> >>
> >> Stefan Winter
> >>
> >> Am 24.02.21 um 16:56 schrieb Stefan Winter:
> >>>
> >>> Hello!
> >>>
> >>>
> >>> It's been little while since our last update of eduroam CAT. A number
> >>> of small bug fixes accumulated over time, and there are a few "mini"
> >>> features that deserve cutting a release 2.0.4.
> >>>
> >>>
> >>> The notable features are:
> >>>
> >>>   * [FEATURE #1] The system now sends out notification/alert mails if
> >>>     a significantly security relevant parameter was changed. The
> >>>     mails go to the NRO admin. Significant changes are:
> >>>     - change of institution name
> >>>     - addition of a new root CA (with more prominent WARNING if the
> >>>     new CA has the same DN as an existing one)
> >>>     - addition of a new acceptable server name
> >>>   * [FEATURE #2] support negotiation of TLS versions higher than 1.0
> >>>     while still rejecting SSL2 and SSL3
> >>>   * [FEATURE #3] realm reachability checks now produce a WARNING
> >>>     level message if the EAP server does not support TLS1.2 or higher
> >>>   * [FEATURE #4] check whether SRV-discovered hostname and
> >>>     certificate hostname match
> >>>
> >>>
> >>> Also, we are happy to add a new translated language: welcome, Română
> >>> (Romanian).
> >>>
> >>>
> >>> You can find the tarball on GitHub as usual (
> >>> https://github.com/GEANT/CAT/releases/download/v2.0.4/CAT-2.0.4.tar.bz2
> >>> ) but for most of you the most interesting question is probably when
> >>> the new code will be deployed on https://cat.eduroam.org.
> >>>
> >>>
> >>> We have reserved a maintenance slot for that tomorrow, 1300 CET. The
> >>> expected downtime is in the seconds range, so you would be
> >>> particularly unlucky to notice at all.
> >>>
> >>>
> >>> As usual, if you notice new buggy behaviour of any sorts after the
> >>> update, please let us know.
> >>>
> >>>
> >>> Greetings,
> >>>
> >>>
> >>> Stefan Winter
> >>>
> >>
> > --
> > Daniele ALBRIZIO -daniele.albrizio AT units.it
> >           Tel. +39-040.558.3319
> >    UNIVERSITY OF TRIESTE - Network Services
> >       Unita' di Staff Reti di Ateneo
> > via Alfonso Valerio, 12 I-34127 Trieste, Italy
> >
> > To unsubscribe, send this message:
> > mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
> > Or use the following link:
> > https://lists.geant.org/sympa/sigrequest/cat-users
> To unsubscribe, send this message: 
> mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
> Or use the following link: 
> https://lists.geant.org/sympa/sigrequest/cat-users