A New Test For The Brave Browser and New Security Focused Browsers

How Can We Test For Brave?

By Strictly-Software

I use the Brave browser as well as a few other Chromium-based security-focused browsers such as (Opera, CCleaner, and DuckDuckGo) most of the time due to their inbuilt security measures. My preferred browser is Brave due not only to its Shield which removes trackers, cookies, adverts, and has a measure of built-in fingerprint spoofing. Plus it has its own search engine, which can be accessed from the address bar, and it doesn't block certain sites like Google and other search engines do.

It also blocks Google's Accelerated Mobile Pages and takes you to the original publisher's site, can have strict upgrades to HTTPS URLs when linked to an unsecured domain, as well as its incognito pages are based on the TOR engine.

I never use Chrome anymore as it used to be a quick plain browser but has now got bogged down with too many options. Also, I don't like Google which relies on heavy use of adverts and selling user information for revenue, plus its other links to intelligence agencies, and its censorship. This has pushed mainstream media articles ahead of legitimately more relevant sites. I also don't like it's use of banned reading lists that try to prevent people from viewing sites the US Intel Establishment has deemed unsuitable like RT.com or Infowars.com. 

Plus I don't know what they now do server side to try and identify users due to all these new privacy-based browsers, and the number of privacy plugins/extensions, that could help protect you. However, it's good to know you can have a measure of protection without bogging the browser down with plugins such as fingerprint spoofers like Trace and AdBlockers like MalwareBytes or the DuckDuckGo plugin. Also, I like being able to earn cryptocurrency from Brave which rewards the user, not the site for viewing small adverts.

However, the issue with Brave is that it hides as Chrome and doesn't have its own user agent. It used to, and the hope is that in the future it will again but at the moment it just shows a Chrome user-agent. 

For example, my latest Brave user-agent is:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/122.0.0.0 Safari/537.36

There have also been a lot of changes to how Brave identified itself in the Window and Navigator sub-object that used to make Brave identifiable through inspection of certain objects. These seem to have changed back and forth many times and you can see some of the old objects that used to be checked in my older article on looking for Brave here.

Why bother looking for Brave, or indeed any browser when feature detection should be used rather than user-agent sniffing or other means to find the name of the Browser?

Well, Brave prides itself on security, hiding adverts, removing tracking code and cookies, and now has a certain level of fingerprint sniffing protection to stop sites from using properties identified by JavaScript or Server Side code to change Response headers to make identifying unique users and traffic to sites much harder.

Therefore you may want to write Chromium extensions that add extra protection to Brave browsers or do the reverse, add code back in to replace removed adverts, or help track link clicks with removed Ping attributes or other devious plans your boss wants you to run on sites accessed by people using Brave. 

I don't know, I just like to play with the code and see what object detection features each browser reveals. They may all be based on Chromium but they can all have unique features.

An updated function from my previous article makes use of the fact that Brave now identifies itself in the window.navigator object, specifically the brave object in navigator and the isBrave property within that. 

First I rule out any Mozilla browsers e.g Firefox by looking for a well-known Mozilla property, and ensure the browser is Chromium based by checking for a Webkit property. It is similar to the two line old function but uses a new Webkit property as the old one has been removed and is wrapped in a function.

function IsBrave(){
	
	let w=window,n=w.navigator; // shorten key objects

	// as many tests we know browsers now support; prove its not Mozilla; prove its Chromium based and has Brave properties in window and navigator objects
	let isBrave = !("mozInnerScreenX" in w) && ("chrome" in w && "onwebkitanimationiteration" in w && "brave" in n && "isBrave" in n.brave) ? true : false;
	
	return isBrave;
}

And if you want to check for the new CCleaner browser there isn't any specific objects in the navigator object I can see but it does have a unique user-agent e.g:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0.0.0 Safari/537.36 CCleaner/121.0.0.0

However, the Duckduckgo browser, which comes with an email protection service, allowing you to use a specific @duck.com email address that only forwards non-spam emails to your real address, does have a specific object if you want to check for it.

// detect duckduckgo
let duckduckgo = ("duckduckgo" in navigator) ? true : false;

However, we all should be detecting objects to allow for features rather than the old method of user-agent sniffing, but if you did want to identify certain browsers there are unique objects, usually on the navigator object that can be checked.

You should know that there are lots of ways you can protect yourself from tracking and unique identification nowadays but it does rely on the device you are using to browse as well as the model of that device.

For instance, even if you are now using IPv6 addresses on your router which makes unique identification a lot easier than the older DCHP method of picking a free IPv4 address as local to you as possible when accessing the web, your system can be set to use temporary IPv6 addresses.

This means that your real unique identifying IP address is never shown to outside sites. A look at ipconfig /all in your command prompt will show you whether you are using them or not and a search online will show you how to change the settings if you're not using them yet.

Also, if you are using Android or iOS phones or devices that use Google as an integral part of their system, you can delete the unique advertising ID that exists to allow sites to uniquely track you whether or not your browser or plugin removes Google tracking codes. 

On iOS the ad identifier is also called "IDFA" and on Android, "AAID". As these IDs can only be accessed using server-side code, Java or Python, and a Google library, modifying the DOM won't stop you from being tracked. 

You can easily remove these IDs in the Privacy / Advertising section of your phone's settings if you have Android 12 or above. iOS devices are more complicated but this article explains how to remove them.

If you want to check what properties exist for a browser object then these two lines of code can help you out rather than a loop.

const keys = Object.keys(window);
console.log(keys);

This just outputs all the keys such as events, other objects like document and navigator, and properties as well into the developer tools console area that all modern browsers have.

Remember as Brave, CCleaner, DuckDuckgo, Edge, Opera and Chrome are all based on the same Chromium browser they are the same standard-compliant browsers. However, as I stated in my last article, it is amazing how many modern sites still break when I use a user-agent switcher and change my string to IE6 for example. 

They really shouldn't if they were using feature detection by checking for the existence of objects before running certain code.

By Strictly-Software

Running JavaScript Before Any Other Scripts On A Page

Injecting A Script At The Top Of Your HTML Page

By Strictly-Software

If you are developing an extension for either Firefox, Opera or Chrome, Brave, Edge, and Chromium, then you might come across the need to be able to inject some code into the top of your HTML page so that it runs before any other code.

When developing extensions for Chromium based browsers such as Chrome, Brave and Edge, you will most likely do this from your content.js file which is one of the main files that holds code to be run at certain stages of a pages lifetime.

As the Chrome Knowledge Base says the property values for the "run_at" property include;

document_idle, the preferred setting where scripts are guaranteed to run after the DOM is complete and after the window.onload event has loaded all resources which can include other scripts.

document_end, content.js scripts are injected immediately after the DOM is complete, but before subresources like images and frames have loaded. So after the DOM is loaded but before window.onload has finished loading external resources.

document_start, ensures scripts are injected after any CSS files are loaded but before any other DOM is constructed or any other script is run.  

There is of course the "run_at" property in the manifest.json file, which can be set to "document_start", to enable the codes running before other code does. This is especially useful if you need to change header values before a web page loads so that modified values such as the Referer or User-Agent can be modified. However, there may also be a need for you to set up an object or variable that is inserted into the DOM for code within the HTML page to access.

For example in a User-Agent switcher where you need to both overwrite the Navigator object in JavaScript and the Request header, you may want to create an object or variable that holds the original REAL navigator object or its user-agent so that any page you may create yourself or offer to your users the ability to see the REAL user-agent, browser, language, and other properties if they wanted to.

For example, I have my own page that I use to show me the current user-agent and list the navigator properties. 

However, if they have been modified by my own user-agent switcher extension I also offer up a variable holding the original REAL user-agent so that it can be shown and compared with the spoofed version to see what has changed. I also have a variable that holds the original navigator object in case I want to look at the properties.

Therefore my HTML page may want to inspect this object if it exists with some code on the page.

// check to see if I can access the original Navigator object and the user agent string
if(typeof(origNavigator) !== 'undefined' && origUserAgent !== null)
{
	// get the real Browser name with my Detect Browser function using the original Navigator user-agent
	let realBrowser = Browser.DetectBrowser(origUserAgent);

	// output on the page in a DIV I have
	G("#RealBrowser").innerHTML = "<b>Real Browser: " + realBrowser "</b>";
}

