Live data from Hacker News

Purge site data when site identified via old tracking cookies

bugzilla.mozilla.org

51–60 of 135 posts

Re: Purge site data when site identified via old tracking cookies

#51
post #25

I have been using “Cookies Autodelete” for years. Except for a short list of 20 sites, nothing can store data on my Firefox. These tracking sites would not be able to show me ads anyway because I have “uBlock origin” And finally “I don’t care about cookies” to automatically dismiss these stupid GDPR “we’re going to use cookies” prompts. Without these the Internet feels broken.

>I have been using “Cookies Autodelete” for years. Except for a short list of 20 sites, nothing can store data on my Firefox. Not really. It doesn't delete indexeddb for instance.

    delete indexedDB;
in userjs is all it takes in Chrome to disable indexedDB permanently

Re: Purge site data when site identified via old tracking cookies

#52
post #31

Earlier quoted context omitted.

Why would that matter? If the browser fetches images hidden behind onhover, then presumably it would also fetch plain tags, so why not use those. If it doesn't fetch onhover images (which admittedly might break the "reasonably formatted" bit), then tracking pixels are useless because, well, it doesn't fetch them.

Because after you hover on something, it can be an indication of intent. Just loading an image when the webpage loads doesn't give you any insight into what the user 'interacted' with.

> Because after you hover on something, it can be an indication of intent.

Yes, that's (one of the many reasons) why javascript needs to die.

> Just loading an image when the webpage loads doesn't give you any insight into what the user 'interacted' with.

That's what I said: regardless of whether the browser, when loading a page, does or does not include hidden images in what it fetches, that cannot possibly tell you anything about what the user interacts[0] with after the page has loaded and browser is no longer communicating with your server.

0: edit: obviously excluding clicking links or other navigation-causing interactions, but that's a separate problem.

Re: Purge site data when site identified via old tracking cookies

#53
post #37

Earlier quoted context omitted.

"I wouldn't mind going back to a JavaScript-less experience." By not using a graphical, JavaScript-enabled browser, I have been experiencing the web this way for the last 15 years. It works just fine for the purposes I use if for, mainly informational retrieval. For me, there is no such thing as "page load time". This shifts all awareness to "server response time". This is more or less the same from one website to an…

How do you deal with pages that use JavaScript to fetch page content after the initial markup is loaded?

"How do you deal with pages that use Javascript to fetch page content after the initial markup is loaded?"

Provide an example page and I will demonstrate how I would solve the problem.

Not every user visits the same websites and web pages, so without giving specific examples, discussions about how to deal with these pages never go anywhere on HN.

To be honest, out of all the websites I have visited over entire lifetime using the www, the number where I have had to make any extra effort because of Javascript in order to retrieve some text/html, image or video is very small proportion. Not one that is large enough to justify using a JavaScript-enabled browser as default. For me, these are exceptional cases, not the norm.

The extra effort is usually a one-off script, not something I need to save.

Occasionally it is something I save for future use. One example of a saved script would be for non-commercial YouTube channels. Goal was a 2-column CSV of all videos from a channel in the form of title, url. Goal was not "perfection", just quick solution.

yy025 and yy032 are custom utilties for generating HTTP and decoding HTML, respectively.

Using a short script called "ytc" the process would be something like the following. openssl s_client is used as an example of a TLS client. "XYZ" is the name of the channel.

   echo https://www.youtube.com/channel/XYZ/videos|ytc|sed wXYZ

   Connection=keep-alive yy025  1.html

   ytc title  XYZ.1

   ytc url  XYZ.2

   paste -d, XYZ.[12] > XYZ.csv
Here is the "ytc" script

   case $1 in 
   "")exec 2>/dev/null;
   export Connection=close;
   yy025|openssl s_client -connect www.youtube.com:443 -servername whatever -ign_eof |sed 's/%25/%/g'|yy032 > 1.tmp;
   while true;do
   x=$(sed 's/%25/%/g;s/\\//g' 1.tmp|yy032|grep -o "[^\"]*browse_ajax[^\"\\]*" |sed 's/u0026amp;/\&/g;s/&direct_render=1//;s,^,https://www.youtube.com,')
   echo > 1.tmp;
   test ${#x} -gt 100||break;
   echo "$x";
   echo "$x"|yy025|openssl s_client -connect www.youtube.com:443 -ign_eof > 1.tmp;
   done;rm 1.tmp

   ;;-h|-?|-help|--help)echo usage: echo https://www.youtube.com/user/XYZ/videos \|$0;echo "usage: $0 {title|url} 

Re: Purge site data when site identified via old tracking cookies

#54
post #51
post #25

Earlier quoted context omitted.

>I have been using “Cookies Autodelete” for years. Except for a short list of 20 sites, nothing can store data on my Firefox. Not really. It doesn't delete indexeddb for instance.

delete indexedDB; in userjs is all it takes in Chrome to disable indexedDB permanently

It is still possible for websites to access indexedDB by using Web Workers:

  new Worker("data:application/javascript,console.log('indexedDB: ', indexedDB)")
This works since userscripts only run in top-level websites and frames, but the above code runs JS code in a seperate thread with no attached DOM.

