[Deferred] SDL 0245 - WiFi Transport: Sharing SSID and password with Mobile Proxy

[theresalech]

Hello SDL community,

The review of the revised proposal "SDL 0245 - WiFi Transport: Sharing SSID and password with Mobile Proxy" begins now and runs through June 2, 2020. Previous reviews of this proposal took place July 31 - August 20, 2019, September 25 - October 15, 2019, October 30 - November 18, 2019, January 15 - January 28, 2020, February 19 - February 25, 2020, and April 15 - April 21, 2020. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0245-sharing-wifi-ssid-and-password.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

https://github.com/smartdevicelink/sdl_evolution/issues/799

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study? Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you, Theresa Lech

Program Manager - Livio theresa@livio.io

[joeljfischer]

This would be a vast improvement over the existing situation.

2. The iOS details use iOS 11.0+ APIs, but the iOS library supports iOS 8.0+. Please provide details on what to do with older devices.

3. There is no discussion of the consent of the user to connect the device to the WiFi network. Please provide details on how the user's consent to connect to that WiFi network should be accomplished. Is this automatic through iOS (I was unable to test the example code you provided due to the need for Apple entitlements, see below, 4)? What are the driver distraction implications?

4. The iOS details for connection require Network Extensions methods. But these methods require special entitlements from Apple to use. Please provide details on if you intend all video streaming developers to go through the process of getting this information.

EDIT: (1) was found to be irrelevant, so I edited to remove it.

[BrettyWhite]

A concern of mine is the broadcasting of network information. I know in the proposal it is stated that changing passwords is recommended, but based on the language it is not guaranteed to happen.

In the case that a user changes the wifi password on their head unit, would it broadcast 2 SSIDs (the network SSID and PW set by the user, and one for SDL)? Otherwise this could expose customer information (many people probably would use the same wifi password as they do at their homes).

Additionally, exchanging the data in a Control Frame, which to my knowledge, at this point in SDL is not and can not be encrypted. If someone like @JackLivio could confirm, I'd be appreciative. If this cannot be encrypted, I highly advise finding an alternative route for this information to be securely passed through, or wait until a total encryption solution is integrated into SDL.

[BrettyWhite]

Also, would SDL developers be forced to implement:

<uses-permission android:name="android.permission.CHANGE_WIFI_STATE" />

or would that permission be optional? I can think of many cases where application developers and users would not like to see apps that are free to change WIFI states.

[ashwink11]

Thank you @joeljfischer and @BrettyWhite for reviewing this proposal.

2. In case of an older iOS device, the library will not try connecting to WiFi on receiving transport event update. In this case, I propose to keep behavior as it is today. HMI or App will be responsible to show the appropriate message to the user to connect WiFi manually or to use another transport.

3. Yes, the iOS device manages this. iOS device would show popup to the user to allow WiFi connection. I would think that in case of WiFi connection is not established due to pop up being ignored or the user does not allow it. HMI or App will be responsible to show the appropriate message to the user to connect WiFi manually or to use another transport.

   In case, the concern is regarding pop up being shown to the user while driving, the library may not attempt automatic WiFi connection when it receives Driver distraction ON notification. However, I do not think we should do this, because:

• secondary transport is required for high bandwidth requirement, video streaming apps, the user would anyway need to launch the app and keep it in the foreground on the phone when using that app on SYNC.
• Driver distraction rules are not applicable to all countries.
• Users can always neglect pop-ups shown on the iPhone screen when driving.

4. We will need to provide an API to the app developer to set a WiFi autoconnection flag. If this flag is set library will attempt auto-connection on receiving credentials. If this flag is unset, the app does not attempt connecting to WiFi. For example setAutoConnectWiFi in SDLManager iOS. Please do let us know if you have any other suggestions.

   In the case of Android, we can achieve this behavior by checking if permissions are granted. So, we do not need a flag stated above. If permissions are granted then the library will attempt WiFi connection otherwise it won't.

but based on the language it is not guaranteed to happen.

True. HMI can decide this behavior.

In the case that a user changes the wifi password on their head unit, would it broadcast 2 SSIDs (the network SSID and PW set by the user, and one for SDL)?

No, proxy will receive only one SSID. As mentioned in a proposal. 0141-multiple-transport we need to provide network interface in smartdevicelink.ini file for SDL Core. The system should provide WiFi credentials of network active on specified network interface.

... expose customer information

This details will be provided by primary transport. I believe the security provided by this transport is enough to communicate network credentials. SDL enabled apps currently uses these transport to communicate a wide range of data including private data such as location info.

Regarding App permissions in Android:

Apps should request these permissions. As mentioned in the guide here.They should provide an appropriate rationale for using this permission so that the user can make an informed decision whether they should allow the app to connect or not. The proxy should attempt WiFi connection only if permissions are granted.

[BrettyWhite]

As mentioned in a proposal. 0141-multiple-transport we need to provide network interface in smartdevicelink.ini

True this provides an interface, but it does not provide security credentials. The current implementation assumes the devices are on the same network and the primary transport provides an address.

It looks like as of protocol V5, control frames can be encrypted (https://github.com/smartdevicelink/sdl_core/issues/2142). Maybe for this feature we should require protected services due to the increased risk of transmitting credentials

[joeljfischer]

2.

HMI or App will be responsible to show the appropriate message to the user to connect WiFi manually or to use another transport.

I think this proposal should specify which and how. Specifically, the HMI should do it based on the RegisterAppInterface DeviceInfo struct.

3.

a.

I would think that in case of WiFi connection is not established due to pop up being ignored or the user does not allow it. HMI or App will be responsible to show the appropriate message to the user to connect WiFi manually or to use another transport.

How would the HMI know unless we added an RPC? Or the app, for that matter? Only the proxy library would know unless this proposal added an interface between this code and the app and wants to burden the app developer with displaying a message to the user via either the phone or SDL?

b.

In case, the concern is regarding pop up being shown to the user while driving, the library may not attempt automatic WiFi connection when it receives Driver distraction ON notification. However, I do not think we should do this, because:

I think that we should prevent this from happening while the driver is distracted.

• secondary transport is required for high bandwidth requirement, video streaming apps, the user would anyway need to launch the app and keep it in the foreground on the phone when using that app on SYNC.

While this is true, this is a far less than ideal situation, and we'd be adding an additional popup that users would have to read and respond to, on their phone, while distracted driving. This is illegal in many jurisdictions.

• Driver distraction rules are not applicable to all countries.

So we ignore them where they are applicable?

• Users can always neglect pop-ups shown on the iPhone screen when driving.

But will they? If they're attempting to accomplish a task and the HMI (I'm assuming) is directing them to read and respond to a popup on their phone, they are unlikely to neglect this task and simply abandon what they're trying to do.

4. Your response did not answer this question. I want to be clear; we are asking all video streaming app developers to request this entitlement from Apple, correct? What if Apple denies this request? Have you talked to Apple about this feature?

I do agree, however, that consent needs to be given by the developer to enable this feature through their app as well, and a StreamingMediaConfiguration option should be added, disabled by default.

I'm going to assign Brett's first point as (5):

This details will be provided by primary transport. I believe the security provided by this transport is enough to communicate network credentials.

There is effectively no security on this transport and it can be read by the app, or, theoretically anyone with a man-in-the-middle attack. I don't know what you mean by:

This details will be provided by primary transport...SDL enabled apps currently uses these transport to communicate a wide range of data including private data such as location info.

If by this you mean that SDL apps transmit data over without encryption over the RPC protocol, you are correct, but WiFi passwords seems like a next level issue, primarily because it's not information that the app is already knows. They already know the user's location, but they definitely do not know their WiFi password.

New items:

6. There is no information on detecting if the device is already connected to the target wifi network. Is this handled by the APIs already, or is this something that needs to be added? The HMI has no way of knowing if the device / app is already connected to the WiFi network, so it will probably always have to transmit those credentials.

[joeygrover]

