Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RFC 35140: HTTP Do-Not-Stab (2023)

5snb.club

Post reply on HN
Print view View original

41–50 of 219 posts

Re: RFC 35140: HTTP Do-Not-Stab (2023)

#41

Post by adra »

shadowgovt wrote: post #33
thrtythreeforty wrote: post #22

Earlier quoted context omitted.

I'm registering my elderly relatives for dmachoice.org, to prevent them from getting junk mail. These clowns create the problem and then have the audacity to charge you to be added to the opt out list. I was really skeptical about the GDPR when it was passed and I am now fully on board for an American version.

I'm still extremely skeptical of it because in practice it basically added a cookie banner to every every website I visit infrequently with no particular benefit to me. I'm just going to click "yes," stop asking.

Clearly you don't have a browser plugin that simply opts out of all cookie banners. Ultimately, the webs ites have a financial interest in malicious compliance, so you either work within the system as given or throw your hands in the air and let every and all sites rape your data.

Re: RFC 35140: HTTP Do-Not-Stab (2023)

#42

Post by lolc »

dcsommer wrote: post #38
shadowgovt wrote: post #33

Earlier quoted context omitted.

I'm still extremely skeptical of it because in practice it basically added a cookie banner to every every website I visit infrequently with no particular benefit to me. I'm just going to click "yes," stop asking.

ePD in 2002 mandated cookie banners well before GDPR in 2018. But yes, point taken that well intentioned regulation can be poorly implemented and have negative repercussions.

I know of no regulation that mandated cookie banners. I just know a lot of sites who chose to use banners because the operators are somewhere between weasely and malicous.

Re: RFC 35140: HTTP Do-Not-Stab (2023)

#43

Post by shadowgovt »

blooalien wrote: post #39
shadowgovt wrote: post #32

Earlier quoted context omitted.

On the internet, it started as the user's responsibility. For netizens, the idea that the use should be able to opt out of logs about their interaction with the service the operator owns is novel (because they always had the option of not using the service if they found the pattern distasteful).

There's a bit of a difference between normal logging of access to services to protect your devices / network (and to understand your users' access to your services), and using every nasty trick in the book to build extensive detailed profiles of everyone's browsing footprint across the entire web, often without their knowledge or consent (hence the laws, because it's the only way to convince some folks to not do bad…

It's a difference of degree, not kind, which is how it became normalized.

Re: RFC 35140: HTTP Do-Not-Stab (2023)

#44

Post by shadowgovt »

adra wrote: post #41
shadowgovt wrote: post #33

Earlier quoted context omitted.

I'm still extremely skeptical of it because in practice it basically added a cookie banner to every every website I visit infrequently with no particular benefit to me. I'm just going to click "yes," stop asking.

Clearly you don't have a browser plugin that simply opts out of all cookie banners. Ultimately, the webs ites have a financial interest in malicious compliance, so you either work within the system as given or throw your hands in the air and let every and all sites rape your data.

Yes, the second one. I don't really care; it's not "my" data. It's data about me.

When I walk down the street and sometime sees me go by, those aren't my photons they caught. By analogy, same with my browsing history.

Re: RFC 35140: HTTP Do-Not-Stab (2023)

#45

Post by shadowgovt »

blooalien wrote: post #37
shadowgovt wrote: post #33

Earlier quoted context omitted.

I'm still extremely skeptical of it because in practice it basically added a cookie banner to every every website I visit infrequently with no particular benefit to me. I'm just going to click "yes," stop asking.

> ... "it basically added a cookie banner to every every website I visit" ... Yeah, no. Hostile advertising companies added that cookie banner as a form of "malicious compliance" with the law purely to annoy everyone like a buncha spoil't little brats who didn't get their way, so now they're gonna make everyone suffer... If we get a similar law in the USA, you can expect to see annoyances just like it (and probably w…

And if the regulators didn't predict such compliance they should be replaced with competent actors in their jobs.

That was the obvious outcome. What did people predict: site owners leaving money on the table? Who pays for operating the sites then?

Re: RFC 35140: HTTP Do-Not-Stab (2023)

#46

Post by jeroenhd »

It's important to note that the Do-Not-Stab header has been deprecated because one browser engine switched it on by default and requiring users to opt into stabbing hurt the bottom line of the stabbing industry, so it's no longer respected. Luckily someone came up with General Assault Control, a non-standard alternative, which also only has one value, so you can set Sec-GAC to 1 to request websites not to assault you. By design, this header cannot be extended, so it cannot be used to distinguish brutal stabbings from a comedic pie to the face in the future.

Because of legal requirements, the General Assault Control header may not be enabled by default, as American states like Colorado require explicit opt-out (rather than explicit opt-in). This protects Colorado's thriving stabbing and shooting industry as most users will never want to opt into being stabbed.

Despite the feature being forced to be disabled by default, the organisation behind the spec is pushing hard for customers to download fringe browsers that implement the feature (though you may need about:config to enable it). Because of the small user base, the request not to be assaulted can be used by websites not willing to follow the standard to make their stabbings and shootings more precise. End users can request a JSON file from the web server containing the supposed support for the GAC header, but requesting this URL may be used to kick the user in the teeth by non compliant servers.

Re: RFC 35140: HTTP Do-Not-Stab (2023)

#49

Post by hedora »

shadowgovt wrote: post #43
blooalien wrote: post #39

Earlier quoted context omitted.

There's a bit of a difference between normal logging of access to services to protect your devices / network (and to understand your users' access to your services), and using every nasty trick in the book to build extensive detailed profiles of everyone's browsing footprint across the entire web, often without their knowledge or consent (hence the laws, because it's the only way to convince some folks to not do bad…

It's a difference of degree, not kind, which is how it became normalized.

The internet started with decentralized protocols like NNTP, so you could just choose a different news server if the one you were using started tracking + selling your download logs.

Centralizing the serving of third party (or even first party) content is already way outside the original norms of the internet.

Heck, back in the day, HTTP caching would be enough to block tracking. (No javascript, and only the ISP sees which users pulled the document from cache.)

Post reply on HN