Friday, September 23, 2005

Battling Google, Microsoft Changes How It Builds Software (Wallstreet Journal)

Quoted from (Wallstreet Journal)

Code Red
Battling Google, Microsoft
Changes How It Builds Software

Delay in New Windows Version Drove Giant to Develop Simpler, Flexible Product
Engineers Get Trip to 'Bug Jail'

By ROBERT A. GUTH
Staff Reporter of THE WALL STREET JOURNAL
September 23, 2005; Page A1

REDMOND, Wash. -- Jim Allchin, a senior Microsoft Corp. executive, walked into Bill Gates's office here one day in July last year to deliver a bombshell about the next generation of Microsoft Windows.

"It's not going to work," Mr. Allchin says he told the Microsoft chairman. The new version, code-named Longhorn, was so complex its writers would never be able to make it run properly.


The news got even worse: Longhorn was irredeemable because Microsoft engineers were building it just as they had always built software. Throughout its history, Microsoft had let thousands of programmers each produce their own piece of computer code, then stitched it together into one sprawling program. Now, Mr. Allchin argued, the jig was up. Microsoft needed to start over.

Mr. Gates resisted at first, pushing for Mr. Allchin's group to take more time until everything worked. Over the next few months, Mr. Allchin and his deputies would also face protests from programmers who complained he was trying to impose bureaucracy and rob Microsoft of its creativity.

"There was some angst by everybody," says Mr. Gates of the period. "It's obviously my role to ask people, 'Hey, let's not throw things out we shouldn't throw out. Let's keep things in that we can keep in.' "

Ultimately, Mr. Allchin's warning proved cathartic and led to what he and others call a transformation in Microsoft's most important product. A key reason: the growing threat from rivals such as Google Inc., Apple Computer Inc. and makers of the free Linux operating system. In recent years these companies have been dashing out some software innovations faster than Microsoft. Google has grown particularly effective at introducing new programs such as email and instant messaging over the Internet, watching how they perform and regularly replacing them with improved versions.

Microsoft's Windows can't entirely replicate that approach, since the software is by its nature a massive program overseeing all of a computer's functions. But Microsoft is now racing to move in that direction: developing a solid core for Windows onto which new features can be added one by one over time.


As always, Microsoft's great fear is that it will lose its near-monopoly on computer operating systems and basic office software. In the short term, there is little danger of that. But the more Google and other software makers encroach on Microsoft's turf, the greater the chance that someday computer users will wake up and find Microsoft Windows superfluous.

"What happened when the American car companies failed to update their manufacturing lines? There was a more efficient way to bring cars to market for a lower price and they lost their market," says Microsoft Vice President Chris Jones. "We're in a little bit of a different industry but it's the same thing."

Microsoft's holy grail is a system that cranks out a new, generally bug-free version of basic Windows every few years, with frequent updates in between to add enhancements or match a competitor's offering.

The Longhorn crisis helps explain the sweeping restructuring that Microsoft Chief Executive Steve Ballmer announced this week to organize the company into three major business units. A key goal is to force Microsoft to be more nimble in producing and delivering software.

Mr. Allchin's reforms address a problem dating to Microsoft's beginnings. Old-school computer science called for methodical coding practices to ensure that the large computers used by banks, governments and scientists wouldn't break. But as personal computers took off in the 1980s, companies like Microsoft didn't have time for that. PC users wanted cool and useful features quickly. They tolerated -- or didn't notice -- the bugs riddling the software. Problems could always be patched over. With each patch and enhancement, it became harder to strap new features onto the software since new code could affect everything else in unpredictable ways.

The 53-year-old Mr. Allchin, who joined Microsoft in 1990 and is now co-head of the Platform Products and Services Division, says he always disdained the fast-and-loose culture of PC software. The holder of a doctorate in computer science, Mr. Allchin craved discipline in code writing. But in the booming 1990s, when it seemed Microsoft could do no wrong, there was little Mr. Allchin could do. As soon as Microsoft was done with one version it pushed on to the next. Mr. Allchin was haunted by what he calls his "little demons."

In 2001 Microsoft made a documentary film celebrating the creation of Windows XP, which remains the latest full update of Windows. When Mr. Allchin previewed the film, it confirmed some of his misgivings about the Windows culture. He saw the eleventh-hour heroics needed to finish the product and get it to customers. Mr. Allchin ordered the film to be burned.

When the Longhorn project to build an XP successor got started, teams of engineers set off to develop it as they always had. Mr. Gates was especially eager for them to add a fundamental change to Windows called WinFS that would let PC users search and organize information better. One goal was to let users scour their entire computer for work they had done on a subject without needing to go through every individual program or document.

Mr. Allchin says he soon saw his fears realized. In making large software programs engineers regularly bring together all the new unfinished features into a single "build," a sort of prototype used to test how the features work together. Ideally, engineers make a fresh build every night, fix any bugs and go back to refining their features the next day. But with 4,000 engineers writing code each day, testing the build became a Sisyphean task. When a bug popped up, trouble-shooters would often have to manually search through thousands of lines of code to find the problem.

