Closed Bug 616712 Opened 9 years ago Closed 9 years ago

Repeated warning about visiting encrypted page containing unencrypted information

Categories

(Firefox for Android Graveyard :: General, defect)

ARM
Android
defect
Not set

Tracking

(fennec2.0b3+)

VERIFIED FIXED
Tracking Status
fennec 2.0b3+ ---

People

(Reporter: ehsan, Assigned: mbrubeck)

Details

Attachments

(1 file)

Every time I visit Google Reader on my phone using Fennec, I get this Security Warning:

You have requested an encrypted page that contains some unencrypted information.  Information that you see or enter on this page could easily be read by a third party.

[x] Alert me whenever I'm about to view an encrypted page that contains some unencrypted information.

When I uncheck the above box and press OK, I expect not to see this message next time.  But the message reappears no matter how many times I have seen this dialog.
tracking-fennec: --- → ?
tracking-fennec: ? → 2.0b3+
Assignee: nobody → doug.turner
this alert happens from content.  the result of the the checkbox is given back to content, and it tries to set a perferences which fails (because you can't write out preferences from the child process)

Options:

1) Special case this preferences

2) Just removing this warning from Fennec (by adding the correct pref to mobile.js)


I am leaning toward (2).
(In reply to comment #1)
> this alert happens from content.  the result of the the checkbox is given back
> to content, and it tries to set a perferences which fails (because you can't
> write out preferences from the child process)
> 
> Options:
> 
> 1) Special case this preferences
> 
> 2) Just removing this warning from Fennec (by adding the correct pref to
> mobile.js)
> 
> I am leaning toward (2).

Is this the only similar alert?
Here's a complete list of similar prefs.  The only ones that are enabled by default are this one (viewing_mixed) and "You have requested a page that uses low-grade encryption" (entering_weak):

> 76 pref("security.warn_entering_secure",    false);
> 77 pref("security.warn_entering_weak",      true);
> 78 pref("security.warn_leaving_secure",     false);
> 79 pref("security.warn_viewing_mixed",      true);
> 80 pref("security.warn_submit_insecure",    false);

http://mxr.mozilla.org/mozilla-central/source/netwerk/base/public/security-prefs.js
In addition to doug's options, we could remote nsISecurityWarningDialogs so that the dialog is displayed by the parent process, or override it to provide a mobile-specific UI.

Whatever else we do, I would suggest changing the Larry UI to use a red background and provide information when on a weak or mixed SSL page.
right, remote nsISecurityWarningDialogs.  quite easy too.
spoke too soon.  not that easy. that interface requester fans out a bit.
spoke to jesse, dveditz, and lucas.

i think we all agreed that this dialog was not very important as it is currently implemented.  jesse suggested it had lots of false positives.  It also looks like it is only ever displayed one time -- not per url.  Lucas mentioned there are bugs to improve this -- for example, XHR loads of http content that get eval'ed are not monitored.

For this bug, we believe it is fine to set the security.warn_viewing_mixed pref to false in Fennec.
Attached patch patchSplinter Review
Assignee: doug.turner → mbrubeck
Status: NEW → ASSIGNED
Attachment #496269 - Flags: review?(doug.turner)
Comment on attachment 496269 [details] [diff] [review]
patch

// Broken in e10s

to

// Warning is disabled.  See Bug 616712.
Attachment #496269 - Flags: review?(doug.turner) → review+
Pushed with comment change: http://hg.mozilla.org/mobile-browser/rev/32803bacba02
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Ehsan Akhgari, can you provide the Build Id for this reported bug and the device? It seems to be verified fixed now, but I also have to be sure I could reproduce this issue on my device
Verified the pref change - Mozilla/5.0 (Android; Linux armv7l; rv:2.1.1) Gecko/20110415 Firefox/4.0.2pre Fennec/4.0.1 ID:20110415172201
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.