[Question] Limiting connections to running hubs

[Nelvarion]

Question
Are there any plans on protecting running hubs from outside connections?
Perhaps limiting pairing only to the computer used to flash the hub?

Context
After uploading a script to a hub and letting it run, you can open the editor and hijack the hub, stopping the running program and allowing you to run any other code.

[dlech]

Yes, we plan on making the hub no longer connectable once a program has started.

[Nelvarion]

Good to hear, could be interesting in shows otherwise 😄

[GianCann]

we plan on making the hub no longer connectable once a program has started

I hope this feature is programmable, because there are cases where is useful to interact with the hub when the program run.

[Nelvarion]

@GianCann right now when you connect to hub while it's running it terminates the running processes.
You mean some interactive interrupt?

[GianCann]

it terminates the running processes.

No, it's not true (at least with Powered Up Hub).

[GianCann]

Watch this video:
https://youtu.be/s1B9pz1sM9U

Se CPlusHun send data to stdout (with Print command) ad you can connect device to read the data. If you disconnect the tablet and connect another tablet to the same BLE service, you continue to see the data output from the Hub.

Only if you send CTRL+C you can stop the program (but you can catch the KeyboardInterrupt exception and manage as you want)

[Nelvarion]

That was my experience earlier, after pairing with the hub using the web editor the console logged the same message as hitting the stop button

[Nelvarion]

Seems like you're connecting through some other interface and not the pybrick web editor

[GianCann]

Yes @Nelvarion ,
you can connect to nRF UART service exposed by the hub with any BLE client and interact with him.

[dlech]

This seems to be a limitation of the Web Bluetooth specification/implementation. Showing connected devices in the device chooser is by design: WebBluetoothCG/web-bluetooth#266. I haven't found a way to work around it (e.g. the gatt.connected property returns false even if the device is already connected in another browser window).

Also see WebBluetoothCG/web-bluetooth#295

[Nelvarion]

Can you even reject a connection attempt?

What about the ability to manually add an item or array with a pre-defined name in our scripts, populate it with the desired devices MAC(s) and have it cross-checked when a device attempts to connect?

[dlech]

Chromium doesn't actually create a 2nd connection to the hub. It shares the underlying OS connection between browser windows. So the hub has no way of knowing which browser window requests are coming from. So I don't think we can do anything in the firmware.

Chromium has some new advertisement watcher APIs that could allow us scan devices differently, but I haven't really looked into it yet since they are still experimental and not available on all OSes. But that is probably the way forward eventually.

Hubs stop advertising when a program is running, so other computers cannot find the hub at that point. The only problem, as I understand it, is multiple connections from the same computer.

[Nelvarion]

From my perspective as long as the hub is no longer discoverable after starting the program then there's no issue.
At least for this scenario multiple connections from the same computer are not relevant as the assumption is that it's running autonomously.
If/when messaging will be added to PU then it will become important again.

[dlech]

Closing since this is working as much as it technically possible right now. Also see #262.