Possible workarounds for APIs which support only HTTP

> Oddly, it appears Garmin allows clear text to Garmin domains.

If you send a request to http://garmin.com, you are redirected to https://garmin.com automatically. Same for other Garmin properties that I've just checked.

> My 1030 can access 192.168.*.* without needing https.

Most likely this is because your request is being processed over WiFi and does not have to go through GCM.

> 192.168.*.* doesn't appear to work on Android (I just tried it). It works fine on iOS. That's odd.

I'm not sure what is going on here. As I understand it, if you're using HTTPS, the address you're connecting to should not matter.

>  it's unfortunate that ios behaves in a different way than Android, Android shouldn't be more strict.

The alternative is to have an app behave differently based on the operating system used on the mobile that the Garmin device is paired to. This is also not ideal.

> Most likely this is because your request is being processed over WiFi and does not have to go through GCM.

No. WiFi is disabled on the 1030. If you disable WiFi on the phone running GCM, it fails.

Anyway, how do you not go through GCM?

The makeWebRequest documentation say it uses "Garmin Connect Mobile as a proxy to the web".

>> 192.168.*.* doesn't appear to work on Android (I just tried it). It works fine on iOS. That's odd.

>I'm not sure what is going on here. As I understand it, if you're using HTTPS, the address you're connecting to should not matter.

https isn't being used. Only http. 192.168.*.*  is a private network. Basically no one can use HTTPS on them.

> The alternative is to have an app behave differently based on the operating system used on the mobile that the Garmin device is paired to. This is also not ideal.

But that's what you have currently. The GCM app allows it on iOS and disallows it on Andrioid.

Things work in iOS and fail in Android.

I'm saying the app should work the same on iOS and Android (but it doesn't currently).

================================

It makes no sense for GCM to require the use of HTTPS on private network.

No other Android app does this because it wouldn't work.

No private network uses HTTPS (except in odd, rare situations).

> Anyway, how do you not go through GCM?

The edge devices enable WiFi when they are powered on and not recording an activity. If WiFi is available (not disabled in the settings, and a configured WiFi network is found, WiFi will be used). If WiFi is not available, the device will fall back to using GCM as a bridge.

> https isn't being used. Only http. 192.168.*.*  is a private network. Basically no one can use HTTPS on them.

I'm sorry, you're confusing me. There are 4 combinations here to be concerned with:

1. http://192.168.x.x using GCM/Android
2. http://192.168.x.x using GCM/iOS
3. https://192.168.x.x using GCM/Android
4. https://192.168.x.x using GCM/iOS

The discussion you've started is only about #1 and #2 (you don't care about #3 and #4). Your previous message seems to indicate that #1 fails and #2 works just fine, but this last post indicates that #3 and #4 do not work. I'm pretty sure that they do, and as mentioned, you don't care about these configs because they'd require SSL/TLS support on your IoT device, which is likely not possible... I'm pretty sure you meant to say HTTP in the above quote.

> But that's what you have currently. The GCM app allows it on iOS and disallows it on Andrioid.

I'm pretty sure the requirement to use HTTPS originated with Apple's App Transport Security announcement at WWDC2016, where they said that all iOS apps would be required to use HTTPS.

I'm guessing that the Android implementation was updated to enforce this, and the iOS implementation was just left to fail when the platform rejected the HTTP request. Since that time, it appears that Apple has changed their mind on this requirement (see https://developer.apple.com/news/?id=12212016b), which would explain why this stuff works on iOS but not Android.

> It makes no sense for GCM to require the use of HTTPS on private network.

Well, if you consider the history, it makes perfect sense.

Also, IANA has reserved a 192.168.x.x, 172.16.x.x, and 10.x.x.x as private, so this issue isn't isolated to just 192.168.x.x addresses as you've suggested.

> No private network uses HTTPS (except in odd, rare situations).

I have a NAS device on my home network that uses HTTPS, and has an option to completely disable HTTP access. My wireless router has similar options.