I do believe a feature like this needs to be included to actually make WiFi as a secondary transport viable. I do have some concerns including the already stated concerns over user consent and security vulnerability.

3.c. User consent is important, if the phone switches over to connect to the module's WiFi AP, it is assumed that all other internet traffic would go through this connection as a first attempt. This could eat at the data plan in the vehicle as an unintended action of connecting to it. For example, if a Navigation app implements this behavior, switches the WiFi while the user is also streaming music, the music will start streaming over the module's modem if an internet connection is active. This could incur cost to the user, app, or OEM.

5.b.(?) I don't believe the answer provided for using<uses-permission android:name="android.permission.CHANGE_WIFI_STATE" /> is clear. Are all app developers going to be requested to include this new permission? Is it possible we give them an explanation of why it's needed? Pushing it off on the developer will likely be a poor choice. Developers are very cautions about what permissions they are adding to their apps so this is an important issue that can't be skimmed over.

7.

If MultipleTransportsEnabled is set as true and SecondaryTransportForBluetooth is WiFi in smartDeviceLink.ini configuration file. HMI should create a WiFi Access Point and the WiFi credentials should be communicated to the mobile proxy.

Is this a hard responsibility of the HMI? I'm not sure if all HMI's will have access to the APIs that can turn on a WiFi Access Point, and to create one with dynamic credentials.

8.

  <function name="OnWiFiTransportAvailable" messagetype="notification">
      <description>HMI must notify SDL about WiFi Access point.</description>
        <param name="ssid" type="String" minlength="1" maxlength="30" mandatory="true">
        <description>name of the WiFi ssid</description>
      </param>
        <param name="password" type="String" minlength="1" maxlength="30" mandatory="true">
        <description>password to use to connect AP</description>
      </param>
        <param name="securityType" type="WiFiSecurityType" mandatory="true">
        <description>security type of WiFi AP</description>
      </param>
  </function>

Is there a reason why the maxlength is 30 for both ssid and password? SSIDs can be up to 32 characters, and I believe the passcode low max limit is 63 characters. Also the parameters are all mandatory, would it make sense if the access point didn't have a password and used WIFI_SECURITY_NONE? For xcample the SSID isn't broadcasted but is changed each connection which would make it about as secure as sending the password through plain text but no need for the password param. I would vote that password is moved to mandatory=false.

9.

When will the app connect to the WiFi AP? As soon as it gets the update?I would assume no. How about when the app requests a service to be started that requires a WiFi connection? What happens if multiple apps are trying to connect the phone to that network at the same time?

10.

On successful connection or if the mobile device is already connected to WiFi access point mentioned in Transport Event Update, core and proxy should follow use case described in a proposal Supporting simultaneous multiple transports.

There is a bit of hand waving to this piece. How will the mobile libraries know that there was a successful connection to the network?

[ashwink11]

The proposal is created keeping in mind, that apps can communicate/work with HMI using primary transport i.e. USB or Bluetooth and secondary transport configured in smartDeviceLink.ini file is WiFi. WiFi is required only for high bandwidth data requirements, for example, Video streaming Apps.

If Apps want to use secondary transport, they can choose, if they want to use the WiFi auto-connect feature or not. If so, they would need to add entitlements or permissions. If not user can manually connect WiFi and use their App.

The proxy should provide APIs to configure on/off WiFi auto-connect feature.

2. From this proposal, ...HMI may implement an error message stating that Wi-Fi or USB transport is required for a mobile projection app to work.

Although the above-mentioned proposal is for App resumption. I would propose to extend the behavior of HMI showing error message... to video streamings apps registered using just primary transport. Please do let me know your thoughts. For template-based Media and Non-media apps, they will continue to work using primary transport.

3.a. We do not need any new RPC to let HMI know that WiFi connection failed. I do not think, HMI would need this information. If proxy failed to connect WiFi, HMI will consider a case similar to point 2 discussed above and HMI should show an appropriate message to the user that WiFi needs to be connected to use App.

3.c. A mobile device will show user consent pop-up for either requesting permission (Android) or before connecting WiFi(iOS). These pop-up are managed by the system. If we add one more pop-up, there will be two pop-ups in total to connect to WiFi. I would recommend this user consent to be added in HMI which would be shown once when the device connects to WiFi on HMI.

This could eat at the data plan in the vehicle as an unintended action of connecting to it. For example, if a Navigation app implements this behavior, switches the WiFi while the user is also streaming music, the music will start streaming over the module's modem if an internet connection is active. This could incur the cost to the user, app, or OEM.

This issue would come even if the user manually connects to WiFi. So, I recommend showing this SDL specific user consent on HMI.

4. I did not speak to Apple. If the request of entitlements is denied, the app developer needs to disable WiFi auto-connect, as suggested in your comment, using StreamingMediaConfiguration. The proxy will not connect WiFi if this setting is disabled. User will need to manually connect WiFi to use Apps.

5. As @BrettyWhite pointed out encryption is already available in protocol V5, this proposal does not change this behavior.

WiFi passwords seem like a next-level issue

I am not a data privacy expert, but I do not agree with this statement. On researching further on this issue, location data is considered as Personally identifiable information (PII) from here. I would still consider security provided by primary transport should be enough to share WiFi credentials of a non-stationary device if this was working without any issue earlier for other data.

Also, if we compare other solutions, like Wireless projection, Android Auto and CarPlay, credentials are transferred using Bluetooth using their respective protocols. Not that I want to copy their solution "as is", but I don't see any reason for not implementing this proposal in the dearth of encryption capability.

5.b No, all apps do not need to request these permissions. As discussed for iOS, an API should be provided for Android as well, so that App developer select if they want to enable/disable WiFi Autoconnect. If this setting is enabled, the android proxy will check if these permissions are "granted" before attempting a WiFi connection.

In the case of iOS proxy, if WiFi auto-connect is enabled, the proxy can directly use APIs to connect WiFi.

6. In that case, iOS API to connect WiFi will return error "already associated".

However, APIs are available to get current WiFi information as well. In iOS new entitlement need to be used, please find info here.

If we are concerned about App getting Apple approval to use entitlements. We can rely on the error returned by iOS API's.

7. Usually, on Linux, Android and QNX platform, a component called "wpa_supplicant" are used. HMI can use APIs provided by this component to create access point either by using predefined credentials or dynamically created credentials.

8. I will include changes as mentioned.

9.

When will the app connect to the WiFi AP? As soon as it gets the update?

I assume, as soon as WiFi credentials are available, the proxy can start a connection.

How about when the app requests a service to be started that requires a WiFi connection?

a. If the proxy tries WiFi connection when service is to be started, it will delay the App use case, as service would start when App is launched by the user on HMI. b. In case, WiFi connection from proxy fails due to some reasons, HMI will have to wait, first for WiFi connection and then for Service setup, downloading certificates and so on.

Could you please share your thoughts on not connecting WiFi as soon as credentials are available?

10. The proxy should check the error callbacks and return values provided by platform APIs. In case of any errors or WiFi connection failed, the proxy should consider case similar to point 2 discussed above and rely on the user to connect manually.

Alternatively, the proxy could use additional permissions to access current WiFi connection state and check if the connected WiFi is the same as that received from the core. However, as stated above there are concerns regarding Apple approving required entitlements.

[joeljfischer]

From your intro:

If Apps want to use secondary transport, they can choose, if they want to use the WiFi auto-connect feature or not...The proxy should provide APIs to configure on/off WiFi auto-connect feature.

There is no API in the proposal to enable / disable this, are you saying that it will be added in a revision of the proposal?

2.

I would propose to extend the behavior of HMI showing error message... to video streamings apps registered using just primary transport.

This cannot be the case. USB is a primary transport (at least on iOS).

3.a.

We do not need any new RPC to let HMI know that WiFi connection failed. I do not think, HMI would need this information. If proxy failed to connect WiFi, HMI will consider a case similar to point 2 discussed above and HMI should show an appropriate message to the user that WiFi needs to be connected to use App.

