In the context of CodeMOOC, a massive open online course offered by the University of Urbino about computational thinking and coding, a large-scale coding quiz was planned for 20 October. Using only a Telegram client and a QR Code scanner, the participants were able to take part in the game and compete with over 900 groups in Italy.

Participants did register to a Telegram channel where they would receive instructions before the start of the game. At the start of the game, we handed out the link to a live Youtube stream, where further instructions and quiz questions were given out.

For each coding quiz, the Telegram bot coordinating the event wrote a special link to the channel conversation, that would redirect users to the voting conversation using Telegram’s deep link feature. Since each quiz had a unique identifier, the deep link would not only transfer the user to the bot, but also send out a hidden command.

/start IY4

(Where IY4 is the hidden code for the 4th quiz question.)

Participants could also access the voting process by scanning a QR Code, containing the same deep link.

Once invoked, the bot did ask for an answer from the user.
As soon as the question was closed from our side (by simply providing the correct answer to the bot), the bot did rank all correct answers by timestamp and signal the results on the channel. The first 3 correct answers were publicly acknowledged with various, priceless, emoji medals. ?

Message processing

A total of 974 participants (in terms of Telegram users) took part in the event. Since each person could register for a group of people (acting like a team leader), a total number of 9689 people were involved with the game.
14 questions were asked, collecting a total of 7004 responses by participants, over approximately one hour and a half.

In other words: a lot of messages were sent to our bot over a short amount of time.

Telegram supports two different modes of fetching incoming messages: pull and push.

Pull mode

In pull mode, your bot server periodically connects to a Telegram end-point and downloads part of the messages queued up for delivery. The delivery mechanism can be customized, for instance downloading a batch of messages in a single call and using long-polling to stall the request until some data can be returned.

In theory, the pull method ensures higher efficiency: requests are sent out by your server, they can be controlled easily, and large batches of messages can be returned in a single HTTP data transfer.

However, pull operations are synchronized by nature. The Telegram API disallows multiple parallel requests (since, of course, the pull request operates sequentially on the delivery queue).
While transferring one single large payload and performing one single JSON decode step may be more efficient, in pull mode you are indeed increasing the average response time of each message.
Moreover, after the download phase, data parallelism is entirely up to the developer. Handing off message handling to different threads can be more or less easy, depending on your development framework: in Go a goroutine can be dispatched for each message, while the same can be done for async tasks on any .NET language.

Push mode

This mode—which incidentally is the only mode of operation of many other messaging platforms—trades off the single, efficient data transfer step for multiple parallel message handling operations.

Instead of waiting for your server to fetch messages, updates are pushed to your bot’s web server to an URL of your choice (Telegram requires HTTPS, a domain name, and a certificate). Instead of having to deal with parallelism, this mode exploits the inherent strong points of a web server: dealing with multiple incoming connections and handling them off efficiently to your code.

Results

Based on our logs, 7.414.458 messages where sent to the bot through Telegram, in little over 80 minutes of operation.

An average of over 380 messages per minute were handled, with a peak of around 1200. If you watch closely, you can get a hint of when the 14 questions were asked.

Initially, our bot was configured to operate via pull and synchronous message handling, since this mode allows for far easier debugging and development. However, as soon as the event did start, we quickly discovered that the queue of messages was growing uncontrollably and the bot simply could not keep up.
We quickly switched over to push mode. Over the course of a couple of minutes the bot was able to catch up and performed very responsively for the rest of the event.

The bot was running on a quad-core machine clocked at 2.6 GHz, with 2 GBs of RAM.

In conclusion, pull mode is perfectly suited for bot development, since it allows developers to control the flow of messages and to carefully debug the code. Implementing an efficient message handling method via pull mode, however, probably isn’t worth the development effort. As suggested by others, it is far easier to entrust the web server with handling parallel requests on your behalf.

