consider allowing service workers when cookie policy is "keep until I close firefox"

NEW
Unassigned

Status

()

P3
normal
a year ago
9 days ago

People

(Reporter: lists, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug)

57 Branch
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171030163911

Steps to reproduce:

Open a https:// secured corporate website that registers a service worker  with "/serviceworker.js" (so it's definitionally the same origin) 


Actual results:

the the following error
DOMException
code: 18
columnNumber: 0
data: null
filename: "https://redacted/sw-client.js"
lineNumber: 22
message: "The operation is insecure."
name: "SecurityError"
result: 2152923154
stack: "@https://redcated/sw-client.js:22:5\n"


Expected results:

Service worker should have been registered .
(Reporter)

Comment 1

a year ago
html snippet that laods sw-client.js:

 <script type="text/javascript" src="/chips-sw-client.js"></script>



Code from sw-client.js that attempts registration:

var workerJS      = "/serviceworker.js";

if (!('serviceWorker' in navigator)) {
    //
    // Service Workers unsupported.
    //
      console.log("Service worker not supported");
    } else {
     
    navigator.serviceWorker.register(workerJS).then(
             function(registration) {
                //
                // Registration was successful
                //
                console.log('ServiceWorker registration successful with scope: ', registration.scope);
             }).catch(
             function(err) {
                // 
                // Registration failed
                // 
                console.log('ServiceWorker registration failed: ', err);
             });

    navigator.serviceWorker.addEventListener ('message',function (evt) {
                                                             console.log(evt);
                                                             console.log("SWClient: recevied message from serviceWorker");
                                                             processSWMessage(evt);
                                                        });

   }
Component: Untriaged → DOM: Service Workers
Product: Firefox → Core
Can you please attach about:support text for the effected profile?  In particular, if cookie policy has been modified we often do not permit storage to be used which also now blocks service workers.

Also, is this being opened in an iframe that might have an http:// parent?  That is also considered insecure.
Flags: needinfo?(lists)
(Reporter)

Comment 3

a year ago
Not in an iframe
Worked in Firefox 56 with same unmodified (by me) profile
Works in Chrome
Flags: needinfo?(lists)
(Reporter)

Comment 4

a year ago
Cookie policy is way to blunt of an instrument for deciding on whether or not a service worker can be registered.
The about:support shows:

  network.cookie.cookieBehavior: 3

Which means cookies are disabled:

  https://searchfox.org/mozilla-central/source/netwerk/cookie/nsICookieService.idl#89

Which means storage is disabled.

(In reply to lists from comment #4)
> Cookie policy is way to blunt of an instrument for deciding on whether or
> not a service worker can be registered.

Service workers must also be disabled since they implicitly require storage and persistent state to function.  If we allow service workers to function they can effectively implement super cookies.  So leaving it enabled defeats the privacy intention of disabling cookies.

Do service workers function if you restore your cookie settings back to the default?
(Reporter)

Comment 6

a year ago
Seems as though it's your cookie policy big-hammer at work.  My cookies were set to allow for session (delete when I close firefox).  Added an exception for the site to "Allow" and it no longer throws this error.   You really need a better way to manage this, than to overload cookie prefs (since cookies are long established old things).  Allowing IndexedDB LocalStorage and ServiceWorkers are really distinct from cookies.

At the very least you really should update the UI in the prefs/options to say Cookies/Local Storage and ServiceWorkers since it's not just for cookies anymore.  You should have updated that when you made the Cookies options control local storage. 

and this is all grouped under history, which is NOT where someone would look to control this.  Pull this out from there and make it a Storage/Workers/Cookies section at the very least.
(In reply to lists from comment #6)
> Seems as though it's your cookie policy big-hammer at work.  My cookies were
> set to allow for session (delete when I close firefox).

I was under the impression we blocked storage for that case, but we actually allow IDB, etc.  We could open service worker back up in that case.  Of course, no quota manager storage is cleared on browser exit with that setting enabled which is probably unexpected:

https://bugzilla.mozilla.org/show_bug.cgi?id=1400678

I need to ask the storage UX folks what the plan is here.

> You really
> need a better way to manage this, than to overload cookie prefs (since
> cookies are long established old things).  Allowing IndexedDB LocalStorage
> and ServiceWorkers are really distinct from cookies.

Non-technical users do not understand this distinction.  As I understand it our UX is going to align cookies/storage/history since users tend to think of them as the same thing; the browser remembering browser usage.

Let me ask the storage folks what they think...

Mike, what do you think we should do here?  Should we match current IDB/Cache behavior by allowing storage when "keep until I close firefox" is selected, even though we don't actually delete on close?  I blocked service workers in this case in bug 1336364 because I thought it was better to err on the side of privacy protection.

I guess I could make SW conform to other quota manager storage types for now and then we can fix bug 1400678 later.
Blocks: 1336364, 1226983
Status: UNCONFIRMED → NEW
Depends on: 1400678
Ever confirmed: true
Flags: needinfo?(mlien)
Summary: ServiceWorker Registration Fails from same origin stating it's not → consider allowing service workers when cookie policy is "keep until I close firefox"
Re: The current IDB behavior, it seems like bug 1147821 which implemented IndexedDB's use of StorageAllowedFor (itself implemented in bug 1184973) didn't really discuss the decision beyond this hand-waving comment[1]:
  // the factory callsite records whether the browser is in private browsing.
  // and thus we don't have to respect that setting here. IndexedDB has no
  // concept of session-local storage, and thus ignores it.

That's also effectively codified by the WorkerPrivate logic that only compares against eDeny as well[2]:
  loadInfo.mStorageAllowed = access > nsContentUtils::StorageAccess::eDeny;

I think the most correct behavior in these situations is to treat session storage like private-browsing mode.  The cookie service and LocalStorage both handle this mode by storing all new data as in-memory.  (However, there's also the unusual behavior where LocalStorage will load what already existed on disk as the starting point, instead of a blank slate like you'd experience in private browsing.  Those would add a frightful amount of complexity, and that behavior seems super un-intuitive in the first place.)

1: https://searchfox.org/mozilla-central/rev/aa1343961fca52e8c7dab16788530da31aab7c8d/dom/indexedDB/IDBFactory.cpp#317
2: https://searchfox.org/mozilla-central/rev/aa1343961fca52e8c7dab16788530da31aab7c8d/dom/workers/WorkerPrivate.cpp#4939
(In reply to Andrew Sutherland [:asuth] from comment #8)
> I think the most correct behavior in these situations is to treat session
> storage like private-browsing mode.

Well, in that case maybe the current behavior blocking service workers in this mode is correct then.  We explicitly don't allow SW in private browsing mode.
(In reply to Ben Kelly [:bkelly] from comment #7)
> (In reply to lists from comment #6)
> > Seems as though it's your cookie policy big-hammer at work.  My cookies were
> > set to allow for session (delete when I close firefox).
> 
> I was under the impression we blocked storage for that case, but we actually
> allow IDB, etc.  We could open service worker back up in that case.  Of
> course, no quota manager storage is cleared on browser exit with that
> setting enabled which is probably unexpected:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1400678
> 
> I need to ask the storage UX folks what the plan is here.
> 
> > You really
> > need a better way to manage this, than to overload cookie prefs (since
> > cookies are long established old things).  Allowing IndexedDB LocalStorage
> > and ServiceWorkers are really distinct from cookies.
> 
> Non-technical users do not understand this distinction.  As I understand it
> our UX is going to align cookies/storage/history since users tend to think
> of them as the same thing; the browser remembering browser usage.
> 
> Let me ask the storage folks what they think...
> 
> Mike, what do you think we should do here?  Should we match current
> IDB/Cache behavior by allowing storage when "keep until I close firefox" is
> selected, even though we don't actually delete on close?  I blocked service
> workers in this case in bug 1336364 because I thought it was better to err
> on the side of privacy protection.
> 

I am guessing the question should go to Mark Liang (Storage UX), not Mike, who is working on Hasal.
Also NI Jacqueline since she is working on aligning cookies/storage/history.

> I guess I could make SW conform to other quota manager storage types for now
> and then we can fix bug 1400678 later.
Flags: needinfo?(mlien)
Flags: needinfo?(mliang)
Flags: needinfo?(jsavory)
Thanks.  Sorry for the NI typo!
I agree that general users consider deleting on close equals don't remember anything during my last session. 

Currently in Nightly if users select "clear history when Nightly closes" and go to settings, they can select what should be cleared including "History" and "Data". Right now under the Data section there's only "Site Preferences" and "Offline Website Data". We should probably add more options to make sure user find the storage types they want to clear, or we could simply add a checkbox to clear all site data which could match with user's expectation.
Flags: needinfo?(mliang)
Priority: -- → P3
I agree as well with airing on the side of more privacy and that users probably understand this checkbox as not remembering anything from the previous session. 

I don't think that the work I'm doing currently will directly affect this in the short term, but when we do consider improving the History section, the improvements should probably also apply to the Settings menu that Mark mentioned. As well, if we add any extra options, it will need to be consistent with History as well.
Flags: needinfo?(jsavory)
At the most recent all-hands Storage UX meeting on the Wednesday morning at 8:30 (https://austinyallhands2017.sched.com/event/D5dI/next-steps-on-storage-persistence-and-permissions), I believe we reached consensus that we can treat eSessionOnly as "clear on shutdown" as proposed in bug 1400678 (and contradicting my comment 8 here where I suggested things should be in-memory-only).  So once bug 1400678 is fixed, we can/should indeed "allow service workers when cookie policy is 'keep until I close firefox'".

I'm also adding bug 1183245 (Service worker registration should be wiped when origin storage is wiped) as a dependency because we need the registrations to also be wiped out by the same logic whether at shutdown or startup.
Depends on: 1183245
Duplicate of this bug: 1534750
Duplicate of this bug: 1534680
You need to log in before you can comment on or make changes to this bug.