

What If Your Emails Never Went to Gmail and Twitter Couldn't See Your Tweets? - kmfrk
http://www.theatlantic.com/technology/archive/2012/04/a-privacy-manifesto-in-code-what-if-your-emails-never-went-to-gmail-and-facebook-couldnt-see-your-status-updates/255414/

======
sedachv
Private "cloud" services seem to be very much part of the zeitgeist.
<http://freedomboxfoundation.org/> is probably the most well known, with
Justin Frankel's WASTE (<http://en.wikipedia.org/wiki/WASTE>) being one of the
earliest. I researched the technical challenges of making these kinds of
systems practical and wrote some findings at
<http://carcaddar.blogspot.ca/search/label/ClearSky>

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>

~~~
wmf
_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.

------
NelsonMinar
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.

~~~
ams6110
Yeah, I was wondering how many people DON'T use a browser to read their email.
How does Privly work for them? Or why wouldn't they just use GPG.

~~~
SoftwareMaven
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. :)

~~~
mike-cardwell
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.

~~~
oconnore
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

~~~
mike-cardwell
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.

------
freshhawk
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.

~~~
seanmcgregor
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.

~~~
freshhawk
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.

Am I missing something?

~~~
seanmcgregor
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.

~~~
freshhawk
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.

------
mcot2
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.

If anyone is interested in this, just message me.

~~~
_exec
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?

~~~
mcot2
thanks, I didn't know that wasn't public by default. Email address added.

------
AdamFernandez
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?

~~~
dredmorbius
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.

~~~
dasil003
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.

------
jmspring
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.

~~~
zmmmmm
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.

~~~
PabloVermeuil
What you need is some sort of false flag operation. If the people are
frightened they will sit up straight and do what they should.

------
ryan_s
I guess I don't see the point. The data is stored on their servers where they
offer the same "promise" that they won't sell your data either.

The only benefit I see is a central location of all data.

~~~
tesseractive
Selling your _encrypted_ data seems like a somewhat more difficult proposition
for them than the one social networking services usually have.

~~~
dce
Do you not understand how encryption works, or do I?

~~~
tesseractive
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.

~~~
dce
Sorry for being flippant. I'm just having a hard time imagining how I could
post something that you could read that's somehow unreadable to them.

~~~
bo1024
That's the entire point of the service being discussed, no?

~~~
buro9
Define "them".

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.

------
aidenn0
The answer to the question in the headline is "Then gmail and twitter wouldn't
be free"

~~~
joedevon
I was waiting for someone to notice. UPvote :)

------
codezero
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.

~~~
pyre
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.

~~~
zobzu
Wah?

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.

------
nextstep
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.

~~~
dclowd9901
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.

------
kodablah
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.

~~~
parley
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.

------
eps
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.

------
JohnnyFlash
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.

------
cowkingdeluxe
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.

~~~
seanmcgregor
Interesting, is it open source?

~~~
cowkingdeluxe
Not sure, here it is: <http://www.cypherpunks.ca/otr/> . We use it with
Pidgin.

------
rdl
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.

Interesting hack, though.

------
gordondevoe
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).

------
DallaRosa
"Email that sits in the cloud -- like Gmail -- could be edited by the sender
even after its been received. Tweets could change on a tweeter's whim."

I guess if this really becomes standard you'd never be able to use an email
conversation as evidence in a court.

------
CGamesPlay
Very related is this Firefox extension which does just the encryption portion:
<http://getfiregpg.org/s/home> (I wrote the inline detection bit!)

~~~
seanmcgregor
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.

------
Sami_Lehtinen
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.

------
p0ckets
The issue of changing your email/tweet after posting is easily resolved by
posting a hash of the email/tweet along with the link.

~~~
wmf
People who _want_ to change stuff after the fact won't post hashes.

------
4ydx
my.zenlok.com

PKI + Your Browser

------
zobzu
Priv.ly, Y U NO USE GPG?

------
EGreg
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.

~~~
_exec
Patent number? Pending or approved?

~~~
EGreg
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 :)

