A Study on Platform's New Strategy in Media 2.0 Era - Based on “Keystone” concept & Google case

The purpose of this paper is to suggest a new strategy of the platform in Media 2.0 era. This goal is approached by firstly examining conceptual change of the platform strategy from mass media world (Media 1.0) to micro media world (Media 2.0). Then, it will discuss "Keystone" strategy by Iansiti & Levien (2004) who introduced four different types of platform and will give an example, Google. The data shows, how Google's keystone strategy could be successfully accomplished with three sources for value creation, revelation, aggregation and plasticity, and how healthy it is in terms of productivity, robustness, and niche creation. Finally, an applicable framework to Media 2.0 will be constructed on the basis sources for value creation and "Keystone" capabilities of ecosystem management. Three main parts of the keystone strategy are the openness, synchronization, and mass customization focus. --Media platform,Keystone,ecosystem

TriCheck: Memory Model Verification at the Trisection of Software, Hardware, and ISA

Memory consistency models (MCMs) which govern inter-module interactions in a shared memory system, are a significant, yet often under-appreciated, aspect of system design. MCMs are defined at the various layers of the hardware-software stack, requiring thoroughly verified specifications, compilers, and implementations at the interfaces between layers. Current verification techniques evaluate segments of the system stack in isolation, such as proving compiler mappings from a high-level language (HLL) to an ISA or proving validity of a microarchitectural implementation of an ISA. This paper makes a case for full-stack MCM verification and provides a toolflow, TriCheck, capable of verifying that the HLL, compiler, ISA, and implementation collectively uphold MCM requirements. The work showcases TriCheck's ability to evaluate a proposed ISA MCM in order to ensure that each layer and each mapping is correct and complete. Specifically, we apply TriCheck to the open source RISC-V ISA, seeking to verify accurate, efficient, and legal compilations from C11. We uncover under-specifications and potential inefficiencies in the current RISC-V ISA documentation and identify possible solutions for each. As an example, we find that a RISC-V-compliant microarchitecture allows 144 outcomes forbidden by C11 to be observed out of 1,701 litmus tests examined. Overall, this paper demonstrates the necessity of full-stack verification for detecting MCM-related bugs in the hardware-software stack.Comment: Proceedings of the Twenty-Second International Conference on Architectural Support for Programming Languages and Operating System

Verifying Policy Enforcers

