Ok that makes sense. A couple of thoughts. I am also interested in the integration with webmail and want to work on that, but I believe other members want to use it for other things (mobile, etc). However, I suppose we could leave the "library" part in the src folder and the extraneous stuff in other folders...
I think the biggest difference between my vision of how webmail integration should work and yours is I think that it should be as integrated in the normal gmail experience as possible. I realize that this means it will be harder to maintain (such as the recently upgraded front end), and other issues such as draft uploading. However, I think the goal should be to make it as seamless as possible for users to use with as few clicks and changes to experience. I want OpenPGP to be more accessible to more people. prometheusx.net has some screenshots that you can check out of my kind of vision. Perhaps the plugin could attempt to integrate with the front end and if the version has changed then resort to use the compose/decrypt pages? I understand the RFC822 now. This seems similar to what I have mentioned with a bit more maintenance but at the cost of ease of use? In my extension I was doing a handful of string replaces for extra <div> and <br>'s introduced by gmail... Thoughts? Sean On Wed, Dec 7, 2011 at 8:09 AM, Carsten Wentzlow <[email protected]>wrote: > Hi! > ~~~ > > Sorry, maybe i misinterpreted the goal of this project. If this project is > only about the core library as described in > https://github.com/openpgpjs/openpgpjs/wiki/Introduction only the src/ > folder is needed and most of the work is already done. > > Once again the structure: > > src/ - Main source folder for the openpgp > implementation (keyring, message, private / public key) > src/ciphers/ - Generic openpgp crypto interface > src/ciphers/asymmetric/ - DSA, RSA, Elgamal > src/ciphers/symmetric/ - AES, blowfish, CAST5, DES, twofish > src/ciphers/hash/ - Hash algorithms (sha*, ripe-md160, md5) > src/compression/ - Compression methods (currently none; ZIP, ZLIB > Bzip2) > src/encoding/ - Encoding libs (base64, ascii armor format, emsa > / eme pkcs1) > src/packet/ - Openpgp packet implementation > src/type/ - Openpgp type objects (MPI, keyId, s2k) > src/util/ - Debugging, type conversion (string <-> array), > checksum calculation > src/storage/ - Storage interface for the keyring > doc/ - Documentation (currently i use JavaDoc) > > I will go ahead and restructure the gpg4browsers code. > > In response to my original idea (which is apparently out of scope): > > On 12/07/2011 01:02 AM, Sean Colyer wrote: > > I think your structure is pretty logical for the src folder. I think we > may additionally want to add a key management folder within src that would > contain different key management that we could be instantiated and they > would work interchangeably (such as using html5 storage and also a dropbox > connector..) > > Ok. I would include this in src/storage. The HTML5 local storage for the > keyring is already implemented (using JSON.stringify() / JSON.parse() for > writing and reading the public and private keys). > > > I think the one thing we might want to break off is the incorporation of > the implementations (in your case the gmail extension code), just because > the goal is to create something of a universal library. If I look at your > code outline correctly it looks like the objective is to create a universal > webmail extension? > > Yes. > > I lined out a project structure with the goal to create plugins for > browsers allowing a user to use openpgp on any webmail page. This follows > the gpg4browsers idea and requires writing code for browser plugins as well > as writing an integration for webmail providers. > > > I'm curious what you're envisioning for plugins and webmail API? I'm not > quite sure I understand what we would need for an API for this that > wouldn't just be direct calls to encrypt/decrypt/sign/key management calls > that would be fairly generic? > > Yes, from the OpenPGP part. > > Webmail does not provide a generic API to read messages from the inbox or > creating a compose window to send the message. Most of them even do not > provide an API for developers (e.g. gmail.com) to access core > functionalities because the business case is to display content related > advertisement within the webmail interface. The googlemail plugin contains > code to check on openpgp messages on the webmail interface and to parse > messages including date, sender, cc and so on out of it. Also opening a > gmail compose window and fill out recipients and body is in there. > > Function to by implemented by a webmail integration would be: > - check currently displayed mail for openpgp content > - get all mail information > - open a compose window > > In general i think that implementing OpenPGP in Javascript does not help > to bring openpgp to webmail. A Plugin using a NPAPI would be more secure > already exists in Firefox, IE and Chrome. Whats really missing are > integrations to webmail providers (usage integrated in your webmail client > without copy and pasting content). > > A openpgp javascript library makes sense in cases where an NPAPI is not > provided by the browser (e.g. Chrome OS). > > > > > RFC822 is pretty old, I believe, how exactly are you combining it into > reading with gmail? > > Since parsing mail content out of HTML and reconstructing the original > content of the email (removing all googlemail modified content) is very > hard and required for verifying signature only messages correctly I am > using the plain HTML interface of googlemail which offers the feature to > retrieve a mail message in raw message format (RFC822). To parse and > display a message correctly a lot of language specific decoding must be > done. This is what i am implementing here. > > regards, > carsten > > _______________________________________________ > > http://openpgpjs.org >
_______________________________________________ http://openpgpjs.org
