Social Web Working Group Teleconference

28 Nov 2017

Attendees

Present: sandro, aaronpk, tantek, ajordan, cwebber, eprodrom, ben_thatmustbeme, csarven, eprodrom_
Regrets Chair: SV_MEETING_CHAIR
Scribe: cwebber2

tantek: wanted to find out when people can meet and why we might do so
... I put PTD and SWP on there, since rhiaro and ben_thatmustbeme aren't here, fyi you should put together what you want to be your final version
... for any spec interop beyond the version we have, if there are as2 implementations that have interop on vocab extensions we do

<ajordan> how much time does it take to publish a Note?

tantek: for AP for things that got dropped from the spec, but implementtaions move forward fast

<ajordan> is there a waiting period like with REC-track documents?

tantek: similarly for LDN, webmention, micropub
... if there are implementations that implement those specs + extensions and do so interoperably, we should write it up and get it written
... if anyone wants to write up a working draft as a note, I think we can just agree to publish it... but I don't think it requires echidna, I think we hand off to sandro / rhiaro
... sandro any comments?

sandro: what's the notes on? current workign drafts turning into notes?

tantek: that's category 1, category 2 is a bunch of recommendations which are interoperably implemented, all of which the implemenations have extensions that are to some degree implemented. Putting out a call to document extensions you believe are interoperably handled

sandro: not a fan of putting that... given our timeline... I think that should just be a wiki page or github page rather than a w3c publication

<aaronpk> https://indieauth.net/spec/

<Loqi> [Aaron Parecki] IndieAuth

aaronpk: specific example, most micropub clients support indieauth section of oauth, I've started to capture that in a note format, so that's one example of capturing distinct behavior as an extension... here's a draft URL I put together
... the outline is there and here's some content
... this is the idea I think
... if possible I'd like to get this captured as a note because it captures what's implemented by implemtntors
... there's a couple blank sections

sandro: when could you get them filled in by

aaronpk: this week?

sandro: I like indieauth so I certainly wouldn't object, I just don't think people have a lot of time and energy left but I think this is a good counter-example

tantek: probably both are true, low time/energy but if people have them, here's an opportunity
... it's a note, doesn't need to meet as high a bar as a working draft per-se
... in some groups I've been in as an observer I've seen this kind of practice of end-of-group snapshots of where things are end of group best practices of specifications

sandro: one thing is this is makes it harder to change
... this makes it a community group editor's draft, it looks like it's kinda real, but then you can keep fixing it
... whereas if it's a note, it's very hard to update

aaronpk: I think that's what tantek was trying to get at to capture existing behavior rather than something specifically new
... but this has been around longer than micropub frankly

tantek: sandro's warning is a good one to heed, once you publish a note and we close we don't get to update it... so capturing "these implementations implement this at this point in time" rather than "this is the right way to do it for all time"

<eprodrom> I'm on the phone call, IRC on my phone too

tantek: that being said, you can always publish a note with here's what you know today, you can always follow up with a CG report

<eprodrom> so I may not speak much

sandro: one quesiton you may know the answer to: W3C TRs have a horrendous popup, a CG shouldn't be able to do that to a note, but maybe it should?

tantek: a note may say "for future notes see..."
... when we authored this there was an intent to follow up on it
... this is all background on why we may want to do more telcons. I think there's enough here to justify that

eprodrom: I think my question was answered, which was "what's the goal of these additional notes" which seems to be "here's extra info for implementors", though if I'm not mistaken don't we reference the CG in pretty much all documents?
... I believe AS2 specifies the CG, because that's where extensions are

<ajordan> so maybe if someone this week can go through the documents and see which ones link to the CG?

eprodrom: we may want to put that on the socialwg landing page is "here's where conversation continues"

<sandro> eprodrom, yes, AS says: Some popular extensions are included in the Activity Streams 2.0 namespace document, and can be reviewed at https://www.w3.org/ns/activitystreams#extensions. The Social Web Incubator Community Group maintains a wiki page on Activity Streams extensions.

eprodrom: that's how we can follow-your-nose to current conversation

tantek: re: extra information to implemetors, if it's "here's what people are already doing" that's good, if it's "here's additional thoughts we had" maybe should go in the CG
... does that distinction make sense

<eprodrom> yes

<eprodrom> sry muted

tantek: last thing I'll say for official notes which must be within scope, which is narrower than socialcg's scope
... that's a good way to tie it into "here's why the WG is publishing this note"

