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

[Stefan Winter <stefan.winter AT restena.lu>]

Hello!

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 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.

Thanks for your thoughts, much appreciated. Android is perhaps the most challenging device type we have to care about, and we are maneuvering in a very complex space, with many versions, API levels, enforced deprecations (sadly, more on that below) and per-vendor customizations on top.

I realise that talking more about these things and earlier would have more easily brought everyone onto the same page. FWIW, those discussions did take place, in the open, mostly on the eduroam tech development mailing list. And I still think that was the right place to take those discussions - as a mere "consumer" of CAT as an IdP admin, this list here should be more down to earth. Everyone is free to subscribe to development AT lists.eduroam.org (https://lists.eduroam.org/sympa/subscribe/development?previous_action=info) if they want to be more deeply involved in technical development, before things reach a certain maturity level. Also, eduroam National Roaming Operators are typically more deeply informed and can get the word out to IdPs.

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.

So becomes vitally important that choices and guidelines get shared in advance within the community to collect possible criticalities and suggestions in advance.

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)

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.

FWIW, I think we all have users behind us, and I always try to look at changes with a sense of "how many calls will our helpdesk get due to that". The people developing geteduroam did not do so in an ivory tower; it was meant to solve real-world problems for actual users out there. Actually, from what I hear (but I was less involved in the actual development than with eduroamCAT) there were large-scale tests, also involving big universities, in the nordic countries. And the app was very well received there. I leave it to Paul to get into more details (he's off today). Either people out there see this as a minor problem anyway, or maybe it just doesn't occur on every device. I for one never noticed any icon changes on my phone. But that's a Fairphone FP3 running an Android AOSP Google-free build ( e/os/ 0.12) and I'm used to have icons looking differently from the rest of the world. The good news is that the app works absolutely fine even in such exotic environments.

We also shouldn't forget that starting at Android 8 allowed the new app to cut many old chords and provide essential new features that the old app didn't - the ability to load more than one root CA into the device, so as to allow root CA rollover, is one of the major things there. I'm sure you can appreciate the amount of /reduction/ of helpdesk problems that this feature (finally) brings to you if you ever need to roll over a root CA.

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.

Sorry for complicating your already hard work, I'm open to discussion or adverse opinions.

Here comes the sad bit I mentioned above. It's even almost absurd, but it is a Google decision we could not reverse despite talking to key personnel behind closed doors.

It is not possible to update the apps (neither eduroamCAT, nor geteduroam) for Android 8 and 9 any more in Play Store. Never again. Google introduced a restriction that any new version upload for a Play Store app needs to target a certain minimum API level from a date some months in the past (I can look up the exact day if someone's curious). The API level is the one used in Android 10. Trying to publish an app update for older versions is not allowed any more.

So, on Android 8 and 9, the apps are what they are. We can sure publish APK files with bug fixes outside Play Store, but as I understand it this is something that doesn't reach typical end users.

We could update with a min target of Android 10. The catch here is that once an app targets a level which contains the new API, the app can at runtime only use the new API. As it happens, the new API on Android 10 was still ... peculiar, and led to unintuitive UI. To the extent of saying: you really want to use the old API on 10, and leave the new API only to 11. If we do follow that line of thinking, there can also "never again" be an update to the geteduroam app for Android 10, because it locks itself out of the old API when updated.

All of this became known to the development team and acted upon, and as the deadline for the last possible submission loomed, people were working in weekends and long days to fix all outstanding bugs and get the app into a great shape. I do believe they should be commended for doing that.

Sure enough, we are able to update the app for Android 11 and the MIME types are something that can be fixed there.

In the light of the above, Android 8-10 is in a "take it or leave it" state. Still, given the vastly positive feedback that has generally been received, we do not believe that pointing to the new app from CAT is bad; the icon issue is but one nuance where the majority of other changes the app brings outweigh this. Maybe there are remaining bugs, but there also some in eduroamCAT, especially on Android 10.

This is an imperfect situation, so we have to make a choice.

Greetings,

Stefan Winter

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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature