Slashdot Mirror
OpenPGP Implemented In JavaScript
angry tapir writes with this excerpt from Tech World: "Researchers from German security firm Recurity Labs have released a JavaScript implementation of the OpenPGP specification that allows users to encrypt and decrypt webmail messages. Called GPG4Browsers, the tool functions as an extension for Google Chrome and now is capable of working with GMail."
A quick gander at the source leaves me with the impression that it should be more or less portable to other browsers. It's also built using a lot of off-the-shelf Javascript libraries. (Who knew Javascript had a bignum library and a number of cipher implementations?)
who knew Javascript had a bignum library and a number of cipher implementations
Those that know JavaScript?
And I don't mean the kids copy/pasting stuff found on the web, but real people working with JavaScript and having knowledge of the language, libraries, etc.
The biggest problem with JavaScript is that the world is plagued with kiddos that think they know JavaScript when all they know is how to search their needs on Google and copy/paste from there.
Write boring code, not shiny code!
I want to know who at Teh Google screwed that one up !!
Some group of bears maybe?
Write boring code, not shiny code!
Keygen illustrating the use of a Javascript bignum library
http://pastehtml.com/view/5ucd3ts.html
Could be used for web forums too.
http://michaelsmith.id.au
You've obviously never eaten honeycomb, then.
http://www.matasano.com/articles/javascript-cryptography/
Cue Atwood's Law comment, as found on every JavaScript post.
In the last year or so suddenly everyone seems to write everything in javascript whether appropriate or not. So these guys really think the future of development lies in the browser which will what, replace the OS as the top level development platform? Sorry , but thats rubbish. It aint gonna happen. Too many disperate browsers with their own quirks and bugs, poor performance and ultimately limited functionality.
So other than "to see if it can be done" what exactly is the point of these projects? However much webdevs might like it to happen, javascript won't be replacing Java, C++ or C# anytime soon for serious development.
I'll entrust my keys to code coming from a remote server that now has the ability to send mails as me with non-repudiation and read anything sent to me in ciphertext.
I've been to the hideout. It ain't pretty, let me tell you.
I'm pretty sure it's appropriate to write a browser extension in javascript, given that its the only language Chrome allows.
I encountered what was at least a serious attempt to do exaxtly the same thing in the mid-90s. And I used it, too. Together with a colleague. We both worked in a tiny outfit where the boss was meddling in corruption with local politicians and corporate local heroes. Having such a thing as PGP usable in browsers and email clients truly was PGP to us: pretty good protection ( for the evidence we found against our boss ).
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Email encryption (OpenPGP and SMIME ) is done on the client side. People have to use to email client softwares ( outlook, thunderbird ..etc) to encrypt/sign their messages.
The problem, what if you dont wanna use an email client ?
The solution
1 - Do it manually ( copy, encrypt/sign , past)
OR - Implement it on the "new" client software (ie: the browser )
The reason of javascript is that chrome extensions are written in that language ( and every browser support it ). Maybe other releases will be implemented in other languages that integrate to browsers ( Dart ? )
I think for reasons of trust that if you were to use js PGP that it should be from a browser extension that could be reviewed and be within your control to some extent. Or better yet if the js became a core part of a browser where the code could be implicitly trusted. I'd love to see something like Firefox support go further and use a lib like this so unsigned certs could instead describe a web of trust via PGP and modify the manner in which Firefox presents such certs to a user. CAs are the biggest racket on the web and are IMO the biggest impediment to https being the default protocol for web activity.
Would be really cool to see this ported across to gmail. Google is still going to know the contents of your mail during/from compilation but for delivery/verification on the remote side it would be nice.
No, it isn't. This article implicitly assumes user trusts server with everything or not at all. Not a case with GMail: in most attack models I can perfectly assume Google will deliver me correct Javascript code over SSL, but never trust it with securing my email content. Account hijacks are quite usual and replacing code on GMail servers is completely another thing.
Have been working on something similar very very slowly: a single ASP.Net web page (which could easily be ported to PHP no doubt) that acted as a proxy web browser that encrypted its traffic using a GPG key randomly generated (or provided by the user). It'd be text only ( = no accusations of being used for child pr0n or for teh pirates) but the idea would be that anyone could drop it into their own website without having to configure it and instantly people living under opressive censoring regimes (China,Iran,US,etc.) would be able to open that web page and use it as a web browser to get to news sites and the like.
If you don't risk failure you don't risk success.
http://www.matasano.com/articles/javascript-cryptography/
The above was written by someone without an understanding of public key cryptography. All you need to do is ensure that the crypto JavaScript is delivered through a secure channel. Once you have done that you can publish a public key on an insecure site and allow people to send data to you which cannot be intercepted. You can also let them generate a key pair and send you the public key, after which you can send them a response.
Because of the security issues raised by any javascript code:
- transmitted from a potentially rooted server, or
- intercepted by a MITM attack, or
- received by a rooted client
this implementation is not secured as specified in the techworld article
Plagiarist! Almost this exact comment was made 20 years ago:
In the last year or so suddenly everyone seems to write everything in C whether appropriate or not. So these guys really think the future of development lies in the windows interface which will what, replace the command-line as the top level development platform? Sorry , but thats rubbish. It aint gonna happen. Too many disperate GUIs with their own quirks and bugs, poor performance and ultimately limited functionality.
So other than "to see if it can be done" what exactly is the point of these projects? However much appdevs might like it to happen, C won't be replacing assembler, Forth or Fortran anytime soon for serious development.
News flash: turing-complete programming languages can be used to created anything. Why is it news when another random project is done in Javascript?
Pretty good is actually pretty bad.
This epic effort has one reason: ultimate need to get rid of all those machine cycles, which poison our machines. Shame to you, chipmakers!
How about, to solve the problem that I have right now, which I have because of requirments that I cannot escape?
Just because you think that it's not a good idea to solve a problem that way in the realm of theoretical computer science where you can dictate the appropriate topographical seperation of network layers and clients and servers, and configure them however you like, some people in the real world are simply told: such-and-such a browser will be sending such-and-such a request to you. I want that request fulfilled in such-and-such a way.
And we have to make it happen.
Isn't it obvious ? You have a functionality, like PGP, and you want to make it more rubbish. The easiest path is to implement it in Javascript. For this particular project the "interesting part" is security of private key if you give it to a Javascript. By interesting I of course mean stupid.
But couldn't JavaScript in the mail intercept JavaScript loaded over SSL? After all, it's both running in the same web page, isn't it?
Did you even read TFS?
Because most of the internet users still use "IE8" or less and therefor see JavaScript as something which sucks, is slow and can't find it's own tail?
Amen. Soon, JS will run the stove in my living room. Version 2.0 will also run my lover, making her sit really elegantly with a book on the couch facing that stove.
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
News flash: turing-complete programming languages can be used to created anything.
That really would be a newsflash. WHat about the halting problem? Or the P=NP problem?
Indeed. What we need is a low-level language without garbage collection.
Difficult to program by humans.
Easy to target by a compiler back-end.
Give us that, and open-source will give us all the tools and libraries to bring webdevelopment to the next level.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Indeed, it would be way more cool if we would have a compiler back-end that targets javascript.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
News flash: turing-complete programming languages can be used to created anything. Why is it news when another random project is done in Javascript?
Ah, the old Turing-complete chestnut. Just because something is possible, does not mean it is feasible, practical, or easy. It's probably possible to code it in brainfuck, chef, lolcode or a bunch of rocks but no-one in their right mind would want to.
What's really interesting about this is that it now brings PGP to almost device with a browser - that is: those with browsers which have javascript support. This gives us such joys as iPhones with PGP that Apple can't suddenly decide they don't want people to have.
"such-and-such a browser will be sending such-and-such a request to you."
In which case they'll be doing server side development so why exactly would any sane person be using javascript for this? In the "real world" I live in javascript stays in the browser. End of.
You might want to think through your replies before you start typing.
The human brain and the observable universe, implemented in JavaShit... oops Script.
I'm sure cryptologist's agree! What could possibly go wrong?!
How is this different from FireGPG? With the exception that this is still in development versus the stall in FireGPG?
This is something that webmail has need for ages. Encrypted email is relatively easy to implement, and is free, but webmail makes it difficult to do without handing your keys over to a third party (GMail, HotMail, etc). This solves the problem nicely. It would be great to see this, or something similar widely adopted.
Generally speaking, porting cryptographic implementations between systems is not as easy as "do both implementations produce the same output for the many test inputs tried?".
Proper implementations will mitigate against side channel attacks by:
I'm skeptical as to whether a web browser implementation (in JavaScript, not part of the browser itself) can address the issues listed above.
Why would in-mail javascript run at all?
If you have a secure channel, what do you need JavaScript crypto for?
Just communicate the mails via that channel.
In which case they'll be doing server side development so why exactly would any sane person be using javascript for this? In the "real world" I live in javascript stays in the browser. End of.
Exactly! Why didn't this asshole just hack into GMails servers, and then configure encryption for every end user in such a way that Google, who will still ultimately have control over the servers, can't decrypt it? I mean seriously, in the "real world" we live in where there servers are controlled by corporations that we don't actually trust, server side development is always the answer.
You might want to just stop typing.
What about them?
Encrypting mails you send via webmail without having copy your keys on the server sounds like reasonable usecase.
It is hopelessly slow.
It's a "Haute Cuisine" dessert, I think. They sell it at the local boutique over-priced (e.g. organic, etc) food store by me. It doesn't look very appetizing.. do you spit out the wax, or try to eat around it?
Can you be Even More Awesome?!
You can already get encryption of your link between google and yourself - just use https, or imap with ssl. In fact, I'm pretty sure that https is the default for the web viewer now.
The article is talking about something different.
Can you be Even More Awesome?!
Hi dare you call chrome a browser! It's a desktop environment dammit!
A secure out-of-band channel is essential to secure communication.
One channel is never enough.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
I think you mean thirty?
Twenty years ago is so, '90s.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Because you just need the secure channel to exchange the keys, and once that is done you can use any other channel even when the secure channel is not available to you. This is, in fact, the entire point of cryptography. If everyone had access to a known secure channel of infinite bandwidth at all times, then there would be no need for it.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
What about them?
It really would be a newsflash if they could be solved in a Turing-complete language.
Unfortunately it won't be until v3 that it can actually get you to realize that the purpose of a lover is something other than to sit elegantly with a book on the couch facing the stove, and even a massively parallel supercomputer will never get you an actual lover, thereby making the code useless.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
You pretty much just chew on it until you've managed to get all the honey out then spit out the blob of wax.
They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance. - Terry Pratchett
I've had it before. I don't know if it's treated somehow, but you can just eat the whole lot. It's quite tasty, primarily because of the honey.
What does that have to do with the fact you can create any program with a Turing-complete programming language?
Pretty good is actually pretty bad.
Good point, although the tonal setting seems to veer somewhat toward the hostile, as in : "You poor nerd / geek / ..., you seem not to be able to get / have / keep hold of a lover". Which is not my case. The post was meant i r o n i c a l l y, for the sake of cryin' out loud ***sigh***
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
If it's using JavaScript, they should call this version OpenPBP.
That tone you are hearing is in your head. Here on Slashdot, nobody can ever have a girlfriend, even if they are married ;-)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I don't see why all the fuss is made about JS's capabilities. Coming from a very strong Perl/Unix background I see the appealing side of scripting. But if I take into account business programming, JS makes me shiver to the spine.
I grew up being generally interested in CS and specifically in programming. Most programmers I meet hardly ever cease to amaze me at the nonchalance which they adopt when writing code. You (dis-) qualify yourself with me as soon as the argument of "well it works" pops up. Programming the business logic is the easy part. Handling all possible exceptions whilst maintaining integrity is the hard part. Not reaching a conclusion too soon is also "up there."
Most programmers I meet can't be arsed to take exceptions and integrity too seriously. Or to continue pondering over a problem. The natural curiosity of finding out stuff and improving oneself every single day is hardly ever there.
I have adopted the liking of Java for complex solutions. You can only screw up so much in it. And you can program almost anything with it. I like mediocre programmers to write their stuff in Java.
Anything needing complex, low level system interaction I'd program in Perl. I also appreciate other similar languages that do the same. I prefer mediocre programmers around me not to touch Perl.
For setting up running environments for programs to run and to program very simple applications, I advocate Bourne Shell (not bash.) One good thing about Bourne/Unix is that mediocre programmers steer clear from AWK.
Stating that I'm "Not a complete fan of JS" is perhaps an understatement. I find the typing revolting. The means to overload methods. The slightly different method of handling strings compared to Java.
I have had the misfortune of having to know a product using JS and an open runtime implementation. Knowing what other people did is tedious at best and debugging JS there is pure hell. I pity the folks I left behind.
So, from a business point of view I loathe JS. And from a hobby point of view I can't be bothered. Why use a scripting language to program complex software when other better maintainable technologies are around? "Because you frigging can!" is the only answer I can think of.
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
Except a buggy browser needs to store your private key. That doesn't sound so reasonable to me.
Ah. My user id is pretty low (though not as low as yours); still, I was never informed of that rule. Although, wait. Hm. You can not prove that tone I am hearing is in my head. Neither can I prove that it is not. Oh Bishop Berkeley, where art thou ?
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
Yes, that also raises the question why you read/answer encryption worthy emails via webmail but I would argue it is still an improvement that your key does not need to leave your machine.
What does that have to do with the fact you can create any program with a Turing-complete programming language?
Nothing, but was responding to GGP post saying that they could do anything.
So these guys really think the future of development lies in the browser which will what, replace the OS as the top level development platform? Sorry , but thats rubbish. It aint gonna happen.
Yes, it is going to happen. It is happening, and there's nothing we can do to stop it. Not only that, but hypervisors are becoming fatter, and the BIOS is giving way to UEFI. At some point, there won't be much of a role for the traditional operating system.
Give me Classic Slashdot or give me death!
Lets play the fill in the blank game!
COBOL compiles to _________.
FORTRAN compiles to _________.
C compiles to ___________.
Javascript compiles to ___________.
There really isn't a good way to compile to Javascript because of the amount the backend work that is needed for it to run (garbage collection anyone). They could try to do what "Go" does and include the garbage collection functionality in the system libraries or in the executable.
Also, no sane OS dev would ever use Javascript for their language of choice. Javascript is a really badly designed language. Unless they take an axe and start removing a lot of the "cruft", it will be shunned by a lot of people still.
Its not what it is, its something else.
So these guys really think the future of development lies in the browser which will what, replace the OS as the top level development platform? Sorry , but thats rubbish. It aint gonna happen.
Altogether replace? For everyone? Maybe not.
But while I use MS Office for my job, *all* my personal word-processing and spreadsheeting is done in Google Docs, and *all* my personal email has been in GMail ever since I got my beta invite -- and I'm not alone. There are flaws in these applications, but they're all outweighed by the ease of moving between computers, and sharing documents with other people.
You don't have to kill your competition in order to be worth doing.
It's more portable than anything else, and it's capable of more than popups. I can only see this trend utilizing processing power better than the (now fading) model of "do it all on the server". How many more people will use PGP if it's built into their webmail client? They won't need to install anything, configure anything - just use.
There are a number of things I'd like to push to the browser. With accompanying server fallbacks, browser processing could greatly reduce my server load which would increase the number of users I could serve.
Try not to think of it in terms of "if it can be done", think of it more in the terms of "can I distribute the tasks".
"Lame" - Galaxar
Two things: hushmail.com does this. And second, it doesn't really work. If you don't trust your provider (or your connection to the provider) then how do you know your javascript encryption library doesn't have a back door?
yes very nice
In fact I personally think it is a good choice, can exercise to the child's brain, although he is not very familiar with him, so that he would be better suited to each never seen or didn't touch it .
www.loveinbridal.com
yes, i agree. the way google-fox tries to scare an end user just because someone hasn't given symantec their blood money is sickening
Your user id isn't what I call low at all.
Sigh
Kids
Nothing is forcing anyone to use the "cruft" though.. there are corner cases in every language that can be considered *very* bad form.
Michael J. Ryan - tracker1.info
But you do not need a secure channel to exchange the keys if you use asymmetric encryption mechanisms like RSA or ElGamal. You need trust/authentication to know that the public key is legit.
Having a secure channel as a prerequisite is disingenious. If you presume to already have a secure channel available, then why not just swap symmetric keys over that. Of just send the message there, if it has a lot of bandwidth.
This is what Matasano page is arguing. You need a secure transport layer to transport the Javascript and all the content. But, if you have a secure transport layer with that much bandwidth available, you have no need for Javascript encryption.
Javascript is the only language actually delivering on the promise of "write-once-run-anywhere." Well, "anywhere" that has a web browser, which is just about any device that does human interaction these days. All the other languages you mentioned have numerous environmental dependencies (separately installed run-times, OS specific conditionals, browser plug-ins, compiler specifics, etc.). Javascript sucks in many ways, but it sucks less than the alternatives for building an application quickly that can work just about anywhere.
And they're right even if they don't use IE8 or below, how funny.
> Indeed, it would be way more cool if we would have a compiler back-end that targets javascript.
Should read:
Indeed, it would be way more cool if we would have a compiler back-end *besides GWT* that targets javascript.
That is, if you trust SSL and the certificate things, and trust that DigiNotar event can't happen, that there's no evil government running their own root CA, etc. To me, that's a big IF !
The problem, what if you dont wanna use an email client ?
If you don't want to use an email client, don't read/write emails. End of the story...
greasemonkey
The traditional operating system controls access to hardware, virtual memory, provides an API and schedules processes. Something will still have to do that so the "traditional" OS isn't going anywhere. It'll probably just be less obvious.
However much webdevs might like it to happen, javascript won't be replacing Java, C++ or C# anytime soon for serious development.
As someone who has developed Java professionally for a while, I can say that having to pepper 100s of interfaces in the code just to do a closure then write a bunch of cruft to use it is kind of annoying. Not to mention Java the most verbose language gave birth to a bastard child for configuration: XML. I prefer to build cool stuff, not write a bunch of needless code. If JavaScript replaces Java it will be because the JavaScript shops developed better software, faster while the Java shops where writing XML. I have been doing 90% JavaScript the past year or two, solely because of the faster dev times and it's a better language than Java.
Installed it, it fired correctly once, but no won't pop up for pgp signed emails anymore. Creating a public key doesn't work. Pretty much broken out of the box.
...import his private and public keys into the local database...
That's what they want you to think....
Hushmail lost a lot of credibility a few years ago when it turned out that its most commonly-used encryption method that ran server-side was delivered in a modified state at the request of government agencies. Yes, there are issues with trusting anything server-side, but its promises started sounding hollow when the CTO openly admitted it.
If you built your own applet from the public source code, the interception was not an issue, but if you used the easier mechanism hosted by Hushmail, you were at risk of your mail being decrypted and turned over.
http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/
You can never go home again... but I guess you can shop there.
"ease of moving between computers,"
Who moves between computers to do documentation? I mean really, is your company so skint it can't afford laptops and you have to work in netcafes?
This will make basic encrypted messaging tough to block by oppressive regimes like Iran and China. This is good for basic personal freedom.
A secure channel: like a for example a browser extension loaded from your local HDD/SDD ? Which this is.
New things are always on the horizon
I think you have to re-read the link.
However true it is what is said there, truth of the matter is that one thing is security as is considered in cryptography literature (an ideal concept), and another is practical security. JS-based cryptography does add to practical security, but it s very important to read that link and know its limitations.
About the value of JS-based crypto over SSL... well... SSL can now be compromised in a number of ways. JS-based crypto provides protection that is somewhat orthogonal to SSL. If SSL is broken for eavesdropping (as are the latest attacks on it, like BEAST), but not forging, JS-based crypto will protect the contents, since the JS code will still be secure. If SSL is broken for forging, JS-based crypto is doomed, but also is SSL itself. So, overall, the system would be more secure.
And, SSL or not, JS-crypto or not, phishing is still possible. It is actually quite possible to not break any encryption and still collect authentication tokens from users. So, with that huge flaw in all security schemes, crypto literature would consider the system insecure already even if all were to be plaintext. But security researchers don't, because they do know the difference between ideal and practical security.
Ideal security is an oxymoron.
Don't forget XSS attacks. XHTML can help here by its strict error handing, and I have suggested logging XML errors to a server before.
I have a closed-source WiFi phone that has a Netfront browser with a decent implementation of Javascript. This same WiFi phone also has some minimal file manipulation tools, a text editor, and a media capturer and player. What it doesn't have is the ability to encrypt files that I don't want to be readily usable, such as some audio recordings of interrogations as well as a text file containing a list of my registrations to websites each with a hint of what my written password could be. I would like to encrypt a number of these mp3 and txt files so anyone performing a search at an airport will not copy them in their moment of leisurable search to curiously pick at my career or eavesdrop just because he didn't like my attitude in the search line. This has been the case for me and encryption ever since I was visitted by dirty COPS in California, whom sacked my car for no reason and just started copying all my data and mishandling expensive camera equipment; they just looked at me and gave a bullshit reason, wouldn't say why they were doing, and used force to prevent me from locking anything from their prying, and no complaint filed and no reason and no warrant. I was slammed onto the hood of their cruiser because they didn't like my few relevent questions and how I asked those question. When back at their police station, they just stared me down like a priest I didn't give a tythe unto, and after searching through all my stuff one of them starting showing a soft spot and tried to casually converse with me but I wouldn't have it.
Encryption is the invention for a society that is dying. Data needs to be protected by bullets and knives from these bastards in government that demand everyone pay their living even when they do as the Fire Truck Drivers in responding to ambulance emergencies with their full crew just so they can log their division's activity as reason to not get layed-off for lack of an arson helping them out once in a while.
No it wasn't, the author of that article specifically takes on the idea of the crypto being delivered through a secure channel, having two basic objections: 1) If you have a secure channel already, then you don't need JavaScript encryption; and 2) JavaScript is completely malleable at runtime, and so you can't guarantee that running code, or the functions/libraries/objects on which it depends (down to the very basic JavaScript objects), will remain unmodified and trustworthy.
The first issue applies to a little different problem than the one being solved here. While the author was considering client-server communications, what we're dealing with here is a different use: end-to-end email encryption. That is, the browser-GMail encryption of the user session and all its contents is already taken care of by HTTPS, but GMail still knows what your email contains. This is, as I understand it, an attempt to encrypt/decrypt the text of the email on the client, such that GMail would only see the ciphertext and never receive the cleartext at all.
Fine in theory, but the second issue would seem to me to still apply. I haven't looked at their source, so maybe they've found a way to avoid this, but if any code from a server can interact with the code from this plugin, then it isn't obvious how the code remains trustworthy, no matter how secure the original channel was through which it was loaded.
All I see are Javascript cut'n'paste text encryption tools and that realy sucks because not all clients have a cut'n'paste ability. I need an implementation that I can direct to a video file and makes another one with encryption while giving me a key as it deletes the source. That's what it's about, not a Browser plug-in or add-on but an actual Javascript emplementation.
I looked High and low, and haven't found one yet. Can you?
Link-level, yes. However, what if google's certificate got hacked? With your emails signed and encrypted (especially on the client side) it would add en extra layer of security.
I honestly believe being another DigiNotar event victim is a few orders of magnitude less likely then having some script kiddie hack my account.
Ach, mein Gott. A granddad of computing deigns to pay me a visit !! :-))
Religous speak to God. Insane are spoken to by God. When all shut up, one can finally hear Shostakovich in peace
You are being extremely naive. There was about 3 registrar issues last summer, and it's a well known FACT that governments (at least China and USA) are playing with certs (there was some real life cases reported, it's not just wild guesses here...). So if a government wants to get your key, it'd be really easy for them to replace the HTTPS hosted javascript. Do not forget too that there's the patriot act, and that you may very well be considered as a terrorist (everybody is, these days).
I said it was for personal stuff. I can get at my Google Docs on my laptop, on my home desktop, on my partner's PC, on my parents' PC... anywhere.
That said, if I ran my own company, I'd use Google Docs too.
It is OK - but - Implementing encryption on Gmail should be something Google shall be offering right out of the box - Otherwise, every time there is a new Browser version or a change on Gmail's interface it will then be hard to keep up by add-ons developers. One thing I like on Go Daddy's webmail accounts is that it comes with an easy to use function to send encrypted messages without leaving the browser or interact with any add-ons. It is a password protection model (which means it doesn't handle private an public keys) but it is just more practical since you don't have to convince, and sometimes teach, people you want to communicate securely to set up and learn how to use certificates and or public or private keys. Maybe Google will say: If we enable encryption how we are supposed to serve ads? Well, maybe instead of "reading" the users email to find keywords to serve ads - Maybe it will be better to et the users to choose the Keywords to serve such ads. I mean, an email can have hundreds of words and sometimes I see gmail ads of words I mention when composing or reading an email - but the ads really don't match my interest at all. Cappicci?
News flash: turing-complete programming languages can be used to created anything. Why is it news when another random project is done in Javascript?
It's news that someone did it, not news that it was possible. If China landed on the Moon tomorrow, would you say "Why is that news? Everyone already knew it was possible?"
Are you the only one who realizes that "Honeycomb" refers to the cereal product? Really?
Stephen D. Williams
:-)