More generally—and this is very important in the context of the recent focus on bots as a replacement of apps—using a bot instead of a web site (for instance) gave us a very important advantage. The messaging platform, Telegram in this case, acts as an extremely scalable load balancer in front of your service. It handles message queuing, retrying, delivery, and push notifications—essentially Telegram offers an incredible amount of complex infrastructure for free. This allows you to focus on actual service development instead of having to worry about the plumbing.

This Europe Code Week event has been a good opportunity to appreciate the effects of an unusual load (for our scale of development) on our bot. Further similar events will be planned and we look forward to evaluate performance and scaling issues in deeper detail.

The code used during the event is available on Github.

The game had been developed during the week just before the event and the whole team behind the treasure hunt spent the last minutes before the start feverishly fixing the last bugs. (Well, most of them.)

The summer school, aimed at school teachers of all grades, had the main focus of bringing coding to the classroom, in a way that could be engaging for both teachers and young students. Thus, it made more than sense that the treasure hunt itself, “Urbino Code Hunting” as it was called, would be based on coding puzzles as well.

What made the treasure hunt interesting is that the whole registration process, the actual hunting, puzzling, and other game mechanics were directly handled by a Telegram bot. Anyone with a Telegram account could very easily register during the 4 days before the game just by entering a conversation with it.

Registrations to the game were handled by a run of the mill conversation with the bot.

The bot asked registrants to solve a “preliminary” puzzle (to prepare players for what would have come later and to work as some kind of captcha), how many other participants would have taken part to the game together with the team leader, and the team’s name.

Usually a treasure hunt game requires players to find hidden objects or reach secret locations based on some—more or less vague—clues. In our case, the actual puzzling was centered around coding questions delivered by the bot, not around recognizing locations from clues, both because coding was the theme of the game and because many participants weren’t familiar with the city. Therefore, locations to reach were given out explicitly by the bot.

The actual gameplay was structured as follows:

• 1) Each group gets a random location to reach (sent as a precise geographical location and rendered as a point on a map).
• 2) On reaching its assigned location, the group snaps a selfie and sends it to the bot.
• 3) The bot picks one of the coding puzzles and waits for the group’s answer. The bot forces a minimum delay of 1 minute between attempts.
• 4) If the solution is correct, the bot gives out a new clue for the final puzzle.
• 5) Go to 1.

We identified 30 well-distributed locations around the town, which we marked with a description, a precise GPS location, a numeric ID, and a secret code (16 random alphanumeric characters).

Each location had its own secret 16-character code.

How did the bot ensure that a group has reached its destination? Easy. We printed 30 paper signs (on A4 sheets), one for each location, with a special QR Code linking to an URL following this scheme:

https://telegram.me/treasurehuntbot?start=0123456789ABCDEF

This link makes use of the deep linking feature of Telegram: after opening the URL through a QR Code scanner, the user’s phone automatically starts the Telegram client and sends the “/start 0123456789ABCDEF” string to our bot, without actually displaying it inside the conversation screen. Since each QR Code contained the location’s secret 16-character code inside the URL, the bot would know with certainty which code the group had scanned and thus which location was reached.

The bot tracked each group making its way through a sequence of 12 locations. To ensure that groups of players do not follow each other and that they don’t cluster in the same area, the sequence of locations to reach for each group was chosen at random.

In order to ensure fairness, sequences of locations were generated beforehand with a bounded maximum (and minimum) length.

Puzzles—which were given out as soon as a group reached a location and sent a confirmation selfie of the group—were based on the CodyRoby quizzes . These simple logical puzzles make use of shared conventions, like the colored pseudo-code blocks from Blockly used in Code.org and the CodyRoby coding cards .

Sample question.

All puzzles required at most a couple of minutes to be solved and the answer could be provided as a simple text message, usually with a single character or a single number. Answers would be accepted quite liberally, with whitespace, in upper or lower case, and with any formatting. Wrong answers caused a forced delay of 60 seconds before the next attempt.

Correct answers not only let the group move forward, but they also rewarded the group with an important clue that would then be used to solve the last riddle: as soon as a group reached the last location (which we made sure was the same for all groups), they were given a map (like, a real, tangible, honest to goodness map made out of paper) that could be used to find out the exact place where the coveted prize was hidden.