This code just uses a generic Browser detection function for taking a user-agent and finding the Browser name. It even detects Brave by ruling out other browsers and if it is Chrome at the end I check for the Brave properties or mention of the word in the string, which they used to have but newer versions have removed it. 

However there is hope in the community that they will create a unique user-agent with the word Brave in as at the moment people are having to do object detection which is the better method, and as Brave tries to hide, there are plenty of query strings and other API calls which can be made to find out whether the result indicates Brave rather than Chrome.

However, at the moment, I am just using a simple detection on the window.navigator object that if TRUE indicates that it is actually Brave NOT Chrome. 

A later article shows a longer function I developed with fallbacks in case the objects do not exist anymore as there used to be a brave object on the window e.g window.brave that no longer exists, so did many objects for Chrome such as window.google and window.googletag that no longer exist. However, this article explains all that.

This is just the one line test you can do, it ensures it is not FireFox with a test for a Mozilla only object window.mozInnerScreenX and then checks that it is a Chromium browser with tests for window.chrome and that it's also webkit with a test for window.webkitStorageInfo before some tests for navigator.brave and navigator.brave.isBrave to ensure it's Brave not Chrome e.g:

// ensure that a Chrome user-agent is not actually Brave by checking some properties that seem to work to identify the browser at the moment anyway...
let isBrave = !("mozInnerScreenX" in window) && ("chrome" in window && "webkitStorageInfo" in window && "brave" in navigator && "isBrave" in navigator.brave) ? true : false

However, this article is more about injecting a script into the HEAD of your HTML so that code on the page can access any properties within it.

As my extension offers an Original Navigator object and a string holding the original/real user-agent before I overwrite it, then I want this code to be the first piece of JavaScript on the page.

This doesn't have to be limited to extensions and you may have code you want to inject in the HEAD when the DOMLoads before any other code.

This is a function I wrote that attempts to place a string holding your JavaScript into a new Script block I create on the fly and then insert before any other SCRIPT in the document.head.

However, if the page is malformed, or has no defined head area it falls back to just appending the script to the document.documentElement object.

If you pass false in for the 2nd parameter which tells the function whether or not to remove the script after inserting it then if you view the generated source code for the page you will see the injected script code in the DOM.

The code looks within the HEAD for another script block and if found it inserts it before the first one using insertBefore() however if there is NO script block in the HEAD then the function will just insert the script into the HEAD anyway using the appendChild() method.

An example of the function in action with a simple bit of JavaScript that stores the original navigator object and user-agent is below. You might find multiple uses for such code in your own work.

// store the JavaScript in a string
var code = 'var origNavigator = window.navigator; var origUserAgent = origNavigator.userAgent;";

// now call my function that will append the script in the head before any other and then remove it if required. For testing you may want to not remove it so you can view it in the generated DOM.
appendScript(code,true);

// function to append a script first in the DOM in the HEAD, with a true/false parameter that determines whether to remove it after sppending it.
function appendScript(s,r=true){

	// build script element up
	var script = document.createElement('script');
	script.type = 'text/javascript';
	script.textContent = s;
	
	// we want our script to run 1st incase the page contains another script e.g we want our code that stores the orig navigator to run before we overwrite it

	// check page has a head as it might be old badly written HTML
	if(typeof(document.head) !== 'undefined' && document.head !== null)
	{	
		// get a reference to the document.head and also to any first script in the head
		let head = document.head;
		let scriptone = document.head.getElementsByTagName('script')[0];

		// if a script exists then insert it before 1st one so we dont have code referencing navigator before we can overwrite it		
		if(typeof(scriptone) !== 'undefined' && scriptone !== null){	
			// add our script before the first script
			head.insertBefore(script, scriptone);
		// if no script exists then we insert it at the end of the head
		}else{
			// no script so just append to the HEAD object
			document.head.appendChild(script);
		}
	// no HEAD so fall back to appending the code to the document.documentElement
	}else{
		// fallback for old HTML just append at end of document and hope no navigator reference is made before this runs
		document.documentElement.appendChild(script);
	}
	// do we remove the script from the DOM
	if(r){
		// if so remove the script from the DOM
		script.remove();
	}
}