Mr. Gates's WinFS project was so troublesome that engineers began talking about whether they could make the "pig fly." Images of pigs with wings started appearing in presentations and offices.

And Microsoft's culture was facing a new threat. The mass of patches and agglomerations that made up Windows turned it into an easy target for viruses and other Web-based attacks. Mr. Allchin had to divert top engineers into the effort to fix security problems in existing versions of Windows. "The ship was just crashing to the ground," Mr. Allchin says.

In late 2003, Mr. Allchin called on the help of two men. The first was one of Microsoft's best-known "shippers," people known for their ability to turn around troubled software projects. Windows veteran Brian Valentine had a reputation for booming motivational speeches, beer bashes and stunts like showing up to work functions as Elvis, the Easter Bunny or even once a hula girl with a coconut bra.

The second man Mr. Allchin tapped was Amitabh Srivastava, now 49, a fellow purist among computer scientists. A newcomer to the Windows group, Mr. Srivastava had his team draw up a map of how Windows' pieces fit together. It was 8 feet tall and 11 feet wide and looked like a haphazard train map with hundreds of tracks crisscrossing each other.


That was just the opposite of how Microsoft's new rivals worked. Google and others developed test versions of software and shipped them over the Internet. The best of the programs from rivals were like Lego blocks -- they had a single function and were designed to be connected onto a larger whole. Google and even Microsoft's own MSN online unit could quickly respond to changes in the way people used their PCs and the Web by adding incremental improvements.

In April 2004, Google, seemingly out of nowhere, introduced its Gmail service, competing with Microsoft's Hotmail program. Tiny Internet browser maker Mozilla Foundation beat Microsoft to market with browser features planned for Longhorn.

Most alarming: By July 2004, it became clear that Google was working on a "desktop search" tool for finding information on a PC -- offering some of the features that Mr. Gates's WinFS program was supposed to bring to Longhorn. Google, previously focused exclusively on the Internet, was now stepping onto Microsoft's turf as the creator of software inside the PC.

While Windows itself couldn't be a single module -- it had too many functions for that -- it could be designed so that Microsoft could easily plug in or pull out new features without disrupting the whole system. That was a cornerstone of a plan Messrs. Srivastava and Valentine proposed to their boss, Mr. Allchin. Microsoft would have to throw out years of computer code in Longhorn and start out with a fresh base. It would set up computers to automatically reject bug-laden code. The new Longhorn would have to be simple. It would leave bells and whistles for later -- including Mr. Gates's WinFS, Messrs. Srivastava and Allchin say.

Mr. Allchin signed on to the plan and broke the news to Messrs. Gates and Ballmer. Mr. Allchin remembers that Mr. Gates pushed him to keep going with the original version of Longhorn, saying if the software writers needed more time Microsoft could ship a scaled-down version in the interim. The executives agreed to reserve a final decision until Mr. Ballmer returned from a business trip, according to Mr. Allchin and Mr. Valentine, who was also present.

Over the next few weeks, Mr. Gates expressed frustration. At one meeting on Aug. 17, he berated Longhorn engineers for the mess, say people familiar with the meeting. (Mr. Gates says he doesn't remember it.) Afterward, Mr. Srivastava says he called his team together, acknowledging that he had underestimated the scope of the challenge they faced in fixing Longhorn, though he was heartened by the group's apparent willingness to change.

As Microsoft's chief software architect, Mr. Gates says that his role is "almost paradoxical" because he has to push for innovation while being the "ultimate realist" when problems arise on that quest. In this case, he says he and Mr. Ballmer needed to make sure that the recommendations from Mr. Allchin's group were sound.

On Aug. 27, 2004, Microsoft said it would ship Longhorn in the second half of 2006 -- at least a year late -- and that Mr. Gates's WinFS advance wouldn't be part of the system. The day before in Microsoft's auditorium, Mr. Allchin had announced to hundreds of Windows engineers that they would "reset" Longhorn using a clean base of code that had been developed for a version of Windows on corporate server computers.

As he started to learn more about Mr. Srivastava's broader plan, Mr. Gates was concerned that the unproven tools for keeping the Windows core clean would levy a "tax" on engineers -- in other words, that they would spend so much time trying to meet Mr. Srivastava's standards that they wouldn't be able to devise innovations for Windows users. At a meeting on Sept. 8, Mr. Srivastava's team was walking Mr. Gates through the plan when he challenged them. Why, he wondered, weren't the reformers asking the mass of Windows engineers for their view of the changes?

"It was all just, 'Hey, bless this process,' which I was unwilling to do," Mr. Gates says. "They're just talking about process and I'm frustrated we're not talking about how the teams are responding to it."

By late October, Mr. Srivastava's team was beginning to automate the testing that had historically been done by hand. If a feature had too many bugs, software "gates" rejected it from being used in Longhorn. If engineers had too many outstanding bugs they were tossed in "bug jail" and banned from writing new code. The goal, he says, was to get engineers to "do it right the first time."

Recognizing Mr. Gates's concerns over the impact on programmers, Mr. Srivastava hit on a plan to win their hearts and minds. On Nov. 5, he visited the computer-filled office of Dave Cutler, a revered elder statesman among Windows engineers and a stickler for good code writing. Would he publicly throw his weight behind the new approach? Mr. Srivastava asked.

On Dec. 1, Mr. Srivastava escorted Mr. Cutler to Microsoft's auditorium where the software guru told 1,000 engineers that he had used the tools to build Windows code that was nearly bug-free. That Mr. Cutler -- famous for never attending meetings -- would emerge to back Mr. Allchin's revolution helped persuade some engineers to drop their objections.

Others weren't so easily convinced. Responding to an attendee questioning the merits of the new regime, Mr. Valentine, the enforcer, shot back, "Is your code perfect? Are you perfect? If not, you should shut up and support this effort," according to one of his team members, G.S. Rana. (Mr. Valentine says he doesn't remember the remarks but doesn't dispute Mr. Rana's recollection.)

As engineers began cooperating and Mr. Srivastava's team worked overtime to refine the tools, the quality of the code flowing into Longhorn began to improve. The time to create a new "build" fell to just a few days, allowing a faster cycle of writing and testing new code. After the Windows group was able to install a workable version of the system on their PCs four days before Christmas, Mr. Srivastava says the group celebrated by not working over the holidays.

Not everything went so quickly, as engineers grappled with the challenge of making Longhorn more like Lego blocks. Microsoft missed its June deadline for the first "beta" or test version of Longhorn. On the Fourth of July Mr. Srivastava monitored the progress on his wireless laptop, set up next to his grill as he cooked veggie burgers and teriyaki chicken for family guests. Mr. Srivastava was so preoccupied with Longhorn that he inadvertently agreed to his wife's plan to remodel their bedroom. He recalls that when he protested, she joked, "You got the Windows job. I get this. It's a small price to pay."

On July 27, Microsoft shipped the beta of Longhorn -- now named Windows Vista -- to 500,000 customers for testing. Experience had told the Windows team to expect tens of thousands of reported problems from customers. Instead, there were a couple thousand problem reports, says Mr. Rana, the team member.

And last month, Microsoft delivered a test version of Mr. Gates's WinFS idea -- not as a part of Longhorn but as a planned add-on feature. Microsoft this month said it would issue monthly test versions of Windows Vista, a first for the company and a sign of the group's improved agility.

It could take years before Windows can be as flexible as Microsoft needs it to be to pump out new features quickly. But the cultural shift is in swing. Hours after showing off Windows Vista to software makers this month, Mr. Gates in an interview noted how Microsoft's Office group is now using some of Mr. Srivastava's tools to improve its code. "It's amazing the invention those guys have brought forward," he said. "I wish we'd done it earlier."

This week Mr. Allchin announced that as part of the restructuring he will retire next year after Windows Vista is in customers' hands. In a recent interview he said his demons aren't fully exorcised. "There're weaknesses in everything we're doing today," Mr. Allchin says. "But it's such a huge step up from where we were."


Thursday, September 22, 2005

Intersting reading. Google SecureAccess Trojan/Spyware "Conversation in Full-Disclosure"

Hi,
Maybe the frivolous way in which I addressed this problem lead people to believe I am not to be taken seriously. I would suggest you do not judge the book by its cover. Allow me to explain my point of view in more detail: 1. You are not securing your information, you are putting all your eggs in one basket.2. I am not disputing the _reasons_ they may have to gather information or _what_ information the gather, I am merely pointing out that the problem is the _fact_ that they do so. Google Secure Access misleads their users by implying that _no-one_ will get to see anything of what you send to and receive from the Internet if you use their service. But if you read their privacy policy, you will find out that they are tracking this information themselves. A good deal of the services offered by Google are provided so Google can track how you use them. This is an exchange of services, you supply Google with your usage data and Google supplies you with whatever service you request. You may not pay for these services with money, but you do pay for them with information. Google uses this information to make money. I assumed this was common knowledge. Google may do whatever they see fit with this information within the boundaries of the law. The law binds Google to uphold the privacy policy. The privacy policy allows Google to do whatever they want if they so see fit by thinking up a good reason to do so. I am not saying they will, I am saying they can. Mr Boily:I did selectively quote parts of the privacy policy; I only quoted those parts that were relevant to my argument. Again, my argument is about the _fact_ that they collect data, not _what_ they collect nor the _reasons_ they may have for doing so. I also supplied the link to the policy so anyone can read the full version. We seem to use a different definition of spyware. This has happened before on this list. If you Google the definition, you will find everybody has their own. In my previous email and this I am using these definitions:"spyware" - Any software program that monitors a persons actions without his or her knowledge"trojan" - Any software program that presents itself to its users as something useful but, unknown to its user, also performs another action for its creators. If you agree to these definitions, you must see that Google Secure Access is both a trojan and spyware. Cheers,SkyLined

Re:
Dear Ass-Clown (aka, skyline): You have seriously mis-interpreted the privacy policy. Considering that most such documents are written in legalese and are similar to EULAs rather than a list of how the information collected is used, it is normal to be skeptical about published privacy policies. >> 1. "Google may log some information from your web page requests ..." In Full:Google may log some information from your web page requests as may the websites that you visit. We do this to understand how Google Secure Access is being used and to improve our services. Google Secure Access does not log cookies and strips potentially sensitive query data from the end of requests to help better protect your privacy. This roughly translates into 'If you use our service, we are going to track how you use it, and ensure that you are not exposing us to serious liability.'. Hmm.. sounds like any standard business practice, at least for any that plans to be more than a mom & pop. >> 2. "Google also logs a small set of non-personally identifiable information ..." In Full:Google also logs a small set of non-personally identifiable information -- such as routing information, session durations and operating system and Google Secure Access client version numbers -- in order to create your Google Secure Access connection, understand how people are using Google Secure Access and help us maintain the Google Secure Access client. Hey Hey!! Good job skippy, you succeeded in snipping out the part that indicates that the information that is gathered is information that any good service provider tracks! Wow! Do you have a cell phone? Or a land-line? Or an internet service provider? Jackass. They all track this type of information so they can figure out wonderful things like technical support requirements, load management, and a number of other good things. >> 3. "Google will not sell or provide personally identifiable information to any third parties except ..." In Full:Google will not sell or provide personally identifiable information to any third parties except under the limited circumstances described in the Google Privacy Policy . And From the Privacy Policy... actually, too long to summarize nicely. But in short, unless they have your consent they will not share information they collect about you, except to business partners who provide information processing services (in which case they are legally bound to protect and preserve that informtion), and except in cases where they have a legal obligation (HELLO Patriot Act!) etc... In other words, they will keep your information private unless you give them permission, and will only share information with business partners. Hmm, this sounds like a similar practice to what most banks do, except that the banks will sell your information! These business practices are very common, and virtually all businesses take on these sorts of practices. >> 4. "... we may for a limited period of time preserve additional internet traffic or other information." In Full:If Google concludes that we are required by law or have a good faith belief that collection, preservation or disclosure of additional information is reasonably necessary to protect the rights, property or safety of Google, our users or the public, such as if we believe the Google Secure Access service is being abused, we may for a limited period of time preserve additional internet traffic or other information. In other words, if you attack our systems, or our users, or break the law, or any number of other things that may trigger our IDS or IPS then we may track other information, and oh, by the way, if we are required to collect information by law, we will comply. In other words, we will protect our systems even though we are giving you free access. Before you go off FREAKING out you might want to consider a few things, first: 1. This is a free, publicly available service. Without monitoring liablities to the service it would quickly become another example of a failed, free, publicly available service.2. Google owns the network and therefore bears liability if someone uses the network for illegal purposes.3. Google offers this service, not rams it down your throat.4. Google offers uninstallers, and does not inject its software into other processes, nor to my knowledge, does it run multiple processes that share locks so that it can re-launch itself, and prevent deletion of core files. These are all traits of spyware. 5. Google has a strong history of balancing advertising capabilities and privacy. Although they are an advertising company and make money off of context-based advertising, they have done a good job of not hoovering information from peoples computers and selling it to the lowest bidder. If you don't like the idea of the service, or you want to convince others, then try writing something worth reading rather than an adolescent sounding rant about how the MAN is going to invade your privacy, and steal your precious session durations and client version information. Either that or apply for a job with Minitrue, also known as CNN. Your style of "reporting" is strongly appreciated in those circles.
Re:Re
Seriously, Yvan. You really don't know who it is you're talking to. That is Mr. Berand-Jan Wever, creater of all that is more 1337 than you. If you and him are debating about issues pertaining to hacking, more often than not he will be right. I have never ever heard of you. What's the last security advisory that YOU have come out with? I'm sorry, but before you can go calling someone as 1337 as Skylined an "Ass-Clown", you need to build up some credibility for yourself. Until then, good-day sir. Not to mention as Microsoft becomes better at everything it does and becomes righteous, Google is turning into the new Microsoft. Google has become all monopolistic and shit. 75% of website referrals come from google. They are all cocky and think they can get away with everything, just like Microsoft used to be. Fight the power!!!!

Regards,PaulGreyhats Securityhttp://greyhatsecurity.org/