The first group that reached it would get to keep the prize and receive another wonderful QR Code. Who doesn’t love QR Codes anyway? This last code signaled that the game was over for everyone.

A Telegram channel was used to broadcast information, to share selfies, and to make the game more engaging.

The Urbino Code Hunting Telegram channel was created on the day of the game and all participants were invited to subscribe to it. Major advancements of the groups were broadcast on the channel, along with all selfies taken by the groups as soon as they were sent in from the various locations. The channel gave the participants and us a way to monitor the state of the game, thus making it more engaging as the groups got closer to their final destination.

Part of all the selfies collected by the bot.

The bot was powered by a PHP program and a MySQL database, patched together in less than a week. The source code has been published on Github under the MIT license if you want to take a look. At the moment, deploying the bot for your own backyard treasure hunt might not be the easiest of tasks, but we are already planning to make it reusable at will.
(And we have other significant—and scary?—plans for the future…)

When the program executes, keypress events are treated as if they were generated by the local keyboard and received by the focus window.

This provides a very simple and general mechanism to grant collective control of any Scratch project to an arbitrary number of people taking part to an instant poll.

To use DirectPollMonitor:

• 1. Download the DirectPollMonitor archive (requires .NET 4.5.2)
• 2. Extract DirectPollMonitor into a local folder of your choice
• 3. Open a Command Prompt on that folder
• 4. Launch the DirectPollMonitor from command line using as a parameter the URL of the DirectPoll result page
• 5. Start the DirectPoll and invite the audience to vote
• 6. Change the keyboard focus to the Scratch project

In order to make sure that all keypress events are properly received by the Scratch project, it is recommended that the window in which the Scratch project executes keeps the keyboard focus for the entire duration of the poll. Hence, it is better to control the poll from a different computer, while leaving in background the Command Prompt Terminal in which DirectPollMonitor executes.

A standard poll has been created for testing purposes. It has only 5 options associated with keys A, B, C, D, and E. Hence, it can be used to control any Scratch project designed to react to these keypress events.

Provide this link to the audience: http://etc.ch/SAA2

Pass this URL to DirectPollMonitor: http://directpoll.com/r?XDbzPBd3ixYqg8WPz06HavXHDMrW9iAfEQDf3Tuc2U

Use this simple Scratch project reacting to keys A, B, and C to test the remote control: https://scratch.mit.edu/projects/109658618/ (the name of the project has been typed by the audience…).

DirectPollMonitor was tested for the first time on ScratchDay 2016 during a public webinar attended by many Italian School teachers with their pupils. Several Scratch projects were developed during the webinar and controlled in real time by more than 100 people. Here is the video log.

Sources files to be published on GitHub.

The conference was held in the imposing conference center Lingotto in Turin, nicely bathed in sun and nice weather, with more than 700 participants from over 21 different countries.

Saverio and Lorenz after getting their badges. As you can see, badges = bliss.

Last year’s event was marked by an unmanageable epidemy of Google Glass-wearing speakers. The 2015 edition fortunately marked a switch from Google’s glasses to more discreet Android Wear based watches. A nice advantage, from a stylistic perspective at the least.

Because of that, many sessions were actually focused on Android Wear and Android Auto, the brand new platforms where our favorite green droid is expanding into. Many other talks during the two intense days of DroidCon where instead focused on the intersection between Android and the Internet of Things: for instance interesting stuff about iBeacons and (a bit discouraging) experiments on proximity monitoring by Matteo Gazzurelli.

Apart from software development, one of the most discussed topics was actually user experience (or “UX”): Lydia Selimalhigazi and Roberto Orgiu gave a nice overview on why developers and designers need to stick together and help each other in order to obtain results without (too much) conflict. The same topic was taken on, from a branding perspective, during the stimulating talk by Marie Schweiz on how the specific features of a brand influence the user experience (not only the logo, that is).

