Since a couple of years I am trying to provide an inexpensive tool to measure traffic. Maximilian Narr did a thesis on this topic and developed a Rasperry Pie based solution using LIDAR. A few bits an pieces are missing for a complete IoT solution: it needs a decent, rain-safe case, a cloud service for data aggregation and visualization and an energy solution to let the client run at least for 24 hours on a power bank or something similiar. Let me know if you are interested in designing this IoT solution.

The last decade has been dominated by eventually consistent NoSQL DB's. Now we have realized that the QoS in those case often presents an obstacle for application developers and that "always consistent" is a beautiful feature of a system. But that does require coordination, or? And that is expensive, especially on a geo-distributed level. But new research (e.g. by Abadi) has given us new databases (Calvin, Fauna etc.). A first glance at the problem can be found in this post on "Back to the Future with Relational NoSQL" by Evan Weaver of Twitter. Expect a deep dive into serialization, strict serializability etc. If you are interested in doing a thesis - let me know!

For ages I wanted to get my fingers on Google Glasses. Looks like it might happen finally. The company 3SS.TV agreed to do a joint project with HdM students on. They have some ideas already and the general goal is to find new uses of this technology and get an idea about the capabilities and limitations. Last media-night we have seen an application of the old Google glasses in patient care and the potential became immediately clear to everybody. AR - at least in my opinion - will be even bigger than VR. If you are interested in joining the project - let me know!

Minister Spohn has increased pressure on doctors for installing the TK-connector infrastructure. It turns out, that most installations are NOT compliant with GEMATIK rules: parallel installations dominate everywhere even so this type of installation requires advanced firewall know-how and hardware and is intended for large scale corporations with corresponding infrastructure and administartion resources. The connector is not the problem ... claims GEMATIK according to heise security. It is the regional IT-provider who choses the wrong architecture. But a closer look reveals, that there is much more wrong with the current installations. It is not only the wrong installation mode (with firewalls turned off for ease of installation). It is the whole concept of a secure intranet in small practices or companies that is wrong: it cannot be defended against targeted attacks (and sometimes not even the regular 0/8/15 mass attacks). The practice wants and needs internet access which gets cumbersome and expensive behind the TI-connector, that's why the parallel installation is preferred where the TI-connector ist just a part of the internal network (which would require extensive firewall rules, protected channels etc.). GEMATIK now at least starts to acknowledge that there is a problem and published a questionaire for the local IT provider to testify that the installation is correct.

If your are interested in a thesis on this politically and technically challenging topic, let me know.

Well, perhaps not really new in the case of eBPF, but exciting still. eBPF is the cornerstone of Cloudflares l4 DDOS protection at the edge. And Firecracker has just been announced at re:invent as a new and lightweigth micro-VM for servless function support. How to drop 8 million packets/sec . AWS releases firecracker, a Rust based Micro-VM . Let me know it you would like to give it a test drive.

I stumbled recently over an article by Murat Demirbas where he mentions his experiences with formal verification of distributed systems. He used it with Paxos and other complicated consensus protocols. This could be a starting point for further research: Why you should use modeling with distributed systems . Let me know it you would like to give it a test drive.

Frequently over the last couple of years I had a tummy feeling, that we would should look more carefully at byzantine protocols for consensus instead of always depending on a simple fail-stop error model. The discussion at The Morning Paper on Decentralization in Bitcoin and Ethereum networks Gencer et al., FC’18 shows an interesting idea for the use of Byzantine protocols in the blockchain. The measurements show how many of the blocks are controlled by a small group of miners. The group is so small, that the energy hungry mining proof of work process seems like a total overkill. And the paper suggests that a byzantine quorum of the size of 20 miners would already distribute control better. Another very interesting measurement shows, that ping distance between bitcoin miners is rather short and equal and much shorter than with Etereum. This is not a technical problem for the blockchain algorithm to work, but it raises an interesting question: How do we know that the few important miners really are independent identities? In other words: the sybill attack question raises its head. The close ping distances let us assume that most important miners are in one geographical area. Which means, that they can be controlled by one state. So, replacing the proof-of-work algoritm with a distributed consensus would only solve the energy question, not the possible control of the blockchain by external entities. What if ping distances would be much more diverse? First, ping times can always be faked in the direction of slower answers. Second: what stops a state from running mining nodes in other states? This would make the whole system look much more distributed as it really is. And as far as I know, there is currently no solution for the sybil attack in general (one identity controlling several different identities) in peer-to-peer systems, let alone political control of miners or conspiration between them.

This shows nicely, that byzantine protocols are not a panacea for distributed systems. But there are many cases, where conspiration by an external super-power can be reasonably excluded. Byzantine protocls certainly help against few attackers and make distributed protocols much more reliable. A good starting point is again a discussion on The Morning Paper of Practical Byzantine Fault Tolerance by Castro and Liskov.

