Browser is blocked by Akamai and Cloudflare

Bug Reports
#1

Original title: electrolux.fi partially inaccessible

This post is now a wiki; please feel free to add affected web sites at the end.

REPRODUCIBILITY: 100%
OS VERSION: 4.4.0.68
HARDWARE: Xperia 10 II, Xperia 10 III
UI LANGUAGE: English, Finnish
REGRESSION: ?

DESCRIPTION:

Some pages are inaccessible with Browser, e.g. https://electrolux.fi and https://www.gigantti.fi

STEPS TO REPRODUCE:

  1. Go to site
  2. Navigate to e.g. air conditioners: https://www.electrolux.fi/vacuums-home-comfort/air-comfort/air-conditioners/

Note: in general it seems that a page may load on the first access in a while, and may even allow (sometimes) one action, but after that a reload or page navigation action will show error/blocked message (akamai) or the infinitely ‘checking browser’ (cloudflare).

EXPECTED RESULT:

The page is displayed and can be used normally, i.e. use the search, navigate categories, etc

ACTUAL RESULT:

Akamai:

Access Denied

You don't have permission to access
"http://www.electrolux.fi/[...]/" on this server.

Reference #18.da6de5c1......

Cloudflare: infinitely loading ‘checking your browser’ page.

MODIFICATIONS:

None

ADDITIONAL INFORMATION:

Fennec 103 from F-Store is not affected, so it can’t be an IP address block.

List of sites affected:

7 Likes
Can't login to microsoft 365 because browser is 'unusual'
Scripted download of stop releases list fails!
(jolla browser) Sites that aren't working in ESR 78
Community meeting on IRC 18th August 2022
Sailfish browser is too 'unusual' for godaddy webmail
Can't login to microsoft 365 because browser is 'unusual'
Gecko esr91 work (former "Flypig's gecko dev diary")
[Release notes] Vanha Rauma 4.4.0.72
Amazon is not rendering in the default browser
#2

The identical error message appears when visiting Gigantti, e.g.: https://www.gigantti.fi/tv-aani-ja-alykoti

#3

Just now i tested both links you provide, page loads incl. pictures. But then, as the silly cookie permission page comes, on the first page (electrolux) i denied and then page worked, on the other site (gigantti) i didn’t come further because i do not understand finnish.
But under the cookie overlay, or in the seconds before it appears, there was the full text & images visible. Volla. Will test X10 later and also report here.

#4

Here’s how to handle the Finnish cookie dialog:

teen muutoksia (I’ll make changes) > untick everything > päivitä suostumus (update accepted)

I can trigger the error page after I click a category link at least; just click a TV, tablet, vacuum cleaner etc. and you’ll get the error page. Reproducible with private browsing, too. Then, clicking back triggers it, too.

Edit: refreshing the page is needed on the Electrolux site, and the same is needed with Gigantti. So the pages works, but navigation is borked?

#5

Yes, after some surfing the kitchen equipment, there comes ‘access denied’.

#6

This also applies to lippu.fi

Strangely, it was also triggered by a desktop Firefox (103…?), so this might be well dicussed elsewhere. I’ll do some digging.

Edit: Here’s one find: Access Denied with firefox but not with Chrome | Firefox for Enterprise Support Forum | Mozilla Support and it tells basically to clear browser cache. Well, my desktop Firefox hadn’t ever accessed the domain lippu.fi before, so that doesn’t count. My friend suggested a server side issue, and as F5 helps, it looks like one…

1 Like
#7

This looks like to be the culprit:

https://community.akamai.com/customers/s/article/Why-is-Akamai-blocking-me?language=en_US

Customers of Akamai can (and will) set up rules to filter out bots, crawlers, DDoS attacks and so on. My IP may have a low reputation, or my ISP, or my IP block, or my country, or the reason can be something else altogether. Long story short - nothing you can do, pretty much.

The article contains a link to check your IP address reputation, but that may or may not result to a meaningful result. For example, I can constantly trigger the access denied page with Browser, but not at all with Firefox Fennec…

2 Likes
#8

Thanks for flagging this and for looking into and getting to the bottom of it. I experience the same thing, but it does indeed look like this is something only the individual site owners can address.

I’ve tagged it as “fixed”… I know it’s not fixed, but the meaning is really closer to “closed”, since it just avoids the report coming up again for the Community Bug Coordination team.