Another totally different point of view on “user experience”: Kentaro Takiguchi gave a very nice talk “Improving UX through Performance” with an in-depth overview of those little optimizations that can be applied, both on the app and on the server side, in order to improve an app’s fluidity, reliability and responsiveness. An interesting bag of tricks for scenarios where even shaving off 4 KBs from a remote request can have a great impact.

Benjamin Augustin made clear that in fact software development can, at times, be a hellish affair. However, in order to free developers from pain, a growing number of libraries and tools are being worked on. One of those libraries is in fact RxJava, the Java port of the Reactive extensions originally created for .NET: those extensions offer a nice way to “invert” how your code work, by adopting a “reactive” coding paradigm which is very well suited to manage the interactions between user interface and an unreliable backend (like network access, for instance).

Likewise, Maciej Górski presented several ways, especially using Gradle plug-ins, to reduce the amount of “boilerplate” code developers need to write (for instance getter and setter methods for Java classes). Also very interesting: the “Holy Sync!” session by Eugenio Marletti, about cross-platform synchronization methods, using CouchBase.

“Test, test and test!” was the mantra of several other talks, in particular the one given by the always funny Ali Derbane e Wiebe Elsinga (don’t even try pronouncing his name, you’ll fail) who during their talk “The hitchhiker’s guide to functional testing” gave an overview of most functional testing suites available for Android. Stephan Linzner instead showed the glorious new tools developed at the Google mothership for its mobile developers.

Finally, at 12 o’clock of the first day, pushed by hunger more than anything else, our Lorenz gave his talk “The love child of Android and .NET: using Xamarin for app development” about all our recent experiences using the Xamarin platform for Android development during the last year. Slides can be downloaded as PPTX as well.

Gave us the necessary energy between sessions: the Cola from Turin!

After two very intense days we left Turin exhausted, but encouraged and inspired by many new things to check out, technologies to use in our projects and details to keep in mind while developing on Android (and not only)! Looking forward for next year!

And that’s why this morning the very tempting box of the Android mascot, entire made of Lego blocks, showed up at our laboratory’s door! A great opportunity to show off the manual skills of the lab members.

Thank you Catia!

Like all beautiful things, the International Summer School on Smart & Mobile Device Security and Privacy is also approaching to its end.

For the last two days of lectures, the floor was given directly to the attending students. During this Ph.D. Forum, promisingly nicknamed “The Grill”, everybody was given the chance of presenting their own research work by giving a ten minutes presentation and exposing themselves to the comments and (thorough and well-meant) critique. Most of the students have been talking about issues related with mobile security, addressed at different levels: starting from hardware, malicious software detection (through static or dynamic means), using machine learning techniques to detect malicious activity, to the analysis of permissions in order to detect possible attacks.

To conclude with the lecturers, prof. Prakash from University of Michigan gave us a general overview of the Android security model, showing us the most known attacking strategies, such as exploiting communication channels established by applications, or using side channels. He concluded by depicting some of the most used defence strategies.

On Friday, prof. Poovendran from University of Washington moved to a slightly different topic, talking about control-theoretic modelling and mitigation of cyberattacks. He showed us some techniques to detect compromised nodes in networks, meaning some nodes are physically captured by an adversary that wants to inject false messages in the network, thus compromising the good behaviour of the system.  In order to defend the network from such attacks, different possibilities exist, based on so called “witnesses”: periodically all nodes of a network send broadcast messages containing their ID and location and their neighbours act as witnesses, understanding if the sender is a cloned node or a safe one.

Finally, the works have been concluded by prof. Prakash, giving us a very interesting talk about a new solution to avoid app phishing attacks on smartphones, called TIVO “Trusted Visual I7O Paths for Android”. When enabled, TIVO allows users to associate a secret image to each installed application. Then, each time the application is running and displays a keyboard (possibly to input sensitive data, like username and password), TIVO displays the application’s icon, the application’s name and, if set, the secret image picked by the user itself. This should make it much harder for malicious apps to intercept login screens and do phishing attacks.

