Live data from Hacker News

Purge site data when site identified via old tracking cookies

bugzilla.mozilla.org

61–70 of 135 posts

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

#61
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…

> > > 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.

You're missing the point. CSS allows you to load tracking pixels on hover, so you can do that without Javascript.

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

#62
post #18

Earlier quoted context omitted.

That's called pi-hole and having it network wide is a game changer. 30% of all dns requests are blocked.

Pi-hole is on my TODO list for quite some time. Yeah, its definitelly a portal I should get to fast (summon, not get to, hence the TODO entry). Currently using uMatrix and friends but its not network wide and that sux a lot.

NextDNS works well without setting up anything new, too. I use it instead of pi-hole.

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

#63

Earlier quoted context omitted.

Almost all front-end development jobs are looking for React or Vue skills.

You can server-side render React (not sure about Vue, but wouldn't be surprised if you could).

Yes, you’re right about Vue having server side rendering. It’s called Nuxt.

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

#64

Earlier quoted context omitted.

I run a similar sort of policy but I would say the number of sites I visit that display nothing but a blank page without javascript is more than half. Sites that function without it are the exception, not the rule.

A site that renders completely blank without JavaScript is a site that I don't enable JavaScript for. They don't want me to view it, and nine times out of ten I can find the information elsewhere.

Maybe less frustrating than a site that works, and then doesn't. Like a checkout path with a hard dependency near the end.

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

#65
post #57
post #45

Earlier quoted context omitted.

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 r…

I use fastmail, and there is no additional setup needed. Just point the catchall at an account and use the filters to sort as appropriate. Mail from my legacy gmail, yahoo, and hotmail accounts get forwarded to respective aliases at mydomain.com and sorted into appropriate folders as well.

Best online hygiene decision I have ever made. Ranks up there with installing ubock origin on desktop/mobile.

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

#66

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.

For the CMS I make for myself, the general rule is, it's fine to require it for admin, and if I had users it would be fine to require it for them to edit content, but it must always be optional to just browse content as visitor. I don't see that becoming "nonviable" as a principle anytime soon, at least for private non-commercial stuff where I really don't care if other sites are fancier, as long as mine works as it should.

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

#67

Earlier quoted context omitted.

Think of the poor buggy whip makers! Not every desirable activity in life is profitable. If your business plan is "make website -> get money" then perhaps you're in the wrong business.

I was thinking more about investigative reporters and news outlets than buggy-whip makers.

If you're going to treat investigative reporting and news gathering as a profit making venture then you can only charge what the market is willing to pay, and for the vast majority of people, that's nothing.

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

#69
post #28

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 web experience. My default policy is to not allow JS to run, so my experience is already mostly Javascriptless. And, I have to say, my user experience on most web sites is actually better when I don't allow Javascript to execute.

Agreed. Particularly blatant example: Android developer documentation. Once you allow it to run the gstatic script, it slows to an absolute crawl.

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

#70
post #57
post #45

Earlier quoted context omitted.

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 r…

I use hcoop.net and the wildcard address is one line in a configuration file. I do a little bit of filtering with a sieve filter.
Post reply on HN