Alexander’s Blog

Privacy International (PI), a human rights research and campaign organization, prepared a report following a six-month investigation into the privacy practices of key Internet-based companies. The following companies were included in the study:

* Amazon
* AOL
* Apple
* BBC
* Bebo
* eBay
* Facebook
* Friendster
* Google
* Hi5
* Last.fm
* LinkedIn
* LiveJournal
* Microsoft
* Myspace
* Orkut
* Reunion.com
* Skype
* Wikipedia
* Windows Live Space
* Xanga
* Yahoo!
* YouTube

Based on the study, PI ranked Google at the bottom of the stack. Here are some highlights:
* “…throughout our research we have found numerous deficiencies and hostilities in Google’s approach to privacy that go well beyond those of other organizations.”
* “While a number of companies share some of these negative elements, none comes close to achieving status as an endemic threat to privacy.”
* “Google’s status in the ranking is also due to its aggressive use of invasive or potentially invasive technologies and techniques.”
* “…we have witnessed an attitude to privacy within Google that at its most blatant is hostile, and at its most benign is ambivalent.”
* “Google does not indicate how long the information collected through Google Toolbar is retained, nor does it offer users a data expungement option…”
* “Google fails to follow generally accepted privacy practices such as the OECD Privacy Guidelines and elements of EU data protection law.”
* “Google logs search queries in a manner that makes them personally identifiable but fails to provide users with the ability to edit or otherwise expunge records…”
* “Google fails to give users access to log information generated through their interaction with Google Maps, Google Video, Google Talk, Google Reader, Blogger and other services.”
* “Google has access to additional personal information, including hobbies, employment, address, and phone number, contained within user profiles in Orkut. Google often maintains these records even after a user has deleted his profile or removed information from Orkut.”

Here are brief excerpts from the report as to why Google and why not Microsoft.

Why Google?
We are aware that the decision to place Google at the bottom of the ranking is likely to be controversial, but throughout our research we have found numerous deficiencies and hostilities in Google’s approach to privacy that go well beyond those of other organizations. While a number of companies share some of these negative elements, none comes close to achieving status as an endemic threat to privacy. This is in part due to the diversity and specificity of Google’s product range and the ability of the company to share extracted data between these tools, and in part it is due to Google’s market dominance and the sheer size of its user base. Google’s status in the ranking is also due to its aggressive use of invasive or potentially invasive technologies and techniques.

The view that Google “opens up” information through a range of attractive and advanced tools does not exempt the company from demonstrating responsible leadership in privacy. Google’s increasing ability to deep-drill into the minutiae of a user’s life and lifestyle choices must in our view be coupled with well defined and mature user controls and an equally mature privacy outlook. Neither of these elements has been demonstrated. Rather, we have witnessed an attitude to privacy within Google that at its most blatant is hostile, and at its most benign is ambivalent. These dynamics do not pervade other major players such as Microsoft or eBay, both of which have made notable improvements to the corporate ethos on privacy issues.

Why not Microsoft?
The finding that Microsoft is a better privacy performer than Google is also likely to be contentious. Microsoft was awarded “orange” status, two bands better than Google’s position. However it is important, for the sake of clarity, to note that Windows Live Space received the more negative “red” rating, while Google’s Orkut avoided a black rating and was awarded red status.

The true difference between Google Inc and Microsoft Corp can be defined not so much by the data practices and privacy policies that exist between the two organizations, but by the corporate ethos and leadership exhibited by each. Five years ago Microsoft could reasonably be described as a fundamental danger to privacy. In more recent times the organization appears to have adopted a less antagonistic attitude to privacy, and has at least structurally adjusted to the challenge of creating a privacy-friendly environment.

The complete report called A Race to the Bottom: Privacy Ranking of Internet Service Companies is available here. You might also be interested in my article on privacy A Closer Look at the Fine Print in Privacy Statements.

Can’t edit a Web site on a 64-bit Windows Server 2003 using Microsoft Expression Web (EW)? Microsoft has replaced FrontPage with EW. Many administrators who were running FrontPage server extensions on 32-bit Windows Server 2003 and have now switched to 64-bit Windows Server 2003 are running into a problem when they try to setup their Web sites and edit it in FrontPage. Microsoft no longer supports FrontPage server extensions on a 64-bit Windows Server 2003 so you can’t use FrontPage to edit Web sites on a 64-bit Windows Server.

Well, here are 3 basic steps that you need to take to edit a Web site using EW on a 64-bit Windows Server 2003.

1. In IIS 6.0, go to the Properties of the Web site and make sure that on the Directory Security tab both Anonymous users and Integrated Authentication is selected.
2. On the Home Directory tab, check the boxes for Read, Write, and Directory Browsing. This is required for WebDAV.
3. In IIS Manager, under Web Service Extensions, enable WebDAV extension.

You should now be able to edit your site with an account that has appropriate permissions.

On May 10, I discussed a problem with opening Internet Explorer. Microsoft has posted a KB article that discusses the possible solution. Microsoft has confirmed that the problem is caused by the May 2007 Cumulative Security Update for Internet Explorer (MS07-027), as reported by several MVPs.

