When he looked around the Web on the device’s default Xiaomi browser, it recorded all the websites he visited, including search engine queries whether with Google or the privacy-focused DuckDuckGo, and every item viewed on a news feed feature of the Xiaomi software. That tracking appeared to be happening even if he used the supposedly private “incognito” mode.
The device was also recording what folders he opened and to which screens he swiped, including the status bar and the settings page. All of the data was being packaged up and sent to remote servers in Singapore and Russia, though the Web domains they hosted were registered in Beijing.
Mozilla Firefox prior to version 72 suffers from Small Subgroups Key Recovery Attack on DH in the WebCrypto‘s API. The Firefox’s team fixed the issue removing completely support for DH over finite fields (that is not in the WebCrypto standard).
You see, Internet Explorer is a compatibility solution. We’re not supporting new web standards for it and, while many sites work fine, developers by and large just aren’t testing for Internet Explorer these days. They’re testing on modern browsers.
These automatisms in browsers are giving me a bad time. Who the hell came unmedicated to the conclusion to let browsers transform emoticons into emojis? Text has to remain text and images have to remain images.
Of course I could add the text presentation selector (︎) as suffix to every emoticon I write, but that’s not the point. Also the suffix gets removed upon editing, so I need to add it over and over again. Programmatically scanning all texts and adding the suffix automatically is overkill and results in a huge performance loss.
I found an add-on for Firefox which claims to do disable emojis. But it doesn’t work, and also I don’t want a separate add-on for that. Seems like no one thought of a simple CSS setting to disable this crap. I don’t want smileys, emojis, whatever. This is all so painful.
After importing the script make sure the script is activated. Otherwise it won’t work. I know the script is not perfect. I just checked some articles on Wikipedia and also the main page and they look very well. If you find bugs, feel free to contact me.
Relying on the HTTP referrer is bad. Everyone knows this, but at least the WordPress developers seem to ignore the fact. Also I never understood, why PHP keeps writing HTTP_REFERER with a single “R” in the middle. The correct term would be HTTP_REFERRER.
Anyway, instead of storing the current URL in $_SESSION[‘HTTP_REFERRER’] as one would normally do, WordPress checks for $_SERVER[‘HTTP_REFERER’] instead.
‘HTTP_REFERER’ The address of the page (if any) which referred the user agent to the current page. This is set by the user agent. Not all user agents will set this, and some provide the ability to modify HTTP_REFERER as a feature. In short, it cannot really be trusted.
Imagine the following case: you run WordPress from a sub-folder of the root-directory and the referrer is – for whatever reason – set to the web-root of the server, rather than the web-root of your WordPress installation. In fact this is the case on my development machine; I talk about the reason somewhere below.
Now, when you try to delete/recycle a post/page/whatever WordPress checks the referrer in post.php in line 55:
For instance, the code above is taken from WordPress 5.1.1.
So, what happens when the referrer returned by wp_get_referer() contains the wrong URL? You’ll get redirected to anywhere, but the correct location. The only way to somehow fix this without messing with the code is to disable the referrer entirely. You still won’t get to the correct location, but at least you remain inside the WordPress web-root.
Why is the referrer wrong?
As stated above the referrer is set by the user agent (e.g. the browser). It seems like my Waterfox does not set the referrer correctly. For instance, it does not occur in Firefox and Opera. Looking at about:config in Waterfox I found the setting “network.http.referer.trimmingPolicy” being set to “2”. According to this page it will strip the referrer to its origin without any query strings etc.
Setting it back to its default solved the issue, but enables the browser to send the full referrer, which is not desirable by privacy means. On the other hand it did not break any other pages besides the WordPress backend, so I guess it’s time for the WordPress developers to fix their code.
In case you use a Chromium based browser you’ll likely have noticed blurry fonts on this website. First I thought it’s related to font-smoothing, but I don’t use such CSS rules, because they are not part of the standard, yet. Also I checked if forcing the browser to disable font-smoothing changes the way the text is rendered. To my surprise it had no effect at all. So, it must be something else that breaks the font-rendering. In Firefox, Edge and IE the issue does not appear. To make a long story short, in Chrome 72 the text gets blurry if it’s positioned using
That is quite annoying, because you use this rule to center content where the absolute width and height is unknown. If it’s known you could use negative margins instead.
In Opera the positioning using transform does not affect the font-rendering. However, and now things are getting really weird, the cause of the blurry text is the border-radius of the surrounding div element. Wtf!? Yes, the border-radius causes strange font-rendering. And it’s independent of the actual font. A simple
is just enough to make it ugly. Additionally the size of the browser window affects the rendering, too. So, if the browser window is resized by 1-2 pixels, the blurring disappears. Here are some screen shots to illustrate the issue:
UPDATE: Unfortunately, the following does no longer work with the latest Chromium version. :(
So, the autoplay policy for HTML5 videos in Chromium based browsers has been changed some time ago to disallow autoplay if the video contains audio. The intent was to not bother the user with sound being played automatically upon visitin a website, and in turn give him an option to selectively choose to have sound turned on/off for HTML5 videos. Well, I’ve found a nifty workaorund which allows you to play videos with sound automatically.
I just experienced and issue where the height of the container of an HTML5 video (1080px, mp4) was calculated wrong. The respective stylesheet had set video width to 100% and no height (defaults to height:auto). The browser rendered the video container to a height of >6000px while maintaining the width of the surrounding div and the actual aspect-ratio of the video. Really strange behaviour. The issue seems to occur in Chrome 64 and Opera 51. Firefox and Edge are not affected by the issue.