Open Bug 503221 Opened 11 years ago Updated 1 year ago
Locale can be determined using jar: protocol to test resource:///chrome/ entries
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:18.104.22.168) Gecko/2009060214 Firefox/3.0.11 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:22.214.171.124pre) Gecko/20090708 Shiretoko/3.5.1pre The jar: protocol can be used to load resource:///chrome/ entries as script. By examining error responses to differentiate between load failure and parse errors, the locale of the browser can be determined. For users that have modified their user-agent string to mask their actual locale, this behavior may reduce their privacy. Reproducible: Always
demonstration of using jar: protocol to load resource:///chrome/ entries to determine locale.
This is similar to bug 292789, where you could detect the presence of various extensions by loading chrome: URIs from content. I don't think this is serious enough to keep private. You can do the same thing with chrome://global/locale/ can't you?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Product: Firefox → Core
QA Contact: general → general
Why is jar: even relevant here? Just because those files are jars?
(In reply to comment #2) > This is similar to bug 292789, where you could detect the presence of various > extensions by loading chrome: URIs from content. I don't think this is serious > enough to keep private. In Firefox 2, detailed script parse errors were generated. This allowed for partial content reading. Beginning with Firefox 3, this was no longer possible. In general, there are three tests that could be applied using script to read resource and chrome files: 1) the file does not exist 2) file exists but can't be parsed as script 3) file exists and can be parsed as script > You can do the same thing with chrome://global/locale/ can't you? chrome://global/locale/ gets resolved to the appropriate locale. Because we can't access any content, we don't get any additional information about what locale it is.
(In reply to comment #3) > Why is jar: even relevant here? Just because those files are jars? Using jar: provided the appropriate negative response to detect missing files. It is quite possible that jar: wouldn't be required.
You need to log in before you can comment on or make changes to this bug.