> The edge devices enable WiFi when they are powered on and not recording an activity. If WiFi is available (not disabled in the settings, and a configured WiFi network is found, WiFi will be used). If WiFi is not available, the device will fall back to using GCM as a bridge.

Then, the documentation is wrong.

1. http://192.168.x.x using GCM/Android ==>> Fails
2. http://192.168.x.x using GCM/iOS  ==>> Works fine (this is with 13.x, by the way).

> Your previous message seems to indicate that #1 fails and #2 works just fine, but this last post indicates that #3 and #4 do not work.

No, I've only been talking about #1 and #2. I haven't said anything about #3 and #4 (I presume these both work).

Very few people have https enabled for any of their devices on private networks. #3 and #4 are odd cases.

>Also, IANA has reserved a 192.168.x.x, 172.16.x.x, and 10.x.x.x as private, so this issue isn't isolated to just 192.168.x.x addresses as you've suggested.

I didn't suggest that. 

For most of users, they aren't going to use the other private networks.

I agree it's a problem with every private network.

> I have a NAS device on my home network that uses HTTPS, and has an option to completely disable HTTP access. My wireless router has similar options.

I don't think that's common at all. How many consumers have NAS's?

Do all of the devices on your private network use HTTPS?

> Well, if you consider the history, it makes perfect sense.

No, it makes no sense. It kills any practical option to use IQ for IoT control.

That's what all the developers were complaining about in the other thread.

Wifi works on the 1030 for internet access (HTTP and HTTPS). (I only tried HTTP for a private network).

The sim indicates it should work for the 830 and newer devices as well.

> No, it makes no sense. It kills any practical option to use IQ for IoT control.

It makes no sense to you from the perspective of an IoT device user. It makes complete sense if you look at the history I described above... Apple announced no HTTP access for iOS apps (like GCM). To provide consistent behavior across platforms, a check was presumably added to GCM/Android that would prevent HTTP access. If Apple had continued down the path the had announced, we would now have consistent behavior for both iOS and Android.

Unfortunately (or fortunately depending on how you look at it), Apple changed their mind. Now GCM/iOS doesn't fail for HTTP requests, but Android does.

I'm not suggesting that this is how it *should be*, I'm saying that the current state makes perfect sense considering the history.

> No, it makes no sense. It kills any practical option to use IQ for IoT control.

Not necessarily true. It prevents direct access to IoT devices that don't support HTTPS. Some IoT systems don't have you connecting directly to the device anyway, you connect to the service (hosted outside your home network) and the service talks to your devices. This is how you can turn off Hue lights while you're away from home.

I said "most users". That's still likely true. 

And I didn't say other private networks should be excluded (it should need to be said that all of them should be included).

----------------------------------------------

It's what "should be" that's important. And the "perspective of an IoT device user" seems appropriate here anyway.

As far as I can tell, Apple never implemented the restriction. That's part of the "history" too. Maybe, Apple realized that it would break all sorts of things unreasonably.

----------------------------------------------

Hue lights don't require WAN access.

https://huehomelighting.com/philips-hue-need-internet-connection-work/

Requiring WAN access to control stuff in your home from within your home is a terrible idea. 

I never said it was a good idea. I'm saying we were following the directions outlined by apple (to avoid GCM being pulled from the app store).

Travis.ConnectIQ said:

I'm not suggesting that this is how it *should be*, I'm saying that the current state makes perfect sense considering the history.

???

It doesn't seem anything was a risk of being "pulled" on iOS or Android. There was only a risk of certain things no longer working.

GCM on iOS doesn't have the problem.

Android added a restriction but also allowed apps to have a work-around. That's the part of the history you keep avoiding.

Garmin chose not to apply the work-around (maybe, as a result of not understanding the implications).

It's not only something that shouldn't be. It's something that never had to be.

You never said it was a good idea but it doesn't appear you said it wasn't a good idea either.

I'd see it as some progress if you agreed it wasn't a good idea!