14:31:54 RRSAgent has joined #social 14:31:54 logging to http://www.w3.org/2016/11/17-social-irc 14:31:56 RRSAgent, make logs public 14:31:56 Zakim has joined #social 14:31:58 Zakim, this will be SOCL 14:31:58 ok, trackbot 14:31:59 Meeting: Social Web Working Group Teleconference 14:31:59 Date: 17 November 2016 14:32:03 scribenick: ben_thatmustbeme 14:32:05 present+ 14:32:06 present+ 14:32:06 present+ 14:32:08 present+ 14:32:09 present+ 14:32:15 present+ 14:32:17 chair:tantek 14:32:26 chair: tantek 14:32:35 present+ 14:32:41 present+ evanp 14:32:45 (but text only currently, my own fault) 14:32:57 https://www.w3.org/wiki/Socialwg/2016-11-17 14:32:59 Social Web WG Face to Face Meeting at MIT (F2F8) 14:33:18 tantek: we have 5 clusters of topics to discuss, PR transitions, CR transitions, WD updates or note transitions, group continuity or transition to CG, or other business 14:33:41 present+ 14:33:45 ... we have one request form csarven to discuss LDN tomorrow, that seems fine since he is only here tomorrow 14:34:02 Not present completely. Will watch out for keyword highlights., 14:34:08 evan: if its okay i'd like to discuss AS2 tomorrow as well so i can handle some issues first 14:34:08 Yes, I'd appreciate if LDN is tomorrow. 14:34:25 tantek: are there any other specific scheduling concerns? 14:34:41 I have to drive my wife to an event tomorrow, but let me check the time 14:34:42 ... i think we should sort by priorty, but if any preferences 14:35:15 eprodrom: i think we should discuss contintuity to inform our other decisions on what we are doing with these in the future 14:35:30 tantek: that sounds good, lets put that down for 10 today 14:35:34 the thing is at 5pm tomorrow, so it should be fine 14:35:53 cwebber2, I opened an appear.in URL (see above) if you want to try that 14:36:00 ... anotherway to look at things is to tackler harder things in the morning since we are all fresh 14:36:16 ... the one obvious candidate is pubsub 14:36:47 julien: there is one issue that is a bit complicated, but it would be good for group feedback 14:36:55 ... the correct solution might be to do nothing 14:37:01 eprodrom has joined #social 14:37:08 present+ 14:37:11 sandro: Is cwebber2 on audio, wondering how much stuff we have on activitypub 14:37:29 I'm not on audio unfortunately, I can't seem to get my setup working 14:37:31 tantek: i'm going to suggest after continuity, we do pubsub next 14:37:51 my fault for running a fringe GNU/Linux distribution using modified browsers and missing my webcam :P 14:37:58 ... and then activitypub and micropub after that 14:38:04 ... so i guess all the pubs first 14:38:32 I will watch irc closely and participate here, sorry for the non-ideal participation :( 14:38:35 cwebber2: try your phone with talky? assuming you have a camera there 14:38:54 mattl, my phone's microphone broke! but I'll try my wife's 14:38:56 everything is breaking! 14:44:18 tantek: we had some comments from mozilla (publicly) on webmention 14:44:41 ... not officially yet but on their internal messaging 14:45:09 aaronpk has changed the topic to: https://www.w3.org/wiki/Socialwg/2016-11-17 https://appear.in/socialwg Logs: http://socialwg.indiewebcamp.com/irc/social/today 14:45:46 eprodrom: for those of us not as familliar with the process, whats the process from here? 14:46:31 tantek: the voting period is open, its closes on the 30th and it goes by one formal objection can slow it or potentially kill it 14:47:02 ... usually its pretty bad form to have problems raised at that point unless its more beurocratic 14:47:16 ... or possible "good, but please fix X" 14:47:36 ... if you do know any w3c members, encourage them to take a look 14:47:47 https://www.w3.org/2002/09/wbs/33280/webmention/ 14:47:58 (access controlled -- only for W3C AC reps) 14:48:51 tantek: how long for continuity? 14:48:56 swwg_laptop_: https://chat.indieweb.org/social 14:48:59 eprodrom: 30 minutes should be good 14:49:13 tantek: julien, how long for pubsub? 14:49:19 julien: i think 30 minutes 14:50:02 tantek: cwebber2, aaronpk, eprodrom, any preference for which we talk about first and how much time? 14:50:10 aaronpk: i don't care, i don't have any open issues 14:50:27 tantek: its also to discuss what you need to move forward 14:50:35 cwebber2: i'd prefer to go second 14:51:33 https://www.w3.org/blog/news/archives/5976 14:51:39 ActivityPub ^ 14:51:57 https://www.w3.org/wiki/Socialwg/push-name 14:52:25 tantek: ok, i think we have everything through lunch scheduled, lets go ahead and start with that, if we need more time on things we can take more time and movethings around 14:52:40 TOPIC: group continuity / SWICG 14:53:14 tantek: we already resolved to create the group and Ann offered to do that, and consolidate all the other community groups 14:53:19 ... there are several of them 14:53:33 https://www.w3.org/wiki/Socialwg/push-name#Hubbub 14:53:38 ... first question, where are we with that group, is it created yet? 14:54:23 aaronpk: cwebber2 and I offered to chair the group. I am happy to do the actual submission, write up the group description 14:54:41 ... we need a short name 14:54:47 tantek: SWICG? 14:55:04 aaronpk: CG probably shouldn't be in there, its like ATM Machine 14:55:11 tantek: some other groups do that already 14:56:04 ... web platform incubater community group. look at them for an example, look at existing groups and try to incorporate them 14:56:05 jasnell has joined #social 14:56:20 timbl has joined #social 14:56:35 FYI: https://wicg.io/ 14:56:38 (still up) 14:56:39 eprodrom: there is ostatus group, activitypub, others 14:57:16 ... the activitypub one should probably be closed. the activity streams one could still be open since we have work to do 14:57:51 ... well these are at CR, but if there are things we think should be included and incubated, those would be good for the community group. 14:58:12 jasnell_ has joined #social 14:58:17 ... the incubator group can continue to add extensions and add features to the specs we've defined 14:59:01 eprodrom: with AS, when we talked about extensibility, we talked about adding it to the namespace, which means there is some document maintinance 15:00:00 tantek: so part of it should probably be messaging all those other groups to tell them there is a community group that was not active and they may want to look at this group 15:00:20 sandro: I can imagine ppl being annoyed by that because they only want to follow one technology 15:00:48 tantek: i don't think anyone will really care since these groups are pretty much dead 15:01:47 sandro: if someone complains i think it would be good to keep the group open and maybe just have some major updates 15:02:15 tantek: i think that makes it worse as it looks like the discussion is there, but it isn't 15:02:42 ... i think we should include that the description 15:03:10 tantek: in this group most of the discussion takes place on github, is that something we want to keep for the CG? 15:03:18 .. how does cwebber2 feel about that? 15:03:27 scribenick: rhiaro 15:03:29 I'm fine with it 15:03:34 but, the laptop disconnected 15:03:36 so I can't hear/speak 15:04:03 tantek: THe web platform incubator group is not using the email list for the CG as well. That's clearly an option for us 15:05:01 ... We also had tension in this group over use or non-use of email, so we should be explicit rather than ambiguous about it 15:05:07 we are not hearing you cwebber2 15:05:11 one sec 15:06:10 apparently both talky and appear in didn't work for us for different reasons 15:07:05 scribenick: ben_thatmustbeme 15:07:08 I see a "mute" icon on both participants 15:07:45 nope 15:07:50 is the microphone enabled on yours? 15:07:59 it's saying it's not able to send audio 15:08:15 cwebber2, does hangouts work for you? or even a phone number? 15:08:26 I can call in 15:08:37 how about I call in for activitypub and then closely track irc otherwise 15:08:38 call me directly, i'll PM you my number 15:10:10 tantek: i think that gives you some next steps for the incubator group? 15:10:27 cwebber2: we were asking if cwebber2 was okay with using github and no mailing list 15:10:31 use GitLab ;) 15:10:46 s/cwebber2:/aaronpk:/ 15:11:09 cwebber2: i'm okay with it, but its a little ironic 15:11:24 tantek: we are just saying we are specifically NOT using the mailing list 15:11:51 existing CG that look related to me: activitypub, fed soc web, pubsubhubbub, ostatus, microposts, social business 15:11:55 ... i think the community group gets to specify an IRC channel 15:12:10 aaronpk: i think we should continue to use #social 15:12:29 ... it does mean the logs are shared though, if thats good or bad i don't know 15:12:40 tantek: since its a continuation of us, i think thats fine 15:13:04 ... i think that gives you enough time to write everything up and we can take a look tomorrow possibly 15:13:10 ... or later today maybe 15:13:32 tantek: that takes care of the community group portion. now for continuity 15:14:06 sandro: one thing is that when we took on pubsub, we are legally required to extend the group 15:14:22 ... the waiting period requirements makes it required 15:14:39 ... we don't actually have to do anything other than the mechanical things (assuming no issues come up) 15:14:58 ... that makes it pretty easy to continue some things if we need to 15:15:15 ... the administartion is ok with extending the charter for that reason 15:15:31 aaronpk: the winter break also messes things up as well 15:15:45 sandro: i think as long as we got to PR before christmas we were going to be fine 15:16:13 tantek: the publication morritorium starts the 18th, which means the last day ........ etc etc 15:16:26 sandro: yeah, letting that slide to january makes a lot of sense 15:17:33 tantek: you need at least a week before to schedule transition calls, plus the CRs don't end until the 13th for LDN and AP 15:17:58 rhiaro: we could make it happen but its a lot less stressful to do it in january 15:18:33 tantek: so we have to request an extension, do we have to specify additional things? 15:18:42 q+ 15:18:49 sandro: we can probably find out more about what exactly we need for that in the next day or two 15:19:24 ... mostly its for us, do we want to be at a point where we need telcons? 15:19:45 rhiaro: also that will overlap with the CG, is that okay or do we want wait? 15:19:51 tantek: i think its good to have some overlap 15:20:27 sandro: do we want to try to do a webinar. tutorials on what exists already, "this is what webmention is, heres how to use it" etc for each of our specs? 15:20:34 ... its a lot of energy 15:20:58 tantek: i'd say we wait until after PR 15:21:28 aaronpk: this sounds like my talk at open source bridge, i went through a brief overview of the group 15:21:40 q- 15:21:47 tantek: i think for the rest of the agenda, we talkabout how much we want to go past the end of the year 15:21:49 q? 15:22:41 eprodrom: so we are expecting to go to at least april with our group, and we expect to have a CG that will continue indefinitely 15:23:30 tantek: i think we should be clear that everything else should be finished up by january, and the rest is really just for pubsub mainly. its not like we are trying to cram a bunch of other things in there 15:23:45 tantek: and we're not expecting to be doing an F2F after now, right? 15:24:14 sandro: I don't think so, the big question, what happens if someone points out a BIG issue with one of our specs that has to go through the whole cycle again 15:24:44 eprodrom: for us as a group, would it be fair to say, after jan 1, we have telcons as needed 15:24:55 tantek: i'm going to guess we'll want to do them at least monthly? 15:25:17 rhiaro: monthly 4am phone calls will be preferable to weekly 4am phone calls for me 15:25:51 tantek: presumably we can still get staff contact time for the extension? and the chairs will be able to commit to having time? 15:26:04 eprodrom: yes, i can commit to being around for that 15:26:16 q+ 15:26:17 sandro: staff contact time will be fine 15:27:10 cwebber2: we can ge tto this in the AP time, but as AP has the most amount of work to do, i don't want to completely discount work on AP after Jan1 15:27:42 tantek: thats certainly something we need to talk about, and making that kind of request is important, we'll go over that schedule when we get to AP 15:27:56 ... anything else on group continuity / incubation group? 15:28:15 ... as we discussed, any impact on continuity is something the editor should bring up when we discuss them 15:28:35 TOPIC: 10 minute break 15:28:46 [16:22:41] eprodrom: so we are expecting to go to at least april with our group, and we expect to have a CG that will continue indefinitely --- Is this agreed? April is the extension? 15:29:01 we still have to request it 15:29:08 What will be requested? 15:29:10 it's not just up to us 15:29:34 csarven: we will be requesting a charter extension for PubSub in particular 15:29:41 "We'd like request to extent until May 31?" 15:29:41 until April-ish 15:29:52 Ok 15:30:00 per IP requirements for PubSub FPWD + CR disclosure periods 15:30:27 given that, we need to be specific about how much time (if any) any of our other specs need to complete CR & PR 15:30:48 and we will be discussing that, per spec, while we are discussing next steps for each spec during its slot on the agenda 15:31:24 there was a vague discussion about trying to get everything else (not yet in PR) into PR in January 15:31:40 but we'll figure out the specifics for each spec in depth during today & tomorrow 15:32:12 ok, so all specs need to wrapup by April or wahtever 15:32:26 and that it is PubSub that needs the most time.. hence the extension being that long.. 15:32:38 otherwise it is maybe another month or so.. did I understand that correctly? 15:32:41 Sorry I'm not on the call. 15:36:50 csarven, no problem. 15:37:12 that's roughly correct. there's a strong preference to wrap up our other specs in January, however we will discuss each spec in particular and figure out its particular needs. 15:38:23 its not like the arbitrarily chose April, we have to give a certain amount of time for IP exclusions, since that period is still going on for pubsub, we need to extend 15:39:26 that gives us the opportunity to finish dotting i's and crossing t's on other specs, but we want to be clear that we are not just trying to cram a bunch of other new stuff in by extending 15:39:35 btw, I assume #social is a pretty welcome place in general to invite people hoping to implement socialwg specs? 15:39:42 or should I encourage people to join another channel 15:40:17 scribenick: none 15:40:29 that will make things a bit easier on me 15:40:53 cwebber2, i would say thats fine, especially if we are going to suggest this as the IRC for the CG 15:40:59 and you will be co-chair 15:43:54 ben_thatmustbeme, cool, thx for your input 15:45:00 jasnell has joined #social 15:54:24 scribenick: rhiaro 15:54:31 TOPIC: PubSub 15:55:02 tantek: Most complicated issue? 15:55:13 julien: the signature one 15:55:23 https://github.com/w3c/pubsub/issues/36 and https://github.com/w3c/pubsub/issues/43 15:55:26 ... How do we ensure that requests coming from the hub to the subscribers (that are not content) are actually coming from the hub 15:55:39 ... It was suggested that we use a signature mechanism, except we don't have a body, so nothing tos ign 15:56:00 ... I think (and aaronpk agrees) is to not provide a signature mechanism but strongly incentivise subscribers to use complex urls that are not guessable 15:56:04 sandro: capability urls 15:56:27 julien: if we go in that direction, which I think is safe in terms of security, is why do we even need to sign notifications? If we have https and complex urls, that should be secure enough 15:56:33 sandro: https protects the url? 15:56:36 julien: yes 15:56:37 tantek: no 15:56:44 julien: it exposes only the domain 15:56:50 sandro: only the ip address 15:56:55 aaronpk: you iknow the domain because of SNI 15:57:06 julien: you don't even know the method 15:57:10 tantek: so you want to make https a MUST? 15:57:37 julien: I still think we should allow for non-https, that adds complexity, and I think we need the signature for the case where you could have a man in the middle thing where someone could alter the content and you would not know that they had 15:57:43 sandro: there's nothing to sign because..? 15:57:45 aaronpk: two things 15:57:59 ... The confirmation that the hub sends is a GET request, here is: 'yes the subscrption has been activated' 15:58:14 ... For that it's using a complex URL, because there's no body you can't sign the payload 15:58:28 ... Some alternatives could be come up with a signature method based on query strings.. sounds like oauth1, or sign the headers... whatever.. 15:58:38 ... But a much simpler solution is use a 128 bit capability url 15:58:42 ... That's probably fine over https 15:58:52 ... That url is never exposed because it's sent in the POST body over https to the hub 15:59:06 ... With that in mind, totally separate issue: why do we even have signature son the body? 15:59:17 ... If you assume the URL is secret and nobody can send forged requests to it, why does the hub need to sign the payload? 15:59:40 ... One reason to continue using signatures is it does allow subscribers to not support https if they are willing to take the risk of forged confirmations 15:59:42 https://www.w3.org/TR/capability-urls/ 15:59:43 [Jeni Tennison] Good Practices for Capability URLs 15:59:50 ... but when they get the delivery they know the payload was not forged so they can check the signatures 15:59:57 I guess if you don't trust certificate authorities too :) 16:00:00 yeah 16:00:03 ... Second, it secures against mitm over https, which is a thing in corporate network environments 16:00:04 jasnell has joined #social 16:00:10 sandro: how do you know the public key..? 16:00:19 aaronpk: the subscriber sent the secret to the hub during subscription over https 16:00:25 julien: since it's async it's harder to mitm 16:00:38 aaronpk: it's not pgp level safe, but it's.. 16:00:49 tantek: the other reason even in https is the general concept of defense in depth 16:00:55 ... Multiple levels of things to use as defenses 16:00:59 ... One more thing to break through 16:01:03 ... Good security architecture 16:01:09 julien: technically the payload is more important than the confirmation 16:01:22 FYI: https://en.wikipedia.org/wiki/Defense_in_depth_%28computing%29 16:01:23 aaronpk: if you intercept a confirmation the worst thing that happens is the system thinks it is subscribed and it's not 16:01:29 ... whereas the payload could have real consequuences 16:01:47 q? 16:01:47 julien: so the right thing is to not change the spec at this point, but to use capability urls 16:01:48 q+ 16:01:54 aaronpk: it's essentially a bearer token in a URL 16:02:11 ... Not change the normative spec, but the suggestion in security considerations would be to put a strong recommendation to use these URLs 16:02:17 ... It doesn't affect interop, but for your own good you sholuld be doing this 16:02:27 sandro: are people doing that now? 16:02:31 aaronpk & julien: I think so 16:02:34 aaronpk: subscribers 16:02:38 julien: hub is blind to everything 16:02:45 aaronpk: woodwind does and my switchbaord does 16:02:56 tantek: strong enough that you can make it a must? 16:03:00 aaronpk: it doesn't affect interop 16:03:14 tantek: if you can make it a MUST it's good for the future 16:03:25 aaronpk: you don't want to put a specific length.. how do you define what's strong enough? 16:03:37 sandro: you could say it has to be unique for every subscription? 16:03:43 julien: should we enforce it at the hub? 16:03:50 aaronpk: the hub could deny a request if it's seen the URL before 16:04:05 q? 16:04:17 https://www.w3.org/TR/capability-urls/ 16:04:18 [Jeni Tennison] Good Practices for Capability URLs 16:04:22 eprodrom: W3C note on capability URLs that is very thorough 16:04:37 https://w3ctag.github.io/capability-urls/ 16:04:37 ... WD from 2014, so maybe not quite... oh now I found Jan 7 2015 16:04:59 ... Can't be normative, we can use as informative reference 16:05:11 aaronpk: So then the issue is do we require unique URLs for subscription, which would be a testable implementation change 16:05:17 julien: it would break things 16:05:19 aaronpk: It's a strong change 16:05:23 tantek: you could make it a SHOULD 16:05:26 julien: I think it should be a SHOULD 16:05:35 ... These are things that protect you, do them, if you don't you're the one who is going to suffer 16:05:42 tantek: for new implementations and new subscribers it is a MUST 16:05:48 aaronpk: I have a hard tiem justifying it as a MUST 16:05:51 ... It doesn't change the protocol 16:05:59 ... It works just as well with all the peices together whether or not subscribers do this 16:06:05 ... I have a hard time saying it's a MUST because of that 16:06:34 ... but if someone is implementing this.. I opened this issue because I was writing the test subscriber, and I was like 'wait a second what is stopping someone else from making this request?' there wasn't something in the spec to tell me how to protect myself 16:06:50 ... I think just at that point the implementer will go to the spec and see the recommendation to make it a unique URL 16:06:58 aaronpk: I can make the test suite measure that too 16:07:03 ... whether that different 16:07:07 ... could check the entropy as well 16:07:26 tantek: if it becomes common practice we can chane it to a MUST and tighten the security of the whole system 16:07:27 q? 16:07:29 ... What about signatures? 16:07:40 aaronpk: Right now signatures are a optional for the subscriber 16:07:53 julien: the subscriber can take the risk to receive forged content 16:07:59 aaronpk: or they can ignore the payload and go fetch the content themselves 16:08:06 julien: very few implementations actually check the signatures 16:08:14 ... so in practice even though the signature is safer, people will use the URL 16:08:20 ... as a way to cover their base 16:08:25 (mitigate) 16:08:30 ... the reason is because the signature mechanism I felt people have had trouble coding 16:08:42 ... People will not sue the right encoding 16:08:49 ... It's harder to debug 16:09:09 ... THe hub will compute the signature at the byte level, the subscriber will use a different encoding and compute the siganture on the string version of this, and get a different result 16:09:21 aaronpk: shouldn't hte hub compute it on the string level then? 16:09:24 julien: the hub doesn't know th eencoding 16:09:28 eprodrom: the issue is signatures are hard. 16:09:49 julien: PHP doesn't help 16:09:55 sandro: In JS you oculdn't do it until recently 16:10:26 aaronpk & julien: something about gzip 16:10:33 ... good test case 16:10:40 julien: the hub is the party signing the content, not th epublisher 16:10:54 ... it would be more secure for the publisher to sign and the hub just transmit it, and be agnostic of the content 16:11:01 ben_thatmustbeme: but then you're starting to define the publishing 16:11:05 julien: right htat's a completely different thing 16:11:23 sandro: In the current model the hub has to sign it differently for each user (per secret) 16:11:45 eprodrom: one of the problems iwth capability urls is as soon as you publish anything across security boundaries you've started yoru clock ticking. Somebody is going to get to it at some piont, whether it's 100 years from now or next week 16:11:51 ... Once yo've published it, ... 16:12:05 julien: We should have a requirement, when the subscription expires, don't reuse your callbacks 16:12:16 ... So you are exposed for the duration of your lease, when the lease is over you can start fresh 16:12:20 eprodrom: and if you do a large enough key 16:12:28 julien: start with 20, then 50, then 200, then 2000... 16:12:43 eprodrom: if you can do it in a way that your window is small enough then you have enough time 16:12:54 julien: someone has asked about unbound leases before, I think no this is wrong. You need to provide a maximum period 16:13:04 ... the hub MUST have a period 16:13:09 sandro: how does the hub reply? 16:13:13 aaronpk: it's part of the confirmation 16:13:28 sandro: does the spec now say 'we know it's ugly?' 16:13:31 julien: no 16:13:40 sandro: I would like it to say that it recognises that it's in violation of web arch 16:13:53 aaronpk: it's important to put that in there because other people will think that and raise issues or try to reinvent 16:14:05 julien: I think it's elegant to have a different verb for the handshake thing and the notification 16:14:15 ... On the implementer level it's easier to just say it's a GET, or a POST 16:14:25 aaronpk: It is easier. And for the payload, the post body is the document, it's not a wrapper 16:14:35 ... If it was one of the form params it would be much easier on implementer level to use the hub.mode to swithc on that 16:14:50 ... but as an implementor if I have to handel reading the raw POST body to understand what type of .. 16:14:53 sandro: and it's the same URL? 16:14:54 aaronpk: it has to be 16:15:02 sandro: if they were both POST I'd use two URLs ors omething 16:15:05 aaronpk: that would be even crazier 16:15:15 julien: SO I understand it's not the nice way of doing http things, but it makes implementers job much asier 16:15:21 sandro: how do you tell whether you're getting a diff or full content 16:15:23 aaronpk: different issue 16:15:46 sandro: I'd use http PATCH verbs 16:16:09 ... and Accept-Patch 16:16:44 ... Not a custom header 16:16:48 ... You can have that in the subscription request 16:16:58 ... For instance when you do the confirmation, on that GET the return header could be Accept-Patch 16:17:05 julien: Oh I see 16:17:10 sandro: could be an extension 16:17:29 ... You could also, the hub could just send a patch and see what status code it gets back 16:17:38 ... A server is not going to give a 200 on a patch unless it's handling it 16:17:46 julien: I was hoping to be using a content type header 16:17:57 sandro: or you could do it after the first post to a subscriber 16:18:03 ... they can say they accept patch for future reference 16:18:14 julien: there's a continue http code, 100 or something, the subscriber can say hey send me the patch 16:18:22 sandro: I think continue is in response to a get 16:18:34 julien: I dunno 16:18:41 aaronpk: All these things are nice to do, but nobody has implemented any of them 16:18:48 sandro: It can cleanly go in as an extension 16:19:07 julien: when we went with fat ping we talked about ability to have extensions 16:19:20 aaronpk: Okay so 16:19:27 ... Recommend SHOULD use capability URLs 16:19:32 ... SHOULD not reuse capability URLs 16:19:45 ... Hubs MUST NOT issue unlimited subscriptions? 16:19:48 ... MUST enforce lease 16:19:57 julien: if the subscriber does not submit one the hub will tell you what it is 16:20:07 sandro: but we're okay with 20 year leases? 16:20:14 aaronpk: I don't think the hub should decide the limit 16:20:17 sandro: in security considerations 16:20:19 julien: Should be short 16:20:25 tantek: how muc hof this can you test? 16:20:31 aaronpk: All testable 16:20:49 ... Can test that a subscriber is using unique urls, that the hub is returning lease seconds 16:21:01 sandro: if it's more than a year you can give a warning 16:21:22 aaronpk: That's basically going to resolve these two issues 16:21:28 ... 43 and 36 16:21:53 ... And then signatures on the notification not changing, because it is implemented some people are doing things with it, if you don't want to use it you don't have to, and you can always go fetch the original content if you don't trust the hub's payload 16:22:09 tantek: are any of these SHOULDs currently unimplemented 16:22:19 aaronpk: we don't know about renewal 16:22:25 julien: we dont' check that you're using a differnet URL 16:22:30 aaronpk: there's no survey of all of them 16:22:36 ... but I know that mine does use a unique one 16:22:45 ... We don't know how widely, but we can test it 16:22:58 tantek: that sounds like we can make a SHOULD and see what happens 16:23:02 ... if everyone is doing it, we can make it a MUST 16:23:06 ... without discussing again 16:23:09 julien: I don't think everyone does it 16:23:43 aaronpk: could you check that on superfeedr's end? 16:23:47 julien: wordpress and google doesn't do it either 16:24:09 tantek: we should gather data 16:24:14 ... and raise it with them as a security concern 16:24:24 q? 16:24:30