Gender http header

[exx8]

I would like to propose that user agents will be able to pass a user statement regarding to its gender via an http header. the content must be a string, but not specified (as the definition of gender is flexible and might change from a culture to a culture and by time). I see 2 main use cases:

1. Some languages have grammar cases which are gender-related.
2. The suggestion will allow to user to make a statement regarding to its gender once. Instead picking his or her gender or their gender each time.

The header should be optional.

[Crissov]

Judging from how a similar idea for media queries was received, I bet this idea would not be welcomed.

MQ for Userʼs Population Group or Browsing Environment

Many sites vary their content or style or both based on the “maturity” of the user and acceptability of “mature content” in their browsing environment: Sites for children have parent sections or modes, where the style may be less playful and concentrate more on dull (and smaller) text than on colorful graphics. Typography may be adapted accordingly to aid either reading many paragraphs or deciphering a couple of words. Entertainment sites are tagging delicate (user-generated) content as not sa…

[mkay581]

Where would user agents get the value from? Also gender and what pronoun people prefer to be called can be two separate things. But this seems like something that can be implemented pretty easily by just passing your own request header. Then you can define it to be whatever you want.

[liamquin]

Well, they already can - you can add, X-UserGender: Non-Binary, for example. Is there widespread exising practice here?

Apart from questions around user fingerprinting and privacy though, what about cache and proxy situations?

People who are gender-fluid also might not give the same answer from visit to visit.

And for sure it could lead to unexpected outing of trans people.

[Ferdy_Christant]

Besides the stated concerns (privacy, fingerprinting, actively going against web neutrality and potentially enabling discrimination) the use case also seems to contradict itself. If the value is non-standard, it seems the benefit of custom grammar is hard/impossible to achieve.

[marcosc]

Closing, as this risks blowing up. It wouldn’t be appropriate to send such information for the reasons given above (i.e., privacy, gender-based discrimination, etc).