Tag: browser

Windows Vista EOL

As of April 11, 2017, Windows Vista customers are no longer receiving new security updates, non-security hotfixes, free or paid assisted support options, or online technical content updates from Microsoft. Microsoft has provided support for Windows Vista for the past 10 years

https://support.microsoft.com/en-us/help/22882/windows-vista-end-of-support

The most recent version of Internet Explorer in Windows Vista was IE 9.0.8112.16421 (9.0.57)

Even Apple, Google and Mozilla Firefox have ceased to maintain browsers for this operating system, dropping support for Windows XP and Vista at the same time.

Chrome 49.0.2623.112
https://chrome.googleblog.com/2015/11/updates-to-chrome-platform-support.html

Firefox 52.9.0 ESR
https://support.mozilla.org/en-US/kb/end-support-windows-xp-and-vista

Safari 5.1.7
https://apple.stackexchange.com/questions/68836/where-can-i-download-safari-for-windows

Windows XP EOL

I recently crossed paths with a customer that was still using Windows XP and experiencing problems with a website.   This led me to evaluate their options for continuing to use this once very common, but now unsupported operating system.

After 12 years, support for Windows XP ended April 8, 2014. Microsoft will no longer provide security updates or technical support.

https://www.microsoft.com/en-us/windowsforbusiness/end-of-xp-support

The most recent version of Internet Explorer in Windows XP was IE 8.0.6001.18702

Even Apple, Google and Mozilla Firefox have ceased to maintain browsers for this operating system, dropping support for Windows XP and Vista at the same time.

Chrome 49.0.2623.112
https://chrome.googleblog.com/2015/11/updates-to-chrome-platform-support.html

Firefox 52.9.0 ESR
https://support.mozilla.org/en-US/kb/end-support-windows-xp-and-vista

Safari 5.1.7
https://apple.stackexchange.com/questions/68836/where-can-i-download-safari-for-windows

An additional problem with use of IE8 on Windows XP is that it only supports up to TLS1.0 which is currently being replaced by TLS1.2  in many web applications.

 

HSTS preload

If you have already started using HSTS to force users to your HTTPS website, the use of ‘preload’ is another simple addition as it only requires the addition of the keyword to the header.

Once done, you can either wait for your site to be identified (which can take a long time, or forever for less popular websites) or ideally, submit your hostname to be added to the lists preloaded in many modern browsers. The advantage here is that your users will never make a single request to your HTTP website and will automatically be directed to HTTPS.

An HTTP Header example:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Apache2 configuration example:

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

REFERENCES:

“Referrer-Policy” HTTP Header

A relatively new HTTP Header that is supported by most modern browsers (except MSIE) is the “Referrer-Policy” header. There have been previous attempts to implement similar protections through use of the ‘rel’ (or ‘rev’) attributes on links to external websites. The latest approach takes a different approach and prevents leaking of internal URLs, and in some cases parameters, to external websites. This is important from a security perspective as you might maintain some sensitive information in your page urls, that would otherwise be inadvertently shared with an external website.

Clearly, you’ll need to determine your own level of security based upon your needs. Example: ‘no-referrer’ would be the most strict and would prevent the browser from sending the ‘Referer'(sic) header even to your own websites pages.

Example header values:

Referrer-Policy: no-referrer
Referrer-Policy: no-referrer-when-downgrade
Referrer-Policy: origin
Referrer-Policy: origin-when-cross-origin
Referrer-Policy: same-origin
Referrer-Policy: strict-origin
Referrer-Policy: strict-origin-when-cross-origin
Referrer-Policy: unsafe-url

Implementation can be accomplished in many ways, the most simple being and addition to your HTTP server configuration similar to the one shown below for Apache 2.x:

Header always set Referrer-Policy strict-origin

REFERENCES:

Content-Security-Policy: block-all-mixed-content

If you are running a secure website, it’s a good idea to prevent non-secure assets from being included on your page. This can often happen through the use of content management system, or even through website vulnerabilities. A simple change in HTTP headers will help browsers to defend against them.


Content-Security-Policy: block-all-mixed-content

Most modern browsers, except MSIE, currently support this approach.
– Firefox 48+

REFERENCES

document.write() Intervention!

The use of document.write() has always been a bad “code smell” in JavaScript. Most web performance guides such as WebPageTest and Yahoo Exception Performance have warned against this practice.

In most cases, document.write() can be replaced by inserting innerHTML into an empty element after the rest of the page loads. This approach also allows the developer to “think” about how the page might react in cases where JavaScript is disabled or not available on the client.

Google has recently changed the default behavior, such that when on a slow (currently 2G) connection, but discussions have also leaned toward including any slow connection.
As such, right now, the following will occur on slow (2G) connections:

  • Chrome 53+ (warning displayed in debugger console)
  • Chrome 55+ (blocked – code will not execute, warning message will appear in debugger console)

For users on slow connections, such as 2G, external scripts dynamically injected via document.write() can delay the display of main page content for tens of seconds, or cause pages to either fail to load or take so long that the user just gives up. Based on instrumentation in Chrome, we’ve learned that pages featuring third-party scripts inserted via document.write() are typically twice as slow to load than other pages on 2G.


My advice – remove all use of document.write() for required content in your code now, as your users MAY NOT see that content if you do not.

REFERENCES:

Google Chrome installation for Ubuntu

With a few simple steps, Google Chrome can be installed on Ubuntu.


wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | sudo apt-key add -


sudo sh -c 'echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list'


sudo apt-get update


sudo apt-get install google-chrome-stable

or…


sudo apt-get install google-chrome-beta

Selenium HtmlUnit driver separated in 2.53.0

I’ve been a user of Selenium testing for several years, though I noticed that some classes related to the HtmlUnit WebDriver were missing after upgrading from 2.52.0 to 2.53.0. After some research, I discovered that it is now a separate dependency allowing for a separate release cycle. Additionally, if you don’t use this (relatively generic) webdriver, you will no longer need to have it in your binaries.

Here’s all you need to do to add it to your Maven projects for testing.

In your pom.xml file:

<properties>
<selenium.version>2.53.0</selenium.version>
<htmlunitdriver.version>2.20</htmlunitdriver.version>
</properties>
<dependencies>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-java</artifactId>
<version>${selenium.version}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>htmlunit-driver</artifactId>
<version>${htmlunitdriver.version}</version>
<scope>test</scope>
</dependency>
</dependencies>

REFERENCES:

HTML5 Link Prefetching

Link prefetching is used to identify a resource that might be required by the next navigation, and that the user agent SHOULD fetch, such that the user agent can deliver a faster response once the resource is requested in the future.


<link rel="prefetch" href="http://www.example.com/images/sprite.png" />

<link rel="prefetch" href="/images/sprite.png" />

Supported in:

  • MSIE 11+/Edge
  • Firefox 3.5+ (for HTTPS)
  • Chrome
  • Opera

REFERENCES:

HTML5 preconnect

In addition to dns-prefetch, you can take browser performance one step further by actually creating a new connection to a resource.

By initiating an early connection, which includes the DNS lookup, TCP handshake, and optional TLS negotiation, you allow the user agent to mask the high latency costs of establishing a connection.

Supported in:

  • Firefox 39+ (Firefox 41 for crossorigin)
  • Chrome 46+
  • Opera


<link rel="preconnect" href="//example.com" />
<link rel="preconnect" href="//cdn.example.com" crossorigin />

REFERENCES: