Here's a demo of the new Reader functionality in Safari 5. When you click on the Reader button to the right of the URL address, Safari will highlight and magnify the news article on a web page while temporarily hiding the ads.
Tuesday, June 29, 2010
Thursday, June 24, 2010
Stuff From the Cutting Room Floor
I picked up my iPhone 4, this morning. It was a great experience and the employees at the Carlsbad Apple Store were fantastic as they passed out water, juice, coffee, muffins, and croissants around 6 a.m. I arrived at 5 o'clock in the morning, the doors opened at 7 a.m., and I was out by 8 with two new iPhones.
I covered the event for SDNN by writing an article, snapping some photos, and recording several video interviews.

Here are some videos and photos that didn't make it into the article and ended up on the cutting room floor.
Camped out, overnight, on the sidewalk in front of the Apple store.
Catching up with customer #1 at 5 a.m.
About an hour before the doors opened.
The final count down.
I covered the event for SDNN by writing an article, snapping some photos, and recording several video interviews.

Here are some videos and photos that didn't make it into the article and ended up on the cutting room floor.
Camped out, overnight, on the sidewalk in front of the Apple store.Catching up with customer #1 at 5 a.m.
About an hour before the doors opened.
The final count down.
Tuesday, June 22, 2010
The unbundling of content is going mobile
As I went for a run this past weekend I got to thinking about how we, as consumers, have more say in the content we purchase. In other words, we can only pay for what we want.
Remember the old days when you had to buy the entire album for just one song? Sure, you could buy the 45 rpm, but that only worked if the song you wanted was a hit or the b-side. Today, you can purchase almost any song as an individual track for about a buck.
This trend started about ten years ago with news on the Internet and I think it has accelerated in the past few years with MP3 players and smart phones.
I wrote up the details in this SDNN piece.
Remember the old days when you had to buy the entire album for just one song? Sure, you could buy the 45 rpm, but that only worked if the song you wanted was a hit or the b-side. Today, you can purchase almost any song as an individual track for about a buck.
This trend started about ten years ago with news on the Internet and I think it has accelerated in the past few years with MP3 players and smart phones.
I wrote up the details in this SDNN piece.
Monday, June 21, 2010
Sunday, June 20, 2010
Unsaved Documents
Having worked with NeXT and Apple technologies for so long I've taken for granted that many people don't realize the dot in the red close-window "LED" button indicates that your document has unsaved changes.
Labels:
Apple
Saturday, June 19, 2010
Beating Back Facebook Sharer.php Bugs
Epics3.com is a fairly simple site for sharing your photos on the web. It ties in nicely with Facebook and Twitter by either using simple share buttons at the bottom of each large image or through an API when the photos are uploaded via a browser or through e-mail.
On Twitter, the photo's caption is tweeted out with a link to the full size image. In the case of Facebook, though, just the caption is sent over using Facebook's API and it's posted on your wall as a link. Facebook had documented some hints which you can put into the web page's HTML so it can pick up a specific thumbnail of the image to post on your Facebook wall.
Bugs
Unfortunately, there is a Facebook bug, that pops up randomly, where the hints for finding the thumbnail image are ignored. This results in the first image on the webpage being posted to your wall. In the case of Epics3, as in most, this will result in the website's logo posted on your wall instead of the photo. Bad, bad, user experience. How could it work for months without a problem until recently?
click to enlarge
Documentation
Facebook's API documentation is notoriously horrible (on the other hand, Amazon Web Services documentation is the textbook case on how APIs should be documented).
After spending several hours tracking down this bug on the Internet, I concluded that no one had solved it. (I also doubt that it was well documented in a way that Facebook, Inc. can reproduce the problem). When searching for the bug I found many cases of users who had encountered the same problem with shrugged shoulders. After all, this is just HTML - there's no logic to debug.
Details
When you use Facebook's sharer.php button to post a link to your wall, Facebook's servers will take a quick look at the link and spider the webpage to find a suitable photo. You can tell Facebook exactly which photo to post next to the link by adding this HTML code to the HEAD of your webpage:
For some reason, this hint has worked intermittently, lately - most notably it has been failing on the weekends.
User Agent Solution
After several hours of no joy I finally gave up trying to get it to work according to Facebook's API. To solve my problem, I placed a conditional surrounding the entire web page's body. When an incoming request's user agent contains the word facebook, I return a webpage with nothing other than the image. [The full Facebook user agent is "facebook share (http://facebook.com/sharer.php)", but just looking for the word facebook should be enough.] When the user agent in the request is anything other than facebook, I simply return the normal Epics3 webpage.
Problem solved (I hope).
On Twitter, the photo's caption is tweeted out with a link to the full size image. In the case of Facebook, though, just the caption is sent over using Facebook's API and it's posted on your wall as a link. Facebook had documented some hints which you can put into the web page's HTML so it can pick up a specific thumbnail of the image to post on your Facebook wall.
Bugs
Unfortunately, there is a Facebook bug, that pops up randomly, where the hints for finding the thumbnail image are ignored. This results in the first image on the webpage being posted to your wall. In the case of Epics3, as in most, this will result in the website's logo posted on your wall instead of the photo. Bad, bad, user experience. How could it work for months without a problem until recently?
click to enlargeDocumentation
Facebook's API documentation is notoriously horrible (on the other hand, Amazon Web Services documentation is the textbook case on how APIs should be documented).
After spending several hours tracking down this bug on the Internet, I concluded that no one had solved it. (I also doubt that it was well documented in a way that Facebook, Inc. can reproduce the problem). When searching for the bug I found many cases of users who had encountered the same problem with shrugged shoulders. After all, this is just HTML - there's no logic to debug.
Details
When you use Facebook's sharer.php button to post a link to your wall, Facebook's servers will take a quick look at the link and spider the webpage to find a suitable photo. You can tell Facebook exactly which photo to post next to the link by adding this HTML code to the HEAD of your webpage:
<link rel="image_src" href="http://example.com/thumbnail.jpg"/>
For some reason, this hint has worked intermittently, lately - most notably it has been failing on the weekends.
User Agent Solution
After several hours of no joy I finally gave up trying to get it to work according to Facebook's API. To solve my problem, I placed a conditional surrounding the entire web page's body. When an incoming request's user agent contains the word facebook, I return a webpage with nothing other than the image. [The full Facebook user agent is "facebook share (http://facebook.com/sharer.php)", but just looking for the word facebook should be enough.] When the user agent in the request is anything other than facebook, I simply return the normal Epics3 webpage.
Problem solved (I hope).
Tuesday, June 15, 2010
Apple's iPhone 4 Launch a Disaster

