intended feature or not?

  • Thread starter Thread starter Mikolaj
  • Start date Start date
M

Mikolaj

Hello everyone,

In the Microsoft AntiSpyware Software (Pre-Release
Version) Privacy Statement I have found following
information about Spyware Reporting Tool:

"Choice/Control: When you use the Suspected Spyware
Reporting Tool, the choice is up to you whether or not to
submit a report to Microsoft. You will have an
opportunity to view the information contained in the
report before choosing whether or not to send it."

However, it appears to work in completely other way -
first the report has to be send, than I can choose to
view it, and this is not local report, but from SpyNet
research center web page.

Is this going to be that way?

Kind regards
Mikolaj
 
I am able to see the content of the report by clicking the light gray "view
the raw scan result" below and to the right of the send or cancel buttons
once the report completes.

Are you not able to do that?

I agree that this is sub-optimal--not sure what the plan is.

The promise to allow viewing before sending is repeated at the bottom of the
page where you decide to create the report. I think the "allow viewing of
raw scan result" mechanism does fulfill the bare minimum of this promise.
 
If it would work.. :) Unfortunaltelly I experience some
XML usin XSL styles errors - IE reports that it cannot
browse XLM entries like this:


<IEExplorerBar ex="1" clsid="{4D5C8C25-D075-11d0-B416-
00C04FB90376}" prog="" val="&amp;Porada dnia"
nam="Biblioteka powłoki obiektów DocObject i formantów
(shdocvw.dll)" pub="Microsoft Corporation"
md5="0277af17a6ebc1aac774bd8d5708f283"
ver="6.00.2900.2573 (xpsp_sp2_gdr.041130-1729)"
sz="1483264" is="0" gfp="">c:\windows\system32
\shdocvw.dll</IEExplorerBar>

After deleting this line from the report, IE shows errors
in any other entry containing ex="1" ...

Is this my IE configuration problem? (now I understand
that "before-sending" report is available, after I manage
to solve my IE problem)


Kind regards
Mikolaj
 
Ups, it was too fast.. Not every line containin ex="1"
causes problem, but most of them having structure like
this provided earlier..

Kind regards
Mikolaj
 
Other users have reported a similar issue.

I guess I would have to class these XML reporting issues as a bug--if the
report can be surpressed by either an unusual character set or by a choice
of naming by spyware, it is surely a vulnerability in the tool.

I suspect this is another area of program design and execution that the
broader experience of Microsoft development staff may allow them to make
more robust than the original work on which it is based.

I would say that if such issues still exist in the product when we see a
version which is capable of being localized (even if not yet localized)--we
should yell loudly.
--
FAQ for Microsoft Antispyware:
http://www.geocities.com/marfer_mvp/FAQ_MSantispy.htm

If it would work.. :) Unfortunaltelly I experience some
XML usin XSL styles errors - IE reports that it cannot
browse XLM entries like this:


<IEExplorerBar ex="1" clsid="{4D5C8C25-D075-11d0-B416-
00C04FB90376}" prog="" val="&amp;Porada dnia"
nam="Biblioteka powłoki obiektów DocObject i formantów
(shdocvw.dll)" pub="Microsoft Corporation"
md5="0277af17a6ebc1aac774bd8d5708f283"
ver="6.00.2900.2573 (xpsp_sp2_gdr.041130-1729)"
sz="1483264" is="0" gfp="">c:\windows\system32
\shdocvw.dll</IEExplorerBar>

After deleting this line from the report, IE shows errors
in any other entry containing ex="1" ...

Is this my IE configuration problem? (now I understand
that "before-sending" report is available, after I manage
to solve my IE problem)


Kind regards
Mikolaj
 
Hi again,

I have checked this issue on 3 different operating
systems:
- Windows XP Home Edition SP2 Polish with all latesr
updates
- Windows XP Professional SP2 Polish with all latest
updates (on two different computers)
- Windows 2003 Server Standard Polish with all latest
updates
All of them have the same problem.
So I have changed all polish characters in MSSSRT.xml
file to latin substitues, and now IE reports no errors,
but displays only XML file content, not the "nice
looking" report as it can be seen from SpyNet web page
(after sending).
So the problem is surely with national characters in the
XML file content, but maybe something else, too.

Kind regards
Mikolaj
 
Hi again,

All of them have the same problem.
So I have changed all polish characters in MSSSRT.xml
file to latin substitues, and now IE reports no errors,
but displays only XML file content, not the "nice
looking" report as it can be seen from SpyNet web page
(after sending).
So the problem is surely with national characters in the
XML file content, but maybe something else, too.

This is how it works in English, as well--i.e. it displays only raw XML file
content, and not the formatted report.

I would hope that the intent will be to do this better, but thinking about
it--I'm not sure what the best thing to do is:

Now--they give you the raw XML. You can search it using a text editor for
your name, or your national identity card number (in the US, Social Security
number)--for example, and see whether there's information in there you don't
want going out.

If they display the final formatted report--do we paranoid users believe
them when they say we are seeing everything sent? Are we?

I think in an ideal world, we want both forms.
 
OK, I understand the paranoid point of view ;)
But as the report is a XML file, it can be easy opened and searched for
vulnerable information in, for example, notepad or similiar application (if
the paranoid user wants to). So I think normally the report should be
presented in a formatted form.
But of course it's a matter of taste ;)
However, the problem with polish (and/or any other national?) characters
still persists - IE still shows XML/XMS errors when the report contains
infromation with national/polish characters.

Kind regards
Mikolaj
 
Mikolaj said:
OK, I understand the paranoid point of view ;)
But as the report is a XML file, it can be easy opened and searched for
vulnerable information in, for example, notepad or similiar application
(if the paranoid user wants to). So I think normally the report should be
presented in a formatted form.
But of course it's a matter of taste ;)
However, the problem with polish (and/or any other national?) characters
still persists - IE still shows XML/XMS errors when the report contains
infromation with national/polish characters.
Click to expand...

I understand the problem. My thinking, which may be muddle-headed, since
I'm not a developer and have very little sense of the development
process--is that this kind of issue is likely to be addressed as part of the
work of localizing the product--or, perhaps more accurately, redesigning it
so that it is capable of being localized.

That work isn't reflected in the builds we've seen so far--I believe they'll
let us know when this is something we can look at, but I'm not sure.
 
Back
Top