Problem: The problem is caused if you have the Temporary Internet Files (TIF) moved to a location outside the Users folder hierarchy while you have the Protected Mode and the Phishing filter enabled.

Solution: The solution is either to move the TIF back to its original location or to configure permissions for TIF folder as described below. If you move TIF folder out of Users folder hierarchy, e.g. to the root of drive C, then you would have to give the user full-control permission at the root of drive C, which may not be a good idea. For security reasons, a better option is to move the TIF folder back to it’s original location within the user’s profile while Microsoft investigates other possible solutions for this issue.

The following procedure is for modifying permission on Windows Vista computers. Make sure you understand the consequences of this procedure before you implement it.

1. Click Start Start button, type Internet Options in the Start Search box, and then click Internet Options in the Programs list.
2. On the General tab, click Settings in the Browsing History area.
3. Click View Files. The “Temporary Internet Files” folder opens.
4. In the Windows Explorer address box, click the folder name that comes before Temporary Internet Files.
5. Click Organize, and then click Properties.
6. On the Security tab, click Edit.
7. In the Group or user names box, click the name of the affected user. If the name of the affected user is not listed, follow these steps:

a. Click Add.
b. In the Enter the object names to select box, type the name of the affected user, and then click OK.
c. In the Group or user names box, click the name of the affected user.

8. In the Permissions for User_Name box, click to select the Full Control Allow check box.
9. Click Apply, and then click OK.
10. Close Windows Explorer.
11. Click OK two times.
12. Start Internet Explorer 7.

On a Windows XP-based computer or on a Windows Server 2003-based computer, follow these steps:

1. Click Start, click Run, type inetcpl.cpl, and then click OK.
2. On the General tab, click Settings in the Browsing History area.
3. Click View Files.
4. In Windows Explorer, move to the folder that contains the “Temporary Internet Files” folder.
5. In the right-pane, right-click an empty area, and then click Properties.
6. On the Security tab, click the name of the affected user in the Group or user names box. If the name of the affected user is not listed, follow these steps:
a. Click Add.
b. In the Enter the object names to select box, type the name of the affected user, and then click OK.
c. In the Group or user names box, click the name of the affected user.
7. In the Permissions for User_Name box, click to select the Full Control Allow check box.
8. Click Apply, and then click OK.
9. Close Windows Explorer.
10. Click OK two times.
11. Start Internet Explorer 7.

For more information, check out the KB article 937409.

The Strider HoneyMonkey Exploit Detection System, as the research project is code-named, was created to help detect attacks that use Web servers to exploit unpatched browser vulnerabilities and install malware on the PCs of unsuspecting users. Such attacks have become one of the most vexing issues confronting Internet security experts.

A traditional method of inspecting attacks against computers has been to provide a “honeypot” server on the Internet. Such servers are intended to provide information about attackers by presenting themselves as targets.

Manual analyses of exploit sites often provide useful, detailed information about which vulnerabilities are exploited and which malware programs are installed. But such analyses do not provide a big-picture view of the problem.

The Strider HoneyMonkey project takes the static concept of a honeypot in a new direction. A “honeymonkey” is a computer or a virtual PC that actively mimics the actions of a user surfing the Web. A series of “monkey programs”, which drive a browser in a manner similar to that of a human user, run on virtual machines in order to detect exploit sites. The browsers can be configured to run with fully updated software, or without specific updates in order to look for exploit sites that target specific vulnerabilities. In this manner, the attacks more likely to impact customers can be analyzed and detected.

At each Web site identified by Strider HoneyMonkey, however, follow-up work is required to identify what kind of exploit exists and how it operates. And much more work is needed to verify and understand the exploit vector. Click here for more information.

Recently, I was installing Microsoft Office SharePoint Server 2007 Beta 2 on Windows Server 2003 running on my Virtual PC. I installed .NET Framework 2.0, Internet Information Services (IIS) 6.0, Windows Workflow Foundation Beta 2 and then added the ASP.NET 2.0 service extension in IIS 6.0. When I ran the setup.exe I received the following error “This product requires ASP.Net web service extensions to be enabled in Internet Information Services (IIS). Enable this setting and re-run setup.”

I verified that the ASP.NET 2.0 extension was enabled but still received the same error. The .NET Framework 2.0 didn’t give me the option to repair in Add or Remove Programs in Control Panel (similar to the one that’s available for Workflow Foundation shown below).

I knew that the ASP.NET was not properly registered because the General tab showed that the extension was not used by the ASP.NET v2.0.50727 as expected, instead it showed “unknown”, as shown in the following screen shot.

Rather than reinstalling the .NET Framework, I decided to register ASP.NET by using the following command at the command prompt. I made sure that I was in the folder where aspnet_regiis was located.

aspnet_regiis -i

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>aspnet_regiis -i
Start installing ASP.NET (2.0.50727).
……………………………..
Finished installing ASP.NET (2.0.50727).

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727>

When I ran the SharePoint Server setup it failed again. I ran “aspnet_regiis -i” one more time, restarted the IIS Admin service and noticed that the ASP.NET was now being used by v2.0.50727. I ran the SharePoint Server setup again and it finally worked. If you’ve run into a similar situation, hopefully this will help solve your problem.