Policy enforcers are sophisticated runtime components that can prevent failures by enforcing the correct behavior of the software. While a single enforcer can be easily designed focusing only on the behavior of the application that must be monitored, the effect of multiple enforcers that enforce different policies might be hard to predict. So far, mechanisms to resolve interferences between enforcers have been based on priority mechanisms and heuristics. Although these methods provide a mechanism to take decisions when multiple enforcers try to affect the execution at a same time, they do not guarantee the lack of interference on the global behavior of the system. In this paper we present a verification strategy that can be exploited to discover interferences between sets of enforcers and thus safely identify a-priori the enforcers that can co-exist at run-time. In our evaluation, we experimented our verification method with several policy enforcers for Android and discovered some incompatibilities.Comment: Oliviero Riganelli, Daniela Micucci, Leonardo Mariani, and Yli\`es Falcone. Verifying Policy Enforcers. Proceedings of 17th International Conference on Runtime Verification (RV), 2017. (to appear

The Impact of Digital Platform Rapid Release Strategy on App Update Behavior: An Empirical Study of Firefox

The success of platform-based software ecosystems depends on the crucial coordination between the platform and third-party applications during co-evolution. Leveraging the change of platform release governance of Firefox, this paper examines the impact of the rapid release process on app update behavior (app responsiveness and app size change). Drawing on boundary resource perspective, we theorize how rapid release process as a social boundary resource affects app update behavior, and how app developers’ usage of technical boundary resource (i.e. platform API) affects this impact. Using a unique longitudinal dataset in Firefox, we conduct empirical analyses and conclude that the rapid release process decreases size change of app updates while platform API usage enhances app responsiveness. Moreover, platform API usage strengthens the effects of the rapid release process on app update behavior. This research enhances our understanding of the impact of platform governance practices on platform-third party coordination and provides practical guidance. Keywords: Platform-based software ecosystem, platform governance, app update, Rapid Release, boundary resourc

An Exploratory Study of Field Failures

Field failures, that is, failures caused by faults that escape the testing phase leading to failures in the field, are unavoidable. Improving verification and validation activities before deployment can identify and timely remove many but not all faults, and users may still experience a number of annoying problems while using their software systems. This paper investigates the nature of field failures, to understand to what extent further improving in-house verification and validation activities can reduce the number of failures in the field, and frames the need of new approaches that operate in the field. We report the results of the analysis of the bug reports of five applications belonging to three different ecosystems, propose a taxonomy of field failures, and discuss the reasons why failures belonging to the identified classes cannot be detected at design time but shall be addressed at runtime. We observe that many faults (70%) are intrinsically hard to detect at design-time

An Exploratory Study of Field Failures

Field failures, that is, failures caused by faults that escape the testing phase leading to failures in the field, are unavoidable. Improving verification and validation activities before deployment can identify and timely remove many but not all faults, and users may still experience a number of annoying problems while using their software systems. This paper investigates the nature of field failures, to understand to what extent further improving in-house verification and validation activities can reduce the number of failures in the field, and frames the need of new approaches that operate in the field. We report the results of the analysis of the bug reports of five applications belonging to three different ecosystems, propose a taxonomy of field failures, and discuss the reasons why failures belonging to the identified classes cannot be detected at design time but shall be addressed at runtime. We observe that many faults (70%) are intrinsically hard to detect at design-time

A Closer Look at the Security Risks in the Rust Ecosystem

Rust is an emerging programming language designed for the development of systems software. To facilitate the reuse of Rust code, crates.io, as a central package registry of the Rust ecosystem, hosts thousands of third-party Rust packages. The openness of crates.io enables the growth of the Rust ecosystem but comes with security risks by severe security advisories. Although Rust guarantees a software program to be safe via programming language features and strict compile-time checking, the unsafe keyword in Rust allows developers to bypass compiler safety checks for certain regions of code. Prior studies empirically investigate the memory safety and concurrency bugs in the Rust ecosystem, as well as the usage of unsafe keywords in practice. Nonetheless, the literature lacks a systematic investigation of the security risks in the Rust ecosystem. In this paper, we perform a comprehensive investigation into the security risks present in the Rust ecosystem, asking ``what are the characteristics of the vulnerabilities, what are the characteristics of the vulnerable packages, and how are the vulnerabilities fixed in practice?''. To facilitate the study, we first compile a dataset of 433 vulnerabilities, 300 vulnerable code repositories, and 218 vulnerability fix commits in the Rust ecosystem, spanning over 7 years. With the dataset, we characterize the types, life spans, and evolution of the disclosed vulnerabilities. We then characterize the popularity, categorization, and vulnerability density of the vulnerable Rust packages, as well as their versions and code regions affected by the disclosed vulnerabilities. Finally, we characterize the complexity of vulnerability fixes and localities of corresponding code changes, and inspect how practitioners fix vulnerabilities in Rust packages with various localities.Comment: preprint of accepted TOSEM pape

Federated Robust Embedded Systems: Concepts and Challenges

The development within the area of embedded systems (ESs) is moving rapidly, not least due to falling costs of computation and communication equipment. It is believed that increased communication opportunities will lead to the future ESs no longer being parts of isolated products, but rather parts of larger communities or federations of ESs, within which information is exchanged for the benefit of all participants. This vision is asserted by a number of interrelated research topics, such as the internet of things, cyber-physical systems, systems of systems, and multi-agent systems. In this work, the focus is primarily on ESs, with their specific real-time and safety requirements. While the vision of interconnected ESs is quite promising, it also brings great challenges to the development of future systems in an efficient, safe, and reliable way. In this work, a pre-study has been carried out in order to gain a better understanding about common concepts and challenges that naturally arise in federations of ESs. The work was organized around a series of workshops, with contributions from both academic participants and industrial partners with a strong experience in ES development. During the workshops, a portfolio of possible ES federation scenarios was collected, and a number of application examples were discussed more thoroughly on different abstraction levels, starting from screening the nature of interactions on the federation level and proceeding down to the implementation details within each ES. These discussions led to a better understanding of what can be expected in the future federated ESs. In this report, the discussed applications are summarized, together with their characteristics, challenges, and necessary solution elements, providing a ground for the future research within the area of communicating ESs

Methods for Marine Ecosystems Research through the Use of PDAs with Preservice Teachers

Science teachers are charged with the task of providing students in grades K-12 with opportunities that will enable them to make sense of science and develop habits of mind. One goal of science education is to prepare well-rounded citizens who are scientifically literate. Through inquiry-based learning, students formulate questions, perform investigations, and construct new understandings. It is important for preservice science teachers to be introduced to current techniques, discoveries, and debates in the field of science. The use of personal digital assistants (PDAs) can provide K-12 students with increased opportunities for exploring and learning through scientific investigations. In order for these devices to be successfully integrated into classroom instruction, changes in teaching methodologies must be adopted. This paper presents a model lesson that can be used to guide preservice teachers in the use of PDAs for studying a marine ecosystem. The field experience takes place on the shoreline of Long Island Sound at Stratford Point, in Stratford Connecticut