The participant of the summer school at Palazzo Bo, in Padua.

And that’s all from Padua and from SMDSP, folks! A special thank goes out to the University of Padua, to the organizers and lecturers of this very interesting Summer School and of course to all the participating students for making this a really nice week.
See you next year in Padua!

Silvia Malatini & Lorenz Cuno Klopfenstein

As reported before, we are now at day three of the International Summer School on Smart & Mobile Device Security and Privacy, after lots of lectures, a tiny bit of sightseeing, not much sleep and — unfortunately — some bad weather.

Dr. Ivan Martinovic from the University of Oxford gave us an overview about his research about secure key exchange on wireless networks, avoiding the widely used Diffie-Hellman method and exploiting inherent characteristics of the wireless channel between the two parties trying to exchange key (specifically: how the signal between the parties is influenced by the physical room between them as a unique signature). Moreover, he gave us an outline of his work on face and daze detection.

Getting back to the Android platform, prof. Sadeghi continued his outline of the large attack surface that a mobile device (and its OS) represent. Attacks to Android can be performed at various levels, starting from the applications installed, the Android middleware and getting as low as the underlying Linux kernel. Applications can perform many malicious actions even without particular effort, by exploiting the access permissions that users often unknowingly grant during installation. Otherwise, they can try to “collude” with other malicious or unsafe applications in order to perform actions without the user’s consent. Some apps can exploit bugs in system apps or in the middleware to get  higher privileges (or even gain root access to the phone). It was interesting to see many of such attacks live during a short lab session.

Lucas Davi, from University Darmstadt, gave a basic overview of how return-oriented attacks are performed and how ASLR, DEP and similar techniques help preventing such attacks (and how they can be circumvented).

Matthias Schunter, from the Intel Collaborative Research Institute for Secure Computing (ICRI-SC), talked about the evolution of pervasive computing and the so-called Internet of Things, which presents a scenario with a huge number of devices performing privacy-sensitive operations and thus requiring a well thought approach to security. Intel cooperates closely with academic researchers in order to ensure that even smallest devices (as Intel Galileo, for instance) get sufficient security features and can be trusted. Long running devices also face the issue of staying secure through an operating period measured in decades.

Having reached the half of the summer school, we’re now signing off for a (rainy) visit of Padua, including the world-famous Cappella degli Scrovegni painted by Giotto himself and Palazzo Bo, the original seat of the university at the time of its founding in the XIII century, when security could still be ensured by a mechanical lock…

Silvia Malatini & Lorenz Cuno Klopfenstein

Summer is running out, but to keep our feelings high we could not miss this great summer school about Security and Privacy on Smart and Mobile devices. The SMDSP summer school just started on Monday, September 1st, in the beautiful city of Padua. It is organized by some of actual main experts in the field, like professor Mauro Conti, from the University of Padua, the director of the school, professor Asokan from Aalto University and professor Ahmad-Reza Sadeghi from TU Darmstadt.

In fact, the school is co-orgnaized by the University of Padua, particularly the Department of Mathematics, the Aalto University, the Center for Advanced Security Research Darmstadt, and the Intel Collaborative Research Institute for Secure Computing.

The University of Padua is a long tradition University (among the earliest Universities of the world, founded in 1222 as the second one in Italy, just after Bologna; it also hosted people like Galileo Galilei and Nicolaus Copernicus).

The main focus of this summer school is to bring together members from the international security research community to debate contemporary issues in the area of smartphone security and privacy, which is becoming more and more important in the era of Internet of Things.

25 students and 15 organizers, between scientific and operational committees are going to work together for one week, to discuss their works and ideas about this interesting fields.

On Monday works have been opened by the Chancellor’s delegate, Ms. Lucia Regolin and by the Director of the Department of Mathematics, Mr. Bruno Viscolani, explaining us how this school reflects the motto of Padua University “Universa Universis Patavina Libertas“, which aims to give always more freedom of thoughts to teachers and students, along all its long history.

