💾 Archived View for bbs.geminispace.org › s › privacy › 22652 captured on 2024-12-17 at 15:01:49. Gemini links have been rewritten to link to archived content

View Raw

More Information

-=-=-=-=-=-=-

Mozilla removes the 'do not track' setting

Citing that "many websites ignore this feature" Mozilla removed it.

Many drivers ignore stop lights! Lets remove them too.

At least you could see that I did not want to be tracked... Alrhough that probably made me more interesting.

https://windowsreport.com/mozilla-firefox-removes-do-not-track-feature-support-heres-what-it-means-for-your-privacy/

In all likelihood this makes no difference except it does show that we're going in the wrong direction...

Posted in: s/privacy

🚀 stack

Dec 10 · 7 days ago · 🙁 1

17 Comments ↓

🎵 alice-sur-le-nuage · Dec 10 at 21:08:

Makes sense to me - if it can't be enforced anyway, it's just making it look like you're protected when you're not. Best not to give people the false impression that ticking this protects them in any way.

🚀 stack [OP] · Dec 10 at 21:24:

devil's advocate says: the same is true about stop lights

☕️ protoc0l · Dec 10 at 22:04:

Not really.

If a cop catches you running a red light, you get a ticket and points on your license. Theres at least the _potential_ for enforcement and punishment.

If a platform ignores your "do not track" request, nothing happens. It literally cannot be enforced on the client's end.

🐸 HanzBrix · Dec 10 at 22:44:

@stack Was it you or someone else that said, having the featureon, actually made you more trackable? 😂

🦂 zzo38 · Dec 10 at 22:48:

I agree with removing the "do not track" setting, because they should make a more general setting instead, to add arbitrary request headers (this also includes other things such as Accept-Language) and response headers (e.g. you could disable some features by setting the Content-Security-Policy, or to add X-Content-Type-Options), and to delete request and response headers (e.g. Referer, If-Modified-Since, Cookie, etc), instead of being limited to only one possibility.

🚀 stack [OP] · Dec 11 at 01:03:

Agreed, not much of a loss.

👻 darkghost · Dec 11 at 02:13:

It was never going to work.

"Do not track? How are we supposed to monetize our users? They won't pay for this dross with money. Oh it's voluntary? Ha! Not doing that."

👻 ps · Dec 11 at 10:42:

By `thanks` to JS, Cookies, CORS, etc

everything that enabled or disabled in modern web browser by default - means `nothing changed` for me.

🦋 CarloMonte · Dec 11 at 13:10:

This technology is way out of control for most participants. For the user an INCOMPATIBLE, clean restart would be nice: only TLS, URLs, hypertext, CSS, inline data (images etc.) and links.

No scripting, no cookies (we have URLs for that), no embedding, no client-side disclosures (screen resolution, referrals and what not), another PKI concept etc..

Also in dire need is a fair monetization platform. I would be happy to pay, but not to subscribe for sites I visit once in a while. I would even enjoy some high quality advertisments, as were seen in the better newspapers of days past.

This won't happen any time soon, but is clearly doable.

NOTE about the PKI: a new concept is way beyond me; yet, TOFU, the web of trust (GPG), SSH keys all show that alternatives are possible.

It should be possible to quickly set a secure intranet server without having to pay or disclose its existance to third parties (the PKI)!

🐸 HanzBrix · Dec 11 at 14:40:

@CarloMonte The HTML5 standard is actually defined as such and defined to mostly only rely on CSS. So it should be possible for you to say, create a PureHTML conglomerate, where you hand out "verified" stickers.

The beauty if this is that they also can't use and wouldn't even have to be concerned with cookies and GDPR, there wouldn't be any.

So there is a lot of promotional work to be done, but I think it could be spun positively.

You could also do a "speed" verification, mostly meant to check if they are overloading the page with uncompressed images and other nonsense.

🦋 CarloMonte · Dec 11 at 17:01:

almost. incompatible is here the key. i doubt that a smooth transition is possible.

🐸 HanzBrix · Dec 11 at 17:28:

@CarloMonte what incompatibilities? Far as I know HTML5 and CSS3 were written to be stand alone technologies. All browsers should be compatible with it, so it is more of a question of incentivising people to stay away from JS and cookie use.

Shouldn't be too hard either, as most JS pages, load like ass on mobile phones, which is the predominant webviewer now.

🚀 stack [OP] · Dec 11 at 18:25:

Is loading "like ass" bad?

🐸 HanzBrix · Dec 11 at 18:53:

@stack not bad per se, just sticky and flakey. 😂

🚀 stack [OP] · Dec 11 at 18:58:

I suppose the art of the bidet is not universally adopted!

🐸 HanzBrix · Dec 11 at 20:57:

@stack I don't think installing a bidet in your phone is a good idea!

👻 darkghost · Dec 11 at 22:07:

@hansbrix Oh great! NOW you tell me!