669814 - When needed, automatically update Accept-Charset to match Accept-Language if the latter is changed by user via UI (with possible opt-out feature)

Status: RESOLVED INVALID

(Core :: Internationalization, defect)

Description

[Reşat SABIQ (Reshat)]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0
Build ID: 20110615151330

Steps to reproduce:

Changed Accept-Language HTTP header using UI.


Actual results:

Accept-Charset HTTP header's first encoding didn't get automatically updated to use an encoding matching the first locale in Accept-Language header.
intl.charset.default should be automatically updated to an encoding matching the first locale in intl.accept_languages.


Expected results:

intl.charset.default should be automatically updated to an encoding matching the first locale in intl.accept_languages.

Comment 1

[Reşat SABIQ (Reshat)]

Here's a possible workflow:
If the first locale has changed, upon closure of Languages dialog show an extra panel under Languages, saying something along the following lines:

 Your preferred encoding has been automatically updated to have the following encoding first: ISO-dddd-d. This has been done in order to match the new most preferred locale.
 Change Preferred Encoding Back

This message only needs to be shown until the user closes preferences/options dialog or switches to a different tab of it.

P.S. Sorry for 1 duplicated sentence in the original post: resulted from hurrying (and trying to copy all the text to clipboard just in case, then going to advanced form, then going back (and not re-reading everything)).

Comment 2

[Reşat SABIQ (Reshat)]

I'm not sure whether bug 572650 depends on this bug, but the 2 are related, so i think it makes sense to reflect that. If there are more votes to not reflect that, that's fine too.

P.S. Increased fingerprintability (and entropy) here arises from mismatch of Accept-Language (and navigator.language) and Accept-Charset, but it could be argued that it's lower priority because the user made the change on their own. However, most users aren't aware that the change they make increases fingerprintability, so the app does have a responsibility to at least inform them about it (which could be a short term solution before a robust, real solution, if so decided upon).

Comment 3

[Boris Zbarsky [:bzbarsky]]

What does this have to do with the DOM?

Comment 4

[Reşat SABIQ (Reshat)]

(In reply to comment #3)
I wasn't sure about the component, but bug 55366, for instance, being a similar privacy bug, had DOM under component, so i went with that. If Internationalization is an appropriate component for fingerprintability bugs (along with features enabling usage of multiple locales, etc.), that's cool with me.

Comment 5

[Gordon P. Hemsley [:GPHemsley]]

I do believe this problem may go away or be reduced with our plans for BCP 47 implementation, so I'll mark it as blocking the tracking bug.

In particular, I believe the trend is toward UTF-8, rather than ISO-8859-*, etc. Simon will have to confirm that.

Fingerprintability is also on the radar.

Comment 6

[Simon Montagu :smontagu]

I believe that the problem has already gone away, since we no longer send the Accept-Charset header at all (bug 572652)

Comment 7

[Reşat SABIQ (Reshat)]

Based on bug 572652, it appears the code to resolve this issue was checked in in May, and should be released with Firefox 6. I'll try to check that out in Firefox 6, but it does appear Firefox 6 will be free from this issue, which is all i hoped for. :)

Comment 8

[Reşat SABIQ (Reshat)]

FYI: i have checked, and the issue is still not resolved in Firefox 6, and Firefox 7 beta 1. From bug 572652, comment 28 it appears the issue might be resolved only in Firefox 8 or later. Bug 572652 that is to provide solution to the issue reported here doesn't appear to be truly resolved yet, since it depends on 2 unresolved bugs at this time: bug 657153, and bug 664743. Anyway, i'll keep checking for the fix as new releases come out...

P.S. A comment on RESOLVED options: none of them really fits here. This bug is not really INVALID, because there is a valid issue reported, it's just that a different approach to fixing it is currently being attempted (dropping the field, instead of matching its value with another field's; this is also why some issues arose with that approach: it's less backwards-compatible); it's not really WONTFIX because the issue will be fixed; it's not quite DUPLICATE, because a different way of fixing the issue is suggested here in comparison to bug 572652 (this alternative could be re-considered if there are serious issues with the other approach). IMHO, something like FIXEDDIFFERENTLY would fit the bill much better.