Injectable Applications

Injectable Applications (Privly Applications)

When Privly injects content into a host page in place of a Privly-type hyperlink, the resulting content is displayed within a web application. This page contains a list of finished or in-development applications. For more information on the implementation of these applications, read the Injectable Application Development Primer. The current list of injectable applications are:

• Plain Posts: Unencrypted posting
• ZeroBin: Link-key encryption
• PGP: PGP encrypted messages with public keys authenticated via Mozilla Persona
• Group Encryption: Strong-encryption for groups of users

Style Guide

Rules

Injectable applications should abide by the (non-exhaustive) list of rules below:

• The injectable application cannot generate post, put, or delete requests without first checking compatibility with the application via a get request. This ensures the application cannot be used for a CSRF attack.
• The applications must be capable of running without server side code. Build your applications to use data, not server rendered templates. These concepts draw significant inspiration from Unhosted.
• Injectable Applications should identify themselves with a tooltip to indicate that they are not a natural element of the page in which they are embedded. Users need to know when the content they are viewing is not a natural element of the page.
• You must be able to click on the application to view the application without being inside a host page. This is how users can determine the origin of content.

Good Design

This list of design concerns for injectable applications.

• Scope data to a link such that it is only accessible if the user encounters the link someone on the web.
• Account for these layout cases when the application is injected into a host page:
• The user does not have access to either the underlying keys or content (server responds with "unauthorized"). If the server is doing its job properly, the application will not know whether the user is unauthorized or the content doesn't exist.
• The user is unable to decrypt the content or keys
• The user has full access to the content and keys and all operations are successful
• Account for all the layout cases above when the application is viewed outside an iframe.
• Account for all the layout cases above when the application is viewed on a mobile device (none of the current applications do this properly...).
• If the application code is delivered to the client by a remote content server, don't put link-keys on the URL. Put the content URLs on the anchor text. Anchor text is not sent to remote servers.
• Don't make an application that demands attention. It should be a natural element of any page in which it is presented.

See Also

Posting Application