4 Likes
#9

Doesn’t @direc85 's last remark indicate that it’s not something to do with the connection (ip, isp, etc), but rather something with the browser?

Another site where this seems to be really easy to trigger is https://www.buienradar.nl (dutch weather service). If you’re lucky you can just about make it to the weather for a given city, but after a page refresh it goes to an ‘access denied’ page.

The same holds for me. While my phone gets an access denied page, it’s perfectly accessible from my desktop. As this is the same network, this really seems to point more to a problem with the browser.

With no other browsers available this makes a small set of sites unusable and inaccessible from sailfish. I really wish Jolla would look into this problem more closely.

2 Likes
#10

It’s a combination of both. How exactly the servers deduce the connection to be blocked is a trade secret, but it takes into account all of them: geolocation, IP address, request headres, and of course user agent string. Faking the UA string isn’t a long-term solution, because it’s going away anyway, but it most likely is a key factor here. One such place to quickly find out your user agent string is https://whatsmyua.info/ which for the Browser is Mozilla/5.0 (Mobile; rv:78.0) Gecko/78.0 Firefox/78.0. Fennec, for comparison has Mozilla/5.0 (Android 10; Mobile; rv:103.0) Gecko 103.0 Firefox/103.0 and my desktop computer Firefox Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0. Perhaps it’s the missing operating system detail? The Gecko version could indicate using some certain tool that uses the same old version? I don’t know…

Edit: For the fun of it, I tried to set a more specific user agent string, with using WiFi for a different IP address, no change:

CUSTOM_UA="Mozilla/5.0 (Linux 4.19; Sailfish 4.4; Mobile; rv:78.0) Gecko/78.0 Firefox/78.0 SailfishBrowser/2.2" sailfish-browser

Even with a copied UA string from my desktop Firefox didn’t change the outcome. It’s just something the browser inheretly does or doesn’t do…

2 Likes
#11

Ok, but look at it purely from a user’s perspective. All I know is that the same site works (now and always has!) on my desktop, my previous phone (blackberry), all my house mate’s phones (android & ios), and yet it fails to work on my sailfish device. So where should a user logically conclude that the problem must be?

Even if there is some obscure underlying technical reason why it doesn’t work, that doesn’t change the fact that it doesn’t work on my sailfish phone (only). And that is something that jolla really should work to improve. Nowadays browsing on a phone is something that is expected to ‘just work’, it is no longer just a gimmic.

1 Like
#12

That’s true, from the user point of view the browser is to blame…

I tried to find clues from Akamai, but all they say is that they can see that the request was blocked and cannot declare any information of their clients’ WAF (whatever that is, some Akamai thing). If Jolla contacted Akamai directly, that could lead into results, but as users, there’s nothing I can think of…except sending every site complaints.

I managed to find the feedback form of Gigantti, but I couldn’t find one for Electrolux. They really hide away the means for the users to complain send feedback…

I’ll try to edit the opening post to better reflect the situation, and turn it into a wiki post where users can add more web sites that are affected.

1 Like
#13

Web application firewall, the UA is so unique they think it’s randomly generated by bots trying to attack them

2 Likes
#14

It’s not the user agent string, at least not alone.

#15

Your IP and/or footprint probably was already registered as suspected bot, but it’s definitely a policy on their side (very likely AI generated), recently wizzair accused me of being a bot when using desktop FF, chromium monopoly here we go

2 Likes
#16

I also tried at work, with Browser in private mode, same thing. Akamai detects something about Browser and has simply decided to block it.

2 Likes
#17

Yeah, the only problem is akamai won’t listen to jolla or us, the guys losing business might be heard if enough people complain that their phone is recognized as a bot and prevents them from buying stuff (good luck with the weather service, then again their support might still be easier reachable than akamai without a business account)

#18

And the same is now also with cloudflare, their bot-detection never finishes (example of endless ‘checking your browser…’ https://sys.4channel.org/captcha?opened=1&board=tv&thread_id=173381631) so soon no webpage is going to work as those are the biggest cdn/anti-ddos etc providers

#19

It’s getting worse, not fixed at all (but yeah you need WONTFIX (or maybe CANTFIX even) for this ‘bug report’ type tag). I wonder if a lot of aurora OS users accessing finnish stores is causing this?

#20

Another site, this time blocked by cloudflare: https://techtablets.com/