I started to write a post about the problems that I had, today, when I tried to pre-order the new iPhone 4 while stuck on a series of conference calls for a couple hours. Since I used to work at the Apple online store I can only imagine the stress and frustration going on inside that group.
I ended up sending the article to SDNN who ran it as today's feature story.
It was meant to be a timely, yet light article, but the person who posted the first comment took me too seriously. The article's comments are entertaining.
Also, note that the article's headline isn't meant to imply that this was Apple's fault (it wasn't) any more than the Louisiana Beaches a Disaster headline implies that the oil spill is Louisiana's fault.
6/16 Update: SDNN has asked me to write a follow up article when I pick up the phone, so stay tuned for that mini-adventure.
Sunday, June 13, 2010
AT&T Notifies Customers of Privacy Hack
Tonight, I received the following e-mail from AT&T's Chief Privacy Officer.
June 13, 2010
Dear Valued AT&T Customer,
Recently there was an issue that affected some of our customers with AT&T 3G service for iPad resulting in the release of their customer email addresses. I am writing to let you know that no other information was exposed and the matter has been resolved. We apologize for the incident and any inconvenience it may have caused. Rest assured, you can continue to use your AT&T 3G service on your iPad with confidence.
Here’s some additional detail:
On June 7 we learned that unauthorized computer “hackers” maliciously exploited a function designed to make your iPad log-in process faster by pre-populating an AT&T authentication page with the email address you used to register your iPad for 3G service. The self-described hackers wrote software code to randomly generate numbers that mimicked serial numbers of the AT&T SIM card for iPad – called the integrated circuit card identification (ICC-ID) – and repeatedly queried an AT&T web address. When a number generated by the hackers matched an actual ICC-ID, the authentication page log-in screen was returned to the hackers with the email address associated with the ICC-ID already populated on the log-in screen.
The hackers deliberately went to great efforts with a random program to extract possible ICC-IDs and capture customer email addresses. They then put together a list of these emails and distributed it for their own publicity.
As soon as we became aware of this situation, we took swift action to prevent any further unauthorized exposure of customer email addresses. Within hours, AT&T disabled the mechanism that automatically populated the email address. Now, the authentication page log-in screen requires the user to enter both their email address and their password.
I want to assure you that the email address and ICC-ID were the only information that was accessible. Your password, account information, the contents of your email, and any other personal information were never at risk. The hackers never had access to AT&T communications or data networks, or your iPad. AT&T 3G service for other mobile devices was not affected.
While the attack was limited to email address and ICC-ID data, we encourage you to be alert to scams that could attempt to use this information to obtain other data or send you unwanted email. You can learn more about phishing by visiting the AT&T website.
AT&T takes your privacy seriously and does not tolerate unauthorized access to its customers’ information or company websites. We will cooperate with law enforcement in any investigation of unauthorized system access and to prosecute violators to the fullest extent of the law.
AT&T acted quickly to protect your information – and we promise to keep working around the clock to keep your information safe. Thank you very much for your understanding, and for being an AT&T customer.
Sincerely,