Addendum: I just realized that George Bissias, A. Pinar Ozisik, Brian N. Levine and Marc Liberatore have written a paper on Sybil-Resistant Mixing for Bitcoin which could offer a solution in the case of bitcoins.

While measuring dust levels has become rather easy due to Feinstaub selber messen there is nothing to measure noise or to count and analyse traffic available, at least not at decent prices and for the Linux/Raspy guys. The project has basically two parts. One: measure noise levels reliably and with A/C category. This allows to control e.g. nightly truck traffic through villages to avoid toll fees. The measurements need to be automatic and round the clock with timestamps. Data could either be stored on a stick/micro SD or transmitted via Ethernet/WLAN/GSM somewhere. POE or a battery pack might be necessary to allow easy installation.

Second: Based on the raw noise data, a neuronal network should distinguish the vehicle types: truck, traktor, regular car, motorbike. For trucks perhaps also distinguish two weight classes. A counter is needed as well. This allows a detailed traffic profile in a city or village. Of course, this part of the traffic analysis can happen offline. Ideally, the results should be available in the cloud.

The full monty would be if the software could detect the same vehicle across measurement stations. This allows a detailed profile of routes taken by cars and e.g also allows detecton of toll avoidance. Well, while we are at it: the doppler effect might allow us to even measure the speed of vehicles as the change of frequency per time unit.

I was unable to locate anything like this in the public domain yet. It would be no problem to buy a sound level meter for this project, but again: most only can be used with windows and are of no help here. Another alternative could be to use cheap smartphones for this purpose. Or a microphone (outside) connected to a Raspberry pie (inside). Let me know if you think about this project and we can discuss alternatives.

On my first day at work in 1986 I saw DAC, a grammar based HDLC protocol implementation written by my friend Claus Gittinger. He used Yacc to generate the code. The advantages were clear: if some weired behavior showed up, we looked at the grammar to see if there was a protocol violation. This made the protocol very easy to debug and to adapt for changes in the standard. Nowadys, DISEL (based on Coq) seem to allow even more. Programming and proving with distributed protocols Sergey et al., POPL 18 . Let me know it you would like to give it a test drive. Its dependent types make sure that the implementation is correct without refinement and verification is compositional.

A secure core of a system is needed for secure processing. This works in cars as well as in PCs. Teslas RoT . Let me know if you would like to build something on a Raspbery Pie in an IoT context.

Looks like meltdown and sprectre and other attacks finally triggered some fundamental research on hardware and software for secure systems. System Security Integrated Through Hardware and Firmware (SSITH) program and Cyber Grand Challenge (CGC) . Let me know if you would like to look into the hardware or software side (theorem provers, deep learning)

Disributed Systems have always been kind of weak with respect to modeling their domain. TLA+ could change this. Amazon is using it for complex services . And it is used in classes on DS e.g. by Murat Demirbar. Your task would be to give it a test-drive in a demonstration project.

Currently, a group at HdM is building a universal sensor unit. Several sensors can be installed to collect data on NO2, CO2, noise, temparature, location, other chemicals etc. In the simplest version you need to come by with a smartphone to unload the data into a cloud service. If more energy is available, the unit can push data by itself into the cloud via Wifi or GSM. All sensors should have us USB connector. The unit can be used to measure fine dust particles also, using a sensor from Stuttgart.

The paper on time in VMWare VMs made me kind of skeptical about the performance of distributed algorithms (e.g. failuer detection) in settings with instable time. The thesis would set up some VMs and test timing behavior of distributed algorithms for consensus or failure detection. Will jumps in time only affect liveness or even consistency?

Using bots to collect data from social networks, e.g. to investigate the creation and spreading of fake news.

How to simulate distributed algorithms and their failure models to get a handle on complex protocols like Paxos. Or how to simulate a large scale site using components.

Social GUI construction and application integration for large-scale multi-touch installations. Social analysis of interaction patterns, technical design and implementation. The scale of those devices makes single user concepts useless and requires group interfaces.

This has been a sore spot for quite a while: to enable discussions at events it is necessary that everybody has access to a microphone (this is also needed for streaming). Unfortunately the way this is done till now is through the use of long poles with microphones held by helpers into the public, by stationary microphones hanging from the ceiling in large numbers or by speakers leaving their seat and walking over to fixed microphones. This is all either too expensive or too clumsy given out narrow rows of seats and the need to hold events in different rooms each time.

My idea involved throwable microphones which can be centrally controlled and which are activated by pressing the ball. Most discussions involve only very few people and locations within a larger room and a small number of these ball-mics would be distributed across the room. Speakers can get access quickly. The following drawings might give you an idea: and a version that uses balloons hanging from the ceiling:

The article "the problem of many speakers" gives an explanation of the context.

The users must understand when and what kind of authority they grant to other actors like programs. This is perhaps the most important point which seems to also require a concept of capabilities as a means to restrict the delegation of authority. In most systems users have few choices when they run a program because the program will automatically inherit all of the users rights. So there is an interesting architectural problem behind this as well. See our current work on capabilities .