<ajordan> you forgot to ack

tantek: we have 4 possible days in december for telecons

<ajordan> I wonder if we can add "notes we'll _potentially_ do" to the document status section on the homepage?

tantek: let's do a quick straw poll on which days folks can make

<ben_thatmustbeme> i can make any of them

<ajordan> we could put e.g. IndieAuth there

<tantek> +1: 12/5 12/19 12/26

+1 12/5 12/12 12/19

<aaronpk> +1 12/5 12/12 12/19 12/26

<ajordan> I personally had no idea that spec was a thing until now

<eprodrom> +1 12/5 12/12 12/19

<ajordan> I can do all but the 26th

<sandro> +1 12/5, -0 12/12 12/19, 12/26

<ben_thatmustbeme> +1 12/5 12/12 12/19 12/26

<ajordan> I might have a dentist appointment, let me check

<ajordan> IndieAuth

ajordan: I was suggest we do a note on maybe document status on the homepage and put indieauth there?

<ajordan> I can make the 26th too

<ajordan> so all days

tantek: can we put in requests during moratorium
... and doesn't get put in till after?

sandro: yeah probably

tantek: I feel like we've been most productive when we had a two-week cadence to our calls

<eprodrom> 12/12 is a good day for it

tantek: so I'm going to go by the proposal and say why don't we meet on 12/5 and 12/19

<eprodrom> oh those are good

tantek: that gives people till next week to prepare notes, and possibly two weeks to iterate

sandro: I think we have to this meeting first because I don't know what's happening on websub yet and that concerns me first

tantek: right we may need next week for websub

cwebber2: +1 to prioritize meeting time for websub

sandro: this is mostly about availability

websub

<ajordan> tantek: I'll be gone by the time we come back to this but I'm okay with all days

tantek: any new issues since last discussion?

aaronpk: no

tantek: how are we doing with follow-ups to 148 and 146

aaronpk: lots of good feedback from implementors

<aaronpk> https://github.com/w3c/websub/issues/138

<Loqi> [aaronpk] #138 different hub for same topic if denied

aaronpk: let's start with #138
... this is the issue that was not captured as a feature... Julian described it in issue as a posssible way to redirect to public profile for private URLs and we decided to survey implementors to see if they tried to do anything similar
... feedback I got was mostly that people who hadn't implemented private subscription yet don't do it this way, and people who have also don't do it this way
... so this feature is to ??? both people

sandro: no disagreement, that's a good thing

tantek: consensus?

aaronpk: consensus on desirability of feature, not on how to do private subscription
... my suggestion is to drop these two sentences so it's not described in the sped

spec

tantek: how does that affect... is this what we thought was at risk and we missed?

aaronpk: not marked at risk, we thought it was a feature
... potentially overlooked

sandro: going slightly meta for a sec, I spoke to ralph and phillipe ... they suggested assuming WG can reach consensus on what to do, we can say who voted on the PR and confirm this doesn't change their approval
... if we have consensus

<ben_thatmustbeme> so it would be good to have consensus today

tantek: it's not good that nobody caught this... if I were an AC rep and I voted for this spec, I might say "what else may you have potentially missed and didn't see"
... I would try to be prepared to answer that question
... I'd like to say this is, we didn't miss anything
... ok if ralph and phillipe are ok with that then let's move forward
... this is mostly trying to figure out what steps to take.

sandro: let's go ahead and record that
... I guess we could resolve that we don't think we need another PR / CR

RESOLUTION: Group does not think we need another PR / CR on #138 since it does not affect implementations by dropping the feature

<aaronpk> https://github.com/w3c/websub/issues/146

<Loqi> [aaronpk] #146 At risk: limiting the use of HTML <link> to the HTML <head>

<sandro> to be clear, part of that is we're resolved to drop the feature

aaronpk: this is an at risk feature we marked at-risk in the document, restricting the link tag to the html document

<sandro> https://github.com/w3c/websub/issues/146

<Loqi> [aaronpk] #146 At risk: limiting the use of HTML <link> to the HTML <head>

aaronpk: we got some answers, not as many as on last issue
... two of the subscribers look at a link tag anywhere, superfeedr looks only at head section, another one cited robustness principle, so that's the feedback we got
... I think we had tagged... we got responses from all 3

sandro: seems like it's a bit conflicted but I'd say ...?

aaronpk: I think this was originally added for a security concern about link being added to a body via a comment etc can allow subscriptions to be stolen
... which assumes that users are not sanitizing html which is also dangerous

