(I am apparently posting too quickly)
It is up to the individual user on what level of privacy is enough for them.
I think this has great potential as a cross posting mechanism. I can't switch to Diaspora because of network effects. How do I leave my family at Facebook? With Privly I could cross post very personal content, but not give the content to anyone outside the family.
(let me take my Privly hat off and put on my Machine Learning Researcher hat) Facebook needs users far more than access to users' private communications. Their "like" button and the demographic data they collect is more valuable than crawling messages between users. Privly could slightly impact the efficiency of advertising, but it won't shut down advertising as a business model. AdBlock poses a bigger risk for that.
(Privly hat back on) Our biggest challenge to legitimacy is interfacing with the web in a way that is private and allows sites like Facebook to "news feed" something only if the user reading the news feed can read the content. This is why we need to work towards a standard where both Facebook et al and Privacy can coexist. There are many options in this area, with differing amounts of privacy, but it is ultimately up to the posting user to post and the host site to decide what to do with it.
Nice! We'll standardize the URL structures so anyone can write their own extension to interface with the protocol, but we'd love to have more contributors on Privly. There are many components that we can carve up and work in parallel.
Interesting, is it open source?
Thanks, and with help, our implementation will monotonically increase in convincingness.
This concept encompasses both hosted ciphertext (on some other network) and host page ciphertext. There are use cases to both, and development of the server/network does not inhibit the development of the extensions. The road map has a set of priorities, but in the end development will proceed with the passions of Privly's contributors.
Yep, in the long run something will leak out of our servers. The plan is only to store ciphertext.
Our adoption model is to pass through a phase where content is separated into a key hosted by a site like Facebook (on the link), and the encrypted text on a content server like priv.ly. That way it is readable when they click the link, but priv.ly cant see it unless the link is clicked. Over the course of time we will transition away from this model because the ability to read the content without clicking through should be enticing, and we will prompt for installs every time they do click.
The hosted server is how we plan on financing development since many users will want the level of privacy it can provide, but don't have the technical expertise to manage their own environment. Over time we want to push content into a network of content hosts and P2P, but we have to promise something we can deliver as part of the Kickstarter. Our fundraising effort is more about recruiting devs than it is about raising 10K.
More details on the encryption element: http://www.kickstarter.com/projects/229630898/protect-your-c...
They could ban the URLs, but not the IPs since the IPs come from the clients. Regardless, it is politically difficult for FB or other scrutinized companies to block a certain kind of hyperlink whose only purpose and use is to protect ones own content. The best thing Facebook could do for our funding is block us. I don't want to discuss workarounds, although they exist, because our ultimate goal is to move this system from a hack to a web standard. Sites could choose not to support it, but if there is enough pull into the system, they won't have a choice.
--------
We implicitly endorsed democratic movements like the Arab Spring by highlighting its use case, but you'll have to forgive me for going with a use case that is more likely to get media attention. The Arab Spring use case is stronger than you are letting on. Privly can facilitate group encryption keys, where only the members of the group can read or share the content. This allows the use of applications like the Facebook event system mashed together with email invitations and public tweets. Most people don't know how to use PGP, and group coordination is difficult without an easy to use and ubiquitous secure sharing system.
-----
"if you don't want facebook to own your content and personal information, don't give it to them in the first place." Agreed, but they can have my links.
Honestly, this is a huge and important question that we have thought about extensively. In the end it comes down to what people want to be public, and what they want to be private. The absence of a content search feature on Facebook is a good example. People don't want their personal lives to be indexed and searchable for all time. This fixes that problem and allows a person to manage their communications well after they have said it.
An API for search is a secondary concern, and is one I want to revisit in the future. Privly allows you to assert your own copyright even when it is displayed on other sites, and the issues surrounding this are more troublesome for the future of the web than taking away Facebook's ability to crawl my chats to my significant other.
I also allude to the Arab Spring at several points in our materials, but this is dangerous territory for a small band of programmers to wade into. I prefer to keep things apolitical, Egyptian flags aside.
I went Kickstarter on this to: 1. Make it more secure 2. Get open source support and expertise 3. Start a real discussion around these issues that can guide the development of the project
We will not break the web.
I cried a little when I used recaptcha (Google hosted), but I'll yank that once I have time to drop in a different captcha system. There are a few other hosted items, but none are from advertisers and none will last very long if I get more devs helping out.
re crypto-experts: You are right on this, but we are going to stay away from implementing our own crypto libraries. Instead we will develop APIs for well supported libraries like PGP and package them for browser extensions. That is the proper way to do things.
re law requests: All code is and will be open source and executed on the client. Some of our sharing models could fail to man-in-the-middle attacks (they have other benefits though), but the most secure methods will be as strong as client side PGP.