You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When third party cookies are disabled, then you can't install a third party service worker from within a iframe.
I can kinda figure out why, it can have a few persistent stuff in the memory for a short life time as long as it's running and you can figure out if it have been installed before or not, but it's not like it stores anything.
But explaining to someone why they can't use my service worker that don't track anything what so ever is caused by blocked third party cookies is confusing.
I have built a StreamSaving library that utilize service worker to download large generated content data from the client and it's completely cookie free. All it basically dose is listen to a fetch event and doing evt.respondWith(new Response(new ReadableStream(...))) nothing more...
(related conversation jimmywarting/StreamSaver.js#148 (comment))
Basically everyone knows what a cookie is now due to all annoying cookie warning popups. "It's that little thing that stores a identifier in a small text file". and whats comes up when you google it.
But the meaning of "Disable (third party) cookies" in the browser settings is utterly confusing. It can block everything a supercookie can store... it can disable IndexedDB, localStorage, among others and in this case: Service Worker. I think it's wrong to associate navigator.cookieEnabled with "you can't install service worker" or you can't use cache api
I think this needs needs to be divided up.
Browser should really be changing the content/settings of cookies and be more explicit about what disable x means and what it dose. They should change the "disable cookies" for something more in line of prevent sites from tracking you by disable x,y,z and perhaps give a few option of what to enable & disable?
Something needs to be changed... And i think we developers deserve a better way to do feature detection and ask for permission is in order.
I think that the Permission API could solve some things by adding
When third party cookies are disabled, then you can't install a third party service worker from within a iframe.
I can kinda figure out why, it can have a few persistent stuff in the memory for a short life time as long as it's running and you can figure out if it have been installed before or not, but it's not like it stores anything.
But explaining to someone why they can't use my service worker that don't track anything what so ever is caused by blocked third party cookies is confusing.
I have built a StreamSaving library that utilize service worker to download large generated content data from the client and it's completely cookie free. All it basically dose is listen to a fetch event and doing
evt.respondWith(new Response(new ReadableStream(...)))
nothing more...(related conversation jimmywarting/StreamSaver.js#148 (comment))
Basically everyone knows what a cookie is now due to all annoying cookie warning popups. "It's that little thing that stores a identifier in a small text file". and whats comes up when you google it.
But the meaning of "Disable (third party) cookies" in the browser settings is utterly confusing. It can block everything a supercookie can store... it can disable IndexedDB, localStorage, among others and in this case: Service Worker. I think it's wrong to associate
navigator.cookieEnabled
with "you can't install service worker" or you can't use cache apiI think this needs needs to be divided up.
Browser should really be changing the content/settings of cookies and be more explicit about what disable x means and what it dose. They should change the "disable cookies" for something more in line of
prevent sites from tracking you by disable x,y,z
and perhaps give a few option of what to enable & disable?Something needs to be changed... And i think we developers deserve a better way to do feature detection and ask for permission is in order.
I think that the Permission API could solve some things by adding
And not having to do some try-catch things...
Cookies !== Other stuff
The text was updated successfully, but these errors were encountered: