Socialwg/2017-06-20-minutes
Social Web Working Group Teleconference
20 Jun 2017
See also: IRC log
Attendees
- Present
- eprodrom, ben_thatmustbeme, sandro, cwebber, rhiaro, cwebber2
- Regrets
- Tantek
- Chair
- Evan
- Scribe
- ben_thatmustbeme
Contents
<sandro> cwebber2 ? aaronpk ?
i am on, just as i said, through hurts
no problem
<eprodrom> We'll wait for people to join until 5 min past the hour
its not really worth it
I do it from the web
under firefox i never have an issue
<cwebber2> hi
<cwebber2> I'm dialing
<cwebber2> in
yes, on linux
it used to let you rename the callers, which was helpful when i was learning names
the web app doesn't let you do that any more
hah
<cwebber2> I could scribe during the non-AP parts
defaultscribenick: ben_thatmustbeme
yeah, i noticed that sandro
- /
yes
<scribe> scribenick: ben_thatmustbeme
eprodrom: we have 4 on the call, its enough to have a call, but I don't want to do binding resolutions
... cwebber2 are you in need of any?
cwebber2: its okay to not have a resolution, just need group input
eprodrom: i'd be ok with doing things like closing issues, i think thats fine
review of minutes from last week
<eprodrom> PROPOSAL accept https://www.w3.org/wiki/Socialwg/2017-06-13-minutes as minutes for 13 Jun 2017 meeting
<cwebber2> oh yay rhiaro
<eprodrom> PROPOSED: accept https://www.w3.org/wiki/Socialwg/2017-06-13-minutes as minutes for 13 Jun 2017 meeting
<cwebber2> +1
+1
<Loqi> woot
<eprodrom> +1
<sandro> +1
RESOLUTION: accept https://www.w3.org/wiki/Socialwg/2017-06-13-minutes as minutes for 13 Jun 2017 meeting
confirm next telcon
eprodrom: we are moving in to the summer months, so i'd like to have a meeting on the 27th, and then discuss if we are going to have an abbreviated schedule after that
<sandro> +1 meeting on 27t
<cwebber2> +1
<ben_thatmustbeme> +1
eprodrom: then I as chair, unilaterally say we are having a meeting next week
i think i owe tantek one, so I may chair that too
extension update
sandro: what i can say is that voting period ended friday, we don't know the official answer yet
... we should find out tomorrow
eprodrom: well i'm glad that we are meeting next week then
activitypub
cwebber2: my estimate last week was that we would have the test suite up 2 weeks from then, and i hink i'm on track for that. We have a number of new issues i'd like to discuss, they partly came up from mastodon being very active on their implementation right now
<cwebber2> https://github.com/w3c/activitypub/issues/233
cwebber2: we also have another implementation in progress by puckipedia, a dotnet implementation
<Loqi> [cwebber] #233 Move "do not overload" and "don't trust submitted content" to Security Considerations?
cwebber2: first lets look at issue 233
... there are 2 parts, they are SHOULD so they should be in the test suite, but they are hard to test, but the feel like they should be part of the security consideration section things
eprodrom: for me the second one is clearly a security consideration
... trusting client submitted content is an interesting way to get to it, but ...
cwebber2: yeah, the server should definitely should verify the embedded object
eprodrom: if cwebber2 submits "cwebber likes eprodrom's photo" that should be checked, but if its his own photo, thats probably okay
... there is a balance to be struck there
... but existance is definitely an issue
sandro: what about the date field?
eprodrom: thats an interesting one, we do a bunch of things like that in pump.io
sandro: there is an issue on mastodon about bulk uploading posts
if they do that, then they are backdating things, so are they falsly claiming published date?
cwebber2: you could have an updated field, but i don't think that reflects the real meaning
eprodrom: in status.net and pump.io you mark it as a share.
<ben_thatmustbeme> getting back to what cwebber2 asked...
scribe: the first thing is not really testable
the second i feel, while security questions, is VERY testable
and i would argue should be tested
eprodrom: there is a lot in there that could be tested
... do you accept something with an actor that is not the authenticated person
cwebber2: the second can be tested to some degree, maybe we should enumerate some ways in which it should be tested
<ben_thatmustbeme> even just a few tests is fine
cwebber2: it might be some things where it intentionally does leaves parts out and replaces it with its own data
... i agree we could certainly do some tests
as to the exponential backoff is it security of is it just a note in the doc?
eprodrom: is there some other doc we could just reference?
sandro: the security consideration is that most restful apis force backoff
cwebber2: you can only force it to some degree, you could reject the requests, but you can still get ddos'ed
sandro: you should be able to handle a single dos though
... i think there is an appropriate security consideration here though
rhiaro: we don't need 100% automated test coverage, a test can be something as simple as having a checkbox and we take their word for it
cwebber2: that was the original way i was doing it, but i was getting some pushback from it being too prompty
rhiaro: whatever the shortest way is
cwebber2: the former one i would like to ...
being rewritten as proposal
<eprodrom> PROPOSED: move section on exponential backoff to security considerations, section on trusting content to security consideration with tests to close https://github.com/w3c/activitypub/issues/233
<Loqi> [cwebber] #233 Move "do not overload" and "don't trust submitted content" to Security Considerations?
<cwebber2> +1
<sandro> +1
<rhiaro> +1
<eprodrom> +1
+1
is this a normative change?
RESOLUTION: move section on exponential backoff to security considerations, section on trusting content to security consideration with tests to close https://github.com/w3c/activitypub/issues/233
<Loqi> [cwebber] #233 Move "do not overload" and "don't trust submitted content" to Security Considerations?
cwebber2: it sounds like we have been agreeing that relaxing requirements is more ok than adding requirements
sandro: i don't think it matters either given our schedule
... we can't go to PR next week since we don't have the test suite out
cwebber2: next one is , mastodon has been trying pretty hard to be respectful of what people are and aren't willing to see
<cwebber2> https://github.com/w3c/activitypub/issues/232 https://github.com/w3c/activitypub/issues/231
<Loqi> [cwebber] #232 Content Warnings
these two are interrellated
<saranix> my view on this is tags are appropriate
if you haven't seen it in mastodon, you see 'content warning explicit", etc
<saranix> ... handling as tags
cwebber2: the way it is done now using the summary field
... this is like reading a short blog post you see the shortened version of it, but expand to see the full version
<saranix> I agree with the comment that said that summary is meant for different screen realestate / UI concerns
cwebber2: i have a little bit of a concern that its a little bit of an abuse of that property
... if you have those two distinct contexts, if two servers are using them in different ways, someone might see things that they hadn't intended to see
... i had original envisioned it as a tag , but this works, but i think it still should be wrapped in another type
eprodrom: i don't understand why a tag or the context wouldn't work here
... there is no need to have backward compatibility with ostatus
cwebber2: it does need to give a clear indication that it should not be exposed by default, so i think it should have its own type on the tag
... i agree that it makes more sense to me at the moment to use a tag
... i think it would be more useful to tag multiple things at once
if you lump them all in one big text box, you can lose them
sandro: a tag should default to being show, don't show, or prompt
eprodrom: that is between you and your user agent ..
... the sender should not have to decide how the content is receieved
sandro: well thats what the tagging is
... before my client has ever seen one of these tags, ... the person who is inventing the tag, the creator would have to say 'when a server sees this for the first time' what do they do
<saranix> the tagging is semantic
<saranix> is that bad?
<saranix> sandro, is that bad?
sandro: while we are doing this, i want a 3rd option, that is an opt-in tags
... what i want to be able to do is scribe meetings on mastodon, i am going to be posting 4-500 things in an hour, i don't want them to be prompted at all
cwebber2: that is quite a bit different
sandro: but it comes into the same implementation territory
eprodrom: the pump.io way of doing that is setting up a list and limiting it to only a specific audience
sandro: and thats something people can join later?
eprodrom: exactly
cwebber2: it could apply to more things than we initially thought about.
eprodrom: movie ratings, appropriate for children, trigger warnings, there is a lot that goes in to this area, and people do a lot of non-semantic stuff, like stuffing things in to the summary. or people make the post much longer than the default wrap, like "spoiler warning" then a bunch of extra lines, etc
... finding a good way to do this is good, is good to add
cwebber2: i am in favor of tags, but if we want to get others in to it, we should get like Gargron and evenminto on the CG call and bring it up there
... i'll try to get them on tomorrow or next week to discuss this
<eprodrom> tag, warning, freetext, id
eprodrom: ideally i'd like to see something where 'this is a tag' and a warning
... either a url or some text that indicates what we are warning about
cwebber2: there are 2 issues related to this
<cwebber2> https://github.com/w3c/activitypub/issues/231
<Loqi> [cwebber] #231 "Sensitive Media" tag
cwebber2: that might be a good solution to one of them
... i think there might be a good solution for this, a specific content warning one that is just 'NSFW'
<rhiaro> do they use nsfw on japanese mastodon?
maybe 'senative media' or something like that
cwebber2: people on mastodon don't want to use NSFW anymore
but a more accurate 'sensative media'
eprodrom: .... YES
... so they don't want to use that term because for some people sex work is WORK, but...
<cwebber2> https://github.com/w3c/activitypub/issues/231#issuecomment-309835489
<Loqi> [cwebber] We're thinking related to #232 there would be a common Content Warning type tag for sensitive media.
cwebber2: they seem pretty related to me, so using the same mechanism seems to make sense to me
eprodrom: where the concern comes from for me, is when we start dictating what people want to see, but its pretty useful to have that people will want to see different things
... i wonder if just having a 'content warning' tag and then the other tags after that describe what it is
sandro: i don't see how that would work
eprodrom: if i had a post on 'stephen universe', i put in a tag of type content warning,
or 'here is the content warning' and here is the other tag related to it
sandro: i don't see how i could read that as a spoiler vs trigger warning, etc
eprodrom: going in to the ontology of what content makes people uncomfortable ...
cwebber2: i think there are 2 things beeing suggested
one is marking certain tags as content warning,
sandro: spoiler warnings are definitely a thing
cwebber2: you could still handle it all with eprodrom proposal
eprodrom: do you put up police tape or police tape that says quatentine, murder, etc
cwebber2: i feel like its good for this to go to the CG as well
sandro: and some hundreds of thousands of users may have opinions about it as well
cwebber2: plus changing people over who may not like it, they may have some complaints about it
sandro: exactly why i would want to add functionality
<ben_thatmustbeme> my hands can't take much more though
<cwebber2> https://github.com/swicg/general/issues/6
<Loqi> [Gargron] #6 Hashtag representation
<cwebber2> https://mastodon.social/users/Gargron/updates/3288643
<Loqi> [Eugen] @cwebber i had another concern: OStatus URIs of the type tag:example.com;12345;foobar are not represented in ActivityPub, but present in Mastodon. How to avoid duplicates between things Mastodon sees via AP vs what it sees via OStatus?
cwebber2: the basic question is 'how you represent tags'
... what the id of a tag
<eprodrom> https://www.w3.org/TR/activitystreams-vocabulary/#microsyntaxes
cwebber2: does each server have its own tag id?
<cwebber2> tag:example.com;12345;foobar
cwebber2: the way ostatus does this, is there are tag status URIs
eprodrom: there is a big section on this in the AS2 vocab
... it sounds like 'what are the identities' is the question
cwebber2: i'll bring this to the CG as well
sandro: is this 'aspect' part actually implemented yet?
cwebber2: i'm about to
sandro: they are very different from groups
cwebber2: they are just a collection of people
sandro: does that work if the server is down?
cwebber2: well, you can't do that with mailing lists
sandro: no, but you can with hashtags
... its never going to be anything more than another twitter if there is context collapse
... i don't want the person sending it to say who it goes to , but the subscriber has to opt in to it
eprodrom: i think you should probably write this up as an issue
<eprodrom> trackbot, end meeting
eprodrom: lets wrap this up
<cwebber2> ben_thatmustbeme++ for scribing YET AGAIN
<Loqi> ben_thatmustbeme has 74 karma in this channel (233 overall)