👍
👍
https://github.com/stpeter gave me a heads-up about this.
tl;dr: All the same reasons for not re-using WebID apply to Web Sign-in (and Sign-on is too similar), and thus we object to the proposed re-use.
There’s already an existing set of related specs[1][2][3], numerous deployed & in-use implementations[4][5], and an open standards community actively using (including numerous actual users using) the term / phrase / technology[6][7].
https://GitHub.com/BigBlueHat wrote in https://github.com/WICG/WebID/issues/41#issuecomment-742737907:
> Naming is hard and taking an existing name from an existing community doesn't win you any friends or collaborators.
Indeed.
To state it even more strongly, Google of all parties must not act in a bullying way (we must consider the outsized influence & power dynamics), even within the auspices / context of a CG (using a vote in a CG to justify squatting over an existing active spec and a community’s use thereof). Rallying more folks to tacitly or otherwise approve of bullying is still bullying, perhaps even a worse form of doing so.
I can sympathize with the naming challenges in the area of identity (seems fitting).
That noted, an exploration in a CG seems premature to worry so much about a "marketable" name, especially in an area where naming is hard.
Instead, make up a throwaway placeholder name (like WID2021), first get the technology right, working across at least a few different vendors relying/consuming each others identities interoperably, and then worry about an actual marketable name, perhaps at WD/CR time. We know this can work per the prior example of "Atom" which went through a few throwaway names like "Pie" before being standardized as Atom in RFC 4287 at IETF.
Thanks for your consideration,
Tantek
[1] https://microformats.org/wiki/web-sign-in
[2] https://microformats.org/wiki/RelMeAuth
[3] https://indieauth.spec.indieweb.org/ (previously a W3C Note published by the Social Web Working group: https://www.w3.org/TR/2018/NOTE-indieauth-20180123/)
[4] https://indieweb.org/Web_sign-in#Implementations
[5] https://indieweb.org/IndieAuth#Implementations
[6] https://indieweb.org/Web_sign-in
[7] https://indieweb.org/chat-names
👎
👎
👍
Finished #RodeoValley 30k #trailRace in 5:10:43 on Saturday. In the photo I’m massaging a midsection cramp while power hiking uphill, and grinning because I knew I was almost at the top of the last big climb of the course.
First race post lockdown was exciting, fun, steady, strong, until a downhill trip (no fall) broke my momentum, strained the right leg/glute, and killed the appetite. Struggled and pushed thru remaining climbs to finish strong on the final downhill without injury, 26s longer than 2018.
Great starting with 50k runners Bryan & Eliza, and having pal Erika run me in the last 4 miles (also took this 📷) and share salty snacks, a needed boost.
Taking notes as memories resurface. Processing everything & how each section went, insights gained, and lessons learned.
#runner #running #instaRunner #trailRunner #ultraRunner #trailRace #grassRootsGear #NovemberProject #NPSF #Marin #MarinHeadlands #CoastalTrail #Hill88 #uphill #powerhike #50kTraining #50mileTraining #2021_219 #laterGram #noFilter
The night before: https://tantek.com/t5E51
2018 Rodeo Valley: https://tantek.com/2018/175/t1/finished-rodeovalley-my-first-30k
The pandemic is not over just because you’re over it. Wear a mask. Get vaxed. Get boosted with another vax. Stop indoor dining. Black Lives Matter. Trans rights are human rights. Respect women. Housing & healthcare for all. There’s no Planet B.
Also, running my first race tomorrow since lockdown, @insidetrail #RodeoValley 30k!
Longest training stretch between races since I started running. Huge thanks to coach @CorrineMalcolm’s guidance for almost a year now.
Carving out little deliberate pockets of the past in the ever-changing present.
#runner #running #instaRunner #trailRunner #ultraRunner #trailRace #grassRootsGear #NovemberProject #NPSF #letsDoThis #LFG #Marin #50kTraining #50mileTraining #noFilter
2018 Rodeo Valley: https://tantek.com/2018/175/t1/finished-rodeovalley-my-first-30k
I have user-surveillance and user-control concerns about the Idle Detection API. Even with the required 60 second mitigation, it can be used for monitoring a user’s usage patterns, and manipulating them accordingly. (Also noted in Mozilla’s formal objection to the proposed 2021 W3C DAS WG charter: https://lists.w3.org/Archives/Public/public-new-work/2021Jul/0011.html)
As it is currently specified, I consider the Idle Detection API too tempting of an opportunity for surveillance capitalism motivated websites to invade an aspect of the user’s physical privacy, keep longterm records of physical user behaviors, discerning daily rhythms (e.g. lunchtime), and using that for proactive psychological manipulation (e.g. hunger, emotion, choice [1][2][3]). In addition, such coarse patterns could be used by websites to surreptiously max-out local compute resources for proof-of-work computations, wasting electricity (cost to user, increasing carbon footprint) without the user’s consent or perhaps even awareness.
Thus I propose labeling this API harmful, and encourage further incubation, perhaps reconsidering simpler, less-invasive alternative approaches to solve the motivating use-cases.
[1] https://pubmed.ncbi.nlm.nih.gov/31589063/
[2] https://www.apa.org/pubs/journals/releases/emo-emo0000422.pdf
[3] https://www.sciencedirect.com/science/article/abs/pii/S0195666310000723
Mentions:
* Christine Hall. (2021-10-04). Google’s New Spyware in Chrome 94. https://fossforce.com/2021/10/googles-new-spyware-in-chrome-94/