Re: Purge site data when site identified via old tracking cookies

#55

Earlier quoted context omitted.

I think the issue is verification that an ad has actually been shown to a human. Even print and TV advertisers can have companies do audits to verify ads get run as expected. Thing is, nobody ever said ad supported sites have to be viable.

> Thing is, nobody ever said ad supported sites have to be viable. That's true, but if a site is not ad-supported, and "paywall" is almost an epithet (and circumvented to boot), how is any site supposed to remain viable?

>> but if a site is not ad-supported, and "paywall" is almost an epithet (and circumvented to boot), how is any site supposed to remain viable?

They're not. Think about news sites that rewrite stories from paywalled sites and collect ad revenue. They are parasites that make money from other peoples work. Same thing for all those YouTube channels (though they are not other sites) that repackage other peoples content and make money doing so.

What we need is not so much a way to advertise on the net, but a way to make small payments and subscriptions simple. If sites needed their users to pay them, the quality of the content might go up dramatically. Places like HN could still exist just fine too.

Having said that, I think there are ways to verify ads without cookies and such. It's just that it takes more effort on the server side.

Re: Purge site data when site identified via old tracking cookies

#56

Earlier quoted context omitted.

> Thing is, nobody ever said ad supported sites have to be viable. That's true, but if a site is not ad-supported, and "paywall" is almost an epithet (and circumvented to boot), how is any site supposed to remain viable?

>> but if a site is not ad-supported, and "paywall" is almost an epithet (and circumvented to boot), how is any site supposed to remain viable? They're not. Think about news sites that rewrite stories from paywalled sites and collect ad revenue. They are parasites that make money from other peoples work. Same thing for all those YouTube channels (though they are not other sites) that repackage other peoples content a…

> If sites needed their users to pay them, the quality of the content might go up dramatically

What do you mean by "if"? There are already many sites that require users to pay them (e.g. The New York Times) but everyone simply circumvents their paywalls.

Every method that high-quality sites use to generate the revenue they need to operate is defeated either by ad blockers or someone reproducing their content outside their paywalls. You may be right that news and reporting are not viable, but it is a shame.

Re: Purge site data when site identified via old tracking cookies

#57
post #45
post #42

Earlier quoted context omitted.

Nah. The adtech people are already talking about persistent identification mechanisms to allow the same identification in the absence of third party cookies. If you're privacy-minded, it's worth keeping an eye on these efforts, as some of them involve getting publishers to require a login and an email address or phone number from their users, then using that as the persistent identifier. If that idea takes root, then…

Or a sign-in with Apple-like system so tracking is limited to each site.

Best decision I have made so far is setting up a catch-all polic for my domain. any_random_address@mydomain.com is saved in a "dummy" inbox, I check it from time to time and give different emails for different services to identify who sold my email.

instagram is insta@mydomain.com, netflix is nflx@mydomain.com etc.

If someone needs pointers: I use webfaction for MX, setup mailboxes with catch-all policy and setup a rule to forward these email to my gmail and have a filter on gmail to skip inbox and save in "dummy" category.

p.s. if someone has a better alternative to webfaction for email only stuff, please let me know, not sure if I can do it with an other provider that is cheaper.

Re: Purge site data when site identified via old tracking cookies

#58
post #31

Earlier quoted context omitted.

Because after you hover on something, it can be an indication of intent. Just loading an image when the webpage loads doesn't give you any insight into what the user 'interacted' with.

> Because after you hover on something, it can be an indication of intent. Yes, that's (one of the many reasons) why javascript needs to die. > Just loading an image when the webpage loads doesn't give you any insight into what the user 'interacted' with. That's what I said: regardless of whether the browser, when loading a page, does or does not include hidden images in what it fetches, that cannot possibly tell you…

> Yes, that's (one of the many reasons) why javascript needs to die.

On hover can be easily done with css.

selector:hover{background-image: url();}

That can trigger a tracking pixel.

Re: Purge site data when site identified via old tracking cookies

#59
post #37

I wouldn't mind going back to a JavaScript-less web experience. I know not all tracking is based on JS, but the browser provides so many heuristics this way: screen size, cursor location, installed plugins. Give me reasonably formatted HTML, and something a little bit more powerful than curl.

"I wouldn't mind going back to a JavaScript-less experience." By not using a graphical, JavaScript-enabled browser, I have been experiencing the web this way for the last 15 years. It works just fine for the purposes I use if for, mainly informational retrieval. For me, there is no such thing as "page load time". This shifts all awareness to "server response time". This is more or less the same from one website to an…

How do you collapse comments on HackerNews?

Re: Purge site data when site identified via old tracking cookies

#60

I wouldn't mind going back to a JavaScript-less web experience. I know not all tracking is based on JS, but the browser provides so many heuristics this way: screen size, cursor location, installed plugins. Give me reasonably formatted HTML, and something a little bit more powerful than curl.

This just made me think of something.

How do the GDPR popups work if you don't have JavaScript enabled? Are the sites still GDPR compliant if they track you using cookies because you disabled the JS which should have disabled the cookies?

Post reply on HN