Hello.

This post discusses how to use window.name for cross-domain communication between windows/iframes, especially before the onload event. It explains a simple method using window.open to set the name and retrieve it in the opened window. It also addresses IE compatibility issues by base64 encoding/decoding the data and provides code snippets for both encoding and decoding, handling IE's character restrictions and lack of built-in base64 functions.

WebMessaging (postMessage) seems simple but has quirks. Different browsers handle data differently (structured clones vs. strings). The biggest problem is sending messages to a newly opened window/iframe. You can't just send a message immediately; you have to wait for the window to load and signal back. This adds complexity, requiring the new window to postMessage back to the opener, which then sends the actual data. A workaround involves passing data via window.name, but this has security implications as the data's origin is uncertain and the name persists, potentially exposing data.

In this follow-up tutorial, we enhance the "Post to Buzz" Chrome Extension by adding a share count to the browser action button. This involves making cross-domain requests to the Buzz API's buzzCounter endpoint. We've updated the manifest file to include necessary permissions and added code to background.html to handle tab changes and URL updates. The code retrieves the Buzz count for the current URL and displays it on the browser action button, providing users with real-time feedback on share activity. This subtle update enhances the user experience and provides valuable context within the extension.

The Ajax Tagger has been updated with a number of bug fixes and improvements. Key changes include using my own Tag Directory for related tags, providing Yahoo search results as RSS in OPML output, and fixing issues with menu item classes, OPML apostrophe escaping, and image selection persistence. Planned future enhancements include a Blogger interface, Kelkoo integration, addressing a cross-domain CGI request security warning, and Del.icio.us OPML integration.

I've created a tool called DeliTag that automatically suggests tags for any page on kinlan.co.uk and submits them to your Delicious account. It's a quick process: hit "Goto", let the page load, click "Analyze" to see tag suggestions, choose the ones you like, enter your Delicious credentials, and press "Submit". Keep in mind, this currently only works on my site and requires IE6+ with Cross Domain Data Island support. Passwords are sent as plain text, mimicking Delicious's own method. Let me know if you'd like to see this developed further!

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.

Microsoft's Start.com has launched a new developer API, possibly using the ATLAS framework (precursor to ASP.NET AJAX). It seems to focus on creating JavaScript-based "Gadgets," similar to RSS consumers, that need to be hosted on a server. The API also requires enabling cross-domain data sources in Internet Explorer, a topic I've discussed previously.

In part two of this series on the failures of my first AJAX application, I discuss how my initial plan to reduce bandwidth by having the client directly access third-party web services didn't work out. Due to cross-domain scripting issues in Firefox and IE 6/7, I had to implement proxy scripts on my server. This means all client requests now go through my server, increasing my bandwidth demands. While using a proxy server offers benefits like hiding security information (like Technorati developer tokens) and enabling data manipulation/request merging, it comes with the major downside of increased bandwidth usage and the need to create/maintain proxy scripts. I hope to support cross-domain data sources in the next version to mitigate these issues but acknowledge there might still be scenarios where proxy scripts are necessary.

I've been exploring how Microsoft's Start.com retrieves data from external web feeds. It appears they use a server-side script to tunnel requests to the remote server, effectively acting as a proxy. This workaround is necessary due to browser security restrictions that prevent cross-domain data fetching in Firefox and certain Internet Explorer configurations. Consequently, my AJAX application will need to handle the additional bandwidth required for retrieving data from Yahoo and Technorati directly, as redirecting XMLHttpRequest calls isn't a viable option.

I'm developing an AJAX application to automatically generate Technorati, Feedster, and MSN search boxes with relevant tags for my blog posts. It's a JavaScript webservice queryer that uses results from one service as input for another. Currently, it only supports IE6/7 due to cross-domain data source import restrictions in Firefox. I'm exploring JavaScript code signing as a potential solution. The application integrates with Yahoo webservices, with plans to include Technorati and hopefully Feedster. There are security concerns regarding my Yahoo key. I aim to have a prototype available for feedback soon.

I had this brilliant idea to create a merged RSS feed using client-side processing. The idea was to have a main RSS feed that linked to other feeds. My custom XML would include a list of sources. Then, using XSLT in the browser, the client could merge these external feeds into a single view. It worked perfectly locally! However, I hit a roadblock with cross-domain security restrictions when I uploaded it to my server. The browser wouldn't let me pull in feeds from other domains due to security concerns. Additionally, client-side XSLT processing isn't universally supported. So, even if the security issue wasn't there, many feed readers wouldn't be able to display the merged feed. In the end, the project failed. But, I learned a lot about browser security, XSLT limitations and client/server interactions!