Dorothy Attwood
Senior Vice President, Public Policy and Chief Privacy Officer for AT&T
June 13, 2010
Dear Valued AT&T Customer,
Recently there was an issue that affected some of our customers with AT&T 3G service for iPad resulting in the release of their customer email addresses. I am writing to let you know that no other information was exposed and the matter has been resolved. We apologize for the incident and any inconvenience it may have caused. Rest assured, you can continue to use your AT&T 3G service on your iPad with confidence.
Here’s some additional detail:
On June 7 we learned that unauthorized computer “hackers” maliciously exploited a function designed to make your iPad log-in process faster by pre-populating an AT&T authentication page with the email address you used to register your iPad for 3G service. The self-described hackers wrote software code to randomly generate numbers that mimicked serial numbers of the AT&T SIM card for iPad – called the integrated circuit card identification (ICC-ID) – and repeatedly queried an AT&T web address. When a number generated by the hackers matched an actual ICC-ID, the authentication page log-in screen was returned to the hackers with the email address associated with the ICC-ID already populated on the log-in screen.
The hackers deliberately went to great efforts with a random program to extract possible ICC-IDs and capture customer email addresses. They then put together a list of these emails and distributed it for their own publicity.
As soon as we became aware of this situation, we took swift action to prevent any further unauthorized exposure of customer email addresses. Within hours, AT&T disabled the mechanism that automatically populated the email address. Now, the authentication page log-in screen requires the user to enter both their email address and their password.
I want to assure you that the email address and ICC-ID were the only information that was accessible. Your password, account information, the contents of your email, and any other personal information were never at risk. The hackers never had access to AT&T communications or data networks, or your iPad. AT&T 3G service for other mobile devices was not affected.
While the attack was limited to email address and ICC-ID data, we encourage you to be alert to scams that could attempt to use this information to obtain other data or send you unwanted email. You can learn more about phishing by visiting the AT&T website.
AT&T takes your privacy seriously and does not tolerate unauthorized access to its customers’ information or company websites. We will cooperate with law enforcement in any investigation of unauthorized system access and to prosecute violators to the fullest extent of the law.
AT&T acted quickly to protect your information – and we promise to keep working around the clock to keep your information safe. Thank you very much for your understanding, and for being an AT&T customer.
Sincerely,

