5 ms·

I'm desperate for this. The hardware product I work on can be controlled by a mobile app. It was a very deliberate decision to not make the hardware product a

I'm desperate for this. The hardware product I work on can be controlled by a mobile app. It was a very deliberate decision to not make the hardware product and mobile app both have to talk to a remote server acting as a proxy between the two. But that leaves me using plain http between the two.

pstuart 8y ago
Couldn't you use it to coordinate NAT punchthrough?
- rogerbinns 8y ago
  The mobile app (or web browser) are on the same network (subnet) as the hardware device. There is no need for NAT or anything else. Zeroconf is used for discovery. There is little threat in most home networks, but I still prefer using SSL. If we only had to support the mobile app then we could implement a solution (eg ssh style trust on first use with self signed certificates). However we also have to support regular browsers which constrains us to standard protocols and security.
  - mdtusz 8y ago
    I'm working on a product that has a similar case - we luckily have the benefit of the hardware having a display and input so that clients need to effectively pair themselves (i.e. you need to physically click an authorized button on the hardware) before they can have full access. We figure that if someone/something has access to the hardware, you're already boned.
    - rogerbinns 8y ago
      We also have a display and also do pairing. You have to press a physical button the device which results in a 4 digit code on the display that has to be entered in the browser or app (somewhat analogous to bluetooth pairing). At the end of the day this results in a cookie being set. But the traffic is still over http.
matthewmacleod 8y ago
We ended up using the WebRTC data channel to set up communication between our hardware product and mobile app. There’s still a necessity for a signalling server in between to set up the communication, and a STUN/TURN server to proxy where it’s not possible to set up direct channels. But the whole thing is super low latency and uses DTLS, so it’s a nice alternative for many use cases!
- rogerbinns 8y ago
  > We ended up using the WebRTC data channel ... That is an interesting approach. Unfortunately we also have to support browsers so it doesn't look like we could use it. (You have to type in http://something http://something to get the page that does the webrtc as far as I can tell.)
  - andrewmd5 8y ago
    WebRTC can be used a server fashion. We opened a library that does just that: https://blog.rainway.io/real-time-communication-for-everyone-6f27e02c2f14 https://blog.rainway.io/real-time-communication-for-everyone...
    - rogerbinns 8y ago
      Unfortunately not applicable. The problem is a user with a regular desktop browser open and has the ip address of the device (on the same subnet). They have to type something into the browser address bar. As far as I can tell, there is no way they could type something like webrtc://1.2.3.4 and would have to type something beginning with http or https. It can't be the latter because of signing issues, so we are still stuck with http.
      - andrewmd5 8y ago
        More than happy to offer my thoughts if you want to reach out: andrew@rainway.io

pstuart 8y ago

Couldn't you use it to coordinate NAT punchthrough?

rogerbinns 8y ago
The mobile app (or web browser) are on the same network (subnet) as the hardware device. There is no need for NAT or anything else. Zeroconf is used for discovery. There is little threat in most home networks, but I still prefer using SSL. If we only had to support the mobile app then we could implement a solution (eg ssh style trust on first use with self signed certificates). However we also have to support regular browsers which constrains us to standard protocols and security.
- mdtusz 8y ago
  I'm working on a product that has a similar case - we luckily have the benefit of the hardware having a display and input so that clients need to effectively pair themselves (i.e. you need to physically click an authorized button on the hardware) before they can have full access. We figure that if someone/something has access to the hardware, you're already boned.
  - rogerbinns 8y ago
    We also have a display and also do pairing. You have to press a physical button the device which results in a 4 digit code on the display that has to be entered in the browser or app (somewhat analogous to bluetooth pairing). At the end of the day this results in a cookie being set. But the traffic is still over http.

matthewmacleod 8y ago

We ended up using the WebRTC data channel to set up communication between our hardware product and mobile app. There’s still a necessity for a signalling server in between to set up the communication, and a STUN/TURN server to proxy where it’s not possible to set up direct channels. But the whole thing is super low latency and uses DTLS, so it’s a nice alternative for many use cases!

rogerbinns 8y ago
> We ended up using the WebRTC data channel ... That is an interesting approach. Unfortunately we also have to support browsers so it doesn't look like we could use it. (You have to type in http://something http://something to get the page that does the webrtc as far as I can tell.)
- andrewmd5 8y ago
  WebRTC can be used a server fashion. We opened a library that does just that: https://blog.rainway.io/real-time-communication-for-everyone-6f27e02c2f14 https://blog.rainway.io/real-time-communication-for-everyone...
  - rogerbinns 8y ago
    Unfortunately not applicable. The problem is a user with a regular desktop browser open and has the ip address of the device (on the same subnet). They have to type something into the browser address bar. As far as I can tell, there is no way they could type something like webrtc://1.2.3.4 and would have to type something beginning with http or https. It can't be the latter because of signing issues, so we are still stuck with http.
    - andrewmd5 8y ago
      More than happy to offer my thoughts if you want to reach out: andrew@rainway.io