How would the HMI get this information otherwise? Unless you're assuming that the HMI would communicate with the network chip. But even then, how would it know that the correct device connected?

3.b. Has not been responded to.

3.c.

If we add one more pop-up, there will be two pop-ups in total to connect to WiFi. I would recommend this user consent to be added in HMI which would be shown once when the device connects to WiFi on HMI.

If the consent is only added after the connection to the WiFi network, then it would have to disconnect from the network. If they were connected to a different network, they would now be disconnected. The consent prompt would have to happen before the device prompt.

4. I would appreciate if you could add language to this proposal specifying that all apps supporting this feature will have to request entitlements from Apple, along with a link to the place developers will have to go to in order to request the entitlement. There should also be language in the proposal that this information should be added to the app certification guidelines as well. Finally, I would recommend that the Developer Relations Committee talk to Apple about this feature.

5.

As @BrettyWhite pointed out encryption is already available in protocol V5, this proposal does not change this behavior.

I've believe that this control packet is not encryptable because it's on the control session. This password would be plaintext.

I am not a data privacy expert, but I do not agree with this statement. On researching further on this issue, location data is considered as Personally identifiable information (PII) from here.

You're missing my point here. When we provide location details, we're not providing the developer of the app with something they don't already have. Plus, the user has a consent dialog that they need to pass through before any vehicle data is shared.

I would still consider security provided by primary transport should be enough to share WiFi credentials of a non-stationary device if this was working without any issue earlier for other data.

Transports generally do not provide security. There is no security inherent to Bluetooth, for example, so I'm not sure your statement makes sense.

Also, if we compare other solutions, like Wireless projection, Android Auto and CarPlay, credentials are transferred using Bluetooth using their respective protocols.

I want to clarify. You're saying that AA and Carplay transmit wireless SSID and password over Bluetooth in plaintext? Even if that's the case, these credentials are not provided to the app developers, like they would be here, correct?

6. Using the error is probably a just fine way to go.

9.a.

If the proxy tries WiFi connection when service is to be started, it will delay the App use case, as service would start when App is launched by the user on HMI.

I'm not sure, but is the TransportEventUpdate not sent when the video service starts?

b.

In case, WiFi connection from proxy fails due to some reasons, HMI will have to wait, first for WiFi connection and then for Service setup, downloading certificates and so on.

How would the HMI know that the connection failed? What are the retry cases here? Is there a timeout for failure (e.g. 10 seconds)?

[ashwink11]

There is no API in the proposal to enable/disable this, are you saying that it will be added in a revision of the proposal?

Yes, I will add this in revision.

2. From proposal 0141-multiple-transports

Secondary transport for Bluetooth can be configured using smartdevicelink.ini file. So, I understand, primary transport can be Bluetooth. Please do let me know if this is changed now.

3.a.

How would the HMI get this information otherwise?

HMI will not get any information for failed WiFi auto-connect. Proxy as well could not do anything if Wifi auto-connect failed. User will need to connect WiFi manually, as they would do today to use the app.

3.b & 3.c.

I will get back to you on this.

4. Sure, I will add the following info.

Steps to enable entitlements:

1. Apple developer/enterprise account needed to add required entitlement in provisioning profile.
2. Enable required entitilements for your project in XCode. https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_networking_hotspotconfiguration https://help.apple.com/xcode/mac/current/#/dev88ff319e7

As per link below, we need not request entitlement from Apple if we are using Wi-Fi Configuration. https://stackoverflow.com/questions/40285863/network-extension-entitlement-how-to-enable-it

5.

You're missing my point here. When we provide location details, we're not providing the developer of the app with something they don't already have. Plus, the user has a consent dialog that they need to pass through before any vehicle data is shared.

From the previous comments about "man-in-the-middle attack", I understand that point 5 was about concerns regarding transferring data to mobile device on unencrpted channel and not about who is going to receive it. We will also have user consent pop up as discussed in point 3 above to share and auto-connect WiFi.

I was saying that until recently SDL used transport without encryption to transfer data to the mobile device.

The information in AA and CP is sent as per their protocol. As SDL has its own protocol, it would be a similar case. Also, you might be aware that iAP2 has its own authentication mechanism. This authentication mechanism is used for iAP2 connection for SDL as well.

9.a.

Please check section Transport disconnection

TransportEventUpdate will be sent, if WiFi transport becomes unavailable,

9.b.

HMI will not get any information for failed WiFi auto-connect. Proxy as well could not do anything if Wifi auto-connect failed. User will need to connect WiFi manually, as they would do today to use the app using WiFi.

[ashwink11]

3.c

We propose to show user consent on HMI.

1. HMI shows user consent to share WiFi details and auto-connect with the mobile device.
2. If the user allows, Transport Event Update sent with WiFi credentials
3. Mobile proxy attempts WiFi auto-connect feature if it's enabled by App.

[BrettyWhite]

5.

From the previous comments about "man-in-the-middle attack", I understand that point 5 was about concerns regarding transferring data to mobile device on unencrpted channel and not about who is going to receive it. We will also have user consent pop up as discussed in point 3 above to share and auto-connect WiFi.

User consent does not mean that we should not to the right thing with protecting / encrypting their data. Just because it adds complexity does not mean that it should be ignored.

I was saying that until recently SDL used transport without encryption to transfer data to the mobile device.

Unless the transport is protected, the data is plain text. I don't recall seeing language that using this system will require encryption, such as video streaming currently does.

Carplay encrypts their data, while SDL partially does, in certain cases (such as video streaming). see page 29: https://www.apple.com/business/site/docs/iOS_Security_Guide.pdf

Per the discussion during the meeting regarding RPC Message protection, it was agreed that a transport level encryption should be added, and this is a perfect example of how that would be helpful.

This authentication mechanism is used for iAP2 connection for SDL as well.

What about the android devices over BT? AOA?

EDIT: added discussion number for easier following

[ashwink11]

5.

Carplay encrypts their data, while SDL partially does, in certain cases (such as video streaming).

Can we please limit our discussion to WiFi credentials sharing?

see page 29: https://www.apple.com/business/site/docs/iOS_Security_Guide.pdf

Page 29 in the shared document refers to HomeKit. I am not able to find any info in this shared document where it says, WiFi credentials shared are encrypted for CarPlay. Could you please let me know correct page no.?

If you have access to Apple iAP2 spec, I would recommend you to check that. Unfortunately, we won't be able to share iAP2 spec details.

[ashwink11]

3.b. I will include in a proposal that, the proxy should attempt WiFi auto-connect when DD is OFF.

[BrettyWhite]

Can we please limit our discussion to WiFi credentials sharing?

You used AA and CP as an example above before I brought it up, I was simply continuing that discussion.

From page 29 at the top:

AirPlay audio and CarPlay video streams utilize the 
 MFi-SAP (Secure Association Protocol), which encrypts communication between the accessory and device using AES-128 in CTR mode. Ephemeral keys are exchanged using ECDH key exchange (Curve25519) and signed 
using the authentication IC’s 1024-bit RSA key as part of the Station-to-Station (STS) protocol.

You are correct, we do not have the iAP2 spec. However, that only covers half of all SDL users. Please also discuss how you plan to handle Android's transports. In my eyes, this is entirely necessary for a proposal like this to be resolved before this is approved and implemented.

[ashwink11]

You used AA and CP as an example above before I brought it up, I was simply continuing that discussion.

I brought up WiFi credentials sharing for AA & CP in the discussion. I never said video streaming is not encrypted. Video streaming can be encrypted in SDL as well.

I mentioned AA and CP, to mention that they use Bluetooth to share WiFi credentials using their respective protocol.

From my previous comments,

I was saying that until recently SDL used transport without encryption to transfer data to the mobile device.

If we can use Bluetooth for transferring location data which is considered as Personally identifiable information (PII), then why not WiFi credentials?

Edit: Added Context to bring AA and CP in discussion

[BrettyWhite]