tantek: do any of our other specs which do link discovery have this restriction for consuming code?

aaronpk: micropub says look for link tag in html head but is not explicit about what that means, but it does say html head, just not with the brackets
... webmention does not mention the restriction
... micropub doesn't mention where it should go when publishing

tantek: does anyone know about LDN?

aaronpk: looks like LDN says it should use the rel tag, not just on link tags, possibly on a tag

tantek: I think it would be consistent with our other specs to allow everywhere
... if a security problem for one, a security problem for all
... so I think that mitigates it?

aaronpk: is it worth having a security considerations paragraph then?

sandro: well when you mentioned it as a security consideration I thought "I hadn't thought of that"
... link normally seems like... I know HTML sanitizing is the blackest of black arts, but in general "link seems pretty safe"

aaronpk: seems pretty inert at least, and the spec does give it additional power

sandro: you usually let a tags through, and link tag is kinda like an a tag

tantek: well, except link tags can affect styling and etc, which is a security concern
... I'd be in support of a security bullet point

<ben_thatmustbeme> A tags can do rel alternate too, which is similar as well

aaronpk: so dropping restriction means dropping at risk feature?

<ajordan> I'm queued

tantek: so we believe we have 2+ implementations which don't implement the at risk part

<csarven> Following a bit on IRC... LDN doesn't strictly say "rel" attribute.

tantek: so the only one we don't says superfeedr?

<csarven> WRT, HTML, it could be "property"

tantek: I think we should drop this

<aaronpk> csarven, LDN doesn't seem to strictly say anything, but it has an example with an <a rel>

sandro: lost in double negatives around this :) what should people say about looking for link tags? they can't put them anywhere

tantek: should go in the head as a publisher, has to be able to support them anywhere

sandro: SHOULD or MUST

<csarven> https://www.w3.org/TR/ldn/#discovery

tantek: I don't think we can make a MUST at this point

<sandro> so SHOULD go in head, but SHOULD look everyone

<csarven> it talks about the RDF representation.. so, whatever can state x inbox y

tantek: I think ralph and phillipe will sympathize with that approach

sandro: they agree how we partly dodge this from being so serious is that link wasn't even valid outside of HEAD, but now it is because html5

ajordan: so my question is mostly answered... if I'm understanding our known security is put link in head so in case you have an injection problem with your body then the head will say that link in the document gets precident?

aaronpk: specifically says any of the hubs advertised can be used

<ben_thatmustbeme> i think that would definitely make sense in a security considerations section

<aaronpk> PROPOSED: Drop the at-risk limitation of <link> discovery restricted to the <head>, and add a security consideration saying that user-generated content on pages advertising a hub should be sanitized to remove <link> tags

<ben_thatmustbeme> so drop the restriction to the head and change it to a SHOULD put it in the head

<ben_thatmustbeme> as some subscribers will only check there

<ben_thatmustbeme> note: as link has been limited to the head only for many years, consuming code might only check the head so it is safest to place the link tag in the head

<aaronpk> PROPOSED: Drop the at-risk limitation of <link> discovery restricted to the <head>, and add a security consideration saying that user-generated content on pages advertising a hub should be sanitized to remove <link> tags. Replace the at-risk sentence with a "note" that since <link> has been limited to the <head> for many years, consuming code might only check the <head> so it is more robust to place the

sandro: we can't tell web publishers what to do, this affects web publishers that are not websub
... I could go to livejournal and post some content like this

<ajordan> sandro is correct but this is a much less severe issue

<ben_thatmustbeme> same issue different attack vector

<ajordan> could also say "prefer document order" in security considerations

<ajordan> oh wait nvm

<ajordan> yeah forgot about that

<ben_thatmustbeme> how is this not an issue for everyone already with rel=alternate

tantek: sandro, you ok with you and aaronpk handling security consideration wording out of call?

+0.9 :)

<ajordan> +1

<eprodrom_> +1

<sandro> sandro: it's important for security not to look in the <body> I think

<ajordan> I gotta leave for class any second fyi

<sandro> +1 as long as security considerations makes it clear looking for <link> outside of <head> is dangerous

ok +1 with what sandro said

<aaronpk> +1

<ben_thatmustbeme> +1

eprodrom_: I wonder if the wording could maybe match the security effort, which is re: hijacked link, maybe we could say "be careful around user generated content and look out for links"