Later, prof. Asokan has introduced us in the world of Trusted Execution Environments (TEE), where Trusted means that the environment is isolated from the “normal” execution environment (where OS and “normal” applications run), so that integrity is protected. He showed us what constitutes a TEE environment and some used architectures, and which are the state of the art being developed nowadays. He showed us the ongoing work on TPM (Trusted Platform Module) 2.0 and its differences with the past one, 1.2.

Professor Ahmad-Reza Sadeghi gave us a very interesting lecture about the security of mobile platforms in general, going deeper on Android security framework and showing us which are the most problematic attacks one has generally to fight and how doing security is hard work and very difficult to do thoroughly even it things appear to be correct.
As prof. Sadeghi put it: “never trust a working thing“.

To conclude the day, professor Mauro Conti showed us their ongoing works in this matter and the latest issues they are concerned about. And then he also promised to show us why exactly his department’s acronym is SPRITZ…

Silvia Malatini & Lorenz Cuno Klopfenstein

In spite of the large number of amazing new gadgets with unprecedented ergonomic design, my smartphone is by far the most wearable device I use every day. Technically speaking, I’m not exactly wearing it, in that I need either to keep it in hand, or to put it in a pocket or in a bag. But I feel more comfortable with my all-in-one mobile than with any other wearable device, including my mechanical wrist watch.

So my first question is:

1. Do smartphones belong to the category of wearable devices?

To provide a tentative answer to this question I need to go back to the first time I encountered the myth of wearable computing in my professional life (trying not to consider the time spent watching Star Trek as part of it). At that time (the early 90’s) the Internet was in its infancy, Wi-Fi was still WaveLAN, laptops were hardly portable, and I had no cellular phones. To me, wearable computing was just an enabling technology to achieve the goal of ubiquitous/mobile computing. Wearing a computer has never been a big dream of mine, but I’ve always desired to be able to compute and communicate anywhere and at anytime.

The difference between a portable device and a wearable device is that the former is so cumbersome that I decide to bring it with me if and only if I know for sure that I’m going to need it during the day and that its utility will compensate the discomfort that it will cause to me in my daily routine (laptops belong to this category, although they have become much thinner and lighter than in the early 90’s) the latter is so handy and useful that I know for sure that I’ll need it during the day and that I won’t be limited in all other activities because of it, so that I bring it with me without even considering if it is worth or not (I have no doubt that smartphones belong to this category).

This brings to my second question:

2. Is there any device which is more wearable than a smartphone?

According to the definition provided above, I don’t think so. I wear my smartphone more than any other object, clothes included. There is no piece of clothing that I wear for more than 12 hours every day! Even a sweater looks less wearable than a mobile to me, in that I decide to carry it with me when I go out only if I really think I’m going to put it on, or otherwise it will hinder me in my activities.

Going back to wearable electronic devices, smart watches and Google glasses are very good examples of truly wearable gadgets enabling new applications in many relevant fields like augmented reality, accessibility, health care, and gaming. However, they are still not usable enough as general purpose personal devices in order to replace smartphones, while they are more hindering than a smartphone when not used. At the moment, they look more like companion gadgets than like stand-alone devices, and their marketing and usage models rely on the fact that endusers already have their smartphones with them.

For the last days, some students have presented their research works to the class: very interesting topics on traffic load predictions, social networks data analysis and complex systems data modelling.

And to close the works a (not so easy) exam has been subjected to the students, questioning about lectures of the week.

Just a couple of personal opinions about the Summer School.
Firstly, I think that attending lectures about so specific topics, it’s quite a unique occasion, both for students and also for people working in the field: getting to know actual research fields and being able to talk about everybody’s projects and ideas is a very stimulating thing.
Secondly, getting in touch with international students and knowing how research is lead in other european and international universities, it’s something that every student should do, in my opinion, to understand the importance of doing experience in international universities.

A great thanks goes to the organizers of the Summer School and their efforts for letting us have a really great experience.

So, c u next year in Lipari!