If we can use Bluetooth for transferring location data which is considered as Personally identifiable information (PII), then why not WiFi credentials?

Just because something is doesn't mean it should be. I agree with you above this is getting a bit out of context so this will be my last comment on this. I just believe that we, as stewards of the platform, should be the ones protecting the users.

With that said, I believe the easiest solution would be to enforce encrypted services for apps that wish to use this feature. We can create a new RPC that uses the new RPC message protection feature to ensure the data is secure, instead of using a control frame.

Thanks

[joeljfischer]

3a.

I would think that in case of WiFi connection is not established due to pop up being ignored or the user does not allow it. HMI or App will be responsible to show the appropriate message to the user to connect WiFi manually or to use another transport.

HMI will not get any information for failed WiFi auto-connect. Proxy as well could not do anything if Wifi auto-connect failed. User will need to connect WiFi manually, as they would do today to use the app.

But that's my point! You said earlier (the first quote above) that the HMI or app should show a message, and now you're saying that it can't get the information it would need. So then we're on to the app showing the information. Which is probably fine on iOS, due to the user already having to use the phone to allow or deny the Wi-Fi connection on iOS. But on Android is much less than ideal, where the user doesn't have to interact with their device, so having it all on the HMI is the ideal user interaction. So then, we're back to needing a notification to the HMI that the connection failed.

I'd also like to see recommended text, such as (on iOS), "Your device failed to connect to your vehicle's Wi-Fi. Please connect your device manually using these credentials: \credentials here\".

3c. Is the consent prompt going to be saved for future uses (does it display only once), or does it appear every time (probably what should happen). I'd also like to see some recommended language, such as (on iOS) "Would you like to connect to this vehicle's Wi-Fi? Selecting YES means that you will be prompted on your device."

[theresalech]

Here's a summary of the current status of this discussion, for review during our call.

Agreed Upon Items 2. Proposal should be updated to note that pre-iOS 11.0 devices cannot support this feature and that the HMI will display as such based on the RAIR DeviceInfo struct. 3b. Specify that proxy should attempt WiFi auto-connect when DD is OFF. 4. Add language to specify entitlement request procedures, and that this information should be added to the SDLC Application Certification Guidelines. 5b. Add API so developer can enable/disable WiFi auto-connect. 6. Clarify that we will rely on the error returned by iOS APIs for checking if it's already on the wifi network. 8. Update onWiFiTransportAvailable function per https://github.com/smartdevicelink/sdl_evolution/issues/799#issuecomment-517439904.

Items Still in Discussion 3a. Project Maintainer looking for details on how the HMI will display that a connection failed. 3c. Determine recommended language for user consent screen that will be shown before requesting on the phone. 5a. Project Maintainer believes user's WiFi password should be encrypted; author believes this should be plain text. Other Steering Committee members should weigh in. 7. Author to advise how the HMI will get access to the methods available on the system. 9a. Project Maintainer to review and provide feedback. 9b. Project Maintainer to review and provide feedback. 10. Author to provide code examples to assist with discussion.

Note: Item 1 was found to be irrelevant so was removed from discussion.

[theresalech]

The Steering Committee voted to defer this proposal, keeping it in review until our next meeting on 2019-08-20, to allow the author, Project Maintainer, and other SDLC Members to finalize discussion of the open items noted in this summary comment.

[ashwink11]

2. & 3.a.

In previous comments, the discussion went on regarding support of Bluetooth as primary transport in Point 2, hence did not discuss other possibilities. HMI knows App HMI type of Application registered and Transport type. HMI can use this info to alert the user to connect to secondary transport. Using RAIR device info is not necessary.

One of the possible flow depending on HMI implementation and SDL configuration is:

a. If multiple transports are enabled in smartdevicelink.ini b. If System implementation allows video streaming app to register using primary transport. c. HMI knows App HMI type of Application registered and Transport type. d. If secondary transport of Bluetooth is set as WiFi in smartdevicelink.ini e. Secondary transport is not connected. f. HMI checks App HMI type and transport type, and show an appropriate message to the user to connect Secondary transport to use App.

In this flow, we cover both cases where System is connected to a pre-iOS11 device or when WiFi Autoconnect failed. HMI would alert the user to connect to secondary transport using App HMI type and Transport type. This way, HMI does not need any info regarding WiFi auto-connect failure, as it can determine itself using existing information available, that secondary transport is not connected.

As you know, a lot of things depends on OEM's preferred implementation, SDL configuration in smartdevicelink.ini file set by HMI like, whether multiple transports are enabled, whether Bluetooth as primary transport can be used, whether WiFi is secondary transport, etc.

This proposal does not make any recommendations regarding the use of primary transport or secondary transport or the flow mentioned above. The flow mentioned above is just an example for understanding.

This proposal mentions only sharing WiFi credentials and WiFi auto-connect from the proxy. Hence, I do not prefer to write any recommendations text for HMI. OEM's can decide if they want to use RAIR device info and text they want to use depending on their preferred implementation.

5.a.

We do appreciate your concerns regarding users and the great work you guys do.

However, we should also make sure that the solution we design is adaptable, comparable and competing with other solutions in the market. We do not want to make it harder to adapt SDL, compared to AA and CP, when we talk about Wireless projection.

Regarding your suggestion, we like this idea. I can make changes in proposal to use RPC, that would use RPC message protection feature, instead of the control frame. OEM can configure ON/OFF encryption using their policies depending on their preference.

7. The information was provided to answer a query regarding dynamic credentials for WiFi AP. I believe query came as changing passwords were mentioned in the "Motivation" section of the proposal to describe a possible scenario.

However, I do not propose anything related to configuring or creating WiFi AP. This depends on the discretion of OEM. Hence, out of scope for this proposal.

10. This point never came to discussion before. Some sample codes are already provided in the proposal.

[BrettyWhite]

5.a

Awesome, that should work. 👍

[joeljfischer]

2/3a. I think I need clarification here, because it doesn't look to me like you've provided a flow that solves what you say it does.

In this flow, we cover both cases where System is connected to a pre-iOS11 device or when WiFi Autoconnect failed.

Where does this cover either of those cases? The flow you've provided doesn't mention either. I don't see how knowing the AppHMIType has any effect on this. For example, if an iOS 8 device connects, it can go through this whole flow, and the HMI doesn't know that the WiFi autoconnect won't work without the RAIR DeviceInfo struct.

HMI would alert the user to connect to secondary transport using App HMI type and Transport type. This way, HMI does not need any info regarding WiFi auto-connect failure, as it can determine itself using existing information available, that secondary transport is not connected.

I don't think so. The problem is that the HMI can't know if the secondary transport is connected or not due to the nature of WiFi.

This proposal mentions only sharing WiFi credentials and WiFi auto-connect from the proxy. Hence, I do not prefer to write any recommendations text for HMI. OEM's can decide if they want to use RAIR device info and text they want to use depending on their preferred implementation.

We need to provide HMI integration and implementation guidelines for OEMs and flows that their HMIs will need to adhere to for this feature to work consistently across platforms and well. I consider this a requirement for this proposal, though of course, it's up to the SDLC.

5a. I think we're in agreement here that making this an RPC so as to allow or require encryption on it is the better way to go. However, I do still have concerns that these passwords will be available to the app developer. A bad actor app developer would be capable of harvesting these passwords, and putting the encryption over the wire on it does not help that situation.

This is a very tricky problem to solve. I think the only way to mitigate it is to require HMIs to disclose this when they ask for consent to auto-connect.

[ashwink11]

2/3a.

I don't think so. The problem is that the HMI can't know if the secondary transport is connected or not due to the nature of WiFi.

From the information provided in proposal SDL-0141, the proxy needs to register secondary transport.

If WiFi is not connected, then Proxy cannot register secondary transport and hence HMI knows video streaming App cannot work and alerts the user to connect WiFi.

In case the iOS 8 device is connected or WiFi auto-connect fails, HMI knows secondary transport not connected and alerts the user to connect WiFi.

