Hi Hareesan,
Thank you for taking this on!
The crucial parts are the interfaces to the steganography plugins, and how they signal what kind of data they can process (html, image, video, ...). I don't think it will scale if we just dump all data into all plugins for processing. (see comment below)
For the user interface, apart from the ability to select local files as carrier, I think it would be neat to be able to select content from websites (like: right click on image, select "embed secret"). Payload is either textual (entered via form), or binary (file selection).
To encrypt the payload before embedding, a private/public key scheme was proposed. I prefer ECC over RSA. You mention SJCL, which has an ECC branch.
Once Bob open a web site with web contents which he wants to check if it contains any messages steganographically hidden, he will click on the extension icon Figure 5. All the items in the page will be displayed in the extension with decrypt option.
We discussed earlier that the extension, together with its steganography addons, should have the capability to automatically find matching payload while browsing. Depending on the algorithms, this may or may not be feasable, so users may want to disable this for certain types of content, algorithms (plugins), or only enable scanning for specific sites. (which you outline in Figure 6)
Personally, for the manual scan/decrypt, I'd like to see an option in the context menu when I right-click an image or other content.
I was not able to completely follow the steps you describe in "How Alice's side works" and "How Bob's side works". The charts look neat, but are not ideal to describe the process.
The situation of usable javascript steganography libraries does not look too good. For the GSoC project, we should not waste too much time on this, and focus on the surrounding extension and clean interfaces to potential libraries. If we have time left, we can investigate what kind of algorithms we would like to see implemented/ported in Javascript.