Storage-Access-Headers: Handle same-origin/cross-origin redirects
Categories
(Core :: Privacy: Anti-Tracking, enhancement)
Tracking
()
People
(Reporter: manuel, Unassigned)
References
(Blocks 1 open bug)
Details
Follow up on Bug 1968725.
|
Reporter | |
Comment 1•2 months ago
|
||
The redirect tests fail due to us failing the origin checks set in place. We do not add an origin header after the redirect. However, the tests check for the existence of them.
storage-access-headers.tentative.https.sub.window.js:365,411,451
'origin': [https_origin],
'origin': ['null'],
'origin': ['null'],
Also due to having a tainted origin, we do not set the "Sec-Fetch-Storage-Access: inactive" header, but no storage-access header. Making the cross-origin, same-site test fail additionally here in storage-access-headers.tentative.https.sub.window.js:410:
'sec-fetch-storage-access': ['inactive'],
The storage-access-header differientation between "inactive"/"none" disabled checks would need to be put in an external function and also go to
RefPtr<net::HttpBaseChannel> httpBaseChannel = do_QueryObject(aChannel);
if (httpBaseChannel && httpBaseChannel->HasRedirectTaintedOrigin()) {
return nsILoadInfo::NoStoragePermission;
}
(Side note: making it a helper function could allow differentiating between not sending the header and "none" value in Bug 1978856)
I'm not sure how the spec expects the 'inactive' header, when sending a null origin. The whole point of attaching the origin to the request was to let the server make an informed decision. But with 'inactive'-storage-access and 'null'-origin, nothing is won for the server. It could still be activated with the Activate-Storage-Access: retry; allowed-origin=*-response header.
Pernosco session that aided debuging: https://pernos.co/debug/KPWr5G7cwWOXocwG-o1dxw/index.html
Description
•