I find this function very useful for both writing extensions and also when I need to inject code on the fly and ensure it runs before any other scripts by using a onDOMLoad method.

Let me know of any uses you find for it.

Useful Resource: Content Scripts for Chrome Extension Development. 

By Strictly-Software

IE 8 Document and Browser modes

Controlling IE 8 Browser and Document Modes

In Internet Explorer 8 the developer toolbar can control the following settings and will override any other settings that have been set e.g META tags or the Compatibility View options. On changing a setting the browser will refresh and load the appropriate new configuration.

I will list out the various document and browser modes with the basic differences but if you are in a hurry and just require a Javascript function that you can use to determine the clients current IE8 settings then that link will sort that for you. For an explanation on browser compatibility mode testing then this link will give you an article explaining the combination of agent sniffing and object detection that is required for identifying a clients IE8 browser settings.

Browser Modes:

Internet Explorer 8 Mode

The browser will run as IE 8.0 and the user-agent will appear as an IE 8.0 user-agent e.g

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; GTB5; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 1.1.4322; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

Notice the mention of Trident/4.0 which is the name and version of the rendering engine.

A new Javascript engine is used in IE 8.0 so there will be numerous differences for example using getElementById to return an element by name will not work anymore which is the correct way of doing things however if you didn't know this and did use it in IE to access elements you will experience errors when running in full IE 8 mode.

Internet Explorer 7 Mode

The browser will run as if it were actually IE 7.0 and the user-agent will appear as an IE 7.0 user-agent e.g:

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; GTB5; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 1.1.4322; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

Javascript will run as it does in IE 7.0 for example using getElementById to return an element by name will work.

Internet Explorer 8 Compatibility Mode

This mode means that, and I quote from ieblog

"In a nutshell, Compatibility View allows content designed for older web browsers to still work well in Internet Explorer 8."

So in all respects the browser is still running as IE 8.0 but allows sites that worked perfectly well in IE 7.0 to continue to work correctly without having to revert to IE 7.0 mode.

By default IE will set all publicly accessible Internet sites to run in IE 8 mode and all Intranet sites to IE 8 compat mode.

For Internet sites it comes across which it feels should run in compatibility mode such as those with strict doctypes then it will display a button to the user to allow them to change to compatibility mode. For sites that are using quirks mode it will not offer this option so do not expect the button to appear all the time.

The user-agent in IE 8 Compatibility Mode is displayed similarly to IE 8 but with a 7 e.g

Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; GTB5; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 1.1.4322; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)

Javascript should run as it did in IE 7 for example using getElementById to return an element by name will work.

Document Modes:

Quirks Mode (e.g IE 5)

This document mode setting will render pages as if there was no doctype specified. This will be the same as if you were using older IE versions such as IE 5.0.

Internet Explorer 7 Standards Mode

This document mode will render pages as they would be displayed in IE 7.0 when a strict doctype was specified.

Internet Explorer 8 Standards Mode (Page Default)

This document mode will render pages in the new IE 8 standards compliant manner. IE 8 apparently adheres to the CSS 2.1 specification and there are numerous changes to be aware of. For instance there is no longer any support for CSS expressions.

For a list of the various changes and potential problems that IE 8 will bring to your development view the following article: http://blogs.msdn.com/ie/archive/2009/03/12/site-compatibility-and-ie8.aspx


How to detect which settings are enabled

If for whatever reason you need to detect client side which of these various settings the user currently has enabled in their browser then you can use a combination of user-agent sniffing and object detection to work out the true browser version and rendering engine. See the following article about how to detect the settings using Javascript.

The new META UA-Compatible tag

Another new feature in IE 8 is the ability to quickly fix any potential problems that all these new document and browser modes may bring by adding a META tag to your existing sites. To force a page to run in IE 8 standards mode we can add the following META tag to pages:

<meta http-equiv="X-UA-Compatible" content="IE=8">

Or if you find that your sites do not currently work in IE 8.0 standards mode you can force them to work as they did in IE 7.0 with the following META tag:

<meta http-equiv="X-UA-Compatible" content="IE=7">

Once you get your site up to scratch you can remove the tags.

