Anyone can read content on the priv.ly website. What sets the Privly protocol apart is the ability to pull content into any site on the web. We want the first Priv.ly link anyone follows to be their last. The first priority must be to bring the Privly system to as many platforms as possible.

• Browsers: Several browser extensions are under active development. We usually develop features on the Mozilla platform, then port the code to other systems.
• Mobile: Privly is primarily for personal content, and content generated or viewed on mobile devices fits that description. Development begins on the desktop, but the Privly protocol has a home in mobile.

Privly will never assert content ownership, but that promise is meaningless without providing ways for users to move their content into and out of content hosts.

• Content Server: Users have a default server to post private content. The server source code is available for anyone to download and extend. As soon as we can guarantee browsing anonymity, anyone can host their own content.
• Content Portability: Users need the ability to export/import all their content to/from common formats.
• Content lifetime: Users have the ability to define a lifetime for their content (e.g. automatically delete after 30 days) as well as purge their content entirely.
• Content Licensing: Once privacy and security is established, we can allow users to embed licenses in Privly URLs. Flickr is a great example of what happens when users license their content.

We want people to use Privly to protect themselves from data-mining and government attack, so we take security very seriously.

• Extension-side encryption/decryption: With a reliable cryptography library we can generate keys and encrypt content before sending it to any content server. We have big plans for this feature once the core system is fully functional.
• Isolate returned content from host page: The host page cannot have access to injected content. Pages hosting Privly links do not have access to the linked content.
• Differentiate remote content from page content (eliminate phishing risk): Some malicious users may use Privly for phishing by posting content that looks like it originates from the host site. The extension will make it obvious which content is from the host page and which content is from Privly.
• Prevent browser caching: While it is likely impossible to prevent all forms of caching, the extension will provide some steps to ensure that content is not cached any longer than it needs to be.
• Isolate Privly Content from Other Extensions: Privly content is currently injected into the frame using an iframe. While this method prevents the host site from reading the content, other extensions still have access to the displayed content. We need a solution to this problem.

There are numerous ways to identify who you want to share something with. Content should be permissioned by whichever platform you use.

• Share by Email
• Share by Domain
• Share by IP Address
• Share by Password
• Share with PGP key
• Share by Diaspora Aspect, Google+ Circle, Twitter List, etc
• Share by Geography (geoIP): No major platforms have sharing rules for geographic regions. While GeoIP is not a robust security measure, it does make it difficult to access content outside an intended area.

The Privly developers survived the blink tag and midi song era of the internet, and we don't want to return to a time when sites are pieced together with inconsistent typography and generally bad style. Never. Again.

• Allow for Site-Specific Behavior: Privly replaces links too greedily in some places. So far we have had issues with WYSIWYG editors and preview panes, but most of these problems could be taken care of by building a community maintained rule base. A set of link exclusion rules would allow for more greedy replacement of links.
• Allow for Site-Specific CSS: Privly content should identify itself, but should also fit its context. User submitted or host-page CSS should provide generalized styling of text content.
• Provide Domain Specific Language (DSL): Markdown is an excellent starting point for generating HTML for page injection, but it is not intended for systems like Privly. A DSL could solve many formatting problems.
• Non-text Content: Private information is not limited to text, and neither is Privly.

We have many other ideas for Privly. We expand on just two of them below.

• Peer-to-peer storage: Once data is encrypted, it doesn't matter where you store it. Success of systems like BitTorrent and Bitcoin suggest ways to decentralize storage, but we need to extend their ideas to ensure that browsing anonymity is maintained. Privly's researchers find this aspect fascinating, so we will probably revisit this soon.
• Personal Semantic Datastore: Text conversations are not the only type of personal information. Many exciting applications rely on declarations of who you are. When you give Facebook your date of birth, hometown, and likes, you give them a rich dataset that is shared with third-party applications. An anonymized and encrypted personal information database would make it easier for you to use exciting functionality without allowing companies to correlate your personal information with a database of marketing information. You are the customer, not the product.