Is Anybody Stupid Enough To Sniff User-Agent Strings?

Discussion in 'NZ Computing' started by Lawrence D'Oliveiro, Apr 3, 2011.

  1. Google is going to make some changes to the User-Agent strings for its
    Chrome and Chromium browsers
    <http://www.h-online.com/open/news/item/Chrome-and-Chromium-to-change-their-UA-calling-cards-1220162.html>.

    Is anybody’s code really going to be broken by this? I thought it was well
    understood that you should check as directly as possible for the
    functionality you need, not try to deduce it from purely informational
    fields.
     
    Lawrence D'Oliveiro, Apr 3, 2011
    #1
    1. Advertising

  2. In message <>, Allistar wrote:

    > There is no robust way to check for functionality, especially when it
    > comes to bugs. It's not like there is a javascript function called
    > "hasBuggyBoxModel" or something like that.


    Just write a code sequence that tests for the bug. Give an example of such a
    bug, and I’ll show you what I mean.
     
    Lawrence D'Oliveiro, Apr 3, 2011
    #2
    1. Advertising

  3. In message <>, Allistar wrote:

    > Lawrence D'Oliveiro wrote:
    >
    >> In message <>, Allistar
    >> wrote:
    >>
    >>> There is no robust way to check for functionality, especially when it
    >>> comes to bugs. It's not like there is a javascript function called
    >>> "hasBuggyBoxModel" or something like that.

    >>
    >> Just write a code sequence that tests for the bug. Give an example of
    >> such a bug, and I’ll show you what I mean.

    >
    > And you execute that code every time a page loads? One per "feature" you
    > want to test for?


    Yup. What’s the big deal?
     
    Lawrence D'Oliveiro, Apr 4, 2011
    #3
  4. Lawrence D'Oliveiro

    Richard Guest

    On 4/04/2011 10:21 a.m., Allistar wrote:
    > Lawrence D'Oliveiro wrote:
    >
    >> In message<>, Allistar
    >> wrote:
    >>
    >>> There is no robust way to check for functionality, especially when it
    >>> comes to bugs. It's not like there is a javascript function called
    >>> "hasBuggyBoxModel" or something like that.

    >>
    >> Just write a code sequence that tests for the bug. Give an example of such
    >> a bug, and I’ll show you what I mean.

    >
    > And you execute that code every time a page loads? One per "feature" you
    > want to test for?


    Well its not running on your end, and you can cache the .js's used,
    whats the problem?

    Or if you need to vary the page generation based on it, use a cookie as
    that comes down anyway so there is no additional penelty over using the
    user agent string.
     
    Richard, Apr 4, 2011
    #4
  5. Lawrence D'Oliveiro

    Ralph Fox Guest

    On Sun, 03 Apr 2011 18:58:10 +1200, in message <in95q2$i4p$>
    Lawrence D'Oliveiro wrote:

    > Is anybody’s code really going to be broken by this? I thought it was well
    > understood that you should check as directly as possible for the
    > functionality you need, not try to deduce it from purely informational
    > fields.



    If that is what you actually believe, then how do you explain this ?

    <"http://groups.google.com/group/mozilla.support.seamonkey/msg/628762d830897d64">



    --
    Kind regards
    Ralph
     
    Ralph Fox, Apr 4, 2011
    #5
  6. Lawrence D'Oliveiro

    Ralph Fox Guest

    On Mon, 04 Apr 2011 10:04:38 +1200, in message <inaqtm$gr4$>
    Lawrence D'Oliveiro wrote:

    > In message <>, Allistar wrote:
    >
    > > There is no robust way to check for functionality, especially when it
    > > comes to bugs. It's not like there is a javascript function called
    > > "hasBuggyBoxModel" or something like that.

    >
    > Just write a code sequence that tests for the bug. Give an example of such a
    > bug, and I’ll show you what I mean.



    Ok. Provide the code sequence that tests for this bug.
    Without crashing the browser (i.e. non-destructively):

    http://www.mozilla.org/security/announce/2011/mfsa2011-09.html



    --
    Kind regards
    Ralph
     
    Ralph Fox, Apr 6, 2011
    #6
  7. Lawrence D'Oliveiro

    Richard Guest

    On 6/04/2011 8:51 p.m., Ralph Fox wrote:
    > On Mon, 04 Apr 2011 10:04:38 +1200, in message<inaqtm$gr4$>
    > Lawrence D'Oliveiro wrote:
    >
    >> In message<>, Allistar wrote:
    >>
    >>> There is no robust way to check for functionality, especially when it
    >>> comes to bugs. It's not like there is a javascript function called
    >>> "hasBuggyBoxModel" or something like that.

    >>
    >> Just write a code sequence that tests for the bug. Give an example of such a
    >> bug, and I’ll show you what I mean.

    >
    >
    > Ok. Provide the code sequence that tests for this bug.
    > Without crashing the browser (i.e. non-destructively):
    >
    > http://www.mozilla.org/security/announce/2011/mfsa2011-09.html


    Explain what operation on a website requires it to be serving corrupt
    jpegs to users of it?
     
    Richard, Apr 6, 2011
    #7
  8. Lawrence D'Oliveiro

    Ralph Fox Guest

    On Wed, 06 Apr 2011 23:11:02 +1200, in message <inhho6$t21$>
    Richard wrote:

    > On 6/04/2011 8:51 p.m., Ralph Fox wrote:
    > > On Mon, 04 Apr 2011 10:04:38 +1200, in message<inaqtm$gr4$>
    > > Lawrence D'Oliveiro wrote:
    > >
    > >> In message<>, Allistar wrote:
    > >>
    > >>> There is no robust way to check for functionality, especially when it
    > >>> comes to bugs. It's not like there is a javascript function called
    > >>> "hasBuggyBoxModel" or something like that.
    > >>
    > >> Just write a code sequence that tests for the bug. Give an example of such a
    > >> bug, and I’ll show you what I mean.

    > >
    > >
    > > Ok. Provide the code sequence that tests for this bug.
    > > Without crashing the browser (i.e. non-destructively):
    > >
    > > http://www.mozilla.org/security/announce/2011/mfsa2011-09.html

    >
    > Explain what operation on a website requires it to be serving corrupt
    > jpegs to users of it?



    Your intervention still does not keep Lawrence from his offer.

    Take one of the browser crashes caused by logic errors in the browser
    code, and not by corrupt data from the web site. Provide the code
    sequence that tests for this bug. Without crashing the browser (i.e.
    non-destructively):

    http://www.mozilla.org/security/announce/2010/mfsa2010-48.html



    --
    Kind regards
    Ralph
     
    Ralph Fox, Apr 6, 2011
    #8
  9. Lawrence D'Oliveiro

    Murray Symon Guest

    Ralph Fox wrote:

    > On Wed, 06 Apr 2011 23:11:02 +1200, in message
    > <inhho6$t21$> Richard wrote:
    >
    >> On 6/04/2011 8:51 p.m., Ralph Fox wrote:
    >> > On Mon, 04 Apr 2011 10:04:38 +1200, in
    >> > message<inaqtm$gr4$> Lawrence D'Oliveiro wrote:
    >> >
    >> >> In message<>, Allistar
    >> >> wrote:
    >> >>
    >> >>> There is no robust way to check for functionality, especially when it
    >> >>> comes to bugs. It's not like there is a javascript function called
    >> >>> "hasBuggyBoxModel" or something like that.
    >> >>
    >> >> Just write a code sequence that tests for the bug. Give an example of
    >> >> such a bug, and I’ll show you what I mean.
    >> >
    >> >
    >> > Ok. Provide the code sequence that tests for this bug.
    >> > Without crashing the browser (i.e. non-destructively):
    >> >
    >> > http://www.mozilla.org/security/announce/2011/mfsa2011-09.html

    >>
    >> Explain what operation on a website requires it to be serving corrupt
    >> jpegs to users of it?

    >
    >
    > Your intervention still does not keep Lawrence from his offer.
    >
    > Take one of the browser crashes caused by logic errors in the browser
    > code, and not by corrupt data from the web site. Provide the code
    > sequence that tests for this bug. Without crashing the browser (i.e.
    > non-destructively):
    >
    > • http://www.mozilla.org/security/announce/2010/mfsa2010-48.html
    >


    Sounds like Turing's/Godel's "halting problem" all over again.
    How to programmatically test if a program will halt or loop infinitely?
    I think one of the theoretical solutions may require an oracle.
     
    Murray Symon, Apr 7, 2011
    #9
  10. Lawrence D'Oliveiro

    Ralph Fox Guest

    On Thu, 07 Apr 2011 20:41:15 +1200, in message <injtbb$he1$>
    Murray Symon wrote:

    > > Take one of the browser crashes caused by logic errors in the browser
    > > code, and not by corrupt data from the web site. Provide the code
    > > sequence that tests for this bug. Without crashing the browser (i.e.
    > > non-destructively):
    > >
    > > • http://www.mozilla.org/security/announce/2010/mfsa2010-48.html
    > >

    >
    > Sounds like Turing's/Godel's "halting problem" all over again.
    > How to programmatically test if a program will halt or loop infinitely?
    > I think one of the theoretical solutions may require an oracle.



    AFAICS the "loop infinitely" case is not one of the outcomes here.

    It is more like this:

    Your snappy new web page has a piece of JavaScript which executes
    a finite number of operations and produces a result in a finite time.
    After testing, you find that on version 3.6.7 of browser BRZ, the
    browser will crash (again in a finite time) with (say) a "use after
    deallocate" fault.

    You decide to serve the old web page just to BRZ version 3.6.7 users,
    and the snappy new web page to users of other browser versions.

    One way is for the web server to sniff the User-Agent string and
    serve one or the other page accordingly. Of course this may not
    always be correct, as User-Agent strings can be faked. But is
    there a more accurate method (apart from crashing all BRZ version
    3.6.7 browsers)?



    --
    Kind regards
    Ralph
     
    Ralph Fox, Apr 11, 2011
    #10
  11. In message <>, Allistar wrote:

    > I can understand the need to test for advanced features that one browser
    > may have that another doesn't, but find it difficult to see any elegance
    > in sniffing for features where the term "feature" is a euphemism for
    > "bug".


    The test is for whether you can use feature A or not. Whether that’s because
    the engine doesn’t implement it, or doesn’t implement it correctly, doesn’t
    really make that much difference.

    > I don't encourage the sniffing of user agents either. I suppose this is
    > another good reason to use a framework that hides such detection from the
    > developer.


    How do you think the frameworks do it?
     
    Lawrence D'Oliveiro, May 5, 2011
    #11
  12. In message <>, Ralph Fox wrote:

    > On Sun, 03 Apr 2011 18:58:10 +1200, in message
    > <in95q2$i4p$> Lawrence D'Oliveiro wrote:
    >
    >> Is anybody’s code really going to be broken by this? I thought it was
    >> well understood that you should check as directly as possible for the
    >> functionality you need, not try to deduce it from purely informational
    >> fields.

    >
    >
    > If that is what you actually believe, then how do you explain this ?
    >
    >

    <"http://groups.google.com/group/mozilla.support.seamonkey/msg/628762d830897d64">

    How do you explain stupidity?
     
    Lawrence D'Oliveiro, May 5, 2011
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Some Guy...

    Packet sniff analysis question....

    Some Guy..., Jan 29, 2004, in forum: Cisco
    Replies:
    2
    Views:
    3,863
    Some Guy...
    Jan 29, 2004
  2. Marraboy

    Ethernet Frame Sniff-tastic!

    Marraboy, Aug 15, 2005, in forum: Cisco
    Replies:
    3
    Views:
    1,505
    dknetman
    Aug 15, 2005
  3. kpg

    stupid stupid stupid

    kpg, Oct 26, 2004, in forum: MCSE
    Replies:
    17
    Views:
    865
    T-Bone
    Nov 26, 2004
  4. Slumpy

    <sniff> Bye Bye Barry

    Slumpy, Jul 4, 2003, in forum: Computer Support
    Replies:
    2
    Views:
    680
    DaveG
    Jul 4, 2003
  5. =?ISO-8859-1?Q?R=F4g=EAr?=
    Replies:
    6
    Views:
    804
Loading...

Share This Page