We need to provide HMI integration and implementation guidelines for OEMs and flows that their HMIs will need to adhere to for this feature to work consistently across platforms and well. I consider this a requirement for this proposal, though of course, it's up to the SDLC.

I do not propose any changes in the existing SDL WiFi implementation. This proposal is just an add-on to provide convenience to Users. HMI integration and implementation guidelines for OEMs would be a much broader topic and should be discussed in another proposal.

This proposal, as I mentioned would provide a way to share WiFi credentials to Proxy and Proxy trying auto-connection.

5a. Yes, user consent will be provided on HMI to share WiFi credentials. We will bring RPC changes with the revision.

Edit: Added text.

[joeljfischer]

2/3a.

If WiFi is not connected, then Proxy cannot register secondary transport and hence HMI knows video streaming App cannot work and alerts the user to connect WiFi.

So, you're saying that there's a timeout? e.g. That Core sends a TransportEventUpdate, then waits a certain period of time to see if it sends a startService on the secondary transport, then if it doesn't within that timeout, will display the message to the user? If that is what you're saying, I don't think it was made clear, and would need to be added to this proposal.

However, it still doesn't cover all of the use-cases. When does the consent prompt appear in this flow? It can't appear for iOS 8 devices, but should for iOS 11, even if neither are already connected. I believe that you need to add detailed flow diagrams for all possible use cases (pre iOS 11, iOS 11+, and Android) and I think you'll see that you're not covering all of your required cases with the proposal thus far.

We need to provide HMI integration and implementation guidelines for OEMs and flows that their HMIs will need to adhere to for this feature to work consistently across platforms and well. I consider this a requirement for this proposal, though of course, it's up to the SDLC.

I do not propose any changes in the existing SDL WiFi implementation. This proposal is just an add-on to provide convenience to Users. HMI integration and implementation guidelines for OEMs would be a much broader topic and should be discussed in another proposal.

I'm not saying that you need to add additional information for any changes, because you're correct in saying that you haven't altered the existing feature. I'm saying that you need to add additional information because you're adding a new feature. The added stuff is the reason why you need to add additional HMI integration information! Perhaps the SDLC disagrees, but we have consistently to this point required proposals that make broad new features impacting the HMI to discuss how those features should be used (for example with the widgets proposal). I see it as no different in this case. It makes no sense to propose the technical requirements for implementation, then add a proposal discussing HMI requirements on how it should be used. The entire impact of this feature should be in the proposal.

This proposal, as I mentioned would provide a way to share WiFi credentials to Proxy and Proxy trying auto-connection.

And that's great, and this proposal will be a great addition, but it's pointless if HMI integrators don't know how to implement it, or if implementations conflict, or if implementation isn't possible because not all use-cases can be covered. Proposals are not merely technical. They are proposing a feature and that includes technical, business, server, impact, HMI guidelines, etc. as needed based on the feature's scope. I don't believe that you can limit the scope of this feature to merely the technical, because it has a much wider impact.

[ashwink11]

2/3.a

When does the consent prompt appear in this flow?

Timeout, as you suggested, is one of the possibilities. Another possibility is that the user is notified when they want to launch the App on HMI. The HMI can say, "Connect WiFi to continue using App on System"

However, as you know, this depends on OEMs implementation. In case, primary transport is USB, HMI may allow using video streaming apps, without connecting WiFi. In case primary transport is Bluetooth, HMI may not allow registration of Video streaming apps.

If WiFi is not connected, then Proxy cannot register secondary transport and hence HMI knows video streaming App cannot work. HMI can use a timeout or notify the user when they want to launch the app.

I would think, behaviour mentioned above is one of the possible flows irrespective of mobile device used for SDL. Please do let me know if you think the behavior would different for different devices.

In case of iOS 8 or iOS 11 or Android, the user would need to connect WiFi manually if API support to WiFi connection is not available or connection failed for some reasons and with the alert on HMI, HMI will communicate to the user that they need to connect to WiFi manually to continue using/launch App on system.

implement it, or if implementations conflict, or if implementation isn't possible because not all use-cases can be covered I don't believe that you can limit the scope of this feature to merely the technical, because it has a much wider impact.

Could you please mention specific cases, where implementation is not possible or use case is not covered because of this proposal?

If we consider this proposal along with proposal SDL-0141. I think, the flow is complete. However, do let me know, in which specific cases, it's not and we would try to complete it.

[joeljfischer]

I want to take a step back here and give you insight into why I'm making the comments I am. I think that my general concern here is for other OEMs who view this feature and are unclear on the requirements. Because Ford is introducing this feature, I'm sure that they have a set of requirements that they plan to implement into their head unit and are trying to ensure that they get this feature into the code so that they can implement their requirements. My concern is for OEMs who don't currently have requirements set for this feature but because it's available in the open will want or need to implement it.

So I want to be able to provide those other OEMs who investigate or want to build requirements around this feature to ensure that they have good, ready to go integration guidelines, SDL requirements, and feature flows that they can use to evaluate this feature with their own systems, and so that they don't build incompatible systems. We've come across the issue of integration issues in SDL due to a lack of definition to the behavior. That's why the general tone of my comments is the way that it is, and it's why I'm pushing for feature flows and integration requirements for as many edge cases as we can come up with, and it's why I don't view this as simply a technical feature proposal. This is something that will have to be evaluated at other OEMs months or years from now, and we will need adequate documentation to describe how this must be implemented and the various corner cases that we know about.

So, we don't necessarily need to provide hard requirements, but we should at least provide recommended flows that other OEMs can use when evaluating and building their own requirements for this feature implementation into their head units.

So I think the flow that I'm looking for is that which I mentioned in my above comment. A recommended flow from initial connection through the Wi-Fi auto-connect through final connection and startup including example popups that would appear (including where and when). This would also include comments on flows that would be needed for pre-iOS 11 devices and so forth. Does that make sense?

[ashwink11]

After enabling multiple transports in SDL, there are multiple combinations of transport in which SDL can work. The case you described above is not introduced by this proposal, but it is applicable for all combinations when secondary transport is not connected. For example: consider a case where primary transport is Bluetooth and secondary transport is USB(Out of scope for this proposal though).

I would think that the above issue should be addressed in the proposal, where the behavior of SDL when secondary transport is unavailable, is defined. Not sure, if this is already discussed. Secondary transport could be any permissible transport defined by SDL.

Since you emphasize on adding it in this proposal, I will make the below recommendations. Please do review and let me know in case of any issues.

This recommended HMI flow is applicable only when secondary transport is WiFi.

a. HMI allows App registration of all apps using primary transport. b. HMI knows App HMI type of Application registered. c. HMI knows Transport type of the registered App. Information will be available to HMI with HMI API's BasicCommunication.OnAppRegistered and BasicCommunication.UpdateAppList. Please refer proposal SDL-0141 for details. d. Secondary transport is not connected. e. In the case of Video streaming Apps, HMI does not allow App activation using primary transport. f. User tries to launch the App on System. g. HMI checks App HMI type and transport type received from SDL Core in Common.HMIApplication. h. HMI determines, that App activation is not permitted as secondary transport is not connected. i. HMI shows an appropriate message to the user to connect secondary transport to use the App. HMI can show the message, "Connect WiFi to continue using App on System".

[joeygrover]

9. The reason I asked this question was the same reason it was decided that the secondary TCP connection should wait until the user actually opens the app, it's a more responsible use of resources including the battery life of the device. I think this case is a little different though as they are likely to already be connected to a mobile network and WiFi might actually preserve battery life on the device. As long as the user consents to automatically connecting to the WiFi network I think connecting to the vehicle's WiFi network can happen as soon as possible.

