Purge site data when site identified via old tracking cookies • Hacker News Board

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

#41

Post by ficklepickle » Thu, Mar 05, 2020, 10:01 PM UTC

JMTQp8lwXL wrote: post #7

reificator wrote: post #4

Earlier quoted context omitted.

If "reasonably formatted" means CSS comes along for the ride, prepare for tracking pixels behind onhover rules, and on and on we go...

By reasonably formatted, I would actually exclude onhover. To clarify, I meant a document that would be readable without any interaction. You've got me wondering if privacy-focused browsers like Brave have the ability to disable potential tracking mechanisms like onhover.

Disabling CSS :hover and :active states might break sites. Tracking pixels could be as simple as a background image set for either of those CSS states.

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

#42

Post by JohnFen » Thu, Mar 05, 2020, 10:03 PM UTC

tinus_hn wrote: post #17

So the next race is going to be pinging all these cookies to keep them alive

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 we'll probably want to cancel accounts and avoid making new ones.

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

#43

Post by jtolmar » Thu, Mar 05, 2020, 10:21 PM UTC

mumblemumble wrote: post #15

JMTQp8lwXL wrote: post #3

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.

Perhaps create a new and separate Web, that's designed from the ground up to take into account the lessons of the past 25 years, and provide a more mellow experience? It would be an eternal niche, but it might be a nice, cozy little niche.

Most site interactivity could be handled with forms (though some form inputs need improvement) or some sort of conditional view state (for menus and HN's collapse comment feature). For anything more complex I think the "click to enable" model that flash and applets eventually followed is compatible with anything that actually deserves custom code.

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

#44

Post by throwsprtsdy » Thu, Mar 05, 2020, 10:34 PM UTC

ohithereyou wrote: post #36

throwsprtsdy wrote: post #22

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?

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.

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

#45

Post by l31g » Thu, Mar 05, 2020, 10:44 PM UTC

JohnFen wrote: post #42

tinus_hn wrote: post #17

So the next race is going to be pinging all these cookies to keep them alive

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.

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

#46

Post by ck2 » Thu, Mar 05, 2020, 10:50 PM UTC

JMTQp8lwXL wrote: post #3

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.

Alternatively since nojs breaks a bunch of things, also try uMatrix, really locks things down and shows you what kind of nonsense is going down in a nice (blockable) grid.

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

#47

Post by JMTQp8lwXL » Thu, Mar 05, 2020, 11:08 PM UTC

JohnFen wrote: post #28

JMTQp8lwXL wrote: post #3

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.

Hit or miss. I find a noticeable number of sites to be unusable. Some sites send completely usable HTML on the initial response and it's a great experience.

Back when this used to be my default policy, I'd whitelist sites that I deemed worthy. I had maybe 1-2 dozen sites (e.g., my bank among them) enabled.

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

#48

Post by JMTQp8lwXL » Thu, Mar 05, 2020, 11:09 PM UTC

ficklepickle wrote: post #41

JMTQp8lwXL wrote: post #7

Earlier quoted context omitted.

By reasonably formatted, I would actually exclude onhover. To clarify, I meant a document that would be readable without any interaction. You've got me wondering if privacy-focused browsers like Brave have the ability to disable potential tracking mechanisms like onhover.

Disabling CSS :hover and :active states might break sites. Tracking pixels could be as simple as a background image set for either of those CSS states.

Agreed, but it would likely break things that don't matter much to me. A well defined semantic document should say what it has to say, without the use or necessity of :hover or :active states.

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

#49

Post by JMTQp8lwXL » Thu, Mar 05, 2020, 11:10 PM UTC

simple_phrases wrote: post #12

overcast wrote: post #5

Earlier quoted context omitted.

Nothing stopping you from doing this on your next / current project. I've been 100% committed on getting the web back to as lightweight as possible for the last couple years worth of development.

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

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

#50

Post by code_duck » Thu, Mar 05, 2020, 11:22 PM UTC

JohnFen wrote: post #40

donnellycc wrote: post #39

Earlier quoted context omitted.

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

I'm not 3xblah, obviously, but I deal with those sites by not using them.

I wish that was a choice for me. Often I have to interact with websites for services such as phone accounts, banks or taxes where I don’t have the reasonable option of choosing to not use the site.