Quote:
Originally Posted by JamesCH95
That's a great idea in theory. In practice, however, FIRST would be completely overwhelmed with nonsense results from uncontrolled situations that bear little or no relevance to a competition field setup.
Simply put: the problem with the "1,000 monkeys with 1,000 typewriters" postulate in reality is filtering out the 99%+ gibberish content they've created.
|
The simple way to find the non-gibberish is request a proof of concept either in video or in front of field personnel.
This would be easier to accomplish with more open documentation about the field (so it can be more readily replicated) and more access to fields (itself not a trivial request).
Of course all of that is useless without clear lines of communications and process.
Also there are probably more devices than one might realize at any one event that can use 5GHz because they are not line of sight to the field. Consider all the driver's station laptops in the pits. I'll assume that no one on the field with a 5GHz laptop has time to be doing anything but what is expected of them.
With Windows Vista and above it would be very simple to craft a background script running as system that would exploit the failed connect attempt hole totally hidden from all but the most experienced eyes even on a driver's station on the field (in effect malware for the field). This wouldn't seem out of place at all because of the driver station software reliance on Windows. Also if someone had a COTS computing device on the robot a similar tactic with wider OS selection would be possible. I am comfortable making this statement because this particular vulnerability is much easier to remedy than others I am aware of.