What If Your Emails Never Went to Gmail and Twitter Couldn't See Your Tweets?
theatlantic.com
theatlantic.com
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
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.
(Disclaimer: I am working on solving that and hope we can make it work. :)
You can read more here: http://www.alexlambert.com/_media/waterhouse-wip-chi2009.pdf
Then I can finally send encrypted emails to my mom. Yay!
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.
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
"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.
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.
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.
Am I missing something?
Cool project, I'll be following closely. Nice and ambitious roadmap.
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.
If anyone is interested in this, just message me.
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.
(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.
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.
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.
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.
If that's true then there isn't the economic incentive to bother with any paid accounts.
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.
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.
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.
An interesting idea, but one that comes and goes -- be it due to usability, lack of popular need/interest, etc.
Reminds me of http://craphound.com/spamsolutions.txt
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.
It's sobering and worth deep contemplation by anyone thinking about solving this issue.
The only benefit I see is a central location of all data.
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 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.
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.
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.
Interesting hack, though.
I guess if this really becomes standard you'd never be able to use an email conversation as evidence in a court.
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.
Too bad it's discontinued.
PKI + Your Browser
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.
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 :)