Profit is wonderful, even more so if earned through other means than tracking users' Internet activity unknowingly. Most users of the Internet don't know that Google sees them in most corners and much of the data collection remains.
Most users don't know how to defend themselves pro-actively. For example we have the disaster of people being connected with their political views in France[1]. The same (not really, hashed emails) vulnerability was then used by the Swedish Researchgruppen[2], an extremist leftwing organization, to publish who said what under the assertion of anonymity and as a direct followup leftwing journalists are now chasing outed "trolls" with baseball bats and cameras[3] for a TV show(!).
Nedless to say these individuals are being directly targeted and harmed due to what they wrote on the Internet. It's not the fault of Disqus or Gravatar, it's the consequence of uninformed users.
Now imagine the hoards of victims that will emerge in the shadows of a Google database leak. For it will leak, of course it will, it's only a matter of time. If data can get out of North Korea it can get out of Google.
The dangers are not necessarily what Google is doing but what Google enables others to do.
Google closed down their service in China in protest againt what they said was anti democratic; remaining in the US is a hypocrisy, although perfectly aligned with other propaganda.
You are right, this is very much government driven. I agree - we should remove the government. Google can lead the revolution by closing down or switch jurisdiction in protest. Their voice is heard, ours is not.
>> We live under structured societies and under a specific set of rules we call LAW.
We don't, you do. I packed my backpack and moved to the 3rd world at 22 and haven't ever been back because I need chaos. There is practically no law where I am, and that was one of many reasons for abandoning your structured societies.
>> Read Game of Thrones, you might understand that
Amazing insult. "Read a book, you idiot! A really stupid one!" Thanks for the smile. :-)
>> So I suggest you to get out of that imaginary world of yours and live life (I don't say change your ideas), but if you really want to blame someone - BLAME YOURSELF, for voting for the politicians in your country and for not being able to force them into taking your opinion and stop spying on you.
I live in the jungle, life is great here! You should try it. I never voted for any politician. I will never blame myself for something that I didn't create.
>> Noone forced you to use google search or gmail or whatever it is that google has included in their adSense algorythm
Agree, but on the other hand the general public is uninformed about these matters. I consider customer unawareness to be quite a problem in general. How can we fix it? I don't think asking those that you disagree with to change is a good approach.
"Didn't you just loose the security that you wanted by encrypting on localhost?"
No, the sensitive information isn't being protected from localhost but from server A and anything else on the path between user and message destination. localhost is the user. For clarification: GPG is on user's localhost, not the server.
1. Alice uses a web app served by server A
2. Alice wishes to send an encrypted message through the web app served by server A to Bob
3. Alice writes the message on her client sided browser
4. Alice finishes and clicks "Send"
5. The web app's client sided code, JavaScript, sends the message to Alice's pygpghttpd listening on localhost
6. pygpghttpd responds with the ciphertext to Alice's web browser
7. Alice's web browser replaces the cleartext content with the encrypted content
8. The encrypted content is sent to server A to be routed to Bob
---------------
1. Bob receives encrypted message from Alice on web app served by server 1
2. Web app's client sided JavaScript sends the encrypted message to Bob's pygpghttpd listening on Bob's localhost
Check the links posted in the comment you replied to, it's not cryptography in JavaScript: it's JavaScript posting to a httpd on user's localhost which bridges GnuPG. It's not for doing cryptography in JavaScript, it's for doing cryptography in GnuPG and passing it through a httpd which the js talks to.
But yes there is JS crypto in the project, as a planned separate optional driver.
The questions that you raise is of course what I am interested in discussing. I can't think of any way that PGP/GPG protects you against keyloggers or a pre-infected computer. I agree that they are relevant threats but my question is if it's up really to the developers to prevent rogue JavaScript in third party software and user's localhost. The same threats can be applied on all existing cryptosystems, as for with one-time pads where someone could look you over the shoulder - but that itself is not considered to break the underlying strength of the design. Or another example, how does Enigmail for Thunderbird protect you against having code injected and keys stolen? I don't think it does, but Enigmail isn't considered insecure. I think the questions are fair to raise but I see them raised far more often when people confront new ideas in comparasion to established practice, which I truthfully consider is a bit unfair judgement.
One of the factors which can narrow the scope of attackers is to use products like crypto stick, but then again what is preventing a computer from being rootkitted and having it's keys stolen as soon as they are exposed in the system?
Developers can of course only address weaknesses in what they have control over. We can't stop your computer from being infected by neither rootkits nor rogue JavaScript from plugins that you have volontarily installed. My advice would be to be careful and audit everything that may be a threat in order to at least try and minimize the risks. Unfortunately I don't think many users do that but it's not something we as developers can address and prevent.
The dilemma here is the same as with filesharing: if it's accessible it can be copied and transferred. There's no patch against that.
That's a valid point, but you won't be effectively encrypt incoming email in the layer of a webmail client. You'd be better off incorporating that before the message is even saved to disk - in the mail delivery of your MTA. So once again it wouldn't be PHP (I hope for your sake!).
"(And in regards to in-browser crypto - I'm unsure there are strong enough guarantees of security in javascript to make me entirely comfortable having my private keys and passphrases hanging around in the process space where rogue javascript and/or plugins might be able to scoop them up…)"
Your sarcasm is entirely valid, but you didn't actually look at the project that you are criticizing. The entire point of what I linked in my comment is that nothing critical should be exposed to the JavaScript, just an API that it can interact with to send commands to: such as keygen, verify this message, send cleartext and receive ciphertext in response, etc. You're preaching to a believer here, :-)
Your ~/.gpg/ is -not- accessible to JavaScript. The interface, the GnuPG binary, is. That's the point. Now we can both agree that exposing private keys in such an API is a bad idea.
My plugin does nothing crypto based on the server side, everything is happening locally in the browser through JavaScript and in the future there will be an additional driver for performing crypto opts in GPG binaries as described in my comment above.
I don't mean to be harsh but server sided crypto is far from a good idea. It provices violent regimes, such as America, a technical ground to force hosts into backdooring their server sided crypto. Anything alike must be done on the client for safety and privacy to be ultimately achieved.
I'm glad I found your comment, I just pushed something like what you just described to one of my repos yesterday. Hear me out, I'm not self promoting myself out of context here.
I'm currently working on an OpenPGP integration for the Roundcube webmail project and have so far added functionality from the OpenPGP.js library. The pros of this is of course usability and that no external applications are necessary, the cons are, amongst others, what you just wrote above.
To be able to support briding local GPG binaries and keyrings into graphical browsers without exposing any critical information I threw together an HTTPD which listens on the client's localhost. The concept is already proven to work, now it's a mere matter of implementation. It's based on the PyGPG library which wraps GPG into Python and is compatible with both Windows and *NIX systems as long as they can execute GPG and Python (which they can).
It's still a work in progress but currently supports key generation and key listing in response to HTTP requests. Through cross-origin resource sharing users can specify which domains should be allowed to speak to it in a simple text file separated by line breaks.
I can conclude that what you are requesting is actively being built and partially already exists but still needs to be put to use. Hope you don't view this as shameless advertising, because it's not. I'm only responding because your ideas are spot on what I pushed yesterday.
I completely agree. We didn't install a cert since there were some doubts around wether we would sign it ourselves or not.
Either what we decide, a self signed cert is better than none, hence this is now fixed. All http traffic is now redirected to https using a 2048 bit self signed certificate :-)
or "retrieve" instead of "list" for a route which includes PK.
This of course makes the entire path read-only so it's not a way to make some fields writable and others not.