Re: Adding another permission? A guide

Thanks Nick, these changes all look great!

Pete Snyder
{pes,psnyder}@brave.com
Brave Software
Privacy Researcher

> On Jul 15, 2019, at 1:10 PM, Nick Doty <npdoty@ischool.berkeley.edu> wrote:
> 
> cc’ing public-privacy on these blog post updates, in case others have input.
> 
>> On Jul 14, 2019, at 7:21 PM, Pete Snyder <psnyder@brave.com> wrote:
>> 
>> Howdy Nick,
>> 
>> Apologies for the delay in getting back to you.  Here were the three issues / suggestions I had remaining.  If it’d be helpful for me to file them as GH issues, just let me know, would be happy to do so.
>> 
>> Thanks again for putting this together!
>> 
>> re: 1. Is this feature important for the Web platform?
>> 
>> I didn't quite get the connection of this question to designing permission.  Is the idea to get people to say "not only doesn't this feature need a permission, but its doesn't need to exist at all"?  If so (and I think you're right, a lot of functionality falls in this category) then maybe an example or two would be useful here, of features that don't need to be in the "Web API" in general.
> 
> Yeah, the idea was the first question should be whether the feature was even needed to be part of the Web platform at all. I’ve added more text to make that more explicit. If you have other examples in mind, I’m open to them, but it seems like a hypothetical is likely to be either confusing or antagonistic. For now I’ve referred to a specific case where a feature was subsequently removed by implementers, Battery Status, which is also referred to in the Self-Review Questionnaire: Security and Privacy in the “Drop the feature” strategy.
> 
>> Re: 4. What is the duration and persistence of your permission?
>> 
>> This is useful to discuss, but the suggestions / details are not about persistence.  If persistence is useful here, I suggest adding something about lifetimes, discarding at the end of the session, or something along those lines.
> 
> The features for accountability (transparency and revocability) are ones that are important *when* a permission does have some kind of persistence. I’ve tried to clarify a bit just by reformatting this section.
> 
> If there are other affirmative recommendations we can give about duration, that would be great, and hopefully that’s something we can keep working on. I think recommendations/decisions based on the concept of a “session” are becoming less useful as that concept has a less consistent duration itself.
> 
>> Re: 5. How will users understand how...
>> 
>> Who is the "We" in this section (or the document in general).  Is it PING, or the permissions workshop?  Not objecting either way, but I think being explicit would be best, especially if PING is going to direct working groups to it going forward.
> 
> Yeah, I think I was being a little loose with language. I’ve clarified that the finding about additional research was one from the permissions workshop. And more broadly, I’ve re-written to avoid using “we” where it’s unnecessary and clarified that this blog post comes from feedback from PING.
> 
> Thanks,
> Nick
> 
> updates: https://github.com/w3cping/blog-posts/commit/3a8dfeb53b08485a3a027a2a91f6a0c8b9620106
> latest: https://github.com/w3cping/blog-posts/blob/master/adding-permissions.md

Received on Monday, 15 July 2019 20:21:00 UTC