* Posts by Jamie A

5 posts • joined 7 Jun 2007

A serious browser vulnerability, but whose?

Jamie A

Is IE partly to blame?

I've just attempted a number of different ways of launching this exploit, but can't seem to get it to execute except from IE.

* Attempting to launch it by pasting the URL into FF shows a warning with the full URL. Accepting this warning just brings up another warning about "firefoxurl:test". Accepting this one just brings up another, etc, creating a new tab each time.

* Attempting to launch it via the ShellExecute API doesn't work. FF warns about "firefoxurl:test", not the entire URL.

* Launching the URL from IE (either via the link or pasting the URL into the address bar) causes the exploit to run.

It certainly seems that IE is partly to blame, because it does something different in how it executes these links. Perhaps MS should patch IE so that it uses standard mechanisms to launch these links, rather than whatever method it currently uses.


Google Maps aids terrorists, NY lawmaker warns

Jamie A

The terrorists have already won

Why do the terrorists need to blow anything else up? All they need to do is keep making vague threats, and people like this guy will keep over-reacting and thinking that their lives are in mortal peril.

The whole point of terrorism is to strike fear. That goal has been achieved, so it seems.


Crocodile tears for under-fire Microsoft MVP

Jamie A

@Pete McPhedran

I'm not disputing that the Express EULA says that you cannot extend the functionality. Although I have been unable to find a copy of this EULA on the web, I have seen excerpts that mention that clause.

However, that is in the end-user license agreement for the Express products. That license applies to the person(s) installing and using the Express products, i.e. the end-user.

Jamie Cansdale it not installing the product on end-user machines - end-users are. Therefore, it's the end-users who are violating their own EULAs, not Jamie.

I have yet to see any real evidence that mentions which EULAs Jamie has violated. As far as I can tell:

* He has not violated the VSIP EULA, as he's not using the VSIP interfaces to extend the product.

* He hasn't reverse-engineered or disassembled any software - he has only used publically-documented methods and interfaces.

* He is not responsible for violating an Express EULA if someone uses his software with an Express product.

We can infer that Jamie has violated the Express EULAs on his own systems when testing his software. Microsoft can claim any remedies for this that are in the EULA, such as revoking the license. (Note: AFAIK, EULAs are untested in law.) But I can't see how they can stop him from making his software compatible with Express products.

Jamie A

RE: Microsoft didn't cripple it

@Giles Jones:

"They didn't cripple it very well then, Microsoft published APIs for Visual Studio that allow for extensions. These extensions work in the Express edition as it has API.

Microsoft should have deactivated this API or popped up a warning message."

I think you'll find that they can't really remove the API that Jamie is using in his product. In all likelihood, it's used internally by a number of the standard components of VS Express in order to do their thing. Microsoft will also be using this API so that they can share more code between the Express and full versions of the software.


Microsoft will have a hard time proving the reverse engineering or disassembly angles. They published documentation on the APIs that Jamie is using. All Jamie did was to use the standard COM method to see if Visual Studio used the interface he was interested in (QueryInterface).

Also, as other have pointed out, Jamie is not violating any EULAs by *providing* his software. He may have violated the Express EULA while testing if his software works with the Express products, but that's about it. If others install the product on Express versions of VS, they're violating the EULA, not Jamie.

Jamie A

Another way of looking at this

Here's a slightly less technical way of looking at the issue:

Microsoft essentially have 2 editions of a program. The first edition speaks English (User Interface) to the user, but in behind can speak French (COM) to other components.

The second edition also speaks English and French, but can also speak Russian (VSIP - Visual Studio Integration Programme).

Microsoft intends that your components speak Russian in order to extend Visual Studio. Their VSIP license agreement also states that you can only try to speak Russian to the second edition of the software. Attempting to speak Russian to the first edition is not allowed (even if it does speak the language).

Rather than try and speak Russian, Jamie has been using French. He has asked Visual Studio if it talks a certain dialect (COM interface), and it has said "oui". So he uses that dialect to talk to Visual Studio in order to do what he needs.

The main problem from Microsoft's point of view is that they didn't intend for anyone to use that dialect of French in order to talk to Visual Studio. They only expected Russian to be used. However, there's nothing that explicitly states this. Microsoft even has public notes on the French dialect.

Therefore, Jamie thinks he's in the right because Microsoft have not said that speaking French is forbidden. Microsoft sees it the other way. And the way things are going, it looks like the decision is going to come from a judge or jury.



Biting the hand that feeds IT © 1998–2017