Firefox 39.0 released
mozilla.org
mozilla.org
fetch(url).then(data => ...)
https://bachelorburnbook.files.wordpress.com/2013/07/image.p...
This is the one which has the greatest chance of giving people a headache. For instance, one of the biggest banks here still uses only RC4 for its online banking site. Its top-level hostname and a few of its auxiliary hostnames are on the whitelist, but there's no guarantee that all the RC4-only auxiliary hostnames it might use for some of its functionality are on the whitelist.
One day they'll catch up.
Perhaps it helps if you write your payment site operator/bank private emails asking them to allow other ciphers beside RC4, mine looked like this (actual site name removed):
According to Qualys SSL Labs the site **** [2] only supports the RC4 cipher,
and thus is not RFC 7465 compliant [3], and Google Chrome qualifies the site as
"Your connection to **** is encrypted with obsolete cryptography."
The site **** is even worse [4], it uses only 768-bit DH key exchange in some
situations (instead of 2048).
There is an online tool [5] that you can use to generate/compare
configuration for popular web-servers, using the intermediate level is
recommended [6].
For your information I sent a similar email last year to **** and they have
fixed their problems, and get a nice 'A' grade from SSLLabs now.
Apparently this use of RC4 all comes down due to a mistake in NIST's
classification of the severity of the BEAST vulnerability [7], but both Google
Chrome[7] and Mozilla Firefox[8] are trying to avoid the use of RC4 completely,
and mitigating the BEAST vulnerability is no excuse for not providing good
ciphers (in addition to RC4 if you must) when my browser supports TLS 1.2 with
AES-GCM which is NOT vulnerable to the BEAST attack.
I suggest you to include the Qualys SSL Labs test when testing sites for
PCI-DSS compliance, they are usually quite good at reporting the latest TLS
vulnerabilities for a server.
[1] http://www.visaeurope.com/media/images/pci%20dss%20validated%20web%20listing%20march%202015-73-18412.pdf
[2] https://www.ssllabs.com/ssltest/analyze.html?d=****
This server accepts the RC4 cipher, which is weak. Grade capped to B.
Certificate uses a weak signature. When renewing, ensure you upgrade to SHA2.
[3] https://tools.ietf.org/html/rfc7465
[4] https://www.ssllabs.com/ssltest/analyze.html?d=****
This server supports insecure Diffie-Hellman (DH) key exchange parameters. Grade set to F.
Certificate uses a weak signature. When renewing, ensure you upgrade to SHA2.
The server supports only older protocols, but not the current best TLS 1.2. Grade capped to B.
This server accepts the RC4 cipher, which is weak. Grade capped to B.
[5] https://mozilla.github.io/server-side-tls/ssl-config-generator/
[6] https://wiki.mozilla.org/Security/Server_Side_TLS
[7] https://code.google.com/p/chromium/issues/detail?id=375342#c30
[8] https://bugzilla.mozilla.org/show_bug.cgi?id=1088915
[9] https://www.ssllabs.com/ssltest/analyze.html?d=****It basically allows to do scroll hijacking [1] without any JavaScript, just like this: http://blog.gospodarets.com/demos/scroll-snap-full-screen/
Personally I think CSS is "style hijacking" — the Web really is about the text, not the colors.
For example, I tried the demo and saw how the pages jumped to the nearest page if I middle click and pulled down to go half way. Corner cases or anything more complicated than simple wheel flips often don't seem to work if you hack your own solution. Now the browser seems to have a much better idea of what's going on. So.. That's nice. We'll get hijacks but at least they seem to be much more robust? But at the same time I hope this won't make more designers hijack scrolling or go overboard with this. :\
Scrolling/motion performance is the only thing that is keeping me away from FF at the moment - Even dev tools are getting amazingly good.
Type "man firefox" into your terminal and you will see the relevant options and can set up aliases and shortcuts appropriate for your separated browsing needs.
The increased smoothness of the inertial model probably indicates that chrome's scrolling is actually better, repaints more closely aligned to vsync or whatever, but like I say there are no actual artifacts, tearing etc. visible on my macbook retina. If you've got a top of the line 120fps gaming monitor its probably more noticeable.
That fancy lcd-testing website probably has some way of measuring it.
For me the big issue is the lack of visual feedback when swiping left and right to go back and forward. In chrome/safari you get a big sliding animation to tell you you're triggering the gesture correctly. In FF you just get an arrow after the gesture has been triggered, when its just annoying visual clutter. This means it still sometimes takes me multiple attempts to hit it, because I don't have that feedback during the gesture to cement the muscle memory.
EDIT: apparently chrome gives you the arrow, ff gives you absolutely nothing.
In the previous Firefox version scrolling on that site was laggy to the point of being unusuable for some reason.
For example, Safari usually suggests Wikipedia articles or other useful autocompletions. FF only autocompletes from domain names, bookmarks and history, it seems. It does have a separate search input in the toolbar, but even that one doesn't do what Safari does; all the suggested autocompletes are from Google, and additional search engines like Wikipedia or Amazon require that you click on their icon to search.
There's an extension called Omnibar, but it doesn't seem to provide suggestions from other than Google, bookmarks and history.
But I'll put up with whatever to support Mozilla. Their work on Firefox and Rust is some of the most important going on.
If I want to search the Internet, I type in the search box.
Sidenote: I find it really interesting that the current spec suggests preconnect and its siblings accept a probability attribute estimating how likely connecting to different resources is.[1] Something funny to me about making the directed-graph/state-machine nature of the internet finally show through the markup.
This is going to make me never use Chrome dev tools again. Nice
Hmmmm, I'm on ff 40.0a2 and they don't render for me: http://emojipedia.org/man-with-dark-brown-skin-tone/
"As to hair color, dark hair tends to be more neutral, because people of every skin tone can have black (or very dark brown) hair—however, there is no requirement for any particular hair color. One exception is PERSON WITH BLOND HAIR, which needs to have blond hair regardless of skin tone."
But the billions of people who aren't white might have a problem with it.
Google and Microsoft’s neutral yellow was a lot more neutral there, yes.
Nope. Usually white (Apple, Japanese phones).
A Japanese person draws a simple human face, an American draws a simple human face, both will draw "white" skin.
How so? If you're white, perhaps you see no problem with making everyone's skin white.
But the billions of people who aren't white might have a problem with it.
I really thought you meant Caucasian. Did you just mean light-skinned?
It would have been better if I said "light-skinned", yes. While East Asians are not "white" in the "racial" sense (ew), their skin is light much like Europeans', and thus when the Japanese created the emoji, they made them have light skin.
Sorry for the confusion.
> But the billions of people who aren't white might have a problem with it.
I'm not white, and I have a problem with "skin tone" emoji.
Previously, skin tones for emoji were left up to the font creator. In practice, this meant that they were usually lime green, neon blue, or Simpsons yellow, all of which are cartoonish enough not to be evocative of any particular real-life skintone.
I can't really imagine a situation in which drawing attention to the race of an emoji character is desirable or even acceptable. I'm sure some exist, but they're nowhere near important enough to be included in the actual standard itself.
Beyond that, the skin tones used are incredibly reductive. Human skin tones are not as simple as 6 different shades of brown. (I, for one, cannot match my skin tone to any of the examples on the Unicode website). And if we want to get philosophical, there are a number of ways in which race and culture are encoded (literally) into emoji that are far more subtle, yet more significant, than the color used to render the skin of the faces. In a way, it reminds me of the picture-interpretation tests that they used to administer at Ellis Island to "prove" that certain immigrants were not "fit" for life in the US, though that's perhaps a topic for another day.
That's not true, IME -- in several of the popular emoji fonts I've seen that don't incorporate specific "skin tone emoji", most emoji for people that aren't expressly silhouettes are white, except a very small number which are black (in both cases, within the range of flesh tones usually associated with those as races, not cartoonish colors.)
EDIT: This is not true of "smiley face" emoji, but of other emoji representing humans or human body parts.
Yes, they are a bit more complicated. But 6 choices that correspond to a widely-used system (Fitzpatrick) is far better than none.
The fact that a system is widely used when classifying the impact of UV light on melanoma does not imply that it has relevance in another.
> 6 choices is far better than none.
Actually, no, sometimes the "solution" is worse than the problem. It's quite regressive to bake an outdated conception of the color theory of race into a standard that aims to "educate and engage academic and scientific communities, and the general public" (the stated mission of the Unicode Consortium).
As one of the "billions of people who aren't white" that you refer to in your original comment, I find this approach more problematic than the existing status quo (leaving it up to the font creators).
You may have a point there. But it is a classification of skin colour as well.
> It's quite regressive to bake an outdated conception of the color theory of race into a standard
Color theory of race? This isn't the Von Luschan chromatic scale, that was used to enforce racial segregation. It's a simple colour selector based on level of melanin.
It's not perfect, sure, but I think it's surely better to allow a choice of skin shades than to make everyone white (the de facto result otherwise). You might object that implementers could make everyone black, say, and that's also true. But either way, you're enforcing a "default" skin colour, and there is no such thing. Different human populations have different skin colours.
Nobody said anything about race, thats your assumption. These emoji are merely presenting different skin tones.
There are not billions of Japanese people and their skin tone is light (though they're not European).
Emoticons and emoji have traditionally been displayed as yellow cirlces with large faces. White emojis have been the exception, not the rule. I have never had a problem with being represented by a character with Jaundice (a medical condition turning your skin yellow).
If your skin color is already represented you have the privilege of not having to worry about inclusivity of others being represented.
However, I'm not sure this applies to you since I'm not sure what race you are.
Not at all true. Most emoji implementations (Japanese mobile providers, Apple) used white faces.
No, fonts can have colour in them. This isn't a new thing, colour fonts have been around for decades. However, they're particularly useful for emoji.
Also has anyone else noticed that Firefox is no longer keeping the page state when navigating back? For example on Reddit go to the comments section, minimize a few comments then navigate to a link then go back and none of the minimized comments remain minimized, in Firefox prior to 38 things worked correctly.
I don't know how more modern stuff like accelerated transforms, canvas, WebGL or DirectWrite play into that equation. Browsing seems to pull out GPU's from the lowest power modes constantly, which might cause these problems on a wide variety of GPUs.
Chrome still hasn't fixed it. Color me unimpressed.
Did you try to contribute to Chromium and Firefox to speed up fixing the Logjam issue ?
No. The issue isn't that it's (so) hard to fix; the fix in 39 has been out for a while, they just didn't want to release it for the stable release, which means few people got it. (In fact, some distros apparently fixed their versions earlier [1]).
On Firefox, you could manually fix it in 2 minutes [2]
I'm not familiar with the codebases, so it would take me longer to make a patch, but it really should not take 2 months to release to stable a fix that affected 8.4% [3] of popular websites, especially for a company like Google.
The tinfoil hat in me says certain things about this, considering that logjam was likely known by the NSA, but then again I can't prove anything.
I'm a bit surprised there hasn't been more talk about this, actually. A major security hole going unfixed for months after public disclosure should have had more chatter.
[1] https://news.ycombinator.com/item?id=9702061 [2] http://techdows.com/2015/05/how-to-make-firefox-browser-safe... [3] https://weakdh.org/