UA string.

David Hyatt hyatt at apple.com
Mon Feb 24 19:11:06 GMT 2003


Safari does not support document.all.  Only Konqueror does.  We do not 
plan to unconditionally support document.all.  Instead we plan to 
selectively allow access to the .all property based off whether or not 
we're using an MSIE-style UA string.

dave

On Sunday, February 23, 2003, at 02:08 AM, Vadim Plessky wrote:

> On Friday 21 February 2003 03:33, Darin Adler wrote:
> |  On Thursday, February 20, 2003, at 04:05 PM, Dirk Mueller wrote:
> |  > On Don, 20 Feb 2003, Darin Adler wrote:
> |  >> Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/60 
> (KHTML,
> |  >> like Gecko) Safari/60
> |  >
> |  > hmm, the second pair of brackets is not going to be a problem for 
> some
> |  > websites?
> |
> |  We've always had those two sets of parentheses.
> |
> |  > I guess we should change our to
> |  >
> |  > Mozilla/5.0 (compatible; Konqueror/3.1; KHTML, like Gecko; Linux)
> |  >
> |  > But thats not really compatible to your format.
> |
> |  Might be OK. We the key is that they can just look for the substring
> |  KHTML.
>
> Sorry for late comments, but it seems there are several important 
> points not
> listed/not discussed so far.
> IIRC, we were discussing Konqueror/KHTML userAgent string couple of 
> years ago
> (KDE 2.0/2.1 release time), and Harri Porten raised the question of
> _security_, as part of UA identification.
> Within last 2 years, this question became much more important than 
> ever.
>
> let me liste those questions again:
> 1)  should UA identify platform/environemnt it is running on?
>
> For example, shoukd Konqueror running on Linux identify itself as
>   Mozilla/5.0 (compatible; Konqueror/3.1; KHTML; Linux)
> or even
>   Mozilla/5.0 (compatible; Konqueror/3.1; KHTML; Linux 2.4.18-6mdk)
>
> or for Safari running on MacOS X
>   Mozilla/5.0 (compatible; Safari/1.0; KHTML; MacOS X 10.2)
>
> +++
>  Supporters of such identification say that web designers need to know 
> UA
> platform/OS, in order to deliver "best possible" content and tune 
> serve web
> page in accordance with UA capabilities
>
> ---
>  Non-supporters of such UA identification (with platform) say that it
> disclosures too much details about platform, and would simplify 
> potential
> hacker to break in into user's computer/OS, and steal potential private
> information.
>
> At a moment, Konqueror doesn't list OS/Platform by default, while you 
> canturn
> it on is UA Settings dialog.
>
> The only situation when knowledge of OS is really *required*, is when 
> you wnat
> to install ActiveX elements on client's computer.
> This is essentially the case of Windows 98/2000/XP system running MS 
> IE.
> There are several web page which *would not work* at all, unless you 
> allow it
> to install ActiveX element(s).
> Good example of such page is http://windowsupdate.microsoft.com
> Windows Update functionality is 100% ActiveX-based.
>
> 2) should UA list CPU type and type of Windowing Environment?
>
> I am speaking of "PPC" part (and "Mac OS X") in this UA
>   Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us)
> or "X11" and "i686" in this UA string
>   Mozilla/5.0 (compatible; Konqueror/3.1; Linux; X11; i686)
>
> As "Windows" string is quite common in Windows-based user agents, I 
> think that
> listing non-Windows platform in UA string is a Good Idea.
> I hardly believe it disclosures any kind of existing or potential
> vulnerabilities, while it definitly increaes count of non-Windows 
> clients.
>
> |
> |  > Mozilla/5.0 (compatible; Konqueror/3.1; Linux) (KHTML, like Gecko)
> |
> |  Seems as good as the above, not a lot better though. I guess they 
> can
> |  look for "(KHTML," in this one, which might be better.
>
> I am strongly againts using worj "Gecko" in UA string.
> Konq/KHTML and Safari are not based on Gecko engine, while you may 
> wnat to
> fake as Gecko when:
> a) you are not using Gecko
> b) most of web designers arenot aware about Gecko existance, and what 
> the
> Gecko is, they concentrate design around MS IE
>
> Important point for compatibility (on majority of web sites) is 
> compatibility
> with MS IE, and compatibility with those sites is achieved (in KHTML) 
> via
> document.all DHTML.
> Like it or not, but most pages use following JS code to do branching 
> of its
> DHTML features:
>
> var DOM=document.getElementById;
>  if ( document.all)
>    { MS IE branch }
>  else if ( DOM )
>   { Netscape6, Mozilla, Konqueror should go here  }
>  else if (document.layers )
>   { Netscape 4 branch }
>  else
>   { branch for browsers not supporting DHTML; usually empty part 
> inmost cases}
>
> What happens in code above?
> Konqueror (and Safari) would always get document.all branch.
> Which would create potential DHTML problems, as innerHTML and outerHTML
> methods, "designed" by Microsoft, are very tricky and not very well
> documented.
> The real fix (inside KHTML codebase), IMO, would be to disable 
> document.all on
> per site basis (with some database online listing sites where it 
> should be
> disabled).
> Of course, we can try to contact webmasters and ask them to use DOM 
> branch
> first - but in 99.9% cases, those webmasters do not care about such
> letters...
>
> 3)  should UA tell web site that it supports plugins/specific 
> MIMEtypes, and
> therefor supports extended  MIME types (comparing to platfroms' 
> default)?
>
> I am speaking about:
> navigator.plugins
> navigator.mimeTypes
>
> objects, which are supported in KHTML (and partially - in 
> Mozilla/Gecko).
> It's also quite interesting that MS IE on Mac supports plugins, too 
> (while MS
> IE on WIndows ignores those objects)
>
> Problems which exist in current KHTML implementation - that, say, JPG, 
> GIF,
> WAV, MP3, etc. are not listed as valid MIMEtypes if you execute 
> "enumerate
> mimetypes" script in browser.
> But all MIMEtypes installed via plugin (Flash, RealAudio) are listed
> correctly.
> Shouldn't we fix it in both Konqueror and Safari *before* first major 
> release
> of Safari?
> It would be nice if web masters would get one unified method to check
> supported media at specific userAgent, without doing terrible 9and 
> often not
> working correctly) hacks.
>
> |
> |  > Is there any spec on UserAgent string formatting?
> |
> |  I wish there was. There are some documents at mozilla.org, but 
> that's
> |  all I could find.
>
> And IMO, those documents on Mozilla site are badly designed.
>
> |
> |  > and expect "Gecko" after the closing brackets to detect it as 
> Gecko.
> |
> |  We did that on purpose, of course. Many pages don't give modern
> |  standards-compliant content unless they see the substring Gecko
> |  somewhere, but they don't care where.
>
> Can you pls list those pages?
> AFAIK, most web sites do not care wether it's Gecko or not.
> They just ignore this word in UA string.
>
> |
> |  > Mozilla/5.0 (compatible; U; Linux; en-us) KHTML/3.1 like Gecko
> |
> |  That's more like us, but has the problem that "compatible" is going 
> to
> |  make many simple-minded sites think you are IE; we found that led to
> |  bad results.
> |
> |  > BTW, do you happen to know the meaning of the "U;" ? :-)
> |
> |  I do not. I am preparing a document explaining our user agent string
> |  that might some day go up on developer.apple.com, and that's one of 
> the
> |  unanswered questions in my current draft.
> |
> |       -- Darin
>
> Hope to hear you on those issues soon!
>
> Greetings,
> Vadim
>
> P.S. I attach browser-detection script which works quite well on all 
> existing
> browsers, despite script was designed in 2000.
> I hope you can check JS inside and get an idea how detection works.
> Unfortunately, many web pages do somewhat broken UA detection.
> (good examples: CNN, ESPN, etc.)
>
> -- 
>
> Best Regards,
>
> Vadim Plessky
> SVG Icons * BlueSphere Icons 0.3.0 released
> http://svgicons.sourceforge.net
> <Browser_TEST5.html>





More information about the kfm-devel mailing list