ZipDisable

IIS 6.0's auto-compression feature is driving me nuts.  For some reason, my RSS files are being served compressed even when client didn't ask for it via HTTP Content-Encoding header.  I even got Port80's ZipEnable to disable compression just for RSS files but that didn't work consistently so I just disabled compression for all static contents.  Maybe Port80 should have named their product ZipDisable.

Update:

Eeek.  Even disabling compression for everything via ZipEnable doesn't work.  Looks like it's time to explore the IIS 6.0 registry settings.

Secure UI: User Participation

One often overlooked area of security industry is user participation, the role users play in a security system.  Geeks are so obsessed with technology that there is a valuable resource already assigned to each account: the user.  Users are not only free but also highly motivated.  After all, it's their account that they are watching over.

The problem is that today's security systems do not provide enough tools and information to the users.

When users log into a system, they usually receive almost no feedback beyond seeing the protected resource.  With web pages, all they get is a lock at the bottom of the browser and a sign-out button.  All that let's the users know is where they are and where the exit is.  It doesn't tell them whether someone broke into their account last night.  They wouldn't even know if an intruder is standing right next to them.  WTF.

Technologies that help users play a bigger role in security is an area that is still wide open IMHO.  There are already some patent activities in area, including one I recently filed for a client, but that is just a drop in a bucket.  For example, blogging technology like trackback can be applied to this area by helping users become more aware of activities happening around them.

Effectiveness of most security technologies depend heavily on the effectiveness of the user interface.  Unfortunately, there just aren't many engineer with deep experiences in both areas.  If you are a security expert, you should be thinking as much about the users as the hackers.  Helping them become more aware of what is going on and making it easy for them to take actions will lead to more secure systems.

Update:

A reader asked me to explain what my patent is about because he didn't want to wade through all the exasperating mixture of geektalk and legalese.  Quite understandable.  I don't like reading or writing patents myself so some other poor guy had to write it based on a few hours of my handwaving.

Imagine yourself living in a log cabin somewhere high up in the mountains where it snows all the time.  You wake up in the morning and take a walk around the cabin.  If nothing came by while you were sleeping, you will just see your footprints in the snow.  If something did, you will notice right away.

The patent is about visual methods (sorry) to do the same for users signing into secure system either during or after signing in or at the point of transaction.  You can even print it out on credit card invoice so I can be assured that no one but I used that particular credit card in the past week.  It is similar to the 'last time you logged in' message you get when you log into a Unix system except the visuals are designed to present higher density of information effectively like the way Edward Tafte's Sparklines does.

Secure UI: Dark Side of Brand Power

Impact of powerful brands on our minds is stronger than most people realize because it hits us below the belt, at the subconscious level.  It swoops under your flailing arms of reason and strikes hard, leaving long lasting bruises of wanting and trusting.  Those bruises are weak spots hackers will attack to knock you down.

Enough with words.  Click on some of the links below to experience the impact of powerful brand images.  They are links to phishing parody pages.  To experience the impact fully, try to observe the effect of the brand image on each page.  Note that you already know that these pages are fake cockeyed pages.

I think protecting brand images from being abused at the browser level make sense even if strapping DRM technologies into IE or Safari might seem distasteful to some of us.

Too Much Synergy

I like much of ongoing Microsft's .NET-based push, but I think they are going too far with respect to Microsoft SQL Server.  For example, BizTalk Server 2004 requires it.  Across the board, arrows points to Microsoft SQL Server as if it was Rome and I see it just getting worse with Yukon and it's special brand of XML features.  Let up, I say.

Phishing or Spamming?

I just got a HTML e-mail from email.bankofamerica1.com (notice the '1') asking me to sign-in at:

http://links.bankofamerica1.com:8082/Click?
q=c2-oXxLQUEyqThpeyRgVnmX3Fn0xOFR&a=1

Clicking on the link will peg me as a potential Bank of America customer, but I was curious to see if there was a phishing page at the other end so I went ahead and ended up at the real Bank of America login page.  Hmm.  Curious.

This is what their WHOIS record say:

Registrant:
Bank of America Corporation
1201 Main Street, 12th Floor
TX1-609-12-15
Dallas, TX 75202
US

Checking Google, I found that the domain name is on several spammer blacklists.

All this leaves me wondering whether these guys are crooks or just a corporate vehicle for spamming.  Fish or spam makes a terrible menu.

BTW, I am now receiving at least one genuine phishing e-mail everyday.  For me, at least, they are proving to be a good source of entertainment.

Atomizing RSS

Dave is making another effort to pull RSS and Atom together with an outline of a proposal that differs from past attempts including mine (see Making Atom Happen and Atom-Syntax Sin Tax).  These are the bulletpoints of his proposal:

1. The format would differ from RSS 2.0 as little as possible.

2. It would have the great spec that the Atom people are promising. A great validator, and lots of support from developers who evangelize the format. There wouldn't be many flames because everyone would be getting most of what they want.

3. It would be managed by an IETF working group that would be open to anyone who wants to participate, not just me, or Sam Ruby or Blogger and Movable Type, but anyone who wants to make the effort to contribute to furthering the art of syndication technology.

4. It would be backward compatible with RSS 2.0, so that any 2.0 feed could become an RSS/Atom feed by changing (fill in the blank, as little change as possible).

5. The top level item in the feed would be called rssAtom. It's a problem for at least one aggregator that the top level item in Atom is called "feed" — not such a problem today, but later when another format comes along that also calls its top level item "feed." Formats in general should use a distinctive name for their top-level element. (Prior art: HTML, RSS, SOAP, RDF.)

In essence, he is suggesting a common format that is backward compatible with RSS 2.0 at the data model level instead of the syntax level.  I like the proposal and sincerely hope it works out, but engineers are notoriously bad at finding the reverse gear…

Secure UI: Site Seals

In How Not to Get Hooked by a 'Phishing' Scam, the FTC offers this guidance:

Before submitting financial information through a Web site, look for the "lock" icon on the browser's status bar. It signals that your information is secure during transmission.

Unfortunately, credibility of the "lock" icon is questionable (via Payments News).  Arguably, the "lock" icon is even harmful because, as users come to depend on it presence, they become more vulnerable when it's spoofed.

Trust is a double-edged sword.

With the "lock" icon undersiege, e-commerce companies are looking at other types of protections such as VeriSign Secure Site Seal and GeoTrust True Site which work by including a javascript fragment from a site seal server which inlines a site-specific image or an animation like the ones below.

    

Since these javascript fragments are executed inside the target page, they can examine domain the page was served from, ensure that they are being served from an approved site, and prominently display an attractive site-specific image that offer assures the users visually.  The image can also be click-on to display information about the SSL certificate used in the HTTPS session.

Do these services offer any real protection?  No.  Because they rely so heavily on the visual, they are wide open to Visual Spoofing.  Both the 'seal' image and the popup can be spoofed with a notepad and an image editor.  Clever tricks inside the included javascript fragment are useless because they are not included.

IMHO, they are more dangerous than the "lock" icon because they loudly invite the users to trust and depend on presence of images which can be easily spoofed.  The main problem is that those images are site-specific which appears to offer more protection than the generic "lock" icon.  But since hackers typically engineer site-specific phishing attacks, the appearance of improved protection turns into a liability that invites the hacker to leverage to their advantage.

I will post about possible ways to implement site seals with anti-phishing features in the near future.  Meanwhile, be sure to read my other posts on the subject of secure UI.