sandro: problem is publishers will not be reading our spec
... the attack vector is through ordinary publishers who have never heard of websub

<eprodrom_> Good enough here

tantek: flip side is google actually asked everyone to add rel=nofollow but I'm not sure if all publishers changing had impact in practice

<csarven> Just out of curiosity.. why is all this a security concern for a portion of a document in a particular representation? Doesn't it go without saying that input should be sanitised? The outside of <head> being a security concern seems to imply that people have well-formed/valid documents. They usually don't.

tantek: the standards for sanitization have gone up
... I saw a bunch of +1s, no -1s

<ben_thatmustbeme> i feel like this is almost something that should be a security consideration in html5 now that it allows <link> in the body

<ajordan> ^^^

<ajordan> alright, gotta go. thanks for a great telecon all. I'm okay with all the proposed days so I'll see you whenever the next telecon is scheduled

RESOLUTION: Drop at-risk limitation of <link> discovery restricted to <head>, and add a security consideration saying that user-generated content on pages advertising a hub should be sanitized to remove <link> tags. Replace the at-risk sentence with a "note" that since <link> has been limited to <head> for many years, consuming code might only check <head> so it is more robust to place <link> tags in the <head>

<ajordan> bye!

tantek: that takes us to remaining issues.. some editing for sandro and aaronpk to do

sandro: we need ED to show changes before I bring it to AC

tantek: ED update with what REC would look like with changes... aaronpk how soon can you prepare?

aaronpk: by tomorrow

tantek: since we have resolutions on individual issues I don't think we need a separate resolution to go to REC right sandro ?

sandro: no
... not a group decision anyway

tantek: ok, we'll trust aaronpk to move it forward... we have a telcon next week to resolve anything that falls through
... anything else on websub or are we good to go

<eprodrom_> I can scribe

<eprodrom> scribenick: eprodrom

activitypub

tantek: did we get a PR published?

cwebber2: rhiaro said we would get it published on Thursday
... no new issues

<cwebber2> https://github.com/Chocobozzz/PeerTube/issues/104#issuecomment-347476230

<Loqi> [Chocobozzz] **Merged in develop!**

<Loqi> For now, only Server-Server communication is implemented. Of course, the implementation is far from perfect and it misses some features (Block, Reject...) that I'll add later with dedicated issues (I'll create an "ActivityPu...

cwebber2: new implenter
... peertube is supporting federation with AP
... bad news and good news

<cwebber2> https://activitypub.rocks/implementation-report/

cwebber2: IR uses old template

<csarven> and I'm sure cwebber2 is sick of hearing that by now :)

cwebber2: good news is that IR has more implementations of more features
... will contact people with IR updates

telecon schedule

tantek: proposed meetings 12/5 and 12/19
... I still want to see final note versions of publications

<ben_thatmustbeme> thanks whatwg, you blew up our security :P https://github.com/whatwg/html/commit/179983e9eb99efe417349a40ebb664bd11668ddd

<tantek> PROPOSED: December telcons on 5th and 12th

<tantek> PROPOSED: December telcons on the 5th and 19th

+1

<ben_thatmustbeme> +1

<aaronpk> +1

<cwebber2> +1

<sandro> +0

RESOLUTION: December telcons on the 5th and 19th, same time, 60 min.

tantek: lots to be proud off, see you all next week

<ben_thatmustbeme> cwebber2++

<Loqi> cwebber2 has 108 karma

cwebber2: cg meeting tmrw?

<tantek> cwebber++ for scribing

<Loqi> cwebber has 31 karma in this channel (32 overall)

<ben_thatmustbeme> eprodrom++

<Loqi> eprodrom has 52 karma in this channel (53 overall)

<tantek> eprodrom++ for scribing

<Loqi> slow down!

<ben_thatmustbeme> karma flooood

<cwebber2> trackbot, end meeting

<cwebber2> eprodrom++ for scribing

Summary of Action Items

Summary of Resolutions

Group does not think we need another PR / CR on #138 since it does not affect implementations by dropping the feature
Drop at-risk limitation of <link> discovery restricted to <head>, and add a security consideration saying that user-generated content on pages advertising a hub should be sanitized to remove <link> tags. Replace the at-risk sentence with a "note" that since <link> has been limited to <head> for many years, consuming code might only check <head> so it is more robust to place <link> tags in the <head>
December telcons on the 5th and 19th, same time, 60 min.

Socialwg/2017-11-28-minutes