Regarding Joel's post, I think we are more focused on the flow of joining the vehicle's network, not necessarily only the secondary TCP connection that was introduced in SDL-0141. There are a good deal of corner cases and flows that should be considered around joining the network that we simply want to make sure we have a guidance to give other members. It is difficult for the project maintainer to provide such guidance if it is not defined somewhere, and to ensure whatever guidance we give doesn't interfere with other member's implementation. Proposals like this will be used as the basis of those decisions, so if that information is missing it is a big disadvantage for anyone trying to integrate the feature. While other proposals might not have had specifics like this, that doesn't mean we should avoid them. The evolution process has been evolving itself, which is a good thing. We are learning that gaps exist and we want to prevent those gaps when we can. I apologize if it seems like we are trying to add an extra burden to the author, we simply want to make sure each solution/feature is as complete as possible from the start and the from the subject matter expert (author).

[theresalech]

The Steering Committee voted to return this proposal for revisions. The author will update the proposal to include the "Agreed Upon Items" in this comment, as well as the following:

3a/7/10. Add flow of joining vehicle's network and code examples where applicable, including fail cases. Provide guidelines for use cases 3c. Author provides recommended language for user consent that will be shown before requesting on the phone. 5a. Update to use RPC Message Protection feature instead of control frame. OEM can configure ON/OFF encryption using policies. User consent will be provided on HMI to share WiFi credentials. 9a/b. Include that connecting to the vehicle's WiFi network can happen as soon as possible, as long as the user consents to automatically connecting to the WiFi network.

[theresalech]

Hi @ashwink11 we wanted to check in on these revisions. Do you have an anticipated completion date? Thank you!

[BrettyWhite]

After thinking about this, and re-reading it. I am still concerned with 2 things.

1. RPC Message protection in this is optional, I strongly believe that for something as personal as sharing a wifi password with a 3rd party app, that we should take the high road here and make sure that our customers are as protected as they can be, especially now that that RPC protection feature will be available in the next core / proxy releases. I believe this should be a requirement.

2. The second could be an issue with the Android router service setup, where data flows through one app (the host), to the app requesting the RPC. A bad actor could skim this data, and with all of the SDL apps on the road, could amass a large quantity of user Wifi passwords. This one might be a bit harder to solve. Off the top of my head, it could be something as simple as using symmetric encryption from the HMI to the app, using a key that both would know.

I know that I keep bringing these up, but it is important to think about these things when this could be potentially used my millions of cars, and it should not be taken lightly. I'd bet that many people would consider using the same wifi password in their car as they do in other apps, or for their home wifi. Additionally, this is not a complex setup, it is quite easy to change from the car's default: https://www.youtube.com/watch?v=lN5hRHhADkQ

If this is something that might be easier to discuss in another forum or way, I'm more than happy to take a call or help figure something out, and I know a few others who might be as well. I believe this is a useful feature, and I think its possible to implement in a secure fashion 👍

[ashwink11]

1. As we agreed earlier, this RPC protection is optional. OEM can decide on RPC protection.
2. This proposal does not make any changes in RPC protected services implementation. The proposed RPCs should work as other protected RPCs.

[BrettyWhite]

I understand that that’s what the RPC protection feature states, but I strongly believe that we should agree that Wi-Fi passwords require encryption, and so RPC protection should be required for this feature to function.

[Shohei-Kawano]

I agree to protect passwords by encrypting them. BTW, I have a very fundamental question. Why is HU become the AP? I think that it is easier to connect to the Internet if the device is AP.

[ashwink11]

Thank you for your review @Shohei-Kawano Yes, protected service can be enabled if required for your implementation. It's proposed as configurable.

I understand that iPhones cannot create AP programmatically. Hence, HU will create.

[Shohei-Kawano]

@ashwink11 -san Thank you for reply. I understand the limitations of the iPhone. My concern is: If the iPhone is a Wifi client and the HU is not connected to the Internet, then iPhone cannot access the Internet. In other words, since the SDL App is not connected to the Internet, I think that the function will be incomplete. How are these resolved? Or is my prediction wrong?

[ashwink11]

Hi @Shohei-Kawano, Unfortunately, I won't be able to answer your query regarding Internet access. Probably this was discussed in some other proposals. Maybe you can ask project maintainers, they would have more information on this topic.

[joeygrover]

@ashwink11, it is likely you are referring to the SDL0141 - Supporting simultaneous multiple transports proposal which defined a production TCP transport that the mobile libraries could use. In actuality, this proposal did not define any requirement that the head unit would be the network host, nor did it say the phone would be the host. The idea was to keep the transport agnostic to that requirement. Therefore the solution works for all scenarios.

On the other hand, your proposal specifically introduces a requirement that the head unit is the network host. Since this has never actually been agreed to in any other proposal, it will be your burden to defend the position that this requirement is the right path. The libraries will automatically connect to those head unit hotspots so the question left by @Shohei-Kawano is valid for this proposal and should be addressed.

[theresalech]

It should be noted that during the 2019-10-01 Steering Committee meeting, the Steering Committee voted to defer this proposal, and keep it in review until our next meeting on 2019-10-08, so that more discussion about the proposal could take place on the review issue.

[ashwink11]

My apologies, I was not aware that this was not discussed earlier.

I understand that iPhones cannot create AP programmatically. In android there are no such limitations except few permissions would be required.

If the mobile device is creating an AP then

1. internet connectivity would be preserved
2. iPhone device users would need to create Wi-Fi AP and connect devices manually.
3. WiFi can connect automatically only for android devices. If it needs to be supported for android devices, then this would require logic in proxy to select the app that would create an AP and pass on Wi-Fi credentials to HU. Also, this would depend on app developers if they allow their app to create Wi-Fi AP.
4. If multiple mobile devices are connected to Wi-Fi they would use the internet from mobile devices creating Wi-Fi AP.

If HU creates an AP and does not provide internet connectivity, then

1. Internet connectivity for some devices could be hampered and would need user action. iPhones would switch to mobile connection for the internet but on some android devices, the user needs to enable settings to get this behavior.
2. WiFi auto-connect could be supported for both Android and iOS devices (restrictions already mentioned in the proposal)

Since both methods have their pros and cons. The Steering Committee can decide whether to follow any particular approach or keep it transport agnostic so that OEM's can configure framework as per their requirements. The current proposal is applicable only if HU is AP. I will make changes in proposal as per the Steering Committees' decision on this topic.

[theresalech]

It was clarified that the following items are still in discussion with regards to this proposal: requiring RPC Message Protection for encryption of WiFi passwords; determining if the head unit or mobile phone should be the network host/access point (AP) or if the transport should remain agnostic as included in SDL 0141. The Steering Committee voted to defer this proposal to allow further discussions and recommendations to be posted to the review issue.

[BrettyWhite]

I believe it is also possible to setup a phone to connect to WiFi AP but also maintain its cellular data as well. If possible on head units, it would allow for the internet connectivity the user expects while allowing things such as video streaming over the car's network. https://discussions.apple.com/thread/6448960

[joeygrover]

The project maintainer has met and debated the different approaches to find a solution that could work for everyone. We have come up with something that is more than what was asked, but after discussing it the solution seems pretty sound and adaptable.

Require Encryption for Password RPCs

The first change we'd like to see is a new keyword added to the RPC spec to enforce encryption rules. This would be requiresEncryption=true|false. The default value would be false if the keyword is omitted. This would help prevent having to add the keyword to all existing RPC definitions.

This would then be added to the request in the author's proposal:

<function name="GetWiFiStatusInfo" functionID="GetWiFiStatusInfoID" messagetype="request" requiresEncryption="true" since="X.X">

However as described later in this comment, that RPC will be removed and a new one added. The RPC that will need the encryption keyword will be the new JoinNetwork RPC:

<function name="JoinNetwork" functionID="JoinNetworkID" messagetype="request" requiresEncryption ="true" since="X.X">

Make feature for OEM apps only

The process for app developers to go through to enable this type of feature seems to be pretty high. There's also a good chance app developers don't properly integrate the feature and cause it to be unstable. Since Core can only know so much about the app's abilities, the flow has a high probability to fail in production. By limiting this RPC to an OEM app or apps, OEMs can ensure the feature works reliably.

