Meeting minutes
plh: mozilla has been pushing back on @@ due to security and privacy concerns
… which we've been trying to address as much as possible
… but not satifsy moz yet
… is that a proper summary?
marcos: @@ geolocation work
plh: other apis like proximity sensor etc.
marcosc_: css-based solutions for ambient light
… like prefers-color-scheme
<plh> https://github.com/w3c/dap-charter/issues/100
marcosc_: better privacy
plh: no mention of use cases
… only security & privacy
marcosc_: generic sensor is a rehash of the stuff we did
anssi: privacy and security researchers
… state-of-the-art papers
… maybe the objector did not even read the security & privacy section of the specs
marcosc_: mitigated by limit this to 20hz or something
… does not as useful as the css-based solution
anssi: a number of use cases can not be solved by the css solution
… css media feature did not make any progress
… @@ rework
<marcosc_> https://drafts.csswg.org/mediaqueries-5/#descdef-media-prefers-color-scheme
related issue: https://github.com/w3c/csswg-drafts/issues/5359
reilly: @@
… @@ for login and authentication purposes
… i understand mozilla's concerns
… my reaction is that we can solve it in a much aggressive way
… i'd like to see we move forward with the charter as is
… and come to better solutions
… last TPAC marcos and I figured a lot of details in screen wake lock api and use cases
… i'd like to have this wg as space where we can have those kinds of conversation
tantek: 4 categories
… stuff we implemented and deliberatedly dropped
… like battery status api
… it's not in the user's interest
… used in tracking scripts
… we implemented it and find it harmful
… and unimplemented it
reilly: the current ambient light sensor api is completely different from the one mozilla unshipped
… turned into the generic sensor proposal
… the existing design of the orientation sensor api @@
… I'll argument "yes and no"
anssi: the spec was reworked for privacy protection
… the attack described by the paper was no longer effective
… mozilla could have implemented the mitigation
… rather than dropping the whole idea
… we've been working on this for @@ years
marcosc: I have to drop many of my own apis in these years
… sysapps
… and dap
… we come to different conclusions, different approaches to achieve the same thing
… the use cases may no longer relevant for the web itself
… performance optimizations to switch the codecs is already possible
… without battery status api
… youtube widget may not use battery status for this use case
anssi: that's why we emphasized that the group will document use cases and requirements in the charter
plh: just because my battery is below 10% not mean I don't want to watch the video in HD
reilly: Zoom wants something better than the default behavior
… i agree with problem-based approach
… i'm probably the newest person here to standards work
… if we need to complete redesign it in order to have it solve their problem
… let's bring in the browser vendors and app developers and come up with something better
… the goal of this meeting is to address the objections
… leave it open to the possibilities @@
tantek: refine the use case to redesign the solution
… send the use cases to wing to incubate an alternative solution
anssik: i'd like to understand why WICG?
… das is a focused place
… we have built this community for the last 10 years
… many specs are in CR
… not particularly fond of the WICG approach
tantek: WICG is not the only solution for incubation
… but it is our default
… @@
plh: several apis have been harmful to users a few times
tantek: we fundamentally have differences in perspectives
… related to where do we actually put our implementations resources
… in reality there's only two browser vendors participating in this WG
… Google and Mozilla
anssik: Apple has implemented multiple specs in this group
… they may have reasons not to participate in this group
tantek: we didn't list every deliverable in this group in the FO
… we only list specs having sufficient reason to drop from the wg charter
marcosc: given resource constraints
… we have things in the rec-track confusing developers
… with no implementations
… if no browsers are interested in implementing this at all then why do we put it on rec-track
… @@ use cases
… back to the WICG issue
… 90% ideas in WICG will fail
… but fail in good ways that we've had a whole bunch of specs
anssik: in process 2020 we have patent protection in CR
… problematic from a culture perspective participants sometimes in CG sometimes in WG
marcosc: we have a W3C logo in the spec
… and specStatus
tantek: longstanding problem in W3C, for 5+ years
… miscommunication or misrepresentations of things that are not standards
… the problem is not there's only one implementation, but there's only interest from one implementer
… not try to pretend as if they keep advancing
… until we get multiple implementers again we can pull them off CR
anssik: we can use caniuse integration to show the history that firefox implemented the api before
anssik: we implemented webdriver extensions for these apis to better test the hardware features
tantek: normally when we're doing WD development there are multiple implementers involved
tantek: WD not necessily means implementations, but means possibility of implementations
… having them in /TR cheapens the value of /TR
… for better or worse there were many thumb-ups in the GitHub issues I raised
plh: reilly said he's open to look back to the use cases and the goals
… having two implementations seems impossible from today's conversation
… for some of the current apis in the group
anssik: in the charter there's a note:
… "To advance to Proposed Recommendation, each specification must have two independent implementations of all defined features, at least one of which is on a mobile device."
… predicting the future is difficult
… looking back in history i wouldn't have believed the FxOS story
tantek: not has to be true for all time
… we can reevaluate every year
plh: sympathetic to we have a dedicated place to do this work just in this WG
… this is my current sentiment on that
tantek: mozilla is not going to put resources in this area
… at least in short term
… we might reevaluate it every year
plh: think we've done as much as we can for today
… thank you for participating
… we'll keep thinking about it
… hope to have a decision before TPAC