Re:Re:Re
On 9/21/05, Paul Nickerson <pvnick@gmail.com> wrote:Seriously, Yvan. You really don't know who it is you're talking to. That is Mr. Berand-Jan Wever, creater of all that is more 1337 than you. If you and him are debating about issues pertaining to hacking, more often than not he will be right. Considering the radical mis-representation of the Google policy, advisories or not, I refuse to respect the opinion of someone who practices such fine-grained 'clipping' of relevant information when raising an issue. Unless, of course, you expect me to start telling someone that everything is a security hole just because Well-Known-Expert says it is an issue. It is a simple philosophy; when you receive a piece of information that you would like to use as a foundation, then verificy its authenticity, then verify its accuracy. This is why I when I read a report about a vulnerability I will verify the accuracy of the report it before I start advising people to react to them.
I have never ever heard of you. What's the last security advisory that YOU have come out with? None. Congrats. Woohoo. I guess you win, after all, since you have never heard of me. That is a fantastically well-founded argument. I mean, really, you must know *EVERYONE*. Honestly though, I respect that you have never heard of me, but don't judge the posts by reputation, judge them by the details in the post. Wever may have an interesting perspective, but it is based on a limited interpretation of the policies he cited; I submit that this limited interpretation is strongly supported by the fact that in many instances where he cites material from the original, he cites only the components that support his argument, and ignores the components which damage it.
I'm sorry, but before you can go calling someone as 1337 as Skylined an "Ass-Clown", you need to build up some credibility for yourself. Until then, good-day sir. Good-day to you. That is why this list has such an interesting character. At least give me some credit for doing it with my real name instead of hiding behind a pseudonym like many other critics who post to this list :)
Not to mention as Microsoft becomes better at everything it does and becomes righteous, Google is turning into the new Microsoft. Whoa. I guess Microsoft is getting better at security management, and given the horrors of running Microsoft products on the perimeter in the past, well, one can say it is getting better. But still, whoa. Microsoft still has a long way to go before the majority of the community will trust them, given their history. That said, I think the security team over there is doing alot of good work given the challenges they face.
Google has become all monopolistic and shit. 75% of website referrals come from google. They are all cocky and think they can get away with everything, just like Microsoft used to be. Fight the power!!!! 'Used to be', last time I checked Microsoft still behaves like they can get away with anything, but they at least are projecting the impression that they are changing. And yes, Google is becoming more monopolistic, and behaving more like Microsoft. Microsoft, for all of its faults, is a very successful business. Just like any other leader in their field, Google is adopting many of the practices that will allow it to remain that way. At least Google has (thus far) refrained from spamming me horribly with print and email materials when I sign up for services, and they give away many services that I enjoy [search, google earth,.. oh and email :)] I don't blindly trust, but I certainly won't start jumping at shadows because a company that delivers free services that invite serious potential liabilities publish documents with the verbiage required to protect themselves.


Re:Re:Re:Re

Actually Paul, I decided to repost to address one of the things you said.
I have never ever heard of you. What's the last security advisory that YOU have come out with? I'm sorry, but before you can go calling someone as 1337 as Skylined an "Ass-Clown", you need to build up some credibility for yourself. Until then, good-day sir. Because of people like Wevers I don't release any of the research I do to the public because when I have identified vulnerabilities in applications I review because I know that some consultant somewhere will use it as a reason to bilk a client out of piles of money. If I ever discover a serious flaw in a product that has significant market penetration, and I receive approval from my employers, you can bet it would be released to the public, but until I am convinced of the value I will not.
That is the way life is for the people who choose to have a career practicing security rather than researching it; I am too busy finding and assisting with the correction of flaws within the organizations that have employed me in the past to spend time trying to punch holes in vendor xyz's products.
What this really means though, is that instead of having hundreds of security researchers pounding away at applications there is just me. One single solitary person; this means that in my time with my previous employer as a security consultant (god that sucked) I would have to take on identifying and exploiting vulnerabilities by myself against completely unique applications to resolve threats. Usually I would have one project at a time, and it would last a few weeks. Now that I am employed in a reasonably sized organization [12000 employees, ~400 developers, and ~1,200,00 customers] I frequently have multiple projects on the go, and frequently find myself with an overwhelming number of threat vectors to consider to worry about.
Before you go off patting people who manage to find holes in common off the shelf software on the back, or systems that have exposure of millions of users per minor version, take a moment to consider that, no, you do not know me. You have not heard of me because no application that I have reviewed to date has successfully been compromised provided the recommendations I made were followed; if they had you can bet that my former employer would have been sued for liability, and that I would be spending alot more time looking for a job than antagonizing people on Full-Disclosure. Don't bark at me about not having a long list of advisories from one of the most widely used applications on the internet.


Re:Re:Re:Re:Re


From: Yvan Boily Date: Thu, 22 Sep 2005 02:04:19 -0500
Very well then, since the prevailing argument seems to be that mine is an argument of sophistry and rhetoric, I have decided to restate my argument.
I am identifying the individual claims inline, and placing my arguments at the end. >Berend-Jan Wever wrote: > > This is a quite pathetic attempt to install a trojan, let me explain:
Wever makes the statement that the Google Secure Access VPN client is a Trojan Horse. This is naturally an inference, which is a shaky foundation for interpreting. I don't think this is a serious concern, but just to clarify, I am drawing this inference from the context of the mailing list and discussion, and the balance of the argument leads me to beleive that the claimant is not arguing that the subject is a condomn or an ancient enemy of Greece.
Statement: Google Secure Access is a Trojan Horse, and in particular, the application functions as spyware to gather information that is transmitted by the user.
I dispute this statement as the generally accepted description of a Trojan Horse is as follows:
A Trojan horse program is a malicious program that pretends to be a benign application; a Trojan horse program purposefully does something the user does not expect.
Although there are variations on the verbiage, I beleive that this is a fair general description, and cite the following resources: http://www.symantec.com/avcenter/expanded_threats/virus_worm_trojan_horse.html http://us.mcafee.com/virusInfo/ http://www.trendmicro.com/en/security/general/virus/overview.htm