There is also a new preference supplied that will include a user's preference to data usage that will have syncing requirements which are best kept to the minimum participants possible.

Enable both Head Unit and Mobile devices to be Access Points

We appreciate the pros and cons list @ashwink11 put together on having the access point be one or the other. Looking at everything it seems as though there is not a clear, single choice due each scenario having specific advantages/disadvantages. Therefore, we tried to modify the solution to enable both situations. This will require some changes to the RPCs in the proposal, but fairly simple modifications.

At a high level the flow is as follows:

1. App sends RegisterAppInterface with new NetworkingAbilities param.
2. Head unit uses info supplied in NetworkingAbilities to determine best network setup.
3. Head unit sends RegisterAppInterface response with the determined network setup and actions.
4. The network is set up and joined.
   1. If Head unit should be network host:
      1. Head unit requests HMI sets up a WiFi network (needs new request/response not yet determined)
      2. HMI sets up network, sends OnWiFiNetworkStatusUpdate (formerly OnWiFiTransportStatusUpdate)
      3. Once the notification is received by Core, it will send a JoinNetwork request (formerly an OnSystemRequest notification) that contains the information to join the network.
      4. When the OEM app receives the JoinNetwork request, it will attempt to join the network. It will send the success or failure information in the response.
         1. If the OEM app is running is on iOS device, it may be required to put the app into the foreground to join the network programmatically. This will require HMI flows to be created to prompt the user to do so.
   2. If the mobile device is selected to be the network host:
      1. The OEM app will receive the RegisterAppInterface response with the info that it is to host the network.
      2. OEM app sets up "hot spot" WiFi network.
      3. Once network is up and running, app sends JoinNetwork request that contains the information to join the network to the head unit.
      4. When the head unit receives the JoinNetwork request, it will attempt to join the network (likely through the HMI, new RPC needed).It will send the success or failure information in the response.
5. Core then sends the TransportEventUpdate protocol message with IP and port to connect the TCP transport to all appropriate apps. Flow is then as defined in previous secondary transport proposal.

First, we expand the information provided in the RegisterAppInterface request and response:

 <struct name="DeviceInfo" since="3.0">
 ...

    <param name="wifiConfigurationInfo" type="WiFiConfigurationInfo" mandatory="false">
            <description>Device's available configurations around WiFi networking</description>
    </param>
 </struct>

New struct WiFiConfigurationInfo and supporting Enums:

<struct name="WiFiConfigurationInfo since="x.x">
    <description>Describes some of the sending device's available configurations around WiFi networking. This includes the ability to automatically join a network or host one itself.</description>

    <param name="autoJoinWiFiSupported" type="Boolean" mandatory="false">
        <description> </description>
    </param>

    <param name="canHostWiFiNetwork" type="Boolean" mandatory="false">
        <description> </description>
    </param>    

    <param name="dataFallbackSupported" type="Boolean" mandatory="false">
        <description> This describes the devices ability to support joining multiple networks and using one for internet connectivity if the not available on a different, connected network.</description>
    </param>     

    <param name="dataUsagePreference" type="Device" mandatory="false">
        <description> This describe the preference of what data to use. This is useful when a user might have unlimited data on one device but a cap on another</description>
    </param> 

    <param name="wifiFrequencyBandsSupported" type="" array="true" minSize="1" maxSize="100" mandatory="false">
        <description> An array of frequencies supported by the device. Values should be in units of GHz for example 2.4GHz, 5.0GHz, etc </description>
    </param> 
    <param name="wifiSpecsSupported" type="Integer" array="true" minSize="1" maxSize="100" mandatory="false">
         <description> An array of WiFi Specifications, aka "Names", supported by the device. Currently expected values should be from the following: 802.11b = 1, 802.11a = 2, 802.11g = 3, 802.11n = 4, 802.11ac = 5, 802.11ax = 6.  </description>
    </param> 

</struct>

<enum name="FrequencyBand" since="x.x">
    <element name="2_4_GHZ"/>
    <element name="5_0_GHZ"/>
    <element name="6_0_GHZ"/>
</enum>

<enum name="Device" since="x.x">
    <element name="MOBILE"/>
    <element name="VEHICLE"/>
</enum>

Next we add a param in the RegisterAppInterface response:

 <function name="RegisterAppInterface" functionID="RegisterAppInterfaceID" messagetype="response" since="1.0">
     ...

     <param name="networkingInfo" type="NetworkingInfo" mandatory="false">
         <description>Describes the abilities of the head unit as well as who should host a network</description>
    </param>

</function>

<struct name "NetworkingInfo since="x.x">
    <description>Describes the abilities of the head unit as well as who should host a network</description>

     <param name="wifiConfiguration" type="WiFiConfigurationInfo" mandatory="false">
         <description>Device's ability around networking</description>
    </param>

    <param name="networkHost" type="Device" mandatory="false">
        <description> This describe which device is to host the common network that should be joined. The device listed here should immediately start their network.</description>
    </param> 
</struct>

Join Network RPC

<function name="JoinNetwork" functionID="JoinNetworkID" messagetype="request" requiresEncryption ="true" since="X.X">
    <description>A request for the receiver to join the specified network.</description>
    <param name="wifiState" type="WiFiStateInfo" mandatory="false">
        <description>wifi state info</description>
    </param>
    <param name="ssid" type="String" minlength="1" maxlength="32" mandatory="false">
        <description>name of the WiFi ssid</description>
    </param>
    <param name="password" type="String" minlength="1" maxlength="100" mandatory="false">
        <description>password to use to connect AP</description>
    </param>
    <param name="securityType" type="WiFiSecurityType" mandatory="false">
        <description>security type of WiFi AP</description>
    </param>   
</function>

<function name="JoinNetwork" functionID="JoinNetworkID" messagetype="response" since="X.X">
    <description>A response and description of requested action.</description>
  <param name="success" type="Boolean" platform="documentation" mandatory="true">
    <description> true, if successful; false, if failed </description>
  </param>

  <param name="resultCode" type="Result" platform="documentation" mandatory="true">
    <description>See Result</description>
    <element name="SUCCESS"/>
    <element name="UNSUPPORTED_RESOURCE">
    <element name="DISALLOWED"/>
    <element name="REJECTED">
    <element name="TOO_MANY_PENDING_REQUESTS"/>
    <element name="APPLICATION_NOT_REGISTERED"/>
    <element name="GENERIC_ERROR"/>
    <element name="USER_DISALLOWED"/>
    <element name="DATA_NOT_AVAILABLE"/>
  </param>

  <param name="info" type="String" maxlength="1000" mandatory="false" platform="documentation">
    <description>Provides additional human readable info regarding the result.</description>
  </param>   
</function>

Determining which device should host the network

Once the head unit receives the RegisterAppInterface and the WiFiConfigurationInfo it must decide who should host. Each bullet point assumes that the network configurations can be supported by both devices (frequencies, data fallback, etc).

1. If a dataUsagePreference is supplied, the head unit will use this preference.
2. If autoJoinWiFiSupported is set to true and canHostWiFiNetwork is set to false ,the head unit will host.
3. If autoJoinWiFiSupported is set to false and canHostWiFiNetwork is set to true, the mobile device will host.
4. If dataFallback is set to false and the head unit does not have internet access or the head unit has reached its cap, the mobile device will host.
5. If both autoJoinWiFiSupported and canHostWiFiNetwork are set to true, the head unit will host.
6. If the mobile device doesn't supply enough information to rule out that it can connect to a WiFi network hosted by the head unit, the head unit will host the network.

[theresalech]

The Steering Committee voted to return this proposal for revisions. The author will revise the proposal to follow the approach described in this comment from the Project Maintainer.

[theresalech]

During the 2019-10-29 Steering Committee meeting, the author requested that this proposal be brought back into review so they can voice concerns about the previously agreed upon revisions. The Steering Committee first voted that it was acceptable to move a proposal from a Returned for Revisions state to an In Review state without the previously agreed upon revisions being performed, and then voted to move this particular proposal back into review. It was noted that a move like this within the Evolution Process has not happened before, and should not become standard practice. It was also clarified that as the Steering Committee previously voted to return this proposal for revisions, it will be the author's responsibility to speak to their concerns and provide suggestions for next steps.

