Since the OpenSocial announcement, we have been having lots of conversations with both Container and Application developers interested in implementing OpenSocial. The best way to join this conversation is still this OpenSocial Group, but we thought it would be useful to summarize the areas we've been thinking and discussing most closely over the last few weeks.
Security There are several points in the OpenSocial system that require secure communication between Applications, Containers and the Users' browser, and defense against abuse. The main issues break down as follows: *Isolation between Applications Containers need to provide protection against malicious HTML and Javascript in Applications, both from attacks on the container itself, and from attempts by Applications to breach containment boundaries. The initial model being used is iframe isolation - putting each Application in a separate iframe so that security is enforced by the browser, and providing APIs to access external sites. This does impose latency and resource overhead per gadget. An approach that shows promise is object-capability security, where the HTML, Javascript and CSS of the Application is rewritten to run with controlled access to the browser environment and external calls are abstracted. This will eventually allow multiple independent Applications to be inlined within the same page without using iframes. The open source Caja project is implementing this approach, and should provide better performance and more fine-grained security control. Caja: http://code.google.com/p/google-caja Details on the approach can be found in the Caja draft specification: http://groups.google.com/group/google-caja-discuss/web/caja-spec.pdf We welcome feedback; please join the Caja discussion group if you are interested in participating: http://groups.google.com/group/google-caja-discuss *Validating Fetch_Content calls to external sites For Applications to access external websites, Containers need to provide a content-fetching API. If this is used to retrieve or modify per-user Application data, it can be a point of attack to manipulate that data on the Application developer's servers. Accordingly, request signing is needed so that the Application server can trust that the request has come from a known container, and that the user identity parameters have been validated. The proposal for this is based on the OAuth parameter signing model. Details in this blog post: http://opensocialapis.blogspot.com/2007/11/improved-content-fetching-for.html Note that some Containers may have explicit whitelists for both Applications and accessible domains, for example those running within enterprise systems. OAuth: http://oauth.net/ User Navigation and Privacy OpenSocial lets Applications request information about users and their friends. In particular it lets Applications ask for information about the Viewer of the page, and the Owner of the page. This abstraction works in both a profile context with multiple Applications, and in a single-Application view. One thing to note here is that although the Application can request this information, what is actually returned will depend on the privacy policy of the Container, as well as what is being viewed. Some Containers will only show Viewer information if the Viewer has already installed the application on their own profile; some will rely on site-wide state. In addition, the 'friends' information returned may also vary depending on the Container site's policy and user preferences. Applications should cope with either Viewer or Owner requests returning nothing. A way for containers to express different capabilities so that Applications can enquire about them is being considered. API and SPI distinction The distinction between the API visible to Applications, and the SPI that implements the communication between the Container code and the host site was initially a little unclear. The Sample Container is intended to clarify this, by having container.js be the piece that varies between sites. http://code.google.com/p/opensocial-container-sample/ This will be developed further to clarify API distinctions. Different Container sites have different strategies for how to separate out the backend data supplied to the Applications; some have it already present client-side; some use token-based authentication; some use a proxy server. A way for Applications to specify which version of OpenSocial they require is needed, and being planned. Additionally, there is also a need to distinguish the OpenSocial features from the Google Gadget API. There are specific baseline Gadget APIs that are needed for gadgets work usefully - equivalents of IG_Fetch_Content, IG_Adjust_Frame_Height and IG_Register_On_Load_Handler. The existing requires model in the Gadget manifest could be used to specify extensions that may be needed. Open Source There is a broad goal to release an open source reference implementation for OpenSocial to enable a wide range of containers to be deployed. There are different components to the OpenSocial stack that make sense individually, but may need different implementations depending on the host server platform and language. * The JavaScript environment is expected to be common, with the container.js having the container-specific code. * A gadget service that implements the manifest parsing and inclusion of common functions, like gmodules.com does for Google Gadgets. * A gateway API service that exposes Container data to Applications via both Javascript-focused and server-to-server focused APIs. The proposed Apache Shindig project is intended to be the home of the reference implementations of all the components of the OpenSocial stack. The initial server languages under discussion are Java and PHP, with others being considered by other containers. Shindig proposal: http://markmail.org/message/yzkaf33e4v3ajfwx Application directory and installation spread Another area of active discussion is how to share Application Directories between containers, and how Applications can gather users. To some extent the policy for Application installation is dependent on each container's policy, but standard RequestApplicationInstall() API methods could be provided, and the container could decide how it prompts the user. Requesting Viewer data could also be abstracted in this way, so that containers that wish to prompt the user for permission could do so, while those that always allow or always deny this to Applications could respond without a UI prompt. Please reply back to this thread with any comments, suggestions and concerns. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Implementing OpenSocial Containers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/opensocial-container?hl=en -~----------~----~----~----~------~----~------~--~---
