Need per-scope UA-spoofing switch [was "Permanent logouts on crowdin.com"] about umatrix HOT 17 CLOSED

Is there anybody else affected by this problem?

Me. I need to look into this, I think I had the same problem in HTTPSB, so there is something in there in the cookie management which causes ovezealous deletion of cookies (I'm guessing).

from umatrix.

What is your settings for session cookies?

I put in tracing code, and so far no session cookies have been deleted.

from umatrix.

In µMatrix - see above. I Chrome I allowed permament cookies for crowdin.com but block 3rd party cookies. Perhaps that's the problem as cloudfront.net might require cookies, too?

from umatrix.

Ok, I just had a cookie deleted for crowdin.net (not crowdin.com), and then I checked and noticed I was logged out. My crowdin.net cookie is blocked, since it is not 1st-party. So that could be a problem of how Crowdin site is designed. Will repeat and see.

from umatrix.

I think I haven't seen crowdin.net in µMatrix so far. This is how it looks for me:

I've now allowed cookies for cloudfront.net. Will see how this works out.

from umatrix.

I think it was just a fluke: I block 3rd-party cookies, so no way 3rd-party crowdin.net could set a cookie while browsing crowdin.com. Maybe just a leftover cookie for when I was testing while allowing 3rd-party cookies/site data.

from umatrix.

I just saw that allowing cookies for cloudfront.net didn't help either.

from umatrix.

Ok, I just noticed I was logged out again, and no cookies were deleted.

from umatrix.

Could it be that thing: https://mc.yandex.ru/metrika/watch.js?

from umatrix.

Perhaps. That's also blocked in µBlock.

from umatrix.

No, it's not. I was logged out again although I had mc.yandex.ru allowed in µMatrix and µBlock was disabled. Must be something else ...

from umatrix.

Wondering if it is UA-spoofing. I haven't found anything so far done by uMatrix: site cookies are not removed, site local storage are not cleared. Maybe the site uses UA string as an extra variable to determine whether a user logged out. That would be a smart move to help foil attempts at break in.

from umatrix.

Ok it seems UA-spoofing is the problem: I am no longer being kicked out (so far) after I disabled it.

from umatrix.

Yes, same here. If this is really the culprit - what would be the consequence? Is an exception list necessary for UA-spoofing?

EDIT: Or would it be possible that µMatrix does not apply a new UA for sites currently loaded in a tab? I.e, only for newly loaded sites?

from umatrix.

Or would it be possible that µMatrix does not apply a new UA for sites currently loaded in a tab?

Not really. A "site" from uMatrix's point of view is a distinct URL, so that would not work. There is no data structure internally for "site".

I was thinking more of a per-scope switch to override global setting. This would fit well in the current infrastructure with a bit of rework which is needed anyway to address similarly #7.

from umatrix.

While we're on it ... I remember that I was logged out from some other sites (among them 1 banking site) in the past - only rarely, but it happened. I had never related those problems to UA-spoofing but those exmples may confirm that other sites use this technique, too.

And you're absolutely right: The best solution is a per-scope-switch, of course.

from umatrix.

This seems to be an attempt to prevent session hijacking, a normal user is unlikely to change the UA while logged in, so its assumed an attacker acquired the session and its terminated

from umatrix.