This post discusses the security implications of cross-domain XMLHttpRequest access. While some argue that such access increases the risk of phishing attacks and unauthorized data access, others contend that these risks are minimal and that the benefits of cross-domain access, such as reduced bandwidth costs for "mash-up" applications, outweigh the potential downsides. The current security model, which requires proxying requests through the originating server, is seen as costly. I propose a server-side security model where third-party servers can control which clients can directly access their data, addressing the bandwidth theft concerns.
This post kicks off documenting the requirements for the next version of AJAXTagger. The goal is to create a successful application (by my definition) by outlining features across functional areas, UI/UX, client/server-side business logic, data access, and dependencies. Key features include easy journal tagging, related information retrieval (tags, articles, blogs, websites), diverse search provider integration, streamlined results presentation, image inclusion, and efficient article pulling/saving. The UI should minimize user effort, provide immediate feedback, and offer information hiding. Performance is crucial, targeting IE6/7 and Firefox, with emphasis on minimal server round trips, client-side optimization, and error handling. Data storage is preferably client-side, with external access optimized for speed and resilience. External dependencies include various search engines/services, while internal constraints involve limited server access and reliance on HTML, JavaScript, and XmlHTTPrequest.
My AJAX application has a minor cross-site data access security issue, similar to one I've encountered in Firefox. A workaround in IE6/7 involves enabling "Access data sources across domains" in Internet Options -> Security -> Custom Level, though this isn't ideal.