Dorothy Attwood
Senior Vice President, Public Policy and Chief Privacy Officer for AT&T
Handling CNAME Web Requests
I was recently playing around with DNS CNAME aliasing and I began to wonder how different sites handle an incoming request which has a different host header than the one that was expected.
Virtual Hosting
In the early days of the web (before the mid-1990s) it wasn't always possible to host multiple domains at the same IP address unless the web server supported virtual hosting. Virtual hosting allows a server at a single IP address to analyze the host header of each request to properly serve up the correct web page. This is a brilliant solution and Amazon's S3 web service makes excellent use of this technique so you can use your own domain name to serve up content from S3.
For example, here is a static webpage, hosted on Amazon's S3, but you'd never know where it's hosted by looking at the URL. One way to find out that this is hosted on S3 is to use the
CNAME to Another Website
This got me thinking, "What if I pointed my own host name at another website?" This would be less like framing another website (via an HTML frame or iframe) and more like hyperlinking to other's content.
So, I tried it out with three popular sites and each handles it differently.
CNN
http://news.joemoreno.com
CNN doesn't appear to look at the host name header for the incoming request and simply serves up its content. It seems that the only problem this presents is when content is served up via Flash such as ads and video. In other words, Flash ads and video are broken when the host name isn't cnn.com. Since the links on the CNN website are relative, the host name in the web browser doesn't change when clicking on other cnn.com links.
NY Times
http://nytimes.joemoreno.com
The NY Times also doesn't look at the host name of the incoming request to see if it's nytimes.com or www.nytimes.com. However, the NY Times uses absolute URLs on its website so clicking on any link clears out the previous host name and replaces it with www.nytimes.com.
Twitter
http://twitter.joemoreno.com
Twitter handles this issue perfectly. Their web server looks at the host name of the incoming request and, if it's not twitter.com, it returns a 301 redirect to twitter.com while keeping the rest of the request intact.
Legal Issues
I spoke with a couple attorneys who specialize in Internet law to see if this has ever been an issue. They were not aware of any cases where the CNAME aliasing was challenged in court. The most similar case was in 1997 when the Washington Post sued Total News, Inc. since the latter was framing the former's news content. However, a court decision was never reached since it was settled out of court a few months later.
Regardless of the lack of legal challenges, it's possible that a company would be concerned about brand dilution. However, the issues with HTML framing, CNAMES, etc. would most likely be solved by implementing a simple and inexpensive technical solution instead of suing.
Solution
Some companies might not like another website aliasing their website without explicit permission and others might not care. In practice, the deciding factor would be lost revenues or brand damage. Solving this problem is much like preventing someone from framing, deep-linking or hot-linking into your website. The solution is to look at the referrer of each web request and change it if it's not what it should be.
Conclusion
The benefits of aliasing another website, via a CNAME, without them knowing isn't clear. Although many sites will frame other's content without them knowing, the web site that's the target of the framing can simply break the frame with just a single line of JavaScript embedded in the page's HTML:
A very similar JavaScript could be written to simply look at the request's host name. If it's not the correct host name then reload the page with the correct host name (although I haven't tested this theory).
This observation is simply offered as a proof of concept.
Virtual Hosting
In the early days of the web (before the mid-1990s) it wasn't always possible to host multiple domains at the same IP address unless the web server supported virtual hosting. Virtual hosting allows a server at a single IP address to analyze the host header of each request to properly serve up the correct web page. This is a brilliant solution and Amazon's S3 web service makes excellent use of this technique so you can use your own domain name to serve up content from S3.
For example, here is a static webpage, hosted on Amazon's S3, but you'd never know where it's hosted by looking at the URL. One way to find out that this is hosted on S3 is to use the
dig or host command from the command line:
[jmoreno@ ~]$ host web.joemoreno.com
web.joemoreno.com is an alias for web.joemoreno.com.s3.amazonaws.com.
web.joemoreno.com.s3.amazonaws.com is an alias for s3-directional-w.amazonaws.com.
s3-directional-w.amazonaws.com is an alias for s3-2-w.amazonaws.com.
s3-2-w.amazonaws.com has address 207.171.185.131
CNAME to Another Website
This got me thinking, "What if I pointed my own host name at another website?" This would be less like framing another website (via an HTML frame or iframe) and more like hyperlinking to other's content.
So, I tried it out with three popular sites and each handles it differently.
CNN
http://news.joemoreno.com
CNN doesn't appear to look at the host name header for the incoming request and simply serves up its content. It seems that the only problem this presents is when content is served up via Flash such as ads and video. In other words, Flash ads and video are broken when the host name isn't cnn.com. Since the links on the CNN website are relative, the host name in the web browser doesn't change when clicking on other cnn.com links.
NY Times
http://nytimes.joemoreno.com
The NY Times also doesn't look at the host name of the incoming request to see if it's nytimes.com or www.nytimes.com. However, the NY Times uses absolute URLs on its website so clicking on any link clears out the previous host name and replaces it with www.nytimes.com.
http://twitter.joemoreno.com
Twitter handles this issue perfectly. Their web server looks at the host name of the incoming request and, if it's not twitter.com, it returns a 301 redirect to twitter.com while keeping the rest of the request intact.
Legal Issues
I spoke with a couple attorneys who specialize in Internet law to see if this has ever been an issue. They were not aware of any cases where the CNAME aliasing was challenged in court. The most similar case was in 1997 when the Washington Post sued Total News, Inc. since the latter was framing the former's news content. However, a court decision was never reached since it was settled out of court a few months later.
Regardless of the lack of legal challenges, it's possible that a company would be concerned about brand dilution. However, the issues with HTML framing, CNAMES, etc. would most likely be solved by implementing a simple and inexpensive technical solution instead of suing.
Solution
Some companies might not like another website aliasing their website without explicit permission and others might not care. In practice, the deciding factor would be lost revenues or brand damage. Solving this problem is much like preventing someone from framing, deep-linking or hot-linking into your website. The solution is to look at the referrer of each web request and change it if it's not what it should be.
Conclusion
The benefits of aliasing another website, via a CNAME, without them knowing isn't clear. Although many sites will frame other's content without them knowing, the web site that's the target of the framing can simply break the frame with just a single line of JavaScript embedded in the page's HTML:
<script type="text/javascript">
if (parent.frames.length > 0)
{ parent.location.href = location.href; }
</script>
A very similar JavaScript could be written to simply look at the request's host name. If it's not the correct host name then reload the page with the correct host name (although I haven't tested this theory).
This observation is simply offered as a proof of concept.
Labels:
Amazon Web Services,
Internet,
legal
Thursday, June 10, 2010
Short Sale Surprise

This afternoon my wife and I checked out a short sale in North Park (San Diego) that seemed too good to be true and we were pleasantly surprised. My experience with distressed home sales, like short sales or foreclosures, is that they are generally a "pit" (as today's real estate agent described it). Typical short sales have marked up walls and stained carpets, while most everything else is in a state of disrepair.
The only problem we noticed with the property we looked at today was the up-heaved sidewalk. Hopefully that doesn't affect the foundation.
Unfortunately, we learned the obvious lesson you'll encounter when a home is aggressively priced: multiple offers after being on the market for only a few days which usually leads to a bidding war.
Labels:
Life,
real estate
Subscribe to:
Posts (Atom)
