kurt wismer wrote:


> and the absurdity continues... apparently internet exploder (what most
> people use to browse the web with) doesn't exist in your world,


It does, but it isn't a webbrowser and therefore counts as PEBKAC. It's
futile to discuss it in any security content since it's well documented to
not be supposed to provide security in a hostile environment.

> and of the browsers that do exist firefox (of all things) is the one you
> consider obscure...


Which becomes quite clear when looking at the internals of Mozilla
Seamonkey. The developers of Firefox don't even bother exposing really
important configuration options in the UI or not even at all, the coding
style of the components is horrible and full of stupid ideas (with the
firefoxurl: protocol handler being the most recent absurdity).

> i just explained 2 things... the first was that the vulnerabilities that
> the would get documented in the fashion you're looking for are not
> necessarily the ones that are actually relevant to this discussion (it's
> the ones that the blackhats know about but the whitehats don't that are
> most relevant)...


This is a principle attack vector that cannot be avoided unless you have
superior software verification mechanisms (which simply aren't practical
today). Since this is not within the decision of the vendor neither the
users, it's irrelevant to discuss.

> the second was that we can take the assertion that most browsers contain
> unpatched vulnerabilities as axiomatically true and let time do the work
> of revealing the details of those vulnerabilities... in other words, if
> browsers and all the components that plug into them never need security
> updates ever again then you were right, otherwise not so much..


You're forgetting one important detail: configuration can protect against
yet unknown vulnerabilities by reducing functional exposure.

> but, just to put the last nails in the coffin of the debate on how easy
> it is to find vulnerabilities, these articles are all from the past
> month and each one is about something different and has something
> related to web browsing...
> http://blogs.zdnet.com/security/?p=636


That's not even a vulnerability.



> http://isc.sans.org/diary.html?storyid=3540

> http://securitywatch.eweek.com/apple...r_windows.html
> http://www.liquidmatrix.org/blog/200...vulnerability/


And they're all patched already, with very short response time.

> http://blogs.zdnet.com/security/?p=652

That's about MSIE when used in a hostile environment, which was never
supposed to be secure. Thus it's not a security violation.

>
http://www.symantec.com/enterprise/s...ack_again.html
>
http://www.symantec.com/enterprise/s..._the_loos.html

> http://securitywatch.eweek.com/vulne...tsoever_1.html


And these aren't even webbrowser exploits at all.


Now is it ignorance or incompetence why you came up with these non-issues?

> it's clear to me that you are equating exposure to compromise, in spite
> of the fact that (for example) you can be exposed to a biological
> contagion without getting sick...


Oh hello, Mr. Bad Analogy Guy. The analogue world has the funny property
that you can always break a system with more brute force, whereas for
digital systems the set of input is fully enumerable (and that very trivially).

> the majority of web users still use ie, ie supports additional scripting
> languages, and ie's jscript interpreter is separate...


Abusing it as a webbrowser doesn't make it one. Of course, you don't need
any scripting, ActiveX or whatsoever to render MSIE insecure when used on
the world wide web, just like a Telnet session is always unencrypted and not
securely authenticated (which is a documented behaviour, that's why you
can't expect any security in first place).

> no browser does, the browser hands that job off to a different component...


Ok, can anyone point me over to a WMF and/or VML viewer plugin for any
decent webbrowser?

> oh it is reasonable? ok then i suppose i can reasonably expect you to a)
> list the primary domains of all the sites you visit regularly and b)
> list *every* *single* domain that is also registered to those entities...


I don't need to. I just don't create any false positive, but it's fully
secure to not trust a website belonging to an entity due to different
domain. As for your example, paypalsecurity.com doesn't belong to paypal.com
until proven otherwise, period.