> http://wifi.google.com/faq.html"> > 1. "Google Secure Access is a downloadable client application that > allows users to establish a more secure WiFi connection." > 2. "...your internet traffic will be encrypted, preventing others from > viewing the information you transmit." > > > So, by "more secure" Google means using encryption to prevent "others" from > sniffing your packets. That's nice! What else does it do? Here's some > information from the privacy policy: > > http://wifi.google.com/privacy-policy.html"> > 1. "Google may log some information from your web page requests ..." > 2. "Google also logs a small set of non-personally identifiable > information ..." > 3. "Google will not sell or provide personally identifiable > information to any third parties except ..." > 4. "... we may for a limited period of time preserve additional > internet traffic or other information." > > > Aha! What we have here is trojan spyware! It does exactly what it is > supposed to protect you from.
Wever argues that the software exploits exactly the threat the application proposes to shield the user from. At the same time he repeats Googles assertion that there is an improvement in security; since the user now has the benefit of encryption, there is the added benefit that the user has increased privacy.
Wever goes on to assert that the software is trojan spyware; from this a reasonable inference can be drawn that Wever is claiming that the application is a malicious application that surreptitiously gathers information about the user.
> The second snippet clearly states that this concerns NON-personally > identifiable information... what about the information mentioned in the > first snippet, is that personally identifiable? I guess so; the third > snippet mentions Google selling or providing personally identifiable > information, this must have come from somewhere!
This argument is based on the relationship between between the first two references, and the third reference. Beren is infering that because Google includes verbiage in reference 3 to address the possibility of sale or provision of personally identifiable information, that Google must in fact be collecting personal information.
Claim One: Google is collecting personal information because the final paragraph of the previously cited Google Secure Access Privacy Policy states that there are circumstances under which sale or sharing of information would be permitted. Basis for my inference of this claim: 'the third snippet mentions Google selling or providing personally identifiable information, this must have come from somewhere!'
Claim Two: Because Claim One is accepted, and the material described as being collected in the second last paragraph is not ofa personal nature, the information in the 3rd last paragraph of the cited policy must be of a personally identifiable nature. Basis for my inference of this claim: 'what about the information mentioned in the first snippet, is that personally identifiable? I guess so;", leads to Claim One. 'The second snippet clearly states that this concerns NON-personally identifiable information'

