Re: Agenda for Tuesday 4th September

Here are my notes from today's call.

Things moved quickly, so if I didn't capture what you said or meant then
please reply to this thread with corrections.

- Trevor


Ada:
We will send out new calendar invites for the calls.
Please RSVP for the upcoming AR f2f.
In the future, Ada will request a volunteer to take notes in the agenda
email.
Opens the floor for new agenda items.
* crickets*

Session creation:

Ada:
We got cut off last time, so it would be good if we could pick it up and
spend 20 minutes or so to see if we can get something concrete out of that.

Brandon:
The state is not great in my mind, as I have been camping and sick. So, I
haven't followed the GitHub conversations.
I can go over a couple of conversations. The state of things was that I
proposed that we have a fairly radical model where you create a session and
then stack on permissions or features afterward. If you call them on a
single callback then the user agent could combine them into a single dialog.
This was based on various conversations with people from various companies,
but I've had more since then. For example, the idea that you could shove
permissions into a session would make it hard for tooling companies.

Nell:
Expressed concern that people should be able to build tools that allow our
toolchain to force the questions up front. I'm going to prototype something
on our end using the current state of the design. I'm a little delayed
because I'm in the middle of that work.
If it's not possible to do explicitly up front libraries may do something
that we don't want.

Brandon:
Unfortunately, only a few people in Google have seen a prototype for this
(again, camping and sick) but maybe we want to have a configuration token
or object. Currently we have the idea of .supportsSession(...) which is
valuable so that pages can decide whether to add a button to the UI. We
like the idea of that. But, if you have model (which is kind of Vulcan-y)
we can create an object that has these features ... and the system returns
a configuration option that is used to create the session.
That makes supportSession intrisic to the flow.

Ada:
That's something which would enable developers to offer several optioons.
For example, a headset that can do pass-through and fully immersive, would
the site need to query several times?

Brandon:
You can do that with the existing model. The site could offer the different
modes and use the associated configuration object to set up the session.

Blair:
The browser could offer up what it can do, and if all you can about is
"doing 3D stuff" then the page can take whatever is available.
If the configuration objects exist, then you could query the object to get
more details. So, if you say you want VR then the page could ask for "any
VR", the UA could ask the user which VR rig to use (cardboard, Daydream,
send to Go, ...) and the page, and then the page could use whatever
configuration option that's returned.
If it's an opaque object that could be queried then it could serve to give
the page information that we've discussed in various threads.

Nell:
My biggest concern is fingerprinting. We want to avoiding developers to
only work on one platform and we want to encourage them to support many
configurations.
I suspect it would be good to talk less theoretically and more concretely.
My initial hunch is that there are two big levers to expose without
fingerprinting:
Do you support AR or VR?
Do you support immersive or not?
It comes down to thinking through the end user and the developer
experiences.
The end user doesn't want to press the "go into VR" button and be refused.
How would we design this to be polyfill friendly, which will be camera
dependent.
David really called this out in his original explainer document, which I
disagreed with at first but I've come around.
Once we have a sense of the overall goals, the API shape will fall out of
that.

Blair:
I agree. I've been pushing for developers to create the session and then
try to adapt.
One of the long threads is about immersive / exclusive where people use
immersive to mean headmount where I use it to mean 3D. I think of some
handheld as immersive because its entirely 3D.
Inline and exclusive is a question of how you're going to interact, but the
big question is whether I'm creating the UI in WebGL or in the DOM?
How do you envision creating sessions and then asking for permissions? How
does that mesh with creating everyting up front?

Nell:
The idea is to create the sessions using the two big dimensions (above) and
then maybe after the session is created the lesser questions are
configurable?
The media API has constraints that are applied either at media session
setup and you can pass in the same constraints while the session is running
to change the session.
Maybe we have an enumeration of things that if you'd like to use you can
pass it in up front but you can also send them in later. So, the developer
can do it up front or later.

Brandon:
I agree with a lot of the sentiments.
I want to go back to something Blair said. We ened to be careful about
having an up-front mechanism about saying "I want these 20 things" and if I
can't get it then fail.
If we're batching permissions, if I say up front the things I want then the
system can come back and say "I'm capable of doing it but the user might
say no". So, it's somewhat of a fallacy for the system to say it's capable
of doing something but it might also fail after the permission prompt
that's created when requesting the session.
The creation of the configuration object should not initiate permission
prompts. The request to create a session is when that should happen.

Nell:
Are you suggesting that we expose functionality availability even if the
user doesn't want that known?

Brandon:
No. If the dev says "I want all of these features" then the system
shouldn't respond that the feature is definitely available because the user
might refuse during the persmission prompt.

Blair:
I would imagine that we'd want to talk to security people. If I'm using the
latest HMD for VR, I would expect that if a web page popped up asking for
permissions and I say no then the page shouldn't know I have those features
available. From a user privacy perspective, if I go to a random web site
and it says I can't have the experience at all unless I give it everything
then that's that. But, if it knows that my system can do it at all it won't
let me do anything until I give it everything.

