> Disable use of RC4 except for temporarily whitelisted hosts
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.
Banks handle everyone's money and are high-profile targets for compromise over the network. As such, they should be obliged to keep current with best security practices as the technology evolves, not lag far behind these.
But that's the inherent problem; these companies are still setup for a bureaucracy that works fine in a particular area of business, but completely crumbles under the new rules of the technological age. We shouldn't be apologetic for their resisting of change, but rather pushing them to take a long hard look at what needs to be reorganized to fit into the new paradigm.
Banks, of all businesses, should be concerned about online security, for real protection and for appearance of caring for their customers' peace of mind. Mozilla telegraphs these browser changes months in advance.
After the CVE score for BEAST and RC4 got adjusted and the RFC 7465 was introduced I've seen some payment systems update their system quite quickly (in a matter of days),
and if they didn't they'd probably fail their next PCI audit:
https://news.ycombinator.com/item?id=9198889
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=****
Sadly the 768-bit DHE is hardcoded into older versions of Java, which is why I suggested to them that they raise the limit to that instead of 1024-bit for now.
I'm torn.. I dislike scroll hijacking and in a sense don't want support for this practice, _but_ at the same time I assume this will never go away and then this seems less hacky and easier to make it work without ruining use on various input devices and settings.
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. :\
People experimented with new ways of handling user input (as they have for decades), found that it was a good way to layout some pages, and then complained to browser vendors that doing it in JS sucks. CSS snap points is just a way to make the experience better for developers and users. That's exactly how the Web should work.
Personally I think CSS is "style hijacking" — the Web really is about the text, not the colors.
The Firefox/native version of the page works much better than the jQuery version. Both are a little bit janky with touchpad scrolling, but the native version allows you to scroll to the next page before waiting for the animation to finish. With a mousewheel, the native version is far better and acts as you expect; the jQuery version just feels like a terrible hack and doesn't let you scroll where you want, when you want.
As much as the effect can be irritating, Firefox lets you over-scroll before snapping which is a much better experience compared to that fallback jQuery plugin.
I'm on ff 40 (developer edition), so presumably I've been running project silk for a while now, and for me the scrolling is visually indistinguishable from chrome. The difference is in the inertia: chrome slows to a halt marginally more smoothly, and it does that thing where you can elastically scroll past the end of the page.
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.
Maybe that's because OS X makes the scroll wheel consider acceleration (move the scroll wheel quickly, you scroll more, move it slowly, you scroll less), unlike Windows/Linux?
Same here. But I'll keep using Firefox because I cant stand what Chrome is doing with my cpu/memory/privacy and I want to keep Safari (the less 'usable' browser) for work related stuff and Firefox for personal ones, on another desktop space.
Two firefox profiles? One for work and one for personal?
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.
I can't feel any difference between Chrome and Firefox when scrolling, but http://www.vsynctester.com/ is jankier on Firefox on my old-ish Macbook Air.
To those using FF, is there a way to get an "omnibar" similar to Safari?
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.
Firefox's URL bar is literally my favorite Firefox feature. It's quick, it searches my local history much better than Chrome, and it doesn't leak anything to the world.
If I want to search the Internet, I type in the search box.
The preconnect relationship is intriguing; I hadn't been following the adoption of resource hints.
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.
Yey for progress, but one of the most annoying things for me with FF is that if I cmd-t for a new tab, I can't start typing right away for a new search and have that get preserved. There's always some lag and only then do my keys get transcribed. Safari and chrome don't have this problem, and it drives me insane.
That would annoy me too, but I've never noticed it. My main laptop is a Core 2 Duo, so not a speed demon. Have you tried with extensions disabled and/or with a new profile?
Believe so. But either way if its extensions well that sucks because I only have like 2-3 and I want. Extensions shouldn't be written in a way that does that -- chrome and safari don't have this problem and I have about 12 chrome extensions.
There is a Unicode character PERSON WITH BLOND HAIR, but no corresponding PERSON WITH BLACK HAIR. This is obviously discriminatory. We need new emoji modifiers for: blonde-hair, black-hair, brown-hair, red-hair etc.
"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."
I only recently discovered that Unicode characters can now have colour in them, and frankly, I'm disappointed that we're adding complexity to an already hugely complex topic.
Unicode characters don't have colour in them, much as they do not have a shape either. The Unicode standard does not specify the exact visual representation of any codepoint.
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.
The Unicode consortium kinda ran out of useful things to do and has been filling up the address space with whatever comes to mind. Don't worry about it. All the old stuff still works fine.
There are people who write entire sentences in emoji. It is a written language that is understood by speakers of all spoken languages. This just makes the language more expressive.
> 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'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.
> 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.
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.
> correspond to a widely-used system (Fitzpatrick)
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).
> 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.
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.
I have never thought of emoji as having any particular skin colour, until this recent trend to make skin colour selectable.
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).
The color was not specified before, so it was up to the font creator. I think yellow was the most common choice. The test page shows all the icons as blue in my browser. I'm not against the new changes, but I think the old version was more popular in Asian countries than anywhere else, and wasn't really pro-white.
> 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.
Emojis are used for communicating emotion, not skin color. If the user want them to be displayed black (or even replace them with cat and dog faces) it should be up to them, it's just a user preference.
And yet there are still issues on my Sandy Bridge system with display corruption even with the latest Intel drivers.
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.
Yes I have noticed the exact same thing on Reddit lately. My guess it's because they started sending "Cache-Control: no-cache" which prevents Firefox to cache the page for the back button.
I haven't seen many people mentioning this problem before. I've seen it come up in discussions on the current AMD GPU lines. Hard to say who is to blame, but it's rarely obvious just how many problems there are before buying a card. I got a cheap R7 260x which seems to have trouble with waking up from low power states. Some people even made custom BIOS's to fight the problem.
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.
Yes that is exactly my problem! Glad to see it is properly fixed and not "fixed by accident". I will live with h/w acceleration off for a few weeks I guess.
firefox is on a 6-week release schedule, and has been for a while. They increment a by whole number each time, but the for both chrome and FF they shouldn't really be thought of as .0 releases. It's a fairly minor, incremental change.
Since Chromium is open source, you can contribute to the project. I'm sure if you send a quality patch to the Chromium dev team to fix Logjam, they'd be willing to review it.
Did you try to contribute to Chromium and Firefox to speed up fixing the Logjam issue ?
>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.
Why should one provide a patch for Google's browser. Google are rich they can do it themselves? The day that Chrome is a verified build of Chromium with all the Google centric stuff as optional add ons is the day sending Chromium patches makes sense.
