site incompatibility: belastingdienst.nl

[hugobuddel]

Could not find a similar issue.

Description

The website of the Dutch tax agency does not work in Brave: https://www.belastingdienst.nl/

At least not on Linux, have not tried Windows / MacOS.

Steps to Reproduce

1. Visit https://www.belastingdienst.nl/

Actual result:

This site can’t be reachedThe connection was reset.
Try:

Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_RESET

Expected result:

The site as shown in Firefox, Chromium or Chrome

Reproduces how often:

100%

Brave version (brave://version info)

Brave	1.1.5 Chromium: 78.0.3904.97 (Official Build) beta (64-bit)
Revision	021b9028c246d820be17a10e5b393ee90f41375e-refs/branch-heads/3904@{#859}
OS	Linux
JavaScript	V8 7.8.279.23
Flash	(Disabled)
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36
Command Line	/opt/brave.com/brave-beta/brave --enable-dom-distiller --disable-domain-reliability --no-pings --extension-content-verification=enforce_strict --extensions-install-verification=enforce --enable-oop-rasterization=Enabled --sync-url=https://no-thanks.invalid --enable-features=NewExtensionUpdaterService,PasswordImport,WebUIDarkMode,SimplifyHttpsIndicator --disable-features=AutofillServerCommunication,LookalikeUrlNavigationSuggestionsUI,AudioServiceOutOfProcess,SmsReceiver,NotificationTriggers,UnifiedConsent,SyncUSSBookmarks --flag-switches-begin --flag-switches-end
Executable Path	/opt/brave.com/brave-beta/brave
Profile Path	/home/hugo/.config/BraveSoftware/Brave-Browser-Beta/Default

Version/Channel Information:

Don't know

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields? No
• Does the issue resolve itself when disabling Brave Rewards? No
• Is the issue reproducible on the latest version of Chrome? No

Miscellaneous Information:

[krijnsent]

Same issue, site simply won't show. Running Windows 10, Version 1.2.43 Chromium: 79.0.3945.130 (Official Build) (64-bit).

[AronVanAmmers]

Reproduced this too on Windows 10, Version 1.2.43 Chromium: 79.0.3945.130 (Official Build) (64-bit).

Unlike #3437 this is not a profile-specific issue. I can reproduce it on two different profiles and in a private window, and haven't found a workaround within Brave.

In a normal browser window, for me the ERR_CONNECTION_RESET takes a while to appear, whereas in a private window it's instant.

Works fine on Chrome.

[hugobuddel]

Makes me wonder what the belastingdienst is doing. I've narrowed it down to the cookieBLD33.

It is possible to copy the request the network tab of the web developer extension. Pasting the curl command into bash will result in an error, but removing that cookie from the request will make it succeed.

The cookie [seems to be harmless], but I still rather not share the cookie here.(https://www.belastingdienst.nl/wps/wcm/connect/bldcontenten/niet_in_enig_menu/individuals/cookies):

cookieBLD33 | Until the end of your visit | Establishes whether the browser's technique allows for accepting cookies.

One difference with the cookie Firefox uses is that the Firefox one starts with a "!" (exclamation mark) and the Brave one starts with "\u0021" (the unicode representation of an exclamation mark):

• Most modifications of the cookie do not cause the error.
• Modifying the other cookies too gives a "Toegang geblokkeerd" (Access Denied) warning from the site itself.
• Replacing the \u0021 with a ! does cause an error.
• Using the Firefox cookie in Brave causes no error (either with the !, or replaced with \u0021).
• Using the Brave cookie in Firefox causes no error.
• Using the Brave cookie in Firefox and replacing the \u0021 with a ! does cause an error.

Chrome gets/sends a cookie that also has a \u0021, but otherwise resembles the firefox cookie more than the Brave cookie. As in, the Chrome and FF cookies are the same length (Brave is slightly larger) and part of the (base64 encoded?) string is identical between Chrome and FF.

So it seems that there is a problem with the site decoding the

[gwillem]

Same on Firefox 73.0.1, removing the cookieBLD33 fixes the issue. This has been a problem with the belastingdienst for a long time, at least since Oct last year.

[ryanbr]

I've tested this site (from a NZ IP), I'm not seeing this. Site seemed to load okay without error, also browsed a few pages off the homepage. Have they changed the site?

Tested in:
Brave Release: Version 1.4.96 Chromium: 80.0.3987.132 (Official Build) (64-bit)
Brave Nightly: Version 1.7.50 Chromium: 80.0.3987.132 (Official Build) nightly (64-bit)

@hugobuddel @AronVanAmmers @krijnsent

[hugobuddel]

It might depend on operating system too, because I recall it working fine on my work machine (Centos 7), but not on my personal machines (Ubuntu 16.04 LTS and Windows 10). Or perhaps there is some other variable.

[AronVanAmmers]

@ryanbr still same results for me with Brave Release Version 1.4.96 Chromium: 80.0.3987.132 (Official Build) (64-bit) on Windows 10 update 1909.

And hoi @gwillem! 😄
BTW on Firefox 73.0.1 (64-bit) I can't reproduce it.

[gwillem]

Hi :)

BTW on Firefox 73.0.1 (64-bit) I can't reproduce it.

Perhaps me and @hugobuddel are reporting a different issue then, because all my browsers (Firefox, Chrome, curl on Ubuntu 16.04) choke on the connection when the (a?) cookieBLD33 is set, but not without one.

[hugobuddel]

I think it is the same issue. But different browsers/users get different cookies. That is, for me Firefox works fine, unless I use the cookieBLD33 from Brave, then it fails (using curl to forge the request). Vice versa, using the Firefox cookie in Brave also works.

There is no problem on my Scientific Linux 7.7 work machine, both Brave and Firefox work fine. The BLD33 cookie that Brave gets here is very similar to the ones chrome and Firefox get.

I'm going to post the cookies here, because according to the belastingdienst it only "Establishes whether the browser's technique allows for accepting cookies." and has a validity "Until the end of your visit". So there should be no privacy risk in sharing them.

ubuntu16.04 brave:   \u0021UvbY8Avq/sXcL+sa6V3T4wlzkA39UT32757LudMCtAxF01OFZBWzotVCk5F36DhqCvLZ1iaMvTv4xA==
ubuntu16.04 chrome:  \u0021cfCTgay21nqtYWqoNrDww+he4MeXu6cCROzP7ChF4EYqLT31FccdTKGuAsAhGRH0mZgAkFriTGBK
ubuntu16.04 firefox:      !29ZhJWwyPqZI9P+oNrDww+he4MeXu+Ps+HAUcPbtosgi/UlYPDZazvQrz6ysXSCjiMKKCoXSqwGS
fedora30    brave:   \u0021nawehaZtMB3ZCPqTV2/I/CXUU7siVK5FLtKNorbTaDTiFn5Q/FnKzgTFatFGj0tQr6FrVdeTakAY
sl7.7       chrome:  \u0021vaNoh9i9oA/ArpqoNrDww+he4MeXu63CJdYbBkuGxktGxoB4Rcmb13Y2A3mMNVoxHTRvah+ERy4g
sl7.7       firefox:      !AsFcafjnzKPOGguoNrDww+he4MeXu03D+7V7qaGv9osbfYZWwGs8yql6Y9ROOa03I4d4nalilfJB
windows10   brave:   \u0021GYNzAULnl7hG2uIa6V3T4wlzkA39UYMon0JdEZ9zX6zAfbKEY9mZRbPI8EeMxbBuFwNq8Iw4ThLhmw==

I failed to parse these, but there is some structure, with similarities and differences:

• The bad cookie is the only one with "==" at the end (indicating base64?).
• Firefox uses ! and Brave and Chrome use \u0021 (unicode for !), reusing the cookie in another browser requires substituting these.
• Parts of the Firefox and Chrome cookies are identical (oNrDww+he4MeXu), which is not shared with the Brave cookie.
• The structure of the Brave cookie looks different from the Firefox / Chrome ones (more slashes, less pluses), but that might be psychological.

Edit: at work I use singularity to run Brave in a Fedora 30 container.

Edit: also include windows 10 brave cookie, also bad

[hugobuddel]

There doesn't really seem to be a way to report bugs for belastingdienst.nl.

Maybe we should try to get some of their developers involved here, but they turn out to be quite hard to find on github.

@107728 do you perhaps know where to go with problems like this? You're a belastingdienst webdeveloper according to linked-in 😃.

[rebron]

@ryanbr I can't reproduce either. I'm able to load the site site fine.
@btlechowski Can you give this a check too when you get a chance?

[ryanbr]

I'm not really messing with cookies, just purely loading site (with default shield settings), using minimal /no extensions. But its probably more of a site-issue, Maybe reach out to them via twitter? https://twitter.com/Belastingdienst Linking to this ?

[hugobuddel]

Seems indeed a problem on their end. They (sometimes) send Brave a special cookie that they do not accept back. And even if it would be Brave that is mangling the cookie, then the site should still work properly and not crash.

Could we perhaps keep this open a bit longer to see whether us Dutchies can get someone to notice this problem? It is tax season here, so it is a bit annoying to have to switch browsers.

https://twitter.com/HugoBuddel/status/1237658484004532224

[gwillem]

@hugobuddel

I think it is the same issue

Why? @AronVanAmmers reported a connection error without cookies in #7331 (comment). Our problem is strictly limited to a specific cookie.

I did report the cookie problem last year Oct and then again this March, but got only tumbleweeds from our beloved tax service... https://twitter.com/gwillem/status/1234827920188768256?s=20

[hugobuddel]

Hope we have more success now @gwillem !

My reason for thinking the issue is the same is that there are two versions of the BLD33 cookie, a good one and a bad one (of course with specific values each time, but see the == in the examples). And that Brave gets the bad cookie more often than the other browsers.

@gwillem and @AronVanAmmers could you share what BLD33 cookie you get when the site does or doesn't work in Firefox or Chrome? If you don't want to share the actual cookie, could you then perhaps check whether the cookie ends with ==?

I've already tested all the browsers that are easily available to me, so I can't investigate further.

[hugobuddel]

Unlike #3437 this is not a profile-specific issue. I can reproduce it on two different profiles and in a private window, and haven't found a workaround within Brave.

For me the site works fine in private mode (both w/ and w/o Tor) with Brave on Windows 10. So this is a good enough work-around for me when using Brave! (I get the non == cookie in that case.)

But I find it hard to recommend Brave as a browser to other people if belastingdienst.nl does not work. So it would be nice if they fix it.

[AronVanAmmers]

@hugobuddel @gwillem progress. Turns out the two profiles I tried on Brave did both have a cookieBLD33 cookie set that ended in ==. After clearing cookies, www.belastingdienst.nl works for me in normal (profile) browser tabs. I think I cleared cookies before at some point, but can't be sure, haven't been analytical enough about it 😉. It's not impossible that I just regarded private windows as the test case for excluding any cookie issues, and have never tried clearing cookies for the site on the profile.

Interestingly after clearing cookies, the site now also works for me in private windows, even though those don't use cookies of the profile, they start with empty cookies. And I have confirmed this just now when testing before clearing cookies, there were no cookies set in the private window and it still failed. Behaviour before clearing cookies for me was as described in #7331 (comment). What am I missing? 🤔

[hugobuddel]

Clearing cookies indeed solves the issue for me too. Should probably have tried that before... So these are just old cookies from the site and there was nothing special about Brave.

How does one clear cookies for specific sites in Brave? I now cleared all cookies for 1000+ sites, because I couldn't find any other way. (Making it a bit relevant to have this here on the Brave issue tracker.)

(I made a backup of my profile before clearing all cookies, either to debug this issue further, or to put all the cookies back and delete only the belastingdienst ones).

As to what you were missing @AronVanAmmers; maybe de belastingdienst is still sending out bad cookies occasionally, hitting you in the private session.

[AronVanAmmers]

How does one clear cookies for specific sites in Brave? I now cleared all cookies for 1000+ sites, because I couldn't find any other way. (Making it a bit relevant to have this here on the Brave issue tracker.)

From the icon in the address bar, see below. You can inspect and delete individual cookies this way:

[AronVanAmmers]

Further insights. HTTP/HTTPS makes a difference. I did this:

1. Create a new, empty profile and use it.
2. Open http://www.belastingdienst.nl. Result: immediate ERR_CONNECTION_RESET
3. Open https://www.belastingdienst.nl. Result: opens well, cookies get set.
4. Now open http://www.belastingdienst.nl again. Result: opens well, redirects to HTTPS.

Similarly for a private window:

1. Open a private window from this new, clean profile.
2. Open http://www.belastingdienst.nl. Result: immediate ERR_CONNECTION_RESET
3. Open https://www.belastingdienst.nl. Result: opens well, cookies get set.
4. Now open http://www.belastingdienst.nl again. Result: opens well, redirects to HTTPS.

So what seems to happen is opening the HTTP version in a clean browser environment gives the error. Explicitly opening HTTPS does "something", presumably setting the cookieBLD33 cookie makes the difference but I haven't tested to that much detail, and after that the HTTP version opens as well.

This explains what I missed in #7331 (comment). After having opened https://www.belastingdienst.nl successfully in the normal browser window once, the private window autocompleted from my browser history (which is used in private windows, activity in the private window is just not logged to it) when I started typing "www.bela..." to use HTTPS rather than HTTP. I can now still reproduce it from any private window by explicitly typing http://www.belastingdienst.nl.

One further thing I tried is to go from a working situation to a broken situation, i.e. after having opened HTTPS successfully, return to the situation that HTTP gives ERR_CONNECTION_RESET.

• Deleting all cookies for the site does not result in the broken situation. http://www.belastingdienst.nl still works.
• Completely clearing the profile (ctrl-shift-delete, All Time) does result in the broken situation.

After debugging all of this I think we deserve some tax cuts! (and maybe some BAT tokens 😉)

[hugobuddel]

Thank you for this awesome debugging @AronVanAmmers ! I've confirmed your findings, and the problem can also be reproduced on Chrome.

I'm closing this issue as

• The problem is on the side of belastingdienst.nl, not on Brave.
• The problem also occurs on Chrome.
• We have a workaround (use https).

I've still many questions on what exactly is broken, but those are for de belastingdienst.