Browser detect component for Blazor

In this post, I’m going to create a browser detect component for  Blazor WebAssembly and Blazor Server with .NET6. Firstly, if you need help or info about this component, leave your message in the Forum.

There is a new version of this component that can detect Windows 11. Read the update on this post

First thing to remember, you can try your component by yourself from the website. Try it now!

Also, the full source code of this component is on GitHub. So, the following screenshot is an example of the information the component detects from your browser.

User-Agent detection: limitation and issues

User-Agent: <something> is a string of characters sent by HTTP clients (browsers, bots, calendar applications, etc.) for each individual HTTP request to a server. The HTTP Protocol as defined in 1991 didn’t have this field, but the next version defined in 1992 added User-Agent in the HTTP requests headers. Its syntax was defined as “the software product name, with an optional slash and version designator“. The prose already invited people to use it for analytics and identify the products with implementation issues.

So, fast forward to August 2013, the HTTP/1.1 specification is being revised and also defines User-Agent.

Then, a user agent SHOULD NOT generate a User-Agent field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties. Overly long and detailed User-Agent field values increase request latency and the risk of a user being identified against their wishes (“fingerprinting”).

Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility with them, as this circumvents the purpose of the field. If a user agent masquerades as a different user agent, recipients can assume that the user intentionally desires to see responses tailored for that identified user agent, even if they might not work as well for the actual user agent being used.

Basically, the HTTP specification discouraged since its inception the detection of the User-Agent string for tailoring the user experience. Currently, the user agent strings have become overly long and they:

• are abused in every possible way
• include detailed information.
• lie about what they really are and they are used for branding and advertising the devices they run on.

User-Agent Detection

First, user agent detection (or sniffing) is the mechanism used for parsing the User-Agent string and inferring physical and applicative properties about the device and its browser. But let get the record straight. User-Agent sniffing is a future fail strategy. By design, you will detect only what is known, not what will come. The space of small devices (smartphones, feature phones, tablets, watches, Arduino, etc.) is a very fast-paced evolving space.

The diversity in terms of physical characteristics will only increase. Updating databases and algorithms for identifying correctly is a very high maintenance task which is doomed to fail at a point in the future. Sites get abandoned, libraries are not maintained and Web sites will break just because they were not planned for the future coming devices. All of these have costs in resources and branding.

Using capabilities

Therefore, new solutions are being developed for helping people to adjust the user experience depending on the capabilities of the products, not its name. In addition, responsive design helps to create Web sites that are adjusting for different screen sizes. So, each time you detect a product or a feature, it is important to thoroughly understand why you are trying to detect this feature. You could fall in the same traps as the ones existing with user agent detection algorithms.

For example, looking on the internet, we have to deal on a daily basis with abusive user agent detection blocking Firefox OS and/or Firefox on Android. It is not only Mozilla products, every product and brand has to deal at a point with the fact to be excluded because they didn’t have the right token to pass an ill-coded algorithm. User agent detection leads to situation where a new player can hardly enter the market even if it has the right set of technologies. Remember that there are huge benefits to create a system which is resilient to many situations.

For this reason, some companies will be using the User-Agent string as an identifier for bypassing a pay-wall or offering specific content for a group of users during a marketing campaign. It seems to be an easy solution at first but it creates an environment easy to by-pass in spoofing the user agent.

The browser detect component

So, after all this consideration, I decided to use a mix of all user-agent parser and capability detection for creating the component. Firstly, how to use the component in your Blazor project.

Add the component

Firstly, add the component using the NuGet package. Then, in the page add the following tag

<BrowserDetect @bind-BrowserInfo="@Info" />

Now, add the following the code

@code {
    public BrowserInfo Info { get; set; }
}

So, the component is adding automatically the JavaScript to the page to run same tests on the browser. Then, the JavaScript collects info about the browser and runs same capabilities functions. After that, it passes the results to the component. Then the component updates the BrowserInfo and your page receives all the updates. Easy, that’s it, nothing else. In brief, the variable BrowserInfo has all the properties detected from your browser.

Properties

So, this is the list of property the component returns about your browser: same of them are detected parsing the user-agent, other testing the capabilities.

Wrap up

In conclusion, this is the browser detect component for Blazor. Then, please leave your comment in the section “Browser detect component for Blazor” in the Forum.