> In the third snippet, Google neglects to mention non-personally > identifiable information. What about selling that? I guess they do!
This argument is based on the idea that because Google does not specifically state they will not sell non-personally identifiable information this must prove that they do.
Claim Three: Google shares non-personally identifiable information because they do not state that they will not share this information.
> The best thing about the whole policy is the last snippet, which undoes > _everything_ stated before it. Nice one Google!! ;)
This argument claims that the final paragraph frees Google from any responsibility to honor the original statements and privacy considerations made. I am drawing the inference that this argument is made because the final paragraph defines scenarios under which the privacy policy may not be deemed enforceable.
Claim Four: Google does not need to honor the privacy policy because there are terms under which the policy is deemed unenforceable, and therefore qualifies as both a trojan horse and spyware as it misleads the user.
> I suggest that Google comes clean and replaces their privacy policy with a
> shorter, less confusing version: > > *Here's some candy, go play!* > Btw. All your base are belong to us.
> Cheers, > SkyLined
The conclusion that Beren draws is that Google's privacy policy is intended merely to distract people from the actual intention of Google. Since the original statement that Google Secure Access Client is a trojan horse, and spyware, we can infer that Beren intends to draw the following conclusion:
Google's privacy policy is an attempt to distract the user from the fact that Google can use the Secure Client Application to gather information surreptiously while users employ its service. Once users have agreed to use this service, the information collected is the property of Google, and no longer subject to the promises made in the Privacy Policy. Basis: '*Here's some candy, go play!*' - This is inferred to the idea that by offering an incentive the users can be convinced to ignore the situation. 'Btw. All your base are belong to us' - Cultural reference indicating that the end result is domination over the subject, in this case, the information collected by Google.
The entirety of Beren's argument as I have interpreted it is as follows:
Statement: Google Secure Access is a Trojan Horse, and in particular, the application functions as spyware to gather information that is transmitted by the user.
Claim One: Google is collecting personal information because the final paragraph of the previously cited Google Secure Access Privacy Policy states that there are circumstances under which sale or sharing of information would be permitted.
Claim Two: Because Claim One is accepted, and the material described as being collected in the second last paragraph is not ofa personal nature, the information in the 3rd last paragraph of the cited policy must be of a personally identifiable nature.
Claim Three: Google shares non-personally identifiable information because they do not state that they will not share this information.
Claim Four: Google does not need to honor the privacy policy because there are terms under which the policy is deemed unenforceable.
Conclusion: Google does not need to honor the privacy policy because there are terms under which the policy is deemed unenforceable, and therefore qualifies as both a trojan horse and spyware as it misleads the user.
I take significant issue with this argument as the claims used to support it are not sound; to clarify this I submit the following challenges:
Claim one asserts that Google *must* be collecting personal information because the possibility of sharing this information is documented in the policy. The issue here is that with the exception of the second last paragraph, Google never specifically claims that they will collect information, simply that they might. Stretching from "might collect potentially identifiable information" (best effort is described as 'not log cookies and strips potentially sensitive query data from the end of requests to help better protect your privacy') to "is collecting personal information" is a stretch. In fact, it would be considered an inductive fallacy; it requires the inference of behaviour due to a lack of clarity to make this leap, without any good reason to beleive they will. (Google might be collecting personal information, so you must accept that they are collecting personal information, because they are a big evil corporation!)
Claim two asserts that since claim one indicates that personal information is being collected, and that the routing and sesssion duration information is being collected is not personal information, then the web page requests must be personally identifiable. This is an untenable position because it is an deductive fallacy; since it is not stated that it is not personally identifiable, the information must be personally identifiable.
Claim three states that they will sell information non-personally identifiable information; this is actually a fair inference, but only because Google's business model is based on this. That said, this argument does not support the argument because Google clearly states that they may share this information in the resources sited as references.
Claim four states that Google does not need to honor the privacy policy (i.e., that it undoes the previously binding actions), however the cited references dictate that should there be a reason for collecting additional information that they can collect additional information. This statement is not there as a blanket statement, and in fact, only covers circumstances where there may be a suspected or identified threat to any of the actors within the environment (Google, users, network servers, etc). Since the Beren claims that all restrictions on collection and sharing of data are relieved, this is clearly a hasty generalization.
Because the only claim left valid is that Google will share non-identifiable information, and that this behaviour is disclosed rather than concealed, I assert that the conclusion Beren draws is unfounded, and the product of an over-arching appeal to fear to encourage people to be more skeptical of the service. The nature of the argument is such that Beren attempts to use the appearance of legitimate concerns to build a basis for an invalid conclusion is a classis case of rhetoric. In other words, the Google Client is neither a trojan horse, nor is it spyware as all functionality is clearly disclosed.
I further submit that Google Secure Client does in fact offer more security as it initally claims when used with a wireless connection as it reduces the likelihood of an attacker collecting wireless traffic. In exchange for this protection, Google introduces a smaller risk that Google will collect personally identifiable information. The trade off of an unknown attacker possibly stealing any available information against a known service provider with a corporate image to defend, and a range of liabilities introduced through service provision collecting fairly clearly delineated information is a fairly acceptable scenario.
These security trade-offs become more reasonable when one considers the following possibilities:
1) The verbiage about collection of information in the case of percieved threat likely relates to the retention of packet capture information in the case of an IDS or IPS being triggered.
2) The majority of sites which actually contain user identifiable information transmit such information in HTTP headers, do so via POST or PUT requests to store larger amounts of information; as a result these would be part of the 'potentially sensitive query data from the end of requests'. The combination of disclosure and thoughtful selection of visited sites while using a logged connection would yield much higher security in conjunction with increased privacy.
3) The use of tools such as ssh to forward local connections across encrypted tunnels make it possible to securely access sites regardless of the monitoring mechanisms (think local port redirection to a pre-installed squid proxy at a trusted host). Users incapable of this type of setup would likely receive a significant improvement in security through the gained encryption given their (probable) lack of understanding.
4) Aside from the potentially personal information contained in GET HTTP requests that would not be filtered, the next most significant potential issue raised by the Google information that might be shared would be a statistical attack that may allow a remote site that acquires a great deal of information about Google about session duration and routing to identify local session and account information. This is highly improbable so bears a low risk.
As a result, I beleive that the Google Secure Client will in most cases represent an improvement in security, especially when one considers that the intended deployment of the application is for hosts which do not have the option of connecting using a secure wireless technology.
Basically, I stand by my initial assertion. Berend-Jan Wever has presented an opinion designed to turn the security community away from a tool that they can use to alleviate a serious concern in exchange for an issue of information leakage. Like any security technology it has trade-offs, and like many vendor tools, these trade-offs are of a nature the vendor can profit from.
Since there are few other tools or services available for free that offer such a solution that are easy to use (something that Google has done well in many cases), there is no real justification for Berend-Jan Wever's attack on the product and the service provider. The prevailing idea that because Google is getting larger and more proprietary/monopolistic, it must be evil is negated by the consistent disclosure of how information collected is used.
Wevers opinion is a piece of fear-mongering garbage, fairly typical of the sensationalist reviews and reports used by the media to paint minor issues as The End of Civilization, and convince the world that unaffiliated security researchers are a Bad People; this is something that I think most people on this list should like to avoid. On 9/21/05, str0ke_at_milw0rm.com wrote: > > Dear Mr. Ass-Hat (aka, Yvan Boily): > > Nice job shitting on someones email with name calling and childish > remarks. > > Remember to clean your Pot its getting Black: > > "Before you go off FREAKING out you might want to consider a few things, > first:" > > You seemed to be the one FREAKEING out. Let me state a few steps that > can help you in life when you read other peoples emails in the future. > > 1) Breathe deeply, from your diaphragm; breathing from your chest won't > relax you. Picture your breath coming up from your "gut." > > 2) Slowly repeat a calm word or phrase such as "relax", "take it easy". > Repeat it to yourself while breathing deeply. > > 3) Use imagery; visualize a relaxing experience, from either your memory > or your imagination. > > 4) Non-strenuous, slow yoga-like exercises can relax your muscles and make > you feel much calmer. > > Remember if these 4 steps dont help you with your EMAIL RAGE. Please be > sure to seek help at an EMAIL RAGE clinic. > > /str0ke >