Brandon:
One example, if the dev want to do environmental lighting. When they apply
that to the session request and the user refuses the permission, then the
configuration object should just come back with lighting null.

Blair:
Oh, I thought you said the opposite earlier, that the configuration object
would leak that info.

Brandon:
We should identify some critical buckets that the dev should be able to
turn on and off (e.g. AR) but features under that the dev can ask for
features and then detect whether the system allowed it based on user
acceptance.
I do want to post something to GitHub about this.

Nell:
It's worthwhile to revisit the document that David wrote. Brandon it might
be useful to make a PR against that document so that we have it all in one
place. I'd like to take these options and have that be part of the upcoming
privacy workshop. There are people there who have gone through similar
design processes and it would be valuable to get their input.

Brandon:
I agree, having that document would be useful when talking to the privacy
group. A great idea!

Nell:
We need to divide up action items for who is going to distill it into one
document, perhaps a presentation of some form for the upcoming privacy
meeting. I will send that email right after this call.

Blair:
Then we can do a little before our face-to-face.
I would like to see included the ability to later on change, no matter the
mechanism.
I like how a lot of mobile apps that say they're going to ask for
permission for a reason before they ask for permissions. If we have the
ability to group permissions and explain things is a flow that implies the
ability to change things later, once they get to know a site.
For example, with the geo-location web sites today if you say no you're
going to need to reload to change your mind.

Dom:
I'm involved with WebRTC and these conversations feel similar. Part of the
motivation of the workshop is to find better patterns like permission
grouping, what can be implied by user actions, etc.
I see value in picking the collective brain of the WebRTC working group.
The privacy workshop will be an important milestone, some of it is about
privacy and some of it will eb about permission workflows.

Nell:
This is great timing. We'll need to collect our thoughts so that folks who
aren't familiar with our specific topics can help.

Dom:
Contact the meeting organizers to make sure that you get a time slot.

Nell:
Ok, I will reach out and let them know that we're putting together
something.
The first time at I looked at the permissions API I didn't see a way to
request more permissions later, but now that I look at it I see it.

Brandon:
I had the same impression. Maybe different document versions?

Nell:
I think we just missed it.

Dom:
I'm not sure it's implemented anywhere and it's the most controversial
section.

Nell:
Maybe because I looked at it in MDN and it's controversial so it's not
there?

Ada:
It's not the end of the world if its not implement but we need to make it
clear to developers that they do the persmission request after making it
clear to the user why the page will request a permissions.

Alex T:
I agree that we need to have the aspects to ask for up front and seperate
features that can be asked for later. Finding that balance to know even how
important they are is important. For example, camera access on optical
see-through vs. pass-through.

Nell:
Yes, polyfill libraries that use the camera are related.

Alex:
I think figuring it out as a next step will fall out from deciding what the
big buckets are up front.

Nell and Chris:
We'll both be on flights during the call the day after the f2f.
Maybe we should move the call.

Nell:
The privacy meeting will be the 26th & 27th, so the date to figure out
would be at the AR f2f.

*discussion about the timing*

Ada:
Should we move the call after the f2f?

Nell:
We should probably cancel.

Chris:
Yes, that's probably best.

Ada:
Ok, no call after the AR f2f.
Does anyone have last minute points.

John?:
Part of the privacy and security is whether permanent camera access is
possible.

Nell:
Great, thanks for filing that and let's make sure it gets into the workshop
document.

John:
Ok, I'll file Issues.

Ada:
We need to make sure that the email favicons chain gets recorded into the
Issues.
Remember to pester your AC reps to review the charter.

Nell:
Thanks everyone! I'll send out email about the workshop.

Ada:
Thanks everyone! I'll see you next week.











On Sat, Sep 1, 2018 at 4:23 AM, Ada Rose Cannon <ada@ada.is> wrote:

>
> Hi Everyone,
>
> Hope you had a great week, here is the agenda so far for Tuesday's call.
> Please reply to bring up additional discussion points or news.
>
> 🔹️It seems this fortnightly meeting invite has gone missing for some
> people so I have attached a new calendar invite.
>
> 🔹️If you plan to attend the AR face-to-face on September 17th in Mountain
> View, please go now and fill out this form so that we can make sure there
> is food and seating for you:
>
> https://goo.gl/forms/GeGC7SxwfqiOVp8w2
>
> 🔹️if your company is a member of the W3C, if you haven't already please
> find out who your AC rep is and ask them to vote for the proposed Immersive
> Web Working Group: https://lists.w3.org/Archives/
> Member/w3c-ac-members/2018JulSep/0031.html (member-only link)
>
> 🔹️Note taking. To save time in the meeting please can someone volunteer
> to take notes by replying to this email?
>
> Points of Discussion:
>
> 1. Continue session creation discussion since it got cut off last time.
>
> 2. Bring the discussion out of the mailing list into github issue
> discussion to make it more public.
>
> Ada
>
>