266 research outputs found
Hidden Type Variables and Conditional Extension for More Expressive Generic Programs
Generic object-oriented programming languages combine parametric polymorphism and nominal subtype polymorphism, thereby providing better data abstraction, greater code reuse, and fewer run-time errors. However, most generic object-oriented languages provide a straightforward combination of the two kinds of polymorphism, which prevents the expression of advanced type relationships. Furthermore, most generic object-oriented languages have a type-erasure semantics: instantiations of type parameters are not available at run time, and thus may not be used by type-dependent operations.
This dissertation shows that two features, which allow the expression of many advanced type relationships, can be added to a generic object-oriented programming language without type erasure:
1. type variables that are not parameters of the class that declares them, and
2. extension that is dependent on the satisïŹability of one or more constraints.
We refer to the first feature as hidden type variables and the second feature as conditional extension. Hidden type variables allow: covariance and contravariance without variance annotations or special type arguments such as wildcards; a single type to extend, and inherit methods from, infinitely many instantiations of another type; a limited capacity to augment the set of superclasses after that class is defined; and the omission of redundant type arguments. Conditional extension allows the properties of a collection type to be dependent on the properties of its element type.
This dissertation describes the semantics and implementation of hidden type variables and conditional extension. A sound type system is presented. In addition, a sound and terminating type checking algorithm is presented.
Although designed for the Fortress programming language, hidden type variables and conditional extension can be incorporated into other generic object-oriented languages. Many of the same problems would arise, and solutions analogous to those we present would apply
Capturing mobile security policies precisely
The security policies of mobile devices that describe how we should use
these devices are often informally specified. Users have preferences for some
apps over others. Some users may avoid apps which can access large amounts
of their personal data, whilst others may not care. A user is unlikely to write
down these policies or describe them using a formal policy language. This is
unfortunate as without a formal description of the policy we cannot precisely
reason about them. We cannot help users to pick the apps they want if we
cannot describe their policies.
Companies have mobile security policies that definehowan employee should
use smart phone devices and tablet computers from home at work. A company
might describe the policy in a natural language document for employees to
read and agree to. They might also use some software installed on employeeâs
devices to enforce the company rules. Without a link between the specification
of the policy in the natural language document and the implementation of the
policy with the tool, understanding how they are related can be hard.
This thesis looks at developing an authorisation logic, called AppPAL, to
capture the informal security policies of the mobile ecosystem, which we define
as the interactions surrounding the use of mobile devices in a particular setting.
This includes the policies of the users, the devices, the app stores, and the
environments the users bring the devices into. Whilst earlier work has looked
on checking and enforcing policies with low-level controls, this work aims
to capture these informal policyâs intents and the trust relationships within
them separating the policy specification from its enforcement. This allows us to
analyse the informal policies precisely, and reason about how they are used.
We show how AppPAL instantiates SecPAL, a policy language designed
for access control in distributed environments. We describe AppPALâs implementation
as an authorisation logic for mobile ecosystems. We show how
we can check AppPAL policies for common errors. Using AppPAL we show
that policies describing users privacy preferences do not seem to match the
apps users install. We explore the diâ”erences between app stores and how to
create new ones based on policy. We look at five BYOD policies and discover
previously unexamined idioms within them. This suggests aspects of BYOD
policies not managed by current BYOD tools
"Do this! Do that!, And Nothing will happen":Do specifications lead to securely stored passwords?
Does the act of writing a specification (how the code should behave) for a
piece of security sensitive code lead to developers producing more secure code?
We asked 138 developers to write a snippet of code to store a password: Half of
them were asked to write down a specification of how the code should behave
before writing the program, the other half were asked to write the code but
without being prompted to write a specification first. We find that explicitly
prompting developers to write a specification has a small positive effect on
the security of password storage approaches implemented. However, developers
often fail to store passwords securely, despite claiming to be confident and
knowledgeable in their approaches, and despite considering an appropriate range
of threats. We find a need for developer-centered usable mechanisms for telling
developers how to store passwords: lists of what they must do are not working
Towards an Authorization Framework for App Security Checking
Abstract. Apps donât come with any guarantees that they are not ma-licious. This paper introduces a PhD project designing the authorization framework used for App Guarden. App Guarden is a new project that uses a flexible assurance framework based on distribution of evidence, attestation and checking algorithms to make explicit why an app isnât dangerous and to allow users to describe how they want apps on their devices to behave. We use the SecPAL policy language to implement a device policy and give a brief example of a policy being used. Finally we use SecPAL to describe some of the differences between current app markets.
The impact of surface features on choice of (in)secure answers by Stackoverflow readers
Existing research has shown that developers will use StackOverflow to answer programming questions: but what draws them to one particular answer over any other? The choice of answer they select can mean the difference between a secure application and insecure one, as the quality of supposedly secure answers can vary. Prior work has studied people posting on Stack Overflowâa two-way communication between the original poster and the Stack Overflow community. Instead, we study the situation of one-way communication, where people only read a Stack Overflow thread without being actively involved in it, sometimes long after a thread has closed. We report on a mixed-method study including a controlled between-groups experiment and qualitative analysis of participants' rationale (N=1188), investigating whether explanation detail, answer scoring, accepted answer marks, as well as the security of the code snippet itself affect the answers participants accept. Our findings indicate that explanation detail affects what answers participants reading a thread select (p0.05)âthe inverse of what research has shown for those asking and answering questions. The qualitative analysis of participants' rationale further explains how several cognitive biases underpin these findings. Correspondence bias, in particular, plays an important role in instilling readers with a false sense of confidence in an answer through the way it looks, regardless of whether it works, is secure, or if the community agrees with it. As a result, we argue that StackOverflow's use as a knowledge base by people not actively involved in threads'when there is only one-way-communicationâmay inadvertently contribute to the spread of insecure code, as the community's voting mechanisms hold little power to deter them from answers
- âŠ