Misleading names of the methods in a project or the APIs in a software library confuse developers about program functionality and API usages, leading to API misuses and defects. In this paper, we introduce MNire, a machine learning approach to check the consistency between the name of a given method and its implementation. MNire first generates a candidate name and compares the current name against it. If the two names are sufficiently similar, we consider the method as consistent. To generate the method name, we draw our ideas and intuition from an empirical study on the nature of method names in a large dataset. Our key finding is that high proportions of the tokens of method names can be found in the three contexts of a given method including its body, the interface (the method's parameter types and return type), and the enclosing class' name. Even when such tokens are not there, MNire uses the contexts to predict the tokens due to the high likelihoods of their co-occurrences. Our unique idea is to treat the name generation as an abstract summarization on the tokens collected from the names of the program entities in the three above contexts.

Emotions play a major role in how interpersonal conflicts unfold. Although several strategies and technological approaches have been proposed for emotion regulation, they often require conscious attention and effort. This often limits their efficacy in practice. In this paper, we propose a different approach inspired by self-perception theory: noticing that people are often reacting to the perception of their own behavior, we artificially change their perceptions to influence their emotions. We conducted two studies to evaluate the potential of this approach by automatically and subtly altering how people perceive their own voice. In one study, participants that received voice feedback with a calmer tone during relationship conflicts felt less anxious. In the other study, participants who listened to their own voices with a lower pitch during contentious debates felt more powerful. We discuss the implications of our findings and the opportunities for designing automatic and less perceptible emotion regulation systems.

Tracing IP packets to their sources, known as IP traceback, is an important task in defending against IP spoofing and DoS attacks. Log-based IP traceback technique is to log packets at routers in the network and then determine the network paths which packets traversed using data extraction techniques. The biggest advantage of log-based IP traceback is the potential to trace a single packet. Tracing a single packet in the Internet using log-based IP traceback involves cooperation among all autonomous systems (AS) traversed by the packet. The single packet traceback process may not reach the packet origin if some AS on the forwarding path does not support IP traceback. IP traceback mechanisms are deployed within each AS independently. It is not reasonable to assume all ASes begin to support the same IP traceback mechanism in a short period of time. In this paper, we study the effectiveness of log-based IP traceback in tracing a single packet under the environment where not every AS supports log-based IP traceback. We propose a scheme to conduct the single packet traceback process in AS-level partial deployment scenario. We evaluate the performance of single packet IP traceback in AS-level partial deployment scenario based on our scheme through simulation.