[ashwink11]

Concern 1: Require Encryption for Password RPCs “requiresEncryption” attribute in RPC definition

1. Encryption of RPCs is already described in SDL-0207. If an OEM desires a secured channel for any particular RPC, they can use policies to enforce it.
2. The proposed attributes override the OEM decision if the encryption of this RPC is not desired. The consequence is the need for security libraries form every OEM integrating SDL.

Concern 2: Make feature for OEM apps only There are APIs proposed that would enable-disable the use of this feature. If App developers enable this feature, they would just need to add Android/iOS permissions to use Wi-Fi APIs. If app developers do not want to add Android/iOS permissions, they can disable this feature.

Concern 3: Enable both Head Unit and Mobile devices to be Access Points We see a few issues in implementation on reviewing this suggestion. Run time decision to use Wi-Fi mode has some disadvantages.

1. IVI would need to support both Wi-Fi AP and Wi-Fi station mode. Adding more implementation and maintenance efforts for IVI.
2. IVI may have some other features using the Wi-Fi access point. In such scenarios, IVI in the Wi-Fi station mode cannot be used at all.
3. Switch between Wi-Fi access points to Wi-Fi station mode could introduce delays in accessing apps that would require it.
4. Mobile device access point abilities are probably very limited to create programmatically. iPhones cannot create Wi-Fi access point programmatically.

Comparison on the basis Wi-Fi roles and internet connectivity

I think for users, it would be easier to use the Wi-Fi feature if IVI is an access point. There could be other features as well, which would be using IVI Wi-Fi AP and it would be difficult for SDL adapters to implement and manage both Wi-Fi modes in IVI for apps.

[joeljfischer]

EDIT: Minor wording and grammar updates.

1.1. The difference is that policies can be turned off by any given OEM. The addition to the RPC spec requires all OEMs to enforce this by hardcoding it into Core.

1.2. Yes and no. Yes, the point of this requirement is that all OEMs who want to support WiFi password sharing have to support and integrate encryption because it is wrong of them to not do so. That's why the decision was to require it at this level. But no, it's not required of all OEMs implementing SDL; it is only required for those who choose to support WiFi password sharing.

2. There are several reasons the decision was made to require this. First, the burden on 3rd party OEM apps to support this which is not, as you say "they would just need to add Android/iOS permissions to use Wi-Fi APIs." That is not true; on the iOS-side they also need to request these permissions of Apple and give their use-cases. This is a burden on the app developer.

Second, if we don't restrict it only to OEM apps, then some apps will have this support but the majority will not, but (at least on iOS) the app must be in the foreground to support it. This means that the head unit will need to signal the phone to bring that app to the foreground or tell the user to bring it to the foreground before requesting. This is easier if there's a single app that the HU knows supports it, and greatly diminishes any advantage of having multiple apps support the feature.

Third, opening it up to third parties opens security concerns since developers would be able to pull the Wi-Fi password after it has been decrypted (or, on your scheme, just pull the decrypted password at any point).

Fourth, opening it up to third parties restricts abilities of the OEM app to have special settings and configurations for this feature since those won't be shared with other third-party apps.

3.1. This isn't true. Perhaps it was not made clear in the revision, but the head unit can support one, the other, or both schemes by altering what it responds with in the RAIR.

3.2. See 3.1

3.3. This point is speculative, and besides, I can't imagine those delays would be prohibitive for accepting this feature. Also, see 3.1 if such a situation is prohibitive for an OEM.

3.4. This is also related to 3.1 and was mitigated in the design. If an OEM only supports the mobile device being an access point, then they won't be able to support iPhones. If they only support the head unit being the AP, then they may leave out some Android users who would otherwise be able to use the system. That's why the design specified supports both, or if the OEM chooses, one or the other. They would specify this in the RegisterAppInterfaceResponse.networkingInfo.wifiConfigurationInfo parameter.

[kshala-ford]

Stand in for Ashwin as the PM reply came in very late.

1.1. We understand the result of the attribute flag. The point is that we don't agree to enforce encryption. After consulting the Ford cyber security team we don't need encryption on wired transports and we see benefits with a use case of apps connecting over USB without including the security library.

1.2. I'm not sure if we can say wrong From your standpoint you feel that WiFi credentials must be encrypted under all circumstances. We disagree to this and we see your requirement to be fulfilled with SDL-0207. See 1.1. about wired communication and Ford decision that encryption is not required.

2. Just for completeness: I don't think I can speak to this point. I would appreciate the author or other Ford members involved in the discussion to get a change to respond.

3.1. It is very true what Ashwin wrote. Changing the role at runtime results in high stress to the WiFi firmware. Our experience is that the firmware can malfunction especially when changing the mode. Adding role change to IVI for SDL is complex, comes with high cost and the risk of issues is really high. Therefore Ford would probably enforce AP mode only. Other IVIs may be STA only resulting in a cluttered setup making it potentially difficult to sell this feature as a big gain. I think we should decide on one mode highly suggesting IVI at AP mode.

3.2. Determining which device should host the network breaks with Ashwin's argument. If the OEM has a demand to keep the IVI in one state (e.g. AP mode for offering WiFi hotspot) then there is no reason to try to determine. I'm afraid we are making assumptions per mobile OS and all I want to say is that SDL apps are not of highest priority when deciding on IVIs WiFi mode.

3.3. Resuming a mobile navigation app over WiFi after an ignition cycle can be impossible with role changes.

3.4. @joeljfischer I don't think this statement is acceptable. See 3.1. where I mentioned possible cluttered setup across IVIs and OEMs. I think what Ashwin tries to say is that creating a mobile hotspot programmatically requires many changes to the mobile API and it increases IVI complexity and risk to break with WiFi solutions. iOS won't support this feature. This is no evidence but a concern that Android might break the ability which would be severe to the feature. We don't expect this risk with IVI being the AP.

3.5. I want to add a concern to the data usage preference. In Europe unlimited data contracts are very rare or very expensive. I don't believe it'll change in the next couple years expecting that all European SDL users would not accept phone data usage as a preference. There must be requirements that IVI avoids data consumption if IVI connected to phones WiFi due to SDL. Otherwise the data traffic can be out of control having IVI downloading software updates...

3.6. I want to add another security related issue of vulnerability. If the mobile device becomes the AP it'll be subject of attacks. Depending on the phone attacks such as KRACK might still be possible.

[ashwink11]

Regarding second concern: 2. First, as already mentioned, I never said all app developers need to implement this feature. If App developers think that it would be a burden for them to implement this, they can skip it. App developers can take a decision about whether they want to implement this feature or not.

Secondly, if only the OEM app can support this feature, the user would need to always use the OEM app first to use the mobile navigation or projection app. The user path would be for the iPhone device is: a. Launch OEM App b. Accept user consent to connect Wi-Fi c. Launch Mobile Navigation App or projection app

In case, the Wi-Fi connection is lost for some reason, the user would need to repeat the above-mentioned steps.

It would be a lot easier if App which needs Wi-Fi connections initiates it. The user would not need to follow extra steps to connect to Wi-Fi. If an app which requires Wi-Fi initiates connections, user flow would be: a. Launch Mobile Navigation App or projection app (please refer proposal for details ) b. Accept user consent to connect Wi-Fi

Third, already discussed in point 1. OEM can use encrypted service using SDL-0207

opening it up to third parties restricts abilities of the OEM app to have special settings and configurations for this feature since those won't be shared with other third-party apps.

Fourth, please do let us know which special settings and configurations are you referring too.

In addition, if any OEM does not want third party apps to use this feature with their SDL enabled IVI system, they can do so by blocking access to RPCs used to share Wi-Fi credentials using policies(refer proposal for RPC and policy functional group details).

Edit: Added the last point.