Connect version 4.20 broke local http access?

Yeah, for me and my phone this could work... but, I can't really expect the couple thousand of download's users to do this. Many of them could barely configure their WIFI. :)

Mostly this utility was for me and I just posted it up because I'm nice and hoped others might find value. If Garmin wants to make things so painful, I just won't bother with their platform I suppose. 

Once plain text to localhost is allowed, the door would  be open to salvage http connectivity to LAN addresses by running a (custom) proxy app on the phone that has it's own network-security-config. Wasteful and cumbersome, but for sufficiently exotic but mission-critical use cases it might be good enough.

Thanks for the update. 

I however noticed that the solution is to add only 127.0.0.1 to the exceptions list. When are the other use cases fixed?

Kr Arnold

We have a solution coming that will hopefully address the majority of the cases mentioned in this thread. I've updated the issue status accordingly.

As an aside, I saw this comment below:

"I suspect that it is one of those organizational nightmare things where one group within the team fully understands the problem and the fix, but all decisions like that are strictly limited to another group..."

While I wouldn't quite call it a nightmare, this does fairly accurately describe the situation. :) My team focuses on Connect IQ and we do work closely with the Garmin Connect Mobile team. However, we're separate teams, and GCM encompasses much more than just Connect IQ-related features, so we needed time to communicate the issue, make sure the use cases were understood, evaluate security risks, and schedule time into planned work for the fix. My intent is not to make excuses—I'm not particularly pleased with our response time on this—but I do want everyone to understand that this was a multi-team effort, and was not something that the Connect IQ team could just handle unilaterally.

I apologize for the delay and the apparent lack of meaningful updates over the past few weeks. It's encouraging to me that there has been so many vehement responses, because it demonstrates how valuable our platform is to you.

Could this not be implemented with an intentional flag indicating an http only interface? Or, perhaps a user-defined exception list? 

I have a direct WIFI connection from the phone to a Gopro that has a fixed IP address of 10.5.5.9 used in my app. Commands are sent to this device such as:

http://10.5.5.9/gp/gpControl/status  

...in order to control it. So, since only a localhost IP of 127.0.0.1 will be allowed, I do not believe this would work for me.