1317955 - Considering the use of an hash string for firstPartyDomain

Status: RESOLVED WONTFIX

(Core :: DOM: Security, defect)

Description

[Andrea Marchesini [:baku]]

Currently, we use OriginAttributes::CreateSuffix() in many places (from quotaManager to necko).
When mFirstPartyDomain is set, we add it to the suffix string.
This means that, it's possible to know the firstPartyDomain, just checking what quotaManager (or cookies, or anything else) writes on disk on the profile directory.

I suggest to use sha256 (or any other faster/better hash function) to convert the firstPartyDomain value.

Comment 1

[Honza Bambas (:mayhemer)]

Not a bad idea.  Please also note we already do use a hash in HTTP cache index:
https://dxr.mozilla.org/mozilla-central/rev/79feeed4293336089590320a9f30a813fade8e3c/netwerk/cache2/CacheHashUtils.cpp#192 (bug 1201042).  We use SHA1, from two reasons: the index only has an informative value (tells us quickly presence of a cached content with hi confidence).  If a cached entry is found, we check its isolation by comparing the raw OA suffix string then.  The other reason is that we want to keep the index data small and SHA1 has a small footprint.

Comment 2

[Andrea Marchesini [:baku]]

Attachment: suffix.patch

Comment 3

[Andrea Marchesini [:baku]]

Comment on attachment 8811355 [details] [diff] [review]
suffix.patch

This approach doesn't work because, generated suffix, should be parsable by PopulateFromSuffix

Comment 4

[Tanvi Vyas[:tanvi]]

baku, where did we wind up with this?  Is this still about protecting the profile directory?  Or something else?  Is it a close won't fix?

Comment 5

[Andrea Marchesini [:baku]]

The patch of the unminimized version of CreateSuffix() landed in bug 1315905.