1840235 - Unable to connect to My Sony, console shows 403 only on nightly/linux

Status: NEW

(Web Compatibility :: Site Reports, defect, P3)

Description

[:gerard-majax]

Reproducing on nightly for a few releases to me. Tested disabling ublock, new profile (via mozregression), tracking protection, cookies cleanup, user agent swicther.

Works on the same machine in:

• 115.0b9, 115.0b10
• chromium
• stable snap

STR:

• goto sony.fr
• click my sony
• enter email of your account
• click connect

Expected:

• presented reCAPTCHA
• then redirect to ask password

Actual:

• nothing happens
• console shows XHR POST to https://www.sony.fr/mysony/authsearch returning 403

Comment 1

[:gerard-majax]

mozregression with a build of jan 2023 does reproduce.

Comment 2

[:gerard-majax]

Even when I get reCAPTCHA to be displayed and I solve it successfully, still no go.

Comment 3

[Bob Hood [:bhood]]

Alexandre, can you please attach the output of your about:support to this report from the machine that is exhibiting the behavior?

Also, you mentioned in comment 1 that you performed a mozregression. Using that, can you please pinpoint the version where the issue appeared and add that as a comment as well?

Comment 4

[Bob Hood [:bhood]]

Taking a shot in the dark and dropping this into the DOM: Web Authentication component. Please feel free to update to a more appropriate component if this isn't even remotely correct.

Comment 5

[:gerard-majax]

