User agents are strings that the browser sends in the header of every HTTP request that identifies itself, like Mozilla/5.0 (Linux; Android 13; Pixel 5 Build/TP1A.221105.002; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/108.0.5359.128 Mobile Safari/537.36. They tend to be quite long because they contain a brief history of the internet, but serve no real purpose (some people will argue this point, but I think I can back up that assertion).
Some websites don’t work well if they don’t recognize the user agent. Much has been written about how browser detection is a flawed system, but some websites still do it. For Privacy Browser, this means that if the default user agent of PrivacyBrowser/1.0 is used, some aspects of certain websites won’t work because the web server doesn’t have PrivacyBrowser/1.0 on the list of user agents that it knows can run a specific feature, so the webserver doesn’t even try to do it, even though Privacy Browser is perfectly capable of handling the feature.
So, for example, neweggbusiness.com doesn’t allow the user to log on if the user agent is PrivacyBrowser/1.0. http://hss3uro2hsxfogfq.onion/ loads an entirely blank screen if it doesn’t recognize the user agent. Google doesn’t redirect from HTTP to HTTPS if it doesn’t recognize the user agent, and the Google Play Console doesn’t layout correctly.
Setting a user agent in domain settings that the website recognizes, like WebView Default, often resolves the issue. Note that spoofing the user agent does have possible negative fingerprinting implications, because if a browser’s presented behaviors differ from those expected for a particular user agent, it makes it fairly unique for those who are closely tracking such things.