I like the sentiment of this idea, but sadly I think that this will be doomed to failure. It is unfortunate (but understandable) that the browser plugin is required even to read messages or posts by people using Privly. Crypto solutions need to be dead simple to be widely adopted. If users have to download extra software on top of what they already expect, then people like my parents will probably not use this.
I'm not sure what the adoption or usage rates are for it, but a very popular Pinterest has its bookmarklet. This implementation couldn't be far removed from that.
This is actually rather cool, but we are far ahead of this at Qbix. We actually patented (sigh, hate the game not the playa) a way to have social networking integrated into websites with instant personalization and social context, but with total privacy and control over your data.
And the stuff here is just one part of it. If you want to experience it for yourself as we roll out, download the "Groups" app on iPhone.
Sorry I should have said "patent application". We don't have a patent yet.
I am guessing this was downvoted because it says we applied for a patent. I feel ya, downvoters :P If it makes you feel any better, we simply need the patent because many investors ask about IP and "barriers to entry" and because we may want to license it to a company like Google, which respects patents, to get an additional revenue stream enabling us to not need to sell more shares of the company, which makes all of our current stakeholders' holdings more valuable :)
I don't think this is a matter of forcing users to choose between modern technology and privacy. Based on their current revenue models, some of the companies may cease to exist if they can't mine user data for advertising revenue. Then again, Facebook and Twitter could charge users with an agreement that their data won't be used, and they will see no advertisements. I wonder how many users would choose this alternative. It is doubtful many would. So with these 'choices', would privly just shut down companies that use this data as a basis for revenue if widely adopted? Would this be a real positive for users?
Yes, there is a social contract in Web 2.0 that these services are being provided in exchange for data mining. If you post nothing but encrypted blobs you are breaking the contract and you should expect your account to be closed.
This service is actually worse than the previous ones because instead of mooching off other sites to host the data they actually host it themselves. There's no business model to pay for their hosting.
(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.
But if something like Privly was "done right", wouldn't everything — friends, profiles, likes, etc. — be encrypted? I think anything that really provides privacy would be too parasitic to Facebook; that's why I prefer a "clean break" approach like Diaspora/Appleseed/OneSocialWeb. Time will tell, I guess.
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.
Odds are it is market forces that will set such a standard. So if AdBlock is stronger in moving the market, then AdBlock is a better avenue towards a privacy standard.
There may be a peculiar outcome though. If AdBlock manages to decrease demand, will that increase the cost of advertising or increase its effectiveness? Those not adblocking would be the ones easily sold.
Advertising profits not dropping could be enough of an illusion so that, with enough adblocking, one could try a Groupon in reverse.
@wmf: one business model would be users paying for privacy themselves.
Freemium for facebook would be kind of ingenious, but it would almost certainly lead to the 'premium' accounts getting higher visibility in viewers feeds.
Is your aunt glenda passing away going to make your feed? Nope, because Coca Cola wants to tell you that they've got a limited edition coke bottle out for the 2012 Olympics.
FB also does this already, I saw a sponsored post when a friend liked eBay, it appeared at the top of my news feed and said "This is a sponsored story".
It would definitely change things in a big way - especially for services that rely on acquiring user data in order to be profitable, as you mention.
However, I don't agree that Privly would necessarily end the current set-up entirely. It might result in a little more bargaining power for users who, up until now, haven't had any leverage in the user-host relationship.
One outcome that doesn't mean the end of user data-based businesses is where they modify their 'terms of use' to restrict or ban the use of this service. In this case, it's not clear how users could wrest back much control over their information, however.
As with any disruptive technology, the "your enhacement ruins our business model" is really your problem, not mine.
The per-user profit of Facebook (in very fuzzy numbers) is on the order of $1-$2. Presuming there would be some feasible way of capturing this or its equivalent revenue by non-advertising means, a subscription-based service is feasible.
The real problem is that most users are subscription-averse, which has a knock-on effect of making it difficult to attain sufficient network size (and network effect value) while charging fees. Advertising has been the low-friction means to do this for the past decade or so.
An alternative model is to find a sufficient subset of users who are willing and able to pay for a service to underwrite both the remainder and the network growth effects. Craigslist would be the prime example of this. A small fraction of advertising in a small fraction of markets underwrites the remainder of the firm's activities.
Privacy is a feature, not a product. And I mean that in the literal sense, not the dismissive condescending way that people use it to describe startups they don't take seriously.
Privly is not disruptive because it doesn't remove people's desire to use Facebook. If it did manage to kill Facebook's business model, people would not be happy because it doesn't replace Facebook.
Of course this is a moot point because in general people don't care about privacy, so Privly can remain safely parasitic for the indefinite future. Eventually some major event or series of events may get people to take privacy more seriously, and in that case Privly would be well positioned for growth, but were such a sea change to occur Facebook would be the first casualty with or without Privly.
There have been similar ideas over the last few years -- encrypt in the browser before posting. A couple of private email services encrypted in javascript before posting the message. You then needed to share your key/password.
An interesting idea, but one that comes and goes -- be it due to usability, lack of popular need/interest, etc.
Yes, it kind of goes against the idea of sharing when you are limiting your post visibility to only a handful of people in your network. Not all of your friends are going to install addons to every browser they use and maintain yet another network of trust.
> "I think Privly is best viewed as an argument in code. It's an attempt to expand the philosophical and technical terrain on which the privacy debate is playing out."
I think debates on privacy (and even what it means to have a digital identity) are important and things like privly help push this forward.
I'm not convinced by the implementation but I'm glad they made something.
Encrypted email has been around and built into email clients by default forever and nobody uses it. Even just signing emails gets quizzical responses every now from people I send to (why do all your emails have a weird attachment?). The mere need give decryption keys to your contacts by a back channel has been sadly enough to push it over the edge of usability. People prefer total lack of security to even the most minor inconvenience.
It's sobering and worth deep contemplation by anyone thinking about solving this issue.
Everything old is new again. I wonder how many folks reading this article even know how UUCP email worked. Or traditionally decentralized SMTP, for that matter.
The problem with GPG is one of key management. The first person who truly solves that well (both reasonably secure and reasonably easy) is going to do well. To date, everybody has failed.
(Disclaimer: I am working on solving that and hope we can make it work. :)
Another problem with using PGP to encrypt mail is that it only secures the message body. It doesn't secure the subject line or other headers. If I send a PGP encrypted email to somebody, their email provider can't read the message body, but what they do know is the email address of the sender, when they sent it, and when it was picked up.
If everybody in the World started using PGP to encrypt all email tomorrow, we'd still have massive privacy problems that need addressing.
P.S. I use PGP extensively. I sign all of my emails and even my HN profile, and encrypt whenever I can.
If you are providing a communication routing service, you MUST have information about sender* and recipient. That is not a problem with PGP encryption, it is a problem with people who wish to use public routing services like Gmail.
Furthermore, since the internet is also a public communication routing service itself, there is a tradeoff between information leaked to the email provider, and information leaked to the ISP. Using a smaller email routing service implicitly gives the ISP more specificity, and using a large one gives the email provider more specificity.
Since it is, in general, harder to access an ISP anonymously than it is to access an email provider anonymously, the current state of using large email services is in many ways superior from a privacy perspective.
* sender if you want ACK, and recipient so you can deliver the message
Assume I'm mike@example.com and I'm sending a message to dave@example.org.
"sender if you want ACK"
The example.org service doesn't need to know the sender address. It only needs to know a method for prompting the sending server to send an ack to whoever the sender of the incoming message was.
"recipient so you can deliver the message"
My own mail service only needs to know that I'm sending a message to somebody at some domain managed by the example.com server. It doesn't need to know that I'm sending it to dave@example.com.
A better mail system (from a privacy perspective) would be one where the routing logic was handled by the email client first, and the outgoing mail server was just a dumb queue. Imagine I'm sending the email to dave@example.org:
My email client encrypts the message body, subject line and sender address with dave@example.orgs public key.
It then looks up the IPs of the MXs, and their public keys.
It then adds the recipient address (encrypted with those public keys) to the message. It then connects to my outgoing mail relay, tells it the list of IPs to try, and passes the encrypted message on.
When the message is passed on from example.com's servers to example.org's, they can decrypt the recipient address and pass on the message to that recipient.
dave@example.org can decrypt the message and sender address after downloading it.
If you want to retain the "bounce" capability rather than example.org just refusing the message at SMTP time, example.com could pass a unique identifier with the message when it sends it to example.org. Then example.org can just send the bounce back with that unique identifier, and example.com can then map that unique identifier to the original sender.
If they have the ability to decrypt data on their server anytime they want then this whole thing seems utterly pointless. I sincerely hope that's not the case.
If "them" = Facebook or Twitter... it's true, they could not read the text.
But if "them" = the service provider of the encrypted messages, well, I suspect that they can decrypt from their description. Which means that they can be compelled to decrypt, or that a member of staff could access the decrypted message... in which case we only have an illusion of privacy because it only gives us privacy from some parties and not others.
I don't understand why there needs to be a privly server in the loop or what benefit to the users it provides (besides the retroactive editing of an email (that is now unreadable offline) if you read it in a web based email program.)
The main use case is handled by a browser extension that handles encryption and decryption of text input/web site snippets.
Having all the content hosted on the privly servers but embedded on pages and always editable is interesting I guess but seems unrelated to the encryption stuff.
The problem for me is that the encryption portion is interesting while the embedded snippet thing is completely uninteresting to me.
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.
I see this as two separate apps though. This is probably because I already had thought about the encryption part and had a mental model of how this would work.
One is a browser extension to handle encrypted chunks of text on webpages (and some kind of key management i assume). So I post the ciphertext of my message to twitter and my friends see the plaintext while others see the ciphertext.
The second is the snippets of embeddable text hosted somewhere else (p2p, central server, etc) and an extension to auto-embed the special links to this content.
Does it make sense to combine these two ideas from the beginning? Because honestly I would volunteer my time to develop the first but have only marginal interest in the second (although it's a cool piece of tech with some interestingly weird use cases).
I can see the overlap, but I think the encryption part would be much more useful if it wasn't tied to the snippets stuff.
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.
ah, so how is the meta information stored for host page ciphertext? Some sort of recognizable header/footer that the extension can scan for and choose the appropriate key?
Cool project, I'll be following closely. Nice and ambitious roadmap.
If everyone uses GPG in their email we don't have to worry about email being insecure, right? Now we just need to get everyone on board with this extra, third party step.
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.
Usually GPG is used to secure email transmission, and not storage. There are examples out there of storing your email GPG-encrypted, but you would have to leak at least some information to have useful things such as indexing for search on your emails.
I use GPG to encrypt data all the time. For example all backups I do are via http://duplicity.nongnu.org/ (its also super convenient)
Additionally all emails that are GPG encrypted are stored that way with all the mail clients I know of (that is, they just keep the mail the way it is,decryption is in volatile memory only). So yes storage is encrypted too!
Yes it also means search only works on sender/subject. Eventually you can have an index that is GPG encrypted and works once decrypted, no technical issue here.
Could client-side code could read what is placed in the DOM after decrypted by the browser extension? It seems many things (e.g. ad sense) reads the DOM on the client side to determine the context of the ads it will place. Correct me if I'm wrong.
I too was thinking exactly this. I watched the crypto walkthrough video on the kickstarter page and though what was shown looked solid, it didn't mention this. Would it turn into a client-side JS-war between the extension and the host (FB, etc)? It would be nice if someone involved in the project could mention this and why it's not a problem. Thanks! Edit: clarified.
I think it would be possible to read the content if it was just inserted into a <div> in the DOM or something. But the priv.ly link that is pointing to the content could be replaced by an iframe, and then it wouldn't be accessible to outsiders code, because of same-origin policy, I think. Not sure how it's actually done, though, I didn't dig any deeper.
So instead of the original third party destroying your privacy, you hand control to another third party? What measures are being put into place to stop them from doing what the original third party did?
Also: what's to stop someone like Facebook from banning these sort of links?
For everything to work as well as Facebook does today in a fully decentralized manner, there still needs to be a lot of research done in zero-knowledge password proofs and shared public key systems. The most relevant work I've found in those particular fields is http://ai.stanford.edu/~xb/pkc09/index.html
there still needs to be a lot of research done in zero-knowledge password proofs and shared public key systems
You might be setting the bar a bit high. You could also do logins by having a server you trust (e.g. because you own it) that vouches for you via OpenID or BrowserID.
We use something similar at the office. We have chat for all employees based on google talk, but it is encrypted before it's sent to Google's servers and decrypted after receipt.
I understand this boils down to security vs convenience but one of the main reasons I like google talk is that I can search through my old messages and I believe encrypting it before sending it to google, "disables" that functionality.
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.
I was just posting messages to the OP asking why they didn't start with something that does x where x equals exactly what this extension does, including inline detection.
An off-site delivery for Gmail recipients would be a big step forward. Instead of seeing an actual email, the recipient would get an https link to a page on some non-Google server. Extra bonus for attaching an explanation along the lines of "your peer decided not to share the contents of this email with Google."
What really ticks me off personally (and I fully realize I'm not in a majority here, even on HN) is sending an email to john@domain.com only to see the reply come back from Google's servers. In many cases I would've not sent the original email if I have had known it would go through them. They've got enough data on me as it is.
This idea is great. I'm interested to hear what mobile opportunities you plan on exploring. When clicking a youtube link on an android phone the device prompts a user to pick an app to use (browser or youtube or etc). I think this approach might be the simplest implementation (ie: when someone clicks a priv.ly link anywhere on the phone it prompts to use the priv.ly native app).
I already have a proof of concept that works like this but requires no 3rd party servers.
My POC chrome extension uses a JavaScript based AES routine to encrypt text with a given user and passphrase. What gets posted to a site is the encrypted text plus the user name plus a unique string that my extension recognizes.
If you have the extension installed it will scan the DOM for text that matches the known pattern and decrypt transparently given that you have the right username/password combo entered in the extensions settings.
All that is left is to share the username/password combo to whomever should view the text via a different channel. I lost interest and didn't extend this to public/private key pair but that is the next logical step. Also, the extension needs a nice UI and maybe some visual cues on the page as to which text was encrypted/decrypted.
Lastly, once the text is decrypted by the extension, theoretically the host site could query for the decrypted text and send it back via ajax. I couldn't find a great solution to this using chromes pathetic api's for extensions.
Your email address is not visible in your profile, please enter it in the 'about' section, the 'email' field is not visible to the public. How can I reach you?
Sad fact: most users do not access these services using a web browser, they access them through mobile applications controlled by the service provider. Most mobile web browsers doesn't support extensions either.
I'm afraid these browser extension solutions might be a solution for the desktop era, which will be long gone soon (if it isn't already).
This is the price we pay for simplification and applification. People no longer know their machines.
People have been doing this kind of thing (data aliasing/tokenization) for business SaaS apps for a while. It's interesting, but 1) you leak a fair bit of information, which in a business app isn't as big a deal as on a social network, due to volume -- just knowing I've friended you is as important as most of the messages posted -- and you lose a lot of indexing on structured data.
I don't get it.. so anyone with the priv.ly extension installed can view the content? Priv.ly is also open source?
So.. if say 10% of Facebook users started using Priv.ly.. wouldn't Facebook just put their own implementation directly into their site? This would give Facebook access to your content as well as make your content available in the Facebook mobile app's.
Sure, it abstracts away your content but if it can be viewed anonymously it doesn't protect it or prevent twitter etc from reading it.
Well, that's why we have solution called RetroShare, it protects you privacy. Only thing that it leaks is connectivity between peers. If you prefer to hide it too, then you can run it over Tor.
reply