(In reply to Bob Hood [:bhood] from comment #3)

Alexandre, can you please attach the output of your about:support to this report from the machine that is exhibiting the behavior?

Also, you mentioned in comment 1 that you performed a mozregression. Using that, can you please pinpoint the version where the issue appeared and add that as a comment as well?

well that's the point: i went back to jan 1st 2023 nightly and it was still broken. current stable snap, current 115.0b9 or 115.0b10 are OK. I've also filed a webcompat issue, because I'm unsure where the problem lies at that point: https://github.com/webcompat/web-bugs/issues/124018

I guess I'll test deeper next week (with a dedicated account, I dont want to lock mine)

Comment 6

[:gerard-majax]

oh and other websites using reCAPTCHA were fine.

obviously, mozregression got me clean profile so it's not a pref or an extensions I setup

Comment 7

[:gerard-majax]

tried toggling network.cookie.sameSite.noneRequiresSecure=false but to no luck

Comment 8

[:gerard-majax]

Fun: my Nightly on Windows 10, same buildID, even with tracking protection and uBlock, works

Comment 9

[:gerard-majax]

(In reply to Bob Hood [:bhood] from comment #3)

Alexandre, can you please attach the output of your about:support to this report from the machine that is exhibiting the behavior?

it's not specific to my machine, I just reproduced on a (clean) install of Nightly as a Snap package in a VM.

Comment 10

[:gerard-majax]

Even creating an account fails redirecting to a page showing Access Denied, after successfully solving the CAPTCHA. Only on Nightly under Linux.

Comment 11

[:gerard-majax]

Trying to repro for sharing screenshot on the webcompat issue, now mozregression is getting me (some) working builds.

Comment 12

[:gerard-majax]

After many retries, all confirming https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8e04fde24819ae023bfb5f1e7b73e4c074d562bd&tochange=e29e1016c0e30551be3cf6cd40d5b8e1d184e7d6

Comment 13

[:gerard-majax]

Anyone wanting to verify the mozregression window, I can confirm 2023-06-16 is OK and 2023-06-17 is BAD.

Comment 14

[:gerard-majax]

(In reply to Alexandre LISSY :gerard-majax from comment #12)

After many retries, all confirming https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=8e04fde24819ae023bfb5f1e7b73e4c074d562bd&tochange=e29e1016c0e30551be3cf6cd40d5b8e1d184e7d6

Looks like it was the wrong one, local revert does not help ...

Comment 15

[:gerard-majax]

Attachment: mozregression log

Comment 16

[:gerard-majax]

this range (start, stop) seems to be reliable: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c5ccbac639929af650a1c338a7652ef76a7e1ee3&tochange=29e4ffb2c3974dbb81fcc5ca102c6b5bd98f271f

but getting something finer is never getting me the same bad commit ...

Comment 17

[:gerard-majax]

So except for me loosing 4h+ of my time, no conclusive result. I keep getting random bad commits in this range ...

Comment 18

[:gerard-majax]

57dfc72d508c3d7ac1e157efd4939c22f08d47fd: OK
bb9a86b9b26fffa225a80c63c2684fb8d8afb081: KO

Now this is consistent over several retries:

$ mozregression --repo autoland --launch bb9a86b9b26fffa225a80c63c2684fb8d8afb081
$ mozregression --repo autoland --launch 57dfc72d508c3d7ac1e157efd4939c22f08d47fd

https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=57dfc72d508c3d7ac1e157efd4939c22f08d47fd&tochange=bb9a86b9b26fffa225a80c63c2684fb8d8afb081

I have no idea how this can relate, but now this is clearly OK and KO (3 retries on each) on those.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1838768

Comment 20

[Jonathan Kew [:jfkthame]]

I find it hard to see how bug 1838768 could be directly related here, but it will have affected timing (assuming there's canvas2d involved somewhere), and that may be affecting behavior of something that is already fragile.

Comment 1 and comment 5 seem to be saying that the problem existed long before bug 1838768 anyhow, so I suspect the mozregression result pointing there is spurious.

Comment 21

[:gerard-majax]

(In reply to Jonathan Kew [:jfkthame] from comment #20)

I find it hard to see how bug 1838768 could be directly related here, but it will have affected timing (assuming there's canvas2d involved somewhere), and that may be affecting behavior of something that is already fragile.

Comment 1 and comment 5 seem to be saying that the problem existed long before bug 1838768 anyhow, so I suspect the mozregression result pointing there is spurious.

As I said, but you are welcome to reproduce my experiments. Spending half of my day working on solving CAPTCHAs was not fun already that once I found this range, I triple verified. Let alone I let it sink during the night and reproduced this morning.

Comment 22

[Jonathan Kew [:jfkthame]]

(In reply to Alexandre LISSY :gerard-majax from comment #10)

Even creating an account fails redirecting to a page showing Access Denied, after successfully solving the CAPTCHA. Only on Nightly under Linux.

I just got the Access Denied page trying to create an account on Linux with Firefox 114.0.2, just the same as with Nightly. (But with Nightly on macOS, I got past that.)

Comment 23

[:gerard-majax]

(In reply to Jonathan Kew [:jfkthame] from comment #22)

(In reply to Alexandre LISSY :gerard-majax from comment #10)

Even creating an account fails redirecting to a page showing Access Denied, after successfully solving the CAPTCHA. Only on Nightly under Linux.

I just got the Access Denied page trying to create an account with Firefox 114.0.2, just the same as with Nightly.

Yeah. I'm really wondering if there's some kind of fingerprinting happening on their side ... I could create a new account yesterday for my experiments using Chromium :(. For sure I was running a build from prior june 17th when I created and logged in the other day (I just verified timestamp): I created the account on 20/06/2023 at 0644, and my nightly update log shows I updated the same day at 0843. I was running a build from the 8th before.

Comment 24

[Jonathan Kew [:jfkthame]]

The site is definitely doing some fingerprinting stuff; by instrumenting the canvas2d code, I can see that it repeatedly calls a canvas text-drawing API with the string "<@nv45. F1n63r,Pr1n71n6!", among other things. It's doing this with the canvas font set to 16pt Arial, which (because they've expressed it in pt, and it's not divisible by 3) will be affected by the quantization from bug 1838768: converting 16pt to pixels would give 21.333333px, but that'll now snap to 21.25px.

So the change there could affect this canvas fingerprinting -- they're presumably reading back the resulting pixels, and hashing the result or something, and it'll now be slightly different than before.

However, it's not clear why that should block access altogether; and as noted above, it's not the only issue in play. I'm blocked from accessing with Linux even using a version long before that bug landed; also still blocked with a Nightly build where I've locally reverted the change.

I don't know what other factors are causing them to block access, but the canvas change is at most a small incidental factor. Basically, it's a site issue. If they're doing canvas fingerprinting, they're probably doing a bunch of other shady stuff as well, and presumably not doing decent cross-platform/cross-browser testing.

Comment 25

[:gerard-majax]

Thanks, knowing you can confirm there's weird things done makes it more likely we have to webcompat this (I filed it as well https://github.com/webcompat/web-bugs/issues/124018)

Comment 26

[:gerard-majax]

I'm curious how much:

• this fingerprinting is used to distinguish bots vs humans
• this triggers more or less of reCAPTCHA being to solve
• the 403 is just a side-effect of being suspected to be a bot , even though we successfully solve the CAPTCHA.

Probably the WebCompat people can help there?

Comment 27

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1838768

Comment 28

[Cieara Meador [:cmkm] (she/her)]

Hi Dennis! I saw your response on the webcompat issue, just checking in to see if there's any update here? :)

Comment 29

[Dennis Schubert [:denschub]]

(In reply to Cieara Meador [:cmkm] from comment #28)

just checking in to see if there's any update here? :)

The only thing I can say at this point is that we and Akamai are working on it. We'll update this bug if we have something new.

Comment 30

[Johan Lorenzo [:jlorenzo]]

Thanks for clarifying the situation in your previous comment, :denschub. Just a quick question: do you foresee any changes for Firefox 117 (currently in beta)? Or should we call it a wontfix for that particular version?

Comment 31

[Dennis Schubert [:denschub]]

Right now, I don't expect any change on our side - this will probably be fixed on Akamai's end.

Let's move this into the WebCompat product for now.

Comment 32

[:gerard-majax]

Have we heard back from Akamai yet ? Testing this weekend and I can now login on My Sony french website with my Nightly/Linux setup.

Comment 33

[Dennis Schubert [:denschub]]

They're still working on it. I'm glad to hear this works for you now, but I assume this still is a valid (low-frequency) intermittent, so let's keep this open until we've received an official "this shouldn't happen again" from Akamai.

I will, however, correct the metadata so that Release Management doesn't have to touch this bug all the time. To my current knowledge, this isn't something we have to fix, and instead we're just waiting on Akamai.

Comment 34

[:gerard-majax]

There are various reports of people having issues with PSN connection related to My Sony, including https://github.com/webcompat/web-bugs/issues/129199 https://www.reddit.com/r/firefox/comments/17o7mz6/cannot_login_to_playstation_store_on_firefox_1190/

Unfortunately for them it's not just impossible to login, there seems to be some leaking involved making the browser unusable.

So far I cannot reproduce on my system, but it's similar enough to my reports that I am wondering.