Closed Bug 1529396 Opened 11 months ago Closed 5 months ago

Consider relaxing the exception-throwing semantics of window.localStorage when a privacy check fails

Categories

(Core :: Privacy: Anti-Tracking, defect)

defect
Not set

Tracking

()

RESOLVED WONTFIX
mozilla67
Tracking Status
firefox67 --- fixed
firefox70 --- fixed

People

(Reporter: ehsan, Assigned: ehsan)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-needed, site-compat)

Attachments

(2 files, 1 obsolete file)

STR:

Go to https://www.bing.com/videos/search?q=my.mail.ru&&view=detail&mid=F2C789FD6784869C6028F2C789FD6784869C6028&&FORM=VRDGAR. The page fails to load with a SecurityError exception on some JS like this:

G = window.localStorage || null

Perhaps we should consider making this code pattern work.

Keywords: dev-doc-needed
Pushed by eakhgari@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/5306ba39ab30
Stop throwing an exception from window.localStorage when a privacy check fails; r=baku
Status: NEW → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67

Steven, do you mind noting this change of behaviour in our documentation please? Thanks!

Flags: needinfo?(senglehardt)

I think this change is harmful, as the new behavior is not mentioned anywhere in the official specification. Actually, It breaks my logic of detecting whether a given storage object is available:

let storage: Storage;
try {
  storage = getStorage();
  if (!storage)
    // Since Firefox 67, `window.localStorage` no longer throws `SecurityError` when blocked due to privacy settings
    // Source: https://www.fxsitecompat.dev/en-CA/docs/2019/window-localstorage-no-longer-throws-securityerror-when-blocked-due-to-privacy-settings/
    throw new DOMException(
      'Failed to read storage object: Access is denied for this document.',
      'SecurityError',
    );
} catch (error) {
  if (errorCallback) errorCallback(error);
  return;
}

// I would like to use the storage from here, with exception handling for `setItem` calls
const foo = storage.getItem('foo');

(I do not intend to test the storage management mechanism, e.g. getItem and setItem)

Flags: needinfo?(ehsan)

Kristóf, thank you for raising this, and my apologies that this change has impacted you negatively.

I did some investigation on this, here is some data:

  • The original problem doesn't reproduce any longer.
  • The new Chromium-based Edge which is shipping something very close to ETP doesn't have this work-around, and if it did and the original bug came back then bing.com would fail on Edge.
  • It seems like Blink and WebKit both throw SecurityError here.

So I'm going to revert this change as clearly there's no good justification for keeping it any more.

Status: RESOLVED → REOPENED
Flags: needinfo?(ehsan)
Resolution: FIXED → ---
Attachment #9045467 - Attachment is obsolete: true

Updated the site compatibility note to say the change has been reverted with Firefox 70.

You need to log in before you can comment on or make changes to this bug.