Comments For Script Articles - CSS Style Object, Linked Lists, Browser, Lazy Form Validator, Social Bookmarks

Example Scripts, Comments section

There are a number of scripts that I have posted on this site that are actually on another domain and therefore not part of blogger. Therefore I have added this article so that if anyone wants to post comments related to those scripts they can by adding them to this article.

Scripts List

JavaScript Unpacker. This simple form allows you to reverse engineer a block of JavaScript code that has been obfuscated by being encoded and is usually identified because the first few characters of the function look like this eval(p,a,c,k,e,r) . This method is usually used by hackers to try and hide the types of operation they are trying to carry out so its a wonderful way of being able to work out what the code is doing. Just paste the packed code into the box at the top, hit the "Unpack" button and hey presto you now have some readable code

CSS Style Object. A Javascript object that correctly calculates the computed style for Internet Explorer. Currently the example is using a function dedicated to correctly calculating styles for font-sizes but the core details could be applied to other styles requiring a computed size in pixels.

Querystring Parser: A small Javascript object dedicated to parsing a querystring something I thought would be inbuilt into the language but isn't. This article is on the blog and has its own comment section.

Linked Lists: A Javascript object dedicated to handling linked lists where the list box options in a parent list control the options that appear in a child list. The source of the data within the lists is not important this object controls the event handlers and the flow down of the hierarchy when a parent list has an item change as well as other default display options.

Lazy Form Validator: A Javascript object that can be used either in full production or when you want to quickly add client side form validation to a page with nothing more than including a reference to this script and then setting specific classes on each form element if special validation is required.

Social Bookmark Include: A simple include file and Javascript function that can be used on blogs or other sites to include links to social sites such as Digg, Stumble, Reddit etc. The script will append the appropriate URI and title details which it extracts from the source of the page containing the scripts. No need to customise the script on each page its used.

Browser Object. A little object dedicated to the now dirty art of browser sniffing containing details about css box model, spoofing, flash support, browser details etc. Most frameworks will still contain something similar and there are still cases where the the browser type and version is required knowledge due to feature support that cannot be tested with object testing.

Please specify which script you are commenting about when posting. Thanks.

Trying to detect spoofed user-agents

User Agent Spoofing

A lot of traffic comes from browsers either masking their real identity by using a different user agent than the real one associated with the browser or a random string which relates to no known browser. The purpose of doing this is many fold from malicious users trying to mask their real identity to get round code that may ban on user-agents or get round client side code that may be blocking certain browsers from using certain functionality which is all a good reason for using object detection rather than browser sniffing when deciding which code branch to run.

However as you will probably know if you have tried doing anything apart from simple JavaScript coding there are still times when you need to know the browser because object detection just isn't feasible and trying to use object detection to work out the browser is just as bad in my opinion as using browser sniffing to work out the object.

Therefore when someone is using an agent switcher to mask the browsers agent and you come across one of these moments then it may cause you to run code that will raise errors. There is no foolproof way to spot whether an agent is spoofed but one of the things you can do if you do require this information is compare the agent with known objects that should be supported by that browser and if they don't match then you can confirm the spoof.

This form of spoof detection will only work if its only the user agent string that has been changed but an example of some of the checks you can do include for agents that say they are Opera make sure it supports window.opera as well as both event models document.addEventListener && document.attachEvent as far as I know its the only browser that does support both. For IE you shouldn't check document.all by itself as you will actually find Firefox will return true for this but you can check for window.ActiveXObject the non existence of addEventListener and use conditional comments to test for JScript. Firefox should obviously not support JScript as it uses Javascript.

Those are just a few checks you could do and you are basically using object detection as well as agent sniffing together to make sure they match. They may not tell you the real browser being masked but they can be used to tell you what its not. 

The idea of this is to make sure that in those cases where you have to branch on browser rather than object (see this previous article) that you make the right choice and don't cause errors. Obviously you may decide that if the user is going to spoof the agent then leave them to suffer any errors that may come their way.

If you do require a lightweight browser detector that checks for user agent spoofing amongst the main browsers as well as support for advanced CSS, Flash and other properties then see this article.

http://www.strictly-software.com/BrowserObject.asp