Visible to the public Biblio

Filters: First Letter Of Title is W  [Clear All Filters]
A B C D E F G H I J K L M N O P Q R S T U V [W] X Y Z   [Show ALL]
W
Kurilova, Darya, Potanin, Alex, Aldrich, Jonathan.  2014.  Wyvern: Impacting Software Security via Programming Language Design.. Workshop on Evaluation and Usability of Programming Languages and Tools (PLATEAU), 2014.

Breaches of software security affect millions of people, and therefore it is crucial to strive for more secure software systems. However, the effect of programming language design on software security is not easily measured or studied. In the absence of scientific insight, opinions range from those that claim that programming language design has no effect on security of the system, to those that believe that programming language design is the only way to provide “high-assurance software.” In this paper, we discuss how programming language design can impact software security by looking at a specific example: the Wyvern programming language. We report on how the design of the Wyvern programming language leverages security principles, together with hypotheses about how usability impacts security, in order to prevent command injection attacks. Furthermore, we discuss what security principles we considered in Wyvern’s design.

Darya Kurilova, Alex Potanin, Jonathan Aldrich.  2014.  Wyvern: Impacting Software Security via Programming Language Design. PLATEAU '14 Proceedings of the 5th Workshop on Evaluation and Usability of Programming Languages and Tools.

Breaches of software security affect millions of people, and therefore it is crucial to strive for more secure software systems. However, the effect of programming language design on software security is not easily measured or studied. In the absence of scientific insight, opinions range from those that claim that programming language design has no effect on security of the system, to those that believe that programming language design is the only way to provide “high-assurance software.” In this paper, we discuss how programming language design can impact software security by looking at a specific example: the Wyvern programming language. We report on how the design of the Wyvern programming language leverages security principles, together with hypotheses about how usability impacts security, in order to prevent command injection attacks. Furthermore, we discuss what security principles we considered in Wyvern’s design. 

Nistor, Ligia, Kurilova, Darya, Balzer, Stephanie, Chung, Benjamin, Potanin, Alex, Aldrich, Jonathan.  2013.  Wyvern: A Simple, Typed, and Pure Object-Oriented Language. Workshop on Mechanisms for Specialization, Generalization, and Inheritance (MASPEGHI), 2013.

The simplest and purest practical object-oriented language designs
today are seen in dynamically-typed languages, such as Smalltalk
and Self. Static types, however, have potential benefits for productivity,
security, and reasoning about programs. In this paper, we describe
the design of Wyvern, a statically typed, pure object-oriented
language that attempts to retain much of the simplicity and expressiveness
of these iconic designs.
Our goals lead us to combine pure object-oriented and functional
abstractions in a simple, typed setting. We present a foundational
object-based language that we believe to be as close as
one can get to simple typed lambda calculus while keeping objectorientation.
We show how this foundational language can be translated
to the typed lambda calculus via standard encodings. We then
define a simple extension to this language that introduces classes
and show that classes are no more than sugar for the foundational
object-based language. Our future intention is to demonstrate that
modules and other object-oriented features can be added to our language
as not more than such syntactical extensions while keeping
the object-oriented core as pure as possible.
The design of Wyvern closely follows both historical and modern
ideas about the essence of object-orientation, suggesting a new
way to think about a minimal, practical, typed core language for
objects.

Ligia Nistor, Darya Kurilova, Stephanie Balzer, Benjamin Chung, Alex Potanin, Jonathan Aldrich.  2013.  Wyvern: a simple, typed, and pure object-oriented language. MASPEGHI '13 Proceedings of the 5th Workshop on MechAnisms for SPEcialization, Generalization and inHerItance.

The simplest and purest practical object-oriented language designs today are seen in dynamically-typed languages, such as Smalltalk and Self. Static types, however, have potential benefits for productivity, security, and reasoning about programs. In this paper, we describe the design of Wyvern, a statically typed, pure object-oriented language that attempts to retain much of the simplicity and expressiveness of these iconic designs.

Our goals lead us to combine pure object-oriented and functional abstractions in a simple, typed setting. We present a foundational object-based language that we believe to be as close as one can get to simple typed lambda calculus while keeping object-orientation. We show how this foundational language can be translated to the typed lambda calculus via standard encodings. We then define a simple extension to this language that introduces classes and show that classes are no more than sugar for the foundational object-based language. Our future intention is to demonstrate that modules and other object-oriented features can be added to our language as not more than such syntactical extensions while keeping the object-oriented core as pure as possible.

The design of Wyvern closely follows both historical and modern ideas about the essence of object-orientation, suggesting a new way to think about a minimal, practical, typed core language for objects.

Welk, A., Zielinska, O., Tembe, R., Xe, G., Hong, K. W., Murphy-Hill, E., Mayhorn, C. B..  In Press.  Will the “Phisher-men” Reel you in? Assessing Individual Differences in a Phishing Detection Task International Journal of Cyber Behavior, Psychology, and Learning. .

Phishing is an act of technology-based deception that targets individuals to obtain information. To minimize the number of phishing attacks, factors that influence the ability to identify phishing attempts must be examined. The present study aimed to determine how individual differences relate to performance on a phishing task. Undergraduate students completed a questionnaire designed to assess impulsivity, trust, personality characteristics, and Internet/security habits. Participants performed an email task where they had to discriminate between legitimate emails and phishing attempts. Researchers assessed performance in terms of correctly identifying all email types (overall accuracy) as well as accuracy in identifying phishing emails (phishing accuracy). Results indicated that overall and phishing accuracy each possessed unique trust, personality, and impulsivity predictors, but shared one significant behavioral predictor. These results present distinct predictors of phishing susceptibility that should be incorporated in the development of anti-phishing technology and training.

[Anonymous].  2017.  Which Factors Influence Practitioners’ Usage of Build Automation Tools? 3rd International Workshop on Rapid Continuous Software Engineering (RCoSE) 2017.

Even though build automation tools help to reduce errors and rapid releases of software changes, use of build automation tools is not widespread amongst software practitioners. Software practitioners perceive build automation tools as complex, which can hinder the adoption of these tools. How well founded such perception is, can be determined by
systematic exploration of adoption factors that influence usage of build automation tools. The goal of this paper is to aid software practitioners in increasing their usage of build
automation tools by identifying the adoption factors that influence usage of these tools. We conducted a survey to empirically identify the adoption factors that influence usage of
build automation tools. We obtained survey responses from 268 software professionals who work at NestedApps, Red Hat, as well as contribute to open source software. We observe that adoption factors related to complexity do not have the strongest influence on usage of build automation tools. Instead, we observe compatibility-related adoption factors, such as adjustment with existing tools, and adjustment with practitioner’s existing workflow, to have influence on usage of build automation tools with greater importance. Findings from our paper suggest that usage of build automation tools might increase if: build automation tools fit well with practitioners’ existing workflow and tool usage; and usage of build automation tools are made more visible among practitioners’ peers.

Rahman, Akond, Partho, Asif, Meder, David, Williams, Laurie.  2017.  Which Factors Influence Practitioners' Usage of Build Automation Tools? Proceedings of the 3rd International Workshop on Rapid Continuous Software Engineering. :20–26.

Even though build automation tools help to reduce errors and rapid releases of software changes, use of build automation tools is not widespread amongst software practitioners. Software practitioners perceive build automation tools as complex, which can hinder the adoption of these tools. How well founded such perception is, can be determined by systematic exploration of adoption factors that influence usage of build automation tools. The goal of this paper is to aid software practitioners in increasing their usage of build automation tools by identifying the adoption factors that influence usage of these tools. We conducted a survey to empirically identify the adoption factors that influence usage of build automation tools. We obtained survey responses from 268 software professionals who work at NestedApps, Red Hat, as well as contribute to open source software. We observe that adoption factors related to complexity do not have the strongest influence on usage of build automation tools. Instead, we observe compatibility-related adoption factors, such as adjustment with existing tools, and adjustment with practitioner's existing workflow, to have influence on usage of build automation tools with greater importance. Findings from our paper suggest that usage of build automation tools might increase if: build automation tools fit well with practitioners' existing workflow and tool usage; and usage of build automation tools are made more visible among practitioners' peers.

Sarah Nadi, Thorsten Berger, Christian Kästner, Krzysztof Czarnecki.  2015.  Where Do Configuration Constraints Stem From? An Extraction Approach and an Empirical Study IEEE Transactions on Software Engineering. 41(8)

Highly configurable systems allow users to tailor software to specific needs. Valid combinations of configuration options are often restricted by intricate constraints. Describing options and constraints in a variability model allows reasoning about the supported configurations. To automate creating and verifying such models, we need to identify the origin of such constraints. We propose a static analysis approach, based on two rules, to extract configuration constraints from code. We apply it on four highly configurable systems to evaluate the accuracy of our approach and to determine which constraints are recoverable from the code. We find that our approach is highly accurate (93% and 77% respectively) and that we can recover 28% of existing constraints. We complement our approach with a qualitative study to identify constraint sources, triangulating results from our automatic extraction, manual inspections, and interviews with 27 developers. We find that, apart from low-level implementation dependencies, configuration constraints enforce correct runtime behavior, improve users' configuration experience, and prevent corner cases. While the majority of constraints is extractable from code, our results indicate that creating a complete model requires further substantial domain knowledge and testing. Our results aim at supporting researchers and practitioners working on variability model engineering, evolution, and verification techniques.