https webpage with data: images trigger a "Page contains unencrypted information" mixed content warning

RESOLVED FIXED

Status

()

Core
Security: PSM
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: theglu, Assigned: mayhemer)

Tracking

({regression, verified1.9.1})

Trunk
regression, verified1.9.1
Points:
---
Bug Flags:
blocking1.9.2 -
wanted1.9.2 +
blocking1.9.1 -

Firefox Tracking Flags

(status1.9.2 beta1-fixed, blocking1.9.1 .4+, status1.9.1 .4-fixed)

Details

(Whiteboard: [sg:want] regression from FF3.0)

Attachments

(2 attachments, 3 obsolete attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008123017 GranParadiso/3.0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090125 Shiretoko/3.1b3pre

Https webpage with base64 encoded images trigger a "Page contains unencrypted information" with Firefox 3.1. This dosen't happend in Firefox 3.0.

Reproducible: Always

Steps to Reproduce:
Insert this into a https webpage :

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQCAYAAAAf8/9hAAAAAXNSR0IArs4c6QAAAAZiS0dEAP8A/wD/oL2nkwAAAAlwSFlzAAAN1wAADdcBQiibeAAAAAd0SU1FB9kBDxIAOdxBIbcAAAI+SURBVDjLxZO7TxRhFMV/M/PN7EPYhS02yytggo+ERAgxERsNhYnGzsQojaHT3r9F0cTaUjs6NUQLBRKDi4I8FEwkLMgO+5rdeX3XAoVYiZWnP797cu69Bv8gqZ+0QTqIdRpl1VHGvnV884CJwQgwicVtoB/ku/H4ycOnURgP/Q1g21Fw4+r0RjbbNmaq4ayO35UkXp9S2UzHxK2bE4QNl82FVwD0D49jn+hERBCRgwTiIX7pvGUGYF/BlO327d3ENfV7wuL0AyjPICIsfPvAmev3qdVqlMtlCoUCGxurDPT1kEnPomQKkRTFpXOjh4DN4kvGLuSJ/JC38y/ouXyXYrGIiBDHMVtbu1SrvXTlbfp6HcQcoVwp5hRAaWedPXFYfL+E1lAKswSRy+joKEEQICLkcjm01hiGgRcksW0b4SMKYHb+OSt6ma+VffxWRF3S5OeeMX7pHkqpwy5EBK31H90ogFODF1lbm8OtlEhloDORpbdnhDAMaTabhwbbtkkkEkRRhGVZR4BCfojJO4+o1VwQAItEIolpmliWRVtbG7s/dlDKotGo47U8CvkuAEwA3/eJoxhE0WyGuO4+nucRBAHVahXDMKg3agRhQBAGVKsVtNZHCRzHwTAMcrnc0eX9it3e3g7A6cGzhx0AKHWwQOV5jdXXb2ZOaa3BOP5ffF5ZptVqflG+3xpbWv5kh2FolEo7dnmv7Lium6zXG0nf95MiguM4QTqd9jPZTCvX2eF393QHqVRKZ7KZkP+unzPGLX8Jr7F8AAAAAElFTkSuQmCC" />

Actual Results:  
trigger a "Page contains unencrypted information" warning.

Expected Results:  
Does not complain as the information is secure..

Works in Fx3.0
(Reporter)

Updated

8 years ago
Version: unspecified → 3.1 Branch
Assignee: nobody → kaie
Component: Security → Security: PSM
Product: Firefox → Core
QA Contact: firefox → psm
Version: 3.1 Branch → Trunk

Comment 1

8 years ago
Created attachment 360802 [details]
testcase of base64 encoded image
(Reporter)

Updated

8 years ago

Comment 2

8 years ago
It works with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090201 Shiretoko/3.1b3pre

Comment 3

8 years ago
Sorry, please disregard the comment above. The page has insecure content.
(Reporter)

Comment 4

8 years ago
Don't forget to set option in preferences to show this kind of warning btw ;)
could be related to bug 455367

Updated

8 years ago
Blocks: 455367

Updated

8 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.9.1?
Keywords: regression
Whiteboard: regression from FF3.0

Updated

8 years ago
Summary: Https webpage with base64 encoded images trigger a "Page contains unencrypted information" with Firefox 3.1 → https webpage with data: images trigger a "Page contains unencrypted information" with Firefox 3.1
Not a blocker; would take a patch.
Flags: blocking1.9.1? → blocking1.9.1-

Comment 7

8 years ago
cc'ing Honza who worked on insecure image detection
(Assignee)

Comment 8

8 years ago
-> me
going to take a look at this
Assignee: kaie → honzab.moz
(Assignee)

Comment 9

8 years ago
We cannot detect from securityUI that image proxy request is using data channel to load the image - the underlying request is inaccessible - and image proxy itself cares no security info. I had an idea to let the data channel take security info from document channel of it's doc shell accessed through notification callbacks, but it is no-no because we cannot use nsIDocShell from netwerk code. We could add a new data-channel-specific code to NewImageChannel in imgLoader.cpp to add a security info there but neither libimg has access to doc shell.

So, we can add some new interface to say securityUI to ignore the content in this specific case.

However, it seems to me that we have to do some more work to fix this issue.
Status: NEW → ASSIGNED
(Assignee)

Comment 10

8 years ago
Any changes landed here should be covered by mixed content tests from bug 452401.
(Assignee)

Comment 11

8 years ago
Created attachment 365950 [details] [diff] [review]
hohoh v1

This is a bit hacky workaround. When URI scheme is data: say we didn't transfer any data from network (what is actually true). That makes the security UI ignore this image request. This is based on bz's fix for one of mixed content image bugs.
Attachment #365950 - Flags: review?(pavlov)
Attachment #365950 - Flags: review?(bzbarsky)
Wait.  Why is this the right change?  What about an image from a javascript: URI?  Isn't checking for the URI_INHERITS_SECURITY_CONTEXT flag what you really want?  And even given that, wouldn't you care about _where_ it's inheriting from?

Comment 13

8 years ago
This issue is also occurring with resource: and chrome: image file requests. It is causing partially encrypted errors to occur with NoScript, LinkAlert, and RequestPolicy extensions by causing their icons which are resource: and chrome:
Alternately, should we be checking for LOCAL_RESOURCE, if that's really the criterion we care about?
(Assignee)

Comment 15

8 years ago
CrYpTiC MauleR: This has been fixed on trunk and 1.9.1 in bug 450912, please turn your comment there, this is a different bug.
(Assignee)

Comment 16

8 years ago
Created attachment 366002 [details] [diff] [review]
v2

(In reply to comment #12)
> Wait.  Why is this the right change?  What about an image from a javascript:
> URI?  Isn't checking for the URI_INHERITS_SECURITY_CONTEXT flag what you really
> want?  And even given that, wouldn't you care about _where_ it's inheriting
> from?

javascript is ignored by security UI.

something like this?
> javascript is ignored by security UI.

Yes, I'm just saying the mechanism for ignoring these should be the the same, and use properties of the protocol, not be hack upon hack of scheme special-casing.
I like "wip" more.

Is there a reason we let file:// URIs affect security UI but don't let resource:// URIs do it?
Comment on attachment 365950 [details] [diff] [review]
hohoh v1

This is certainly not what we want, imo.
Attachment #365950 - Flags: review?(bzbarsky) → review-
(Assignee)

Comment 20

8 years ago
(In reply to comment #18)
> Is there a reason we let file:// URIs affect security UI but don't let
> resource:// URIs do it?

Files are also ignored, but not by checking a flag or a uri scheme but by QI of the request to nsIFileChannel.
(Assignee)

Updated

8 years ago
Attachment #366002 - Attachment description: wip → v2
Attachment #366002 - Flags: review?(kaie)
Attachment #366002 - Flags: review?(bzbarsky)
(Assignee)

Comment 21

8 years ago
Comment on attachment 366002 [details] [diff] [review]
v2

This fixes the problem and doesn't break regression tests we have so far. As defined, URI_INHERITS_SECURITY_CONTEXT says that requests with this kind of uri has the same security level as the document, so we may presume there is no need to consider such requests as potentially breaking security ui state. Bz, good idea.

Asking also Kai for review to let him check this.
(Assignee)

Comment 22

8 years ago
Comment on attachment 365950 [details] [diff] [review]
hohoh v1

bz found a better approach in a different code.
Attachment #365950 - Attachment is obsolete: true
Attachment #365950 - Flags: review?(pavlov)
How about we just check for the LOCAL_RESOURCE flag then?  That would cover resource, chrome, data, file, moz-icon, and anno protocols, and any extension protocol that's correctly written.  So you won't have to keep adding special-cases and _still_ break the moment an extension is in use...
(Assignee)

Comment 24

8 years ago
Created attachment 366929 [details] [diff] [review]
v3

(In reply to comment #23)
> How about we just check for the LOCAL_RESOURCE flag then?  That would cover
> resource, chrome, data, file, moz-icon, and anno protocols, and any extension
> protocol that's correctly written.  So you won't have to keep adding
> special-cases and _still_ break the moment an extension is in use...

It works for me. I don't include the URI_INHERITS_SECURITY_CONTEXT check because it's related only to wyciwyg requests that are handled specifically by the security UI code.
Attachment #366002 - Attachment is obsolete: true
Attachment #366929 - Flags: review?(kaie)
Attachment #366002 - Flags: review?(kaie)
Attachment #366002 - Flags: review?(bzbarsky)
(Assignee)

Comment 25

8 years ago
And, I will add a test for this bug after bug 480713 gets fixed and mixed content tests are re-enabled.
URI_INHERITS_SECURITY_CONTEXT has nothing to do with wyciwyg.  wyciwyg is document.write().  URI_INHERITS_SECURITY_CONTEXT is javascript: and data:.

As long as we sanely handle javascript: through some other method, patch looks good go me.
(Assignee)

Comment 27

8 years ago
Javascript is also handled separately, so it should be ok.
So wait.  With this patch, can we remove all that QI special-casing of channels we have?  As a followup bug or something?
(Assignee)

Comment 29

8 years ago
We could consider it, but what I wanted to say is that the isSubDocumentRelevant flag we set false for local resources is not relevant for wysiwyg because it is handled separately. So is javascript.

(In reply to comment #26)
> URI_INHERITS_SECURITY_CONTEXT has nothing to do with wyciwyg.

http://mxr.mozilla.org/mozilla-central/source/content/html/document/src/nsWyciwygProtocolHandler.cpp#128
Oh, huh.  I'd forgotten this part.  Those URIs never really inherit a security context, so...
Summary: https webpage with data: images trigger a "Page contains unencrypted information" with Firefox 3.1 → https webpage with data: images trigger a "Page contains unencrypted information" mixed content warning with Firefox 3.1
Duplicate of this bug: 489093
Duplicate of this bug: 486994

Comment 33

8 years ago
Hello, i have a similar problem, and i think that maybe its related to this bug. Heres my bugreport: https://bugzilla.mozilla.org/show_bug.cgi?id=498376

Comment 34

8 years ago
Bug still exists in 3.5RC2. The following in a linked CSS file triggers the bug:
background-image: url(data:image/gif;base64,AAAA);

Updated

8 years ago
Duplicate of this bug: 501458

Updated

8 years ago
Duplicate of this bug: 501438

Updated

8 years ago
Duplicate of this bug: 475450
Duplicate of this bug: 502008
Duplicate of this bug: 502008

Updated

8 years ago
Summary: https webpage with data: images trigger a "Page contains unencrypted information" mixed content warning with Firefox 3.1 → https webpage with data: images trigger a "Page contains unencrypted information" mixed content warning

Comment 40

8 years ago
Is there an eta on getting this fixed?  I'd be happy to be of any assistance.
(Assignee)

Comment 41

8 years ago
(In reply to comment #40)
> Is there an eta on getting this fixed?  I'd be happy to be of any assistance.

Depends on Kai's or someones review. I'll try to find someone else to do it.
Flags: wanted1.9.1.x?
Flags: blocking1.9.2?
(Assignee)

Comment 42

8 years ago
Comment on attachment 366929 [details] [diff] [review]
v3

Robert, could you please take a look? However, it's not that simple to review...
Attachment #366929 - Flags: review?(kaie) → review?(rrelyea)
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-

Comment 43

8 years ago
Comment on attachment 366929 [details] [diff] [review]
v3

The change looks reasonable, but I am unfamiliare with the URI handle to know if the constant change is the correct one, you probably need a different reviewer.

bob
Attachment #366929 - Flags: review?(rrelyea)
(Assignee)

Updated

8 years ago
Attachment #366929 - Flags: review?(kaie)
(Assignee)

Updated

8 years ago
Whiteboard: regression from FF3.0 → regression from FF3.0 [needs review kaie]

Comment 44

8 years ago
Any chance of this being fixed in a 3.5.x release?  Right now I'm having to tell my customers to wait to upgrade to 3.5 because of this.  I really don't want to have to tell them they'll never be able to.
status1.9.1: --- → ?
Flags: wanted1.9.1.x?

Comment 45

8 years ago
I'll +1 this one.  This is causing the bogus security warning for my add-on, as well as many others:

http://www.google.com/search?q=%22contains+unauthenticated+content%22+firefox+add-on

Very unsettling for end users.

Comment 46

8 years ago
This is a serious security flaw, because it destroys the value of that important error message, as everyone gets trained to ignore it.

I realize users are trained to click OK to just about anything already, but that should be getting better, not made worse, especially not by a case of "crying wolf" in a security matter.

Comment 47

8 years ago
I completely agree. I am holding off updating to 3.5 because of this. It should be a priority
(In reply to comment #46)
> This is a serious security flaw, because it destroys the value of that
> important error message, as everyone gets trained to ignore it.
> 
> I realize users are trained to click OK to just about anything already, but
> that should be getting better, not made worse, especially not by a case of
> "crying wolf" in a security matter.

This bug doesn't need "me too" advocacy. No one disputes that it should be fixed.  What this bug actually needs...

(In reply to comment #25)
> And, I will add a test for this bug after bug 480713 gets fixed and mixed
> content tests are re-enabled.

is an updated patch with tests for review. Honza - I would personally expect that for this change, someone like bz might be a good alternate reviewer?
(Assignee)

Comment 49

8 years ago
(In reply to comment #48)
> Honza - I would personally expect
> that for this change, someone like bz might be a good alternate reviewer?

Yes, I will create a test for this and add a new patch, then I'll ask bz for review.
(Assignee)

Comment 50

8 years ago
Created attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]
Attachment #366929 - Attachment is obsolete: true
Attachment #394815 - Flags: review?(bzbarsky)
Attachment #366929 - Flags: review?(kaie)
(Assignee)

Updated

8 years ago
Whiteboard: regression from FF3.0 [needs review kaie] → regression from FF3.0 [needs review bz]
Attachment #394815 - Flags: review?(bzbarsky) → review+
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

I suppose we can live with this....
(Assignee)

Updated

8 years ago
Attachment #394815 - Flags: approval1.9.2?

Comment 52

8 years ago
I apologize for the noob comment, but does the approval1.9.2? flag mean this is being proposed for 1.9.2?  Is there any reason not to propose that it be added to 1.9.1.x given that it seems to be a substantial security concern?
(Assignee)

Comment 53

8 years ago
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

http://hg.mozilla.org/mozilla-central/rev/bec02958a3e1
Attachment #394815 - Attachment description: v3 + test → v3 + test [Checkin comment 52]

Comment 54

8 years ago
If "This bug doesn't need "me too" advocacy. No one disputes that it should be
fixed.", why is not being fixed yet? It was reported in Feb, now it is September, this is over 6 months and several hotfixes old... This is getting quite frustrating...
It's being fixed.  The fix is in the development builds. It's being tested.  Once it's been satisfactorily tested, it will be approved for the upcoming Firefox 3.6 release.

At the moment, no one has requested approval to land this on 1.9.1 (Firefox 3.5.x).  Need driver triage here to see whether it's even wanted there.

If your question is why it took so long to fix, it's because it's not particularly simple to fix and people have other priorities too.
blocking1.9.1: --- → ?
(In reply to comment #54)
> If "This bug doesn't need "me too" advocacy. No one disputes that it should be
> fixed.", why is not being fixed yet? It was reported in Feb, now it is
> September, this is over 6 months and several hotfixes old... This is getting
> quite frustrating...

It also doesn't need entitlement. Firefox is built largely by volunteers and
even those paid to work on it charge nothing for the product or its support. If
you want any bug in Firefox fixed, please feel free to attach a patch. If
coding isn't your thing, I submit to you that other forms of help (regression
range finding, test reducing, running development nightly builds) are
substantially superior to folding your arms and insisting that, damnit, your
bug is most important and you'll not tolerate these volunteers working on other
bugs first.

As it happens, Honza has fixed this bug on our mozilla-central development
branch and is now awaiting approval to land it on the release branch as well.
I'm sure he will comment here once he has done so.

Any time you want to help fix a bug instead of complaining about the
insufficiency of the speed with which other people leap to your assistance, we
have an ample backlog. This is an open source project devoted to making the
internet a better place. We're not sitting on our hands, cackling about the
torment we cause our users, nor do we have our fingers up our nose waiting for
helpful souls to guide us as to which bug we should fix next. I'm sorry if I
seem harsh, but my hope is to turn your evident energy for the project in more
positive directions, because right now you're sort of seeming like an entitled
dickhead, and I'm pretty sure that's not your intent.
Whiteboard: regression from FF3.0 [needs review bz] → regression from FF3.0

Comment 57

8 years ago
Look, I understand this is an open source project and done by volunteers and I am highly grateful on that.
I am highly security conscious person and this effects FF security. How do I know whether the page has insecure content or not if I get warning for every SSL page I visit? (And yes certain people will get that for every SSL page they visit, irregardless of mixed content or not). One of my primary reasons I use FF is I find it is a lot securer. And that is one of the primary reasons I recommend to my friends. This problem does no bode well with that and it reduces FF usage. I don't understand why this is not scheduled for 3.5.x?  After all it is a security flaw. When will 3.6 come out?

And  Johnathan, this is not MY bug, it was reported by somebody else and it is effecting plenty other people. If you do not understand my frustration on a security issue reported 7 months ago and not fixed, you have a problem. I am involved with Firefox AS MUCH AS I CAN. My opening bug reports proves that. It definitely does not help you calling people ****

Comment 58

8 years ago
I'd hate to see this turn into a flame war, especially because I think it would distract from getting this important bug fixed.

Johnath, I tried to ask whether this can make it into 1.9.1 here:
https://bugzilla.mozilla.org/show_bug.cgi?id=477118#c52

But frankly I don't understand the bugzilla process well enough to know how to do this formally.  I'm also happy to help with testing etc, but I'm such a noob to the process I don't know where to start.
Landed on trunk so status is "fixed". Still need approval to land on 1.9.2 (triagers there were probably looking for trunk-fixed bugs and skipping this one).
Status: ASSIGNED → RESOLVED
blocking1.9.1: ? → .4+
Last Resolved: 8 years ago
status1.9.1: ? → wanted
Resolution: --- → FIXED
Whiteboard: regression from FF3.0 → [sg:want]regression from FF3.0
Whiteboard: [sg:want]regression from FF3.0 → [sg:want][needs a=1.9.2][needs 1.9.1 patch or approval request]regression from FF3.0
Attachment #394815 - Flags: approval1.9.2? → approval1.9.2+
(Assignee)

Comment 60

8 years ago
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

This patch clearly applies to 1.9.1 as well.
Attachment #394815 - Flags: approval1.9.1.4?
Whiteboard: [sg:want][needs a=1.9.2][needs 1.9.1 patch or approval request]regression from FF3.0 → [sg:want] regression from FF3.0
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

This means a file: uri will also not cause mixed-mode, but on windows a file: uri can be a UNC path that goes out over the network.
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

Approved for 1.9.1.4, a=dveditz for release-drivers
Attachment #394815 - Flags: approval1.9.1.4? → approval1.9.1.4+
(Assignee)

Comment 63

8 years ago
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/9d30d729f7f6
Attachment #394815 - Attachment description: v3 + test [Checkin comment 52] → v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63]
(Assignee)

Updated

8 years ago
status1.9.1: wanted → .4-fixed
(Assignee)

Comment 64

8 years ago
Comment on attachment 394815 [details] [diff] [review]
v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/fa380bc4f892
Attachment #394815 - Attachment description: v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] → v3 + test [Checkin comment 52] [Checkin 1.9.1 comment 63] [Checkin 1.9.2 comment 64]
(Assignee)

Updated

8 years ago
status1.9.2: --- → beta1-fixed
Duplicate of this bug: 518280
Verified fixed for 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.4pre) Gecko/20090930 Shiretoko/3.5.4pre using attached testcase.
Keywords: verified1.9.1
Duplicate of this bug: 520464

Comment 68

8 years ago
I just installed 3.5.4 and I am very happy to report that this bug is now fixed. Thanks to everyone who helped

Comment 69

8 years ago
Do not fixed yet.
Try load data image encoded from external css file under ssl.

Comment 70

8 years ago
Can someone confirm that 3.5.4 was the first version that has this fix?  And does anyone know in what version this bug first appeared?
> Can someone confirm that 3.5.4 was the first version that has this fix? 

Yes.

> And does anyone know in what version this bug first appeared?

3.5.0.
Unless you were asking for the specific 3.5 alpha/beta/nightly/whatever that first had the behavior?

Comment 73

8 years ago
Hi Boris,

    Thanks for the quick reply.  The original poster on this thread reported this problem in ff3.1.  Are you sure it didn't appear until 3.5.0?

-jon
The release after 3.0 was 3.5.0.  "3.1" was its internal version number in the early stages, before 3.0 even shipped.

Comment 75

8 years ago
Hi Boris,

    That clears things up.  So in which alpha/beta/nightly version did it first appear?

Thanks,

-jon
When bug 135007 landed, which puts you at Gecko 1.9.1a2 (aka Firefox "3.1a2") or the 2008-09-02 nightly.

Not sure why that matters, though...
Blocks: 135007
No longer blocks: 455367
(Assignee)

Updated

7 years ago
Duplicate of this bug: 482245

Comment 78

7 years ago
I still have this bug. For example this site on Mozilla Developer: https://developer.mozilla.org/devnews/index.php/2010/03/03/mozilla-developer-preview-now-available-with-out-of-process-plugins/

But of course this is not the only one.

Comment 79

7 years ago
Because that site contain a mixture of secure and unsecured content. You are supposed to have the warning...

Comment 80

7 years ago
I have also other sites who should be allright but does now and then give that warning and sometimes does not. Even here on bugzilla.

Comment 81

7 years ago
Sometimes here i have the same problem and on Yahoo login page and when i Refresh it's secured again,it's not happening all the time for me,but i can confirm this old bug.
If what you're seeing is intermittent, it is NOT this bug (which happened 100% reliably).  Please file a new bug with steps to reproduce (e.g. the exact pages you see it happening on) and cc me on it.

Comment 83

7 years ago
I'll file a new bug today.

Comment 84

7 years ago
I filed a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=550580
You need to log in before you can comment on or make changes to this bug.