Closed Bug 1145261 Opened 9 years ago Closed 9 years ago

Add some more noticeable UI to warn RC4-only servers

Categories

(Firefox :: Security, defect)

Product:
Firefox
Component:
Security
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox39 + wontfix
firefox40 + wontfix
firefox41 + wontfix

People

(Reporter: emk, Unassigned)

References

Details

Attachments

(2 files, 1 obsolete file)

Screenshot 2015-04-16 09.45.51.png
111.74 KB, image/png
Details
Screenshot 2015-05-04 10.52.51.png
90.46 KB, image/png
Details 
The current indicator (grey triangle icon) is too unnoticeable to warn users.
yeah pls add a warning that explains that the encryption used by that website (obviously rc4 but that doesn't matter to the end user and could be information that could be shown on expanding the info) is deprecated by now and insecure.

It should explain that it shouldnt be considered safe anymore in public environments (starbucks/public wifi) and shouldn't be used for online banking or buying stuff)

But it should still allow users to continue.

This could be done fast and before RC4 is blocked completely (except the whitelist).

a FF 36 fix or as part of FF 37 maybe
(In reply to Djfe from comment #1)
> a FF 36 fix or as part of FF 37 maybe

I'm afraid it is impossible because this requires localizable string changes.
well the faster we get going here (provide a patch) the faster it will be in.
The translation community is quite good to. And it's probably not that much text.

This should be a high priority to get it out fast IMO.

There could be an entry in about:config to disable the warning (for users that know about the risks and surf mostly on rc4 secured websites).


When will 37 be released btw.?
Hmm, I'm not sure about adding a doorhanger for this. If we think it's serious enough to interrupt the user, we should just refuse to load it. (Which, I presume, is the long term plan anyway when RC4-only servers will just error out with ssl_error_no_cypher_overlap.) Otherwise it an annoyance that most users won't understand or be able to make an informed decision about.

But it might be make the UI more alarming, perhaps akin to enabling mixed content on a page? http://cl.ly/image/3J2P1W1d0e1Y
A doorhanger is not a great idea here. An interstitial warning page is generally what's been suggested. Something like a standard security error page, but with the ability to override. Doorhangers are designed to be ignorable.

If you want it to really have the desired effect with a warning/error page, add the phrase: "Browsers that connect to this site without warning or error are out-of-date and insecure."

Really, though, someone needs to work closely with some people from Google & Microsoft and just kill RC4 in all browsers entirely all on the same day. (but that's entirely too logical to happen)
I think it's serious enough to interrupt the user, because else we won't reach all admins in time :/
(then they would suffer from being not available in any current browser at all, which of course would be their fault, but still)
but it's also important to inform the user about the problem

a warning like mixed content might be nice, but is not alarming enough and most people ignore them anyways:
- they think it's mixed content and nothing new
- since they can reach the site they don't expect any issues at all
- it's worse than just mixed content
- a mixed content warning is not that evident as displaying a whole warning on the page
(In reply to Justin Dolske [:Dolske] from comment #4)
> Hmm, I'm not sure about adding a doorhanger for this. If we think it's
> serious enough to interrupt the user, we should just refuse to load it.
> (Which, I presume, is the long term plan anyway when RC4-only servers will
> just error out with ssl_error_no_cypher_overlap.)

The problem is that ssl_error_no_cypher_overlap is not a dedicated error code for RC4-only servers. It is impossible to determine if the server uses RC4 reliably without completing the handshake. And it is too late to shutdown the connection after the handshake finished (cookie will be already sent). I would not like to repeat bug 1113780.

> But it might be make the UI more alarming, perhaps akin to enabling mixed
> content on a page? http://cl.ly/image/3J2P1W1d0e1Y

Sounds good.
Summary: Add doorhanger to warn RC4-only servers → Add some more noticeable UI to warn RC4-only servers
Tracking this for 39. 

I'd like to have QA verify this works as we expect it to once the patch lands. 

I agree that since we are planning to completely disabled rc4 with 39 (as described in bug 999544) we should be contacting teams from other browsers. Who would be the best person to initiate or coordinate that?
tracking-firefox39: --- → +
Flags: qe-verify+
rbarnes, keeler, what is your intention for RC4 ? Should the UI be going into 39, or 40 at this point? Who should be making the decisions about how the ui works and what messages need to be there, and when it should ship?
Flags: needinfo?(rlb)
Flags: needinfo?(dkeeler)
This is something the UX team should address. Failing that, perhaps someone on the content security engineering team can take this on (maybe :tanvi or :sworkman). We'd like to ship disabling RC4 in 39 if possible, but if the UI isn't ready, maybe we'll have to hold it back a release.
Flags: needinfo?(dkeeler)
philipp this may be something your team should look at. 
tanvi, also need-info-ing you in here to have a look or pass it on to whoever should review it.
Flags: needinfo?(tanvi)
Flags: needinfo?(philipp)
From reading the bug comments, I'm not sure what the plan is here.

Are we proposing an interstitial page for rc4 warnings, or just a different site identity icon?

Since Firefox 36, pages that have certificates using rc4 will show a grey triangle instead of a lock in the url bar - https://bugzilla.mozilla.org/show_bug.cgi?id=1093595.  Do we want to change that triangle to yellow?

I think we need to be more careful about how we make this change, so that we can adequately inform the user about whether the icon means mixed content or weak encryption.  We can do this by giving better information in the site identity box that shows up when you click the lock/triangle/globe.
Flags: needinfo?(tanvi)
That sounds almost too subtle too me.
Even though users will eventually pick on the meaning of the icon, it should be an eye catcher somehow since rc4 is going to be disabled in a few months already.
Relaying this to Ash who's been doing work in that area.

Some thoughts from a very brief scanning of this thread:
Generally, making warnings like this too loud will teach users to ignore loud warnings.
The question also is: What would be the ideal action for the user to take? If we think there is imminent risk, straight up blocking might be the better solution.
Flags: needinfo?(philipp) → needinfo?(agrigas)
If we simply block RC4-only servers, users will consider the browser is broken and switch to other browsers because no other browsers degrade the UI for RC4-only servers.
To repeat myself, again: Has anyone from Mozilla officially tried to get in contact with at least someone from Google in order to properly coordinate just dropping all RC4 support on the same day in both browsers? This is the correct solution, but it just seems to be ignored as a possibility.
(In reply to Dave Garrett from comment #16)
> To repeat myself, again: Has anyone from Mozilla officially tried to get in
> contact with at least someone from Google in order to properly coordinate
> just dropping all RC4 support on the same day in both browsers? This is the
> correct solution, but it just seems to be ignored as a possibility.

I agree with Philipp that if we think this is a high priority for the user to see and be aware of entering sensitive data, we should show a page level warning and remove the lock icon in the identity block and put a yellow yield icon with a line through the https to enforce its not secure.  (see attachment).
Flags: needinfo?(agrigas)
proposed UX treatment
Attached image Screenshot 2015-04-16 10.02.59.png (obsolete) — 
Page warning (ignore styling this is a sketch and would match format of similar pages we have)
(In reply to agrigas from comment #19)
> Created attachment 8593366 [details]
> Screenshot 2015-04-16 10.02.59.png
> 
> Page warning (ignore styling this is a sketch and would match format of
> similar pages we have)

The problem is that we can't reliably determine if the server is RC4-only without connecting the server with RC4 cipher suites offered.
(In reply to Masatoshi Kimura [:emk] from comment #20)
> (In reply to agrigas from comment #19)
> > Created attachment 8593366 [details]
> > Screenshot 2015-04-16 10.02.59.png
> > 
> > Page warning (ignore styling this is a sketch and would match format of
> > similar pages we have)
> 
> The problem is that we can't reliably determine if the server is RC4-only
> without connecting the server with RC4 cipher suites offered.

If we can't detect it then, how can we give any feedback?
(In reply to agrigas from comment #21)
> (In reply to Masatoshi Kimura [:emk] from comment #20)
> > (In reply to agrigas from comment #19)
> > > Created attachment 8593366 [details]
> > > Screenshot 2015-04-16 10.02.59.png
> > > 
> > > Page warning (ignore styling this is a sketch and would match format of
> > > similar pages we have)
> > 
> > The problem is that we can't reliably determine if the server is RC4-only
> > without connecting the server with RC4 cipher suites offered.
> 
> If we can't detect it then, how can we give any feedback?

If we don't block the connection to RC4-only servers, we can detect the server selected RC4. But in that case, it's too late to show page level warnings because we already sent cookies or other credentials to the server.
If we block the connection to RC4-only servers, we cannot detect the server requires RC4. So we can't show dedicated warnings for RC4-only servers.
So we can show yellow icon and line through the https (such as comment #20), but can not show page level warnings (such as comment #21).
(In reply to Masatoshi Kimura [:emk] from comment #23)
> So we can show yellow icon and line through the https (such as comment #20),
> but can not show page level warnings (such as comment #21).

Sorry, comment #18 and #19, respectively.
(In reply to Masatoshi Kimura [:emk] from comment #24)
> (In reply to Masatoshi Kimura [:emk] from comment #23)
> > So we can show yellow icon and line through the https (such as comment #20),
> > but can not show page level warnings (such as comment #21).
> 
> Sorry, comment #18 and #19, respectively.

Why can't we mask the page with content when we show the yield icon? If we set a rule when the yield shows to cover the page with something else to prevent the user from seeing it if we're not willing to block it outright?
(In reply to agrigas from comment #25)
> (In reply to Masatoshi Kimura [:emk] from comment #24)
> > (In reply to Masatoshi Kimura [:emk] from comment #23)
> > > So we can show yellow icon and line through the https (such as comment #20),
> > > but can not show page level warnings (such as comment #21).
> > 
> > Sorry, comment #18 and #19, respectively.
> 
> Why can't we mask the page with content when we show the yield icon? If we
> set a rule when the yield shows to cover the page with something else to
> prevent the user from seeing it if we're not willing to block it outright?

Of course we can mask the page, but it will give a false impression we didn't send cookies or other credentials to the server.
(In reply to Masatoshi Kimura [:emk] from comment #26)
> (In reply to agrigas from comment #25)
> > (In reply to Masatoshi Kimura [:emk] from comment #24)
> > > (In reply to Masatoshi Kimura [:emk] from comment #23)
> > > > So we can show yellow icon and line through the https (such as comment #20),
> > > > but can not show page level warnings (such as comment #21).
> > > 
> > > Sorry, comment #18 and #19, respectively.
> > 
> > Why can't we mask the page with content when we show the yield icon? If we
> > set a rule when the yield shows to cover the page with something else to
> > prevent the user from seeing it if we're not willing to block it outright?
> 
> Of course we can mask the page, but it will give a false impression we
> didn't send cookies or other credentials to the server.

Ok then I guess the best we can do is change the icon in the identity block and work towards blocking these pages entirely if we think it is that serious of a threat to sensitive information.
From what I hear from the Firefox frontend team, putting a strike through the https is hard (and potentially impossible).

Right now pages that use rc4 certs get the grey yield triangle instead of the lock.  This bug is to change that to the yellow triangle and add a strikethrough (if possible).  Is that correct?

And then later (in a separate bug and hopefully with coordination with other browser vendors) we can start blocking the loads if we detect a cert with rc4.
(In reply to Tanvi Vyas [:tanvi] from comment #28)
> From what I hear from the Firefox frontend team, putting a strike through
> the https is hard (and potentially impossible).

Why? We already apply styling to various different parts of the URI at once by making the domain.tld a darker shade than the rest. What barrier is there to putting a strikethrough on the protocol? (making it a red strikethrough might be a PITA, but that's not in the current proposal)

> rc4 certs [...] cert with rc4

RC4 is a cipher, not a certificate issue. The certificate is used to authenticate the connection and the cipher is used to encrypt the subsequent traffic.
this ui warning is only useful for the transition phase.
we probably won't need it anymore after a year or something like that

so we could just open the connection don't offer rc4
if there is no match for the encryption on the server-side -> retry with rc4 only (resend all data including POST)
if this matches show the warning and allow the user to progress if he desires to
else show the error message for no encryption match

after the transition phase is over, rc4 will be removed completely or only allowed for white-listed pages where this ui warning isn't needed anymore
(In reply to Tanvi Vyas [:tanvi] from comment #28)
> From what I hear from the Firefox frontend team, putting a strike through
> the https is hard (and potentially impossible).
> 
> Right now pages that use rc4 certs get the grey yield triangle instead of
> the lock.  This bug is to change that to the yellow triangle and add a
> strikethrough (if possible).  Is that correct?
> 
> And then later (in a separate bug and hopefully with coordination with other
> browser vendors) we can start blocking the loads if we detect a cert with
> rc4.

correct.
(In reply to Djfe from comment #30)
> so we could just open the connection don't offer rc4
> if there is no match for the encryption on the server-side -> retry with rc4
> only (resend all data including POST)
> if this matches show the warning and allow the user to progress if he
> desires to

Unfortunately, POST data will already be sent to the sever before the upper layers tell the result. So we can't show the warning before progress.

If we could easily block and detect RC4 servers, I would have already implemented it.
POST data is sent unencrypted over the internet?
doesn't sound to good to me.

And if the cipher suites don't match:
will the server even react to the POST data? Or does one of the lower layers below the webserver already decline the connection?
(In reply to Djfe from comment #33)
> POST data is sent unencrypted over the internet?

POST data is sent encrypted with RC4.

> And if the cipher suites don't match:

If the cipher suites don't match, we can't know if the server is RC4-only. So we can't show dedicated UI for RC4-only servers.
It is possible to show dedicated UI on block, it just requires notably more effort. The most straightforward route would be to write a generic sever TLS capabilities scanner that checks for supported versions & ciphers. On every TLS error page, it would first load the current version of the error page with a throbber and message saying it's trying to learn more, then after the scan finishes it could show a more precise error message based on what it learns. (it'd only take a second or so if its just looking for limited basic stuff) This is theoretically doable, and would allow better errors in other cases like SSL3 & version intolerance, but it would be non-trivial to implement.
thanks Dave, that was exactly what I was thinking about :)

:emk you divorced my statement out of it's context
"And if the cipher suites don't match:" was followed by a question after all, which was not related completely to my previous statement

you said POST data is sent using RC4, but to do that you would need to know that the server supports rc4 lol, so you could intersect before that


another approach that came to my mind just now:
offer all cipher suites (including rc4), then wait for the servers answer
if the server prefers rc4, then cancel the connection and reconnect using all ciphers except rc4
if the server reclines the connection, then we know it's rc4 only and we can show a UI warning
else we will use the other cipher that the server offers (some servers have weird configurations that prefer rc4 over other better ciphers that they are capable of)
Attempting to actually offer/negotiate RC4 is a bad idea, IMO. I'd much rather a dedicated general purpose server scan be done, and only on failure. (basically, just send a wave of TLS connection attempts for stuff and see what is negotiated, but never hook up any application protocols at all)
oh so a scan would behave differently? I thought this would be similar/the same
I mean a scan would also negotiate connections.
Is that different because no real data is sent over?
1. The difference is completely transparent to the TLS layer.
2. Not sending cookies, credentials, or POST data is also the difference.
When I say "application protocols" in comment 37, I mean HTTP in the common case. The web is HTML & etc. transferred over HTTP transferred over TLS (HTTP+TLS=HTTPS) transferred over TCP transferred over IP transferred over the whatever data link & physically layers the hardware network is using. A TLS scan would connect via TLS to the server IP on TCP port 443 with the TLS SNI extension for the domain name, but end the connection after a completed TLS connection handshake (either successful or failed). HTTP and up would not be involved; no request for anything. It'd just be TLS connections, but no HTTP connections over those. (the term "connection" could mean connection with any of those protocols involved, so the word can be ambiguous without further understanding of context)

Whilst the basic idea of a TLS scan is straightforward, I expect an algorithm on how to send the set of requests properly is needed to avoid pissing off the server. (I've not implemented such a scan myself; just used them) A full scan takes some time, but for our purposes we don't need to scan for everything. Only the TLS versions and ciphers Firefox, as well as RC4 and any other formerly used feature, can use need to be scanned for. (e.g. a full scan might check for Camellia or GOST, but we don't care)

Just to reiterate, I'm just stating that this is all very possible. We may or may not actually want to do this. As we are phasing out things now, and will be doing so more in the future (TLS 1.0, 1.1, and CBC ciphers will eventually need killing as well), it would be something that could be continually helpful if implemented, but it could be considered overkill. We've been willing to build more advanced developer tools directly into Firefox recently, however, so this feature does not seem unreasonable to consider.
Blocks: 1158169
In another bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1137677#c19) Yuhong Bao said that he thought that UI degradation would happen if RC4 is negotiated in _any_ of the connections used to load subresources.

Can anyone confirm or deny? I agree in spirit with degrading the security UI if RC4 is used anywhere, but I want to raise a flag because it will be next to impossible for the user (or the web site owner, trying to hit their site with Firefox) to determine why their UI was degraded.

I understand the challenges involved in trying to warn users through the security UI. The UI can change based on cert chain problems, certificate problems (SHA-1), mixed content, etc. If nothing else, there needs to be a way for a savvy user (or their CA's Tech Support team) to tell why they're seeing gray or yellow or a lock with a line through it, even if that's via the Web Console.
Will RC4 be disabled in the next ESR of Firefox (or in the one after that)?
Additional state showing UI when user clicks on yield sign to provide information about the RC4 server causing the error.
Attachment #8593366 - Attachment is obsolete: true
I'm not sure if I should be replying to this bug or to bug 1158169 (since there is a good deal of overlap in them), but I have a handful of issues with the first draft of the error screen, such as:

- Untrusted (a problem with authentication or integrity) is not a problem with RC4, since that is part of ECDSA/RSA key exchange and/or the HMAC.  RC4 has problems with confidentiality (ie, being Insecure), which is not the same thing.  We can still know we're talking to rc4.badssl.com, even if somebody is decrypting the conversation.

- It has technical jargon (namely RC4) in the main error message.

- The use of "hackers" in an error message seems mildly hyperbolic and also possibly misleading, unless you consider a government agency to be a "hacker"

- If this page even appears, presumably it is because we have elected to send RC4 amongst the client's supported cipher suites, which means that we are offering to allow them to elect to continue onward, which isn't really currently reflected.  And if that's so, we need to make sure that we don't just say "Do not submit any sensitive information", because it's badly misleading: their (highly sensitive) session identifier is likely contained in said request, something that a user is likely to not understand.

--

Here is my suggested wording:

This Connection is Insecure

This website's server uses an obsolete encryption technology that makes information you submit, such as passwords and credit card numbers, accessible to eavesdroppers.

What should I do?

Please contact the website owners to let them know their site is not secure. It is not recommended to continue should this site contain or receive any sensitive information.

Technical Details

rc4.badssl.com has chosen to use a cipher (RC4) that is known to have cryptographic weaknesses, and its continued use is prohibited.

I Understand the Risks

If you understand the risks, you can tell Firefox to continue onward to this site. *Even if you trust the website, this error means that someone may be able to impersonate you or steal your information.*

Add Exception // Get me out of here!

--

Continuing to send RC4 amongst our supported ciphers is problematic on its own, and may cause these errors to appear when they didn't need to, e.g. when a server selects RC4 even though they may actually support a stronger cipher.  I have seen this happen in situations where a server was configured to choose RC4 as their primary cipher in response to the BEAST attack.  Instead of bombarding systems with scans for RC4 (such as through ssl-enum-ciphers in nmap), how about this:

Step 1) Firefox attempts to handshake with the following cipher suites, which I believe is the standard in nightly:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

If those fail (ssl_error_no_cypher_overlap), we attempt to do another handshake with RC4 behind the scenes:

TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)
TLS_RSA_WITH_RC4_128_SHA (0x0005)
TLS_RSA_WITH_RC4_128_MD5 (0x0004)

If that succeeds, we tear down the session without making any HTTP requests, present the error page and give them the option to continue onward, should they accept the risks.  We would still present the gray triangle (or whatever) in such a case.
This discussion is mostly about adding a ui warning, the other one is the general discussion.
The second part of your post fits better in the other thread so you may want to repost it there ;)

btw. i had the same idea to reconnect with rc4 ciphers if it fails without them, but some others on here said that's not doable or something (because the decision should be left to the server or something)

I really like your UI warning text: it's easily understandable for every user and it's distinguished from other error warnings.

"hacker" is a bad term anyways because a hacker in general is nothing bad at all

>We can still know we're talking to rc4.badssl.com, even if somebody is decrypting the conversation.
That it wrong: if the attacker is able to decrypt your network traffic in real-time, then MITM attacks are possible.
if no PFS is used then the connection will keep the same key -> the attacker has more time for decrypting and a better chance at decrypting a lot of recorded traffic at the same time
and he might be able to then attack the connection and inject it's own code into the connection (untrusted is a correct term here, untrusted also means that you cannot guarantee that nobody fetches your password despite it being decrypted before being send over the net, even if no direct attack to your connection happens -> attackers might still be able to get access to your accounts and stuff if you don't use two factor authentication(and even that is attackable if the factor is send to your device using rc4 as well))
Well, reconnecting in the presence of failures with all the other ciphers still lets the server choose.  It just doesn't let it choose RC4 as a first choice when it may have selected a different cipher.

Are you sure about that second part?  Even if somebody is able to completely decrypt your message (and has your key), they're not able to MITM you, because they can't generate the proper HMAC based on the client_write_MAC_key/server_write_MAC_key, which was only exchanged via public key crypto and never used with RC4.  Plus, at the point of the conversation where this screen would be displayed, no actual RC4 has even been done yet.  :)

In any case, it's a moot point: being able to decrypt the conversation means they have your session information and any number of other pieces of private information.

I'll go ahead and post my stuff to the other thread as well.
It is getting late to uplift to beta. Marking wontfix for 39 and tracking for 40+. 

Are there any plans coming up to modify the UI?
status-firefox40: --- → affected
status-firefox41: --- → affected
tracking-firefox40: --- → +
tracking-firefox41: --- → +
Flags: needinfo?(sworkman)
This bug will require some string changes, so I don't think it's possible to uplift anyway.
(In reply to Liz Henry (:lizzard) from comment #47)
> Are there any plans coming up to modify the UI?

Rbarnes is leading this effort and will have more info.
Flags: needinfo?(sworkman)
(In reply to Steve Workman [:sworkman] (please use needinfo) from comment #49)
> Rbarnes is leading this effort and will have more info.

Spoke to Richard - We're still working out the details on RC4, so no plans to modify the UI right now.
Flags: needinfo?(rlb)
Assigning to Agrigas because every tracked bug should have an assignee.
Assignee: nobody → agrigas
I am assuming others have seen:

https://www.rc4nomore.com/
https://www.rc4nomore.com/vanhoef-usenix2015.pdf

Because of this, I think it is now time to get fallback removed on a more expedited basis.
The trade off, in my opinion, no longer favours allowing RC4 to be negotiated.
Richard, any news on this? Thanks
Assignee: agrigas → nobody
Flags: needinfo?(rlb)
Anyway, too late for 40.
status-firefox40: affected → wontfix
Steve, has there any decisions since your comment 50? Given that this bug has been wontfix'd since 39, I would like to propose untracking this. I do see bug 999544 which could be a good tracked bug instead. Thoughts?
Flags: needinfo?(sworkman)
I am setting FF41 status to wontfix and waiting for Steve's response before untracking this bug for good. Please let me know if there are reasons not to do so.

IMO, having a better UI notification is a nice to have and not a release blocker.
status-firefox41: affected → wontfix
Ritu, our RC4 deprecation plan is detailed in this post to dev-platform: https://lists.mozilla.org/pipermail/dev-platform/2015-September/011541.html

:rbarnes and :keeler are leading that effort now. We're working on details for the UI currently. I agree that this is probably not a release blocker.
Flags: needinfo?(sworkman)
As 43 goes into beta, will the UI change from the current 42 beta? Or will it stay more or less the same until full deprecation of rc4 on 44 release?
I think the UI has been improved enough.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Flags: needinfo?(rlb)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: