262663 - Option to send evangelism messages using the UA string

Status: VERIFIED WONTFIX

(SeaMonkey :: General, enhancement)

Description

[Prognathous]

Instead of expecting common users to contact the maintainers of broken websites,
it would be nice Mozilla would do it for them via the UA String.

Here's the flow that I have in mind:

1. While surfing, a user encounters a broken website.
2. He/She clicks a menu option (e.g. "Tag site as broken").
3. From then on, every time they visit this page/site, Mozilla will modify the 
   UA string to:

     "Your site is broken in standard compliant browsers. See <URL> for tips
      on how to fix it. Note that the US Department of Homeland Security
      instructs to avoid Internet Explorer due to security issues."

Once the webmaster goes over the site logs and sees these entries, he/she is
likely to notice that (1) IE is not the only browser out there -and- (2)
problems are fixable.

This bug depends on Bug 80658 ("Site specific User-Agent").

Prog.

Comment 1

[Bill Mason]

That would such a completely invalid UA string to be throwing around, it would
be an evangelism issue itself.

And I would be most curious to see what one URL you could direct people to that
will hope to address every issue (or even a majority) that web sites might be
having with Mozilla that need fixing.

And since your motiviation for suggesting this has nothing to do with security,
it's meaningless to throw a mention of IE's security issues into it.

Finally, no one is going to fix a web site because of a spoofed UA string.  They
might fix it if users/customers of the site complain about it not working for them.

Seriously suggesting someone WONTFIX this bug.

Comment 2

[Bob Clary [:bc] (inactive)]

agreed. the new tech evangelism reporting tool will collect info on broken sites
and we can address them one-one if they are important. -> WONTFIX.

Comment 3

[Prognathous]

(In reply to comment #1)
> That would such a completely invalid UA string to be throwing around, it would
> be an evangelism issue itself.

It's not impossible to append this message to the real UA string, or vice versa.

> And I would be most curious to see what one URL you could direct people to that
> will hope to address every issue (or even a majority) that web sites might be
> having with Mozilla that need fixing.

I would base such a page on the Site Evangelism Letter. See
http://www.mozilla.org/projects/tech-evangelism/site/tech-letter-en.html
 
> And since your motiviation for suggesting this has nothing to do with security,
> it's meaningless to throw a mention of IE's security issues into it.

The most common answer tech evangelists face is "Just use Explorer. My site
works perfectly well with it". Stating that CERT recommends to avoid IE unarms
this claim from the very beginning.

> Finally, no one is going to fix a web site because of a spoofed UA string.  They
> might fix it if users/customers of the site complain about it not working for
them.

Most users/customers won't go to the length of writing letters, but many of them
would click a menu option.

As for the site maintainers, with such a message they (1) can't assume that
their site works fine for everyone -and- (2) they do get a good lead on how to
fix it. If they still choose to ignore this new information, it's their choice,
but at least we did *something* to notify them.

(In reply to comment #2)
> agreed. the new tech evangelism reporting tool will collect info on broken sites
> and we can address them one-one if they are important. -> WONTFIX.

With so few evangelist, it would still be too much work. Of more than 2300 TE
bugs, how many have reporters have actually contacted the site maintainers? How
many more sites are out there that no-one is willing to invest the time to
evangelize? That's where a UA-based message has its merits - it takes
zero-effort and can easily be done by non-evangelists.

Please consider re-opening this bug.

Prog.

Comment 4

[Bob Clary [:bc] (inactive)]

Asa, can you give your opinion here? Thanks.

Comment 5

[Asa Dotzler [:asa]]

I agree with bob. This is wontfix. We're going to approach this with additional
tools and processes. Making a client change like this is not going to happen.