Thanks very much for the detailed comments Joe. tl;dr We have to wrap this up tonight (W3C vote deadline) and I'm pretty sure I've captured the suggestions you've made (greatly appreciated) with public github issues (which hopefully you've received notifications thereof).
public github issues filed for specifics, to which anyone is invited to follow-up, even beyond tonight's AC vote submission deadline: * https://github.com/w3c/webmention/issues/75 * https://github.com/w3c/webmention/issues/76 * https://github.com/w3c/webmention/issues/84 We can submit our vote to W3C approving the Webmention PR and asking for these changes. Details inline below: On Fri, Nov 4, 2016 at 9:56 AM, Joe Hildebrand <jhildebr...@mozilla.com> wrote: >> On Nov 4, 2016, at 9:29 AM, Tantek Çelik <tan...@cs.stanford.edu> wrote: >> >>> There should be some mention of the prior art in this space. >> >> Why in the spec? (honestly interested to know what you think should be >> in a spec without making it more wordy as Martin pointed out) > > Because there has been a lot of security work done on the prior protocols, > particularly in terms of implementation detail in spam prevention. It's also > just good karma to call out the giant upon whose shoulders you are standing. > Informative links from the in the document will be nice decades from now when > nobody remembers that those other protocols once existed. > >>> Pingbacks and trackbacks at least. >> >> https://indieweb.org/Webmention-faq#Why_webmention_instead_of_pingback > > Agree that this is much simpler than either. That likely makes it easier for > spammers and other attackers to abuse. Agreed about the explicit mention of Pingback in the spec with the reasoning you gave, issue filed: https://github.com/w3c/webmention/issues/76 >>> Section 4.5 "Limit access to protected resources" points out that this >>> protocol is an attractive nuisance. Anyone who deploys it is likely to >>> make their infrastructure more insecure by mistake. >> >> Could you expand on this? How? Definitely interested in any and all >> security concerns. > > Nobody is going to remember to sandbox the network connection of the process > that is checking the targets. I send you a webmention whose target is > "https://intranet/";, your process requests that URL, and you post a synopsis > of what you found as a comment on the blog entry I put in the source. Yes, > there are protections you can put in place for that, but I can't think of any > that can be coded generically into a piece of open source software that > doesn't open up your internal resources by default. > > Even requiring CORS (with the origin as "something interesting", like a > constant) on the target would be a step toward making this better. Explicitly mentioning using CORS for this is quite sensible. Issue filed: https://github.com/w3c/webmention/issues/84 >>> If there's a good reason to publish this that isn't obvious, I might be >>> more excited about it. >> >> It's interoperably implemented across double-digit implementations, >> and deployed an interoperably in use across tens of thousands of >> websites. > > That's a good enough reason. Thanks much, and thanks again for your review! And welcome on board at Mozilla as well! Tantek P.S. And from previously - to fix the JSON reference: https://github.com/w3c/webmention/issues/75 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
