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.
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.
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 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.
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.
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?
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?
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.
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.
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.
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.
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.
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.
> "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.
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 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.
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.
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 [email protected] 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.
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.
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.
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.
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).
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.
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.
[+] [-] sedachv|14 years ago|reply
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|14 years ago|reply
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|14 years ago|reply
[+] [-] ams6110|14 years ago|reply
[+] [-] freshhawk|14 years ago|reply
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|14 years ago|reply
[+] [-] mcot2|14 years ago|reply
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.
[+] [-] unicornporn|14 years ago|reply
[+] [-] _exec|14 years ago|reply
[+] [-] AdamFernandez|14 years ago|reply
[+] [-] dredmorbius|14 years ago|reply
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.
[+] [-] wmf|14 years ago|reply
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.
[+] [-] electromagnetic|14 years ago|reply
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.
[+] [-] sheac|14 years ago|reply
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.
[+] [-] amirmc|14 years ago|reply
If that's true then there isn't the economic incentive to bother with any paid accounts.
[+] [-] jmspring|14 years ago|reply
An interesting idea, but one that comes and goes -- be it due to usability, lack of popular need/interest, etc.
[+] [-] tommi|14 years ago|reply
Reminds me of http://craphound.com/spamsolutions.txt
[+] [-] zmmmmm|14 years ago|reply
It's sobering and worth deep contemplation by anyone thinking about solving this issue.
[+] [-] amirmc|14 years ago|reply
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.
[+] [-] ryan_s|14 years ago|reply
The only benefit I see is a central location of all data.
[+] [-] tesseractive|14 years ago|reply
[+] [-] ojilles|14 years ago|reply
[+] [-] aidenn0|14 years ago|reply
[+] [-] joedevon|14 years ago|reply
[+] [-] codezero|14 years ago|reply
[+] [-] seanmcgregor|14 years ago|reply
[+] [-] pyre|14 years ago|reply
[+] [-] nextstep|14 years ago|reply
[+] [-] dclowd9901|14 years ago|reply
[+] [-] spung|14 years ago|reply
[+] [-] kodablah|14 years ago|reply
[+] [-] parley|14 years ago|reply
[+] [-] dsetton|14 years ago|reply
[+] [-] eps|14 years ago|reply
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 [email protected] 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|14 years ago|reply
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|14 years ago|reply
[+] [-] oneweekwonder|14 years ago|reply
[+] [-] seanmcgregor|14 years ago|reply
[+] [-] rdl|14 years ago|reply
Interesting hack, though.
[+] [-] gordondevoe|14 years ago|reply
[+] [-] DallaRosa|14 years ago|reply
I guess if this really becomes standard you'd never be able to use an email conversation as evidence in a court.
[+] [-] CGamesPlay|14 years ago|reply
[+] [-] seanmcgregor|14 years ago|reply
[+] [-] freshhawk|14 years ago|reply
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.
[+] [-] Sami_Lehtinen|14 years ago|reply
[+] [-] p0ckets|14 years ago|reply
[+] [-] wmf|14 years ago|reply