process can cause to happen.” -- Stiegler04 • Goal is to protect the user from malicious or poorly implemented clients. • Static authority speciﬁed before application launch. • Dynamic authority granted during application execution.
Capture URIs as they ﬂow through the application. • Do not handle other cases/types. • Multi-prong approach to cover different types of I/O for an application. • Separates dynamic authorization from application implementation.
the user downloads. • User weaves aspect library with application to secure the application. • Application starts with no authority. • Authority derived at run-time from: • HTML, RSS, Atom, XML • HTTP, local disk • SWT, Swing
ﬁle from disk. • Downloading a ﬁle from a server. • Use a policy ﬁle specifying rules to apply to input for granting authority. • Separates concern of parsing I/O from disk or network for driving security decisions.
is readable by the user for auditing. • Authority is dynamically granted based on content of the input. • Common formats are handled generically. • Generically weave into application to handle disk and network I/O.
considered a URI to grant authority to access. • App Developer is untrusted. • Only provides mapping of mouse clicks to URIs. • User can hover to see what consequences their actions will have when clicking through status bar.
generically by our aspect library on its own. • Other half required input from app developer, which can be audited. • Only 1 instance found where our approach could not be applied, requiring prompting.
an application. • Authorizing contexts capture join points where authority ﬂows through an app. • Authority aspects capture authorizing contexts. • For two real-world applications, only one instance existed where dynamic authority could not be captured.