I’ve been increasingly frustrated with Firefox for Android, my preferred mobile web browser. I’ve repeatedly had to re-login to some websites and had various problems with cookies since last year’s release of the new Firefox codenamed “Daylight.” Websites forget me between each visit and I get the “new visitor” experience every time. I finally worked out what’s going wrong.
I’ve suspected that it might have been a side-effect of Firefox’s tracking-cookie-blocking features. I’ve just assumed the issues have been caused by short-lived session cookies, limited device storage space, perverse incentives to give me new opportunities to consent to tracking cookies, and I’ve made other excuses for the buggy behavior.
Yesterday, I stumbled upon the underlying cause of many of my cookie problems. I had implemented an authentication cookie for a project, but the cookie didn’t persist between page-sessions in Firefox for Android (F3A.) Other browsers would remember and retransmit the cookie until its expiration time. I verified that F3A did indeed store the cookie, but it consistently failed to send the cookie back to the server on subsequent visits.
So, what was going on? and why did it only affect some websites? I ran various basic tests for persistent and session cookies, and they all worked as expected. It wasn’t a general problem with cookies, but something more subtle and difficult to identify.
As this was an authentication-related cookie, I’d specified strict security policies for the cookie. The cookie shouldn’t be accessible from JavaScript (HttpOnly), should only be sent over an encrypted connection (Secure), and should only be sent on same-origin requests (SameSite=Strict.) It’s this last property that causes the cookie problems on F3A.
SameSite=Strict tells the browser to only submit the cookie with requests originating from the same origin as the cookie. The restricting is meant to thwart cross-site scripting (XSS) vulnerabilities. For example, if the cookie was set for example.com, it wouldn’t be transmitted along with a request for example.com/image.png loaded from another.example.net. Both F3A and Firefox for desktop supports SameSite=Strict just fine.
However, there’s a slight problem with F3A’s definition of “same-site.” When you navigate to a webpage using the navigation/address bar (e.g. by typing an address or selecting an item from the search/history list), then F3A uses >null as the origin instead of the domain of the destination website. As the origins aren’t the same, the strictly enforced same-site cookie isn’t transmitted along with the request. The bug isn’t a security problem, as it just causes Firefox to be too catious with its cookies.
To make things worse, reloading the page doesn’t fix the problem. The cookie still isn’t sent. You have to navigate to the page by clicking on a link to it to get F3A to submit SameSite=Strict cookies.
Websites like GitHub and Quora don’t rely on SameSite=Strict, and have opted to use duplicate cookies with and without the SameSite property. This completely undermines the security benefits, but ensure sessions work for their visitors. Other websites have assumed web browsers that don’t support the property will simply ignore it. It’s this last category of websites that forgets you between visits and fails to log you in.
Mozilla has known about the issue for over a year. It knew about it before the first public release Daylight. Issue #1573860 has more details and history on the issue.
You can work around the bug by not navigating to websites that require cookies by using Firefox’s navigation/address bar. Unfortunately, opening websites from bookmarks are also affected by the same bug. This hurts me to say as a Firefox enthusiast, but you should probably switch to a less buggy web browser.