Tuesday, September 20, 2005

OSS means slower patches

Excerpt from a news paper article.
Link : http://australianit.news.com.au/articles/0,7204,16650762^15306^^nbv^,00.html

From full-disclosure mailing list

The obvious criticism:
"The Mozilla family of browsers had the highest number of vulnerabilities during the first six months of 2005, with 25," the Symantec report says.
"Eighteen of these, or 72 per cent, were rated as high severity. Microsoft Internet Explorer had 13 vendor confirmed vulnerabilities, of which eight, or 62 per cent, were considered high severity."
Microsoft IE had at least 19 vulnerabilities from 2005-01-01 to 2005-06-30. Why does Symantec make the distinction of "X vulnerabilities in Mozilla" vs "MSIE had X *vendor confirmed vulnerabilities*"? This all to conveniently allows the silently patched vulnerabilities to slip through the cracks of our statistics. Does Mozilla's honesty in acknowledging vulnerabilities come back to bite them in the ass?
Mozilla browsers had more than 25, but are 72 per cent really "high severity"? Download information spoofing x2, File extension spoofing, URL restriction bypass, DoS x2, redirect spoofing, XSS, link status bar spoofing, Dialog overlapping, URL Wrap Obfuscation.. are all of these really "high severity"? Is that theoretical, practical, or hype?
Now, the media/symantec driven propoganda (for lack of better word?):
THE growing popularity of open-source browsers and software may be
responsible for the increasing gap between the exposure of a
vulnerability and the provision of patch to fix it, security software
vendor Symantec has said.
Mr Sykes said the increasing popularity of open source software, such as
the Mozilla Foundation's Firefox browser, could be part of the reason
for the increase in the gap between vulnerability and patch, with the
open source development model itself part of the problem. "It is
relying on the goodwill and best efforts of many people, and that
doesn't have the same commercial imperative," he said. "I'm sure that is
part of what is causing the blow-out in the patch window."
The growth in Firefox vulnerability reports coincides with its
increasing popularity with users. "It is very clear that Firefox is
gaining acceptance and I would therefore expect to see it targeted," Mr
Sykes said. "People don't attack browsers and systems per se, they
attack the people that use them," he said. "As soon as large banks
started using Linux, Linux vulnerabilities started to get exploited."
The premise of this article is open source software is to blame for longer vendor response times. In laymen's terms, blame vendors like Mozilla for having vulnerabilities patched slower? Err, compared to what? This shallow article doesn't even qualify that statement! Slower than previous vulnerabilities? Slower than non open source? Given the article directly compares Mozilla browsers to Microsoft IE, it is trivial to assume the claim is made in relation to closed source vendors such as Microsoft. So then what .. 30 days "blown out" to 54 days is some huge time gap compared to Microsoft IE patches? What clueless *moron* really believes this crap they are shovelling? Is it Symantec or Chris Jenkins or Australian IT?
Given that Symantec won't even quote previous statistics: "Symantec had not published previously statistics on the average time required to produce patches, but Mr Sykes said data showed the lag had previously been about 30 days." Given that Jenkins/AusIT/Symantec won't give us any statistics (even questionable ones) regarding MSIE patches, we're supposed to take this at face value? It is *well documented* that Microsoft takes well over 30 days to patch vulnerabilities. It is also becoming crystal clear that Microsoft is hiding behind their "30 day patch cycle" to imply that is the longest they go before patching a vulnerability, when it simply is not the case. Taking a look at a *single vendor* [1] and their experience with reporting vulnerabilities to Microsoft, we see that they give MS a 60 day window to patch vulnerabilities, and are consistantly overdue. As of this mail, the worse is *ONLY* 114 days past due (we've seen it closer to 250 days before). So again, where are these implications coming from? Where does this statement/conclusion/observation that "OSS causes slower patches" come from exactly?"


link:
BlogSpot
Yahoo! 360
BlogoMonster

Friday, September 16, 2005

Ninetendo bringing revolution the way we play game.

Dont forget to read the story at Ninetendo.
This is a awesome product from Nintendo.






You will forget those pc keys or those joystick. You just move it in air and kill that sucker.

Friday, September 02, 2005

7th Anniversary of Microsoft



We just had a party on the occasion of 7th Anniversary of Microsoft IDC.
So I just wanted to post some pics of IDC and anniversary.
Working in Microsoft is really a beautiful experience, you get a lot to learn. Things are simpally good. We enjoy a lot. Work culture here in microsoft is the best I found till date
:-)




So what are you waiting for?
Aren't you gonna join me.

 

Google Analytics

Popular Posts

Powered by Blogger.