Loqi[Chocobozzz] **Merged in develop!**
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...
cwebber2tantek: 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
cwebber2tantek: 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
cwebber2tantek: 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
cwebber2sandro: 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
cwebber2aaronpk: 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
cwebber2sandro: 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
cwebber2tantek: 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
cwebber2tantek: 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"
cwebber2eprodrom: 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?
sandroeprodrom, 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.
cwebber2tantek: 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
cwebber2aaronpk: 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
cwebber2aaronpk: 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
cwebber2sandro: 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
cwebber2tantek: 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"
cwebber2aaronpk: 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
cwebber2aaronpk: 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
cwebber2aaronpk: 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
cwebber2ajordan: 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?
aaronpkPROPOSED: 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_thatmustbemenote: as link has been limited to the head only for many years, consuming code may only check the head so it is safest to place the link tag in the head
aaronpkPROPOSED: 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
cwebber2eprodrom_: 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"
csarvenJust 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.
tantekRESOLVED: 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>
Loqi[Chocobozzz] **Merged in develop!**
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 PeerTube added ActivityPub support! https://github.com/Chocobozzz/PeerTube/issues/104#issuecomment-347476230
RRSAgent logging to https://www.w3.org/2017/11/28-social-irc
eprodrom present+
ben_thatmustbeme present+
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.
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
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 RESOLVED: 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>
Loqi Cwebber-specops made 1 edit to [[Socialwg/2017-11-28-minutes]] https://www.w3.org/wiki/index.php?diff=105267&oldid=0