Array of Things(arrayofthings.github.io)
arrayofthings.github.io
Array of Things
http://arrayofthings.github.io/
10 comments
Privacy is a major concern for the project, and the directors regularly meet with private and public collaborators. There are also community meetings that take place so that people in the city can ask questions and have their concerns addressed.
For example, the most recent one was in October: http://www.smartchicagocollaborative.org/announcing-the-octo...
Skepticism around projects like this is absolutely necessary and should be actively encouraged. The point of this project is to enable cities, universities and research groups to directly tap into key environmental factors and help craft smarter policies for the benefit of everyone.
For example, the most recent one was in October: http://www.smartchicagocollaborative.org/announcing-the-octo...
Skepticism around projects like this is absolutely necessary and should be actively encouraged. The point of this project is to enable cities, universities and research groups to directly tap into key environmental factors and help craft smarter policies for the benefit of everyone.
"In light of the recent X, we have decided to enable tracking using these cameras, so we can help prevent it in the future."
> the death of privacy seems almost inevitable
That isn't a good excuse to kill it now.
That isn't a good excuse to kill it now.
> Array of Things is interested in monitoring the city’s environment and activity, not individuals. In fact, the technology and policy have been designed to specifically minimize any potential collection of data about individuals, so privacy protection is built into the design of the sensors and into the operating policies.
Bold words this day and age, and ones I'm happy to see. Let's hope they can keep to it.
Bold words this day and age, and ones I'm happy to see. Let's hope they can keep to it.
Sadly, I've yet to see a group in the city of Chicago consume this data in either a programatic, or useful, manner in the context of city operations.
AoT is still experimental and we don't have a wide array of nodes installed across the city.
The majority of the consumers of the data thus far have been researchers at Argonne and UChicago. The City of Chicago is, obviously, our main partner in this and they are looking forward to building applications for residents and internal teams to work with the data.
The majority of the consumers of the data thus far have been researchers at Argonne and UChicago. The City of Chicago is, obviously, our main partner in this and they are looking forward to building applications for residents and internal teams to work with the data.
Agree; I went to a smart cities event where one of the leaders who helped make it happen admitted essentially "we had no goal going into the project except to install a bunch of sensors and see what happened" with no goals at the beginning. Seems like an expected result, sadly.
Get the feeling that this has been done before. I just can't remember where.
I would really like to see this used to tell people where street parking is available in areas where there is alternate side cleaning. A LOT of people spend ~ 5-10 mins 2-3 times a week looking for parking in NYC and its boroughs(where I live) or really any city with this issue.
I would really like to see this used to tell people where street parking is available in areas where there is alternate side cleaning. A LOT of people spend ~ 5-10 mins 2-3 times a week looking for parking in NYC and its boroughs(where I live) or really any city with this issue.
I've always wanted to use a project like this as the shoe-horned justification for creating the backbone of a mesh network in a major city or state in the US.
I am the lead engineer for Plenario. We act as the public API for AoT. Both projects are a part of the Computation Institute at UChicago and I work very closely with the engineers on their team, as well as with people from other partner organizations.
I would be happy to answer any questions people have about AoT or anything related to it.
I would be happy to answer any questions people have about AoT or anything related to it.
Will they prevent sensors reporting a single person on the sensor? If not, you can track a person at night, walking alone back home (or NOT going home).
This could be achieved if they wouldn't track exact number, but ranges like: 0-50 people, 51-150 etc.
This could be achieved if they wouldn't track exact number, but ranges like: 0-50 people, 51-150 etc.
Right now there isn't any data being reported by our test nodes about traffic (people or vehicles) near a given node, but some ideas have been floated regarding how to get a read on pedestrian and vehicle density. We're not sure how we would do it, but I'd love to get some input on what seems both effective and ethical.
The biggest concern is that it's really easy to de-anonymize location data, even if all you have is numbers moving around. Some locations are very unique and identifying (e.g. homes and offices), and other locations are very sensitive. Better to avoid it altogether, if you can.
Also note that bucketing is not sufficient if the lowest bucket is just 0 and the next one up starts at 1, because people walking alone will then easily show up as they go past a series of sensors. There will be a temptation to separate out zero, because it'll seem important to distinguish between "no traffic" and "small amount of traffic". Resist that temptation.
If there is any other information reported that can be correlated, it'll be easy to use that for further identification. For instance, pressure or vibration information, noise-level information, or many other sensors would easily be dual-purposed as a presence-detect.
Beyond that, please read up on all the ways that certain sensor data can have side-channels; for instance, sufficiently high-resolution accelerometer data can be turned into audio with enough fidelity to recognize speech.
Also note that bucketing is not sufficient if the lowest bucket is just 0 and the next one up starts at 1, because people walking alone will then easily show up as they go past a series of sensors. There will be a temptation to separate out zero, because it'll seem important to distinguish between "no traffic" and "small amount of traffic". Resist that temptation.
If there is any other information reported that can be correlated, it'll be easy to use that for further identification. For instance, pressure or vibration information, noise-level information, or many other sensors would easily be dual-purposed as a presence-detect.
Beyond that, please read up on all the ways that certain sensor data can have side-channels; for instance, sufficiently high-resolution accelerometer data can be turned into audio with enough fidelity to recognize speech.
This is excellent! I appreciate how much detail you’ve put into this.
Could you recommend any specific sources I or anyone else on the team could read about how best to work with and protect this kind of data?
Could you recommend any specific sources I or anyone else on the team could read about how best to work with and protect this kind of data?
I can recommend two classes of resources.
First, take a look at material on the "security mindset", starting with https://www.schneier.com/blog/archives/2008/03/the_security_... . Everyone on your team needs to be thinking, for every new feature, "how could this be exploited?".
Second, for the specific case of sensors, start looking at research on sensor side-channel attacks, and how sensors can be used to gather information you wouldn't expect. For instance, see "Sensor Side-Channel Implications on User Privacy: Analysis and Mitigation". And take a look at some of the sensor-related work coming out of the various workshops on "Cyber-Physical Systems Security".
Finally, please keep in mind that it's still risky to have these sensor nodes out there that even have the capability of doing this collection. Even if you keep all of the above in mind, even if you do everything you can to mitigate it, the capability will still exist, and all it would take is some malicious policy changes to abuse your work and your infrastructure, and turn it into a massive invasion of privacy. With that in mind, start now, while policies are in your favor, arranging maximum transparency for the nodes, source code, data collection, and similar. That way, if anyone ever does try to abuse your work and your infrastructure, it'll be extremely obvious, and if anyone tries to remove the transparency first, then it'll be conspicuous by its newfound absence. That same "security mindset" I mentioned above also applies to policies and administrations; take the time, while those policies and administrations are in your favor, to plan ahead for the scenario where they are not. Plan ahead for something you hope you never need, because once you find out you do need it, you might not have the option of building it anymore.
First, take a look at material on the "security mindset", starting with https://www.schneier.com/blog/archives/2008/03/the_security_... . Everyone on your team needs to be thinking, for every new feature, "how could this be exploited?".
Second, for the specific case of sensors, start looking at research on sensor side-channel attacks, and how sensors can be used to gather information you wouldn't expect. For instance, see "Sensor Side-Channel Implications on User Privacy: Analysis and Mitigation". And take a look at some of the sensor-related work coming out of the various workshops on "Cyber-Physical Systems Security".
Finally, please keep in mind that it's still risky to have these sensor nodes out there that even have the capability of doing this collection. Even if you keep all of the above in mind, even if you do everything you can to mitigate it, the capability will still exist, and all it would take is some malicious policy changes to abuse your work and your infrastructure, and turn it into a massive invasion of privacy. With that in mind, start now, while policies are in your favor, arranging maximum transparency for the nodes, source code, data collection, and similar. That way, if anyone ever does try to abuse your work and your infrastructure, it'll be extremely obvious, and if anyone tries to remove the transparency first, then it'll be conspicuous by its newfound absence. That same "security mindset" I mentioned above also applies to policies and administrations; take the time, while those policies and administrations are in your favor, to plan ahead for the scenario where they are not. Plan ahead for something you hope you never need, because once you find out you do need it, you might not have the option of building it anymore.
Hey chicago shout out, this is neat but holy smokes 'array of things (AoT)'? It seems like its just a network of sensors, i thought that was internet of things.
Branding my friend... it's all in the branding :)
If you're interested in the project, feel free to contact me (info in profile).
If you're interested in the project, feel free to contact me (info in profile).
Do they provide schematics?
The code for the sensors is on GitHub. I’ll try to find if the actual boards are hosted anywhere.
https://github.com/waggle-sensor
https://github.com/waggle-sensor
For anyone interested, I reached out to [email protected] and they plan to publish schematics at the end of the year.
If they don't, you might be able to obtain one through a freedom of information act request.
i couldn't see a benefit aside having more eyes for mass surveliance?
we need ethical values at this point, not another array of tech sensors.
"(...) sensors for measuring air and surface temperature, (...). Two cameras will collect data on vehicle and foot traffic, (...)."
They do say "(...) no personally identifiable information will be stored or released by sensor nodes", and opening up the data allows the public to verify that; but I remain skeptical. (Of course, with sensors becoming cheaper and cheaper, the death of privacy seems almost inevitable...)
(Quotes from their linked blog, https://ci.uchicago.edu/press-releases/chicago-becomes-first...)