W3C Proposed Recommendation: Webmention

[L. David Baron]

A W3C Proposed Recommendation is available for the membership of W3C
(including Mozilla) to vote on, before it proceeds to the final
stage of being a W3C Recomendation:

Webmention
W3C TR draft: https://www.w3.org/TR/webmention/
W3C Editor's draft: https://webmention.net/draft/
deadline: Wednesday, November 30 (23:59 in UTC-05:00)

If there are comments you think Mozilla should send as part of the
review, please say so in this thread. (I'd note, however, that
there have been many previous opportunities to make comments, so
it's somewhat bad form to bring up fundamental issues for the first
time at this stage.)

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Martin Thomson]

On Fri, Nov 4, 2016 at 1:25 PM, L. David Baron <dba...@dbaron.org> wrote:
> W3C Editor's draft: https://webmention.net/draft/

Wow, that is an extraordinarily wordy document for something that does
so little. It's the first I've heard of this, but it's remarkably
similar to (albeit much narrower than):

https://www.w3.org/Protocols/HTTP/Methods/Link.html
https://tools.ietf.org/html/draft-pritchard-http-links-00
and recently:
https://tools.ietf.org/html/draft-snell-link-method-12

I wouldn't bother saying anything, though, it's just yet another specification.

[Joe Hildebrand]

The JSON reference really needs to be to RFC 7159, not 4627. (blocking, but trivial issue)

There should be some mention of the prior art in this space. Pingbacks and trackbacks at least. Please differentiate this approach from them, so we have an idea if we need to do this also. Many Wordpress sites get nuked pretty quickly when they leave pingbacks on; pointing out the linkage is important so that the industry at least learns from some of the attacks that have worked in the past.

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.

If there's a good reason to publish this that isn't obvious, I might be more excited about it.

> On Nov 3, 2016, at 7:25 PM, L. David Baron <dba...@dbaron.org> wrote:
>
> A W3C Proposed Recommendation is available for the membership of W3C
> (including Mozilla) to vote on, before it proceeds to the final
> stage of being a W3C Recomendation:
>
> Webmention
> W3C TR draft: https://www.w3.org/TR/webmention/

> W3C Editor's draft: https://webmention.net/draft/

> deadline: Wednesday, November 30 (23:59 in UTC-05:00)
>
> If there are comments you think Mozilla should send as part of the
> review, please say so in this thread. (I'd note, however, that
> there have been many previous opportunities to make comments, so
> it's somewhat bad form to bring up fundamental issues for the first
> time at this stage.)
>
> -David
>
> --
> 𝄞 L. David Baron http://dbaron.org/ 𝄂
> 𝄢 Mozilla https://www.mozilla.org/ 𝄂
> Before I built a wall I'd ask to know
> What I was walling in or walling out,
> And to whom I was like to give offense.
> - Robert Frost, Mending Wall (1914)

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

--
Joe Hildebrand

[Tantek Çelik]

Support :)

I'm co-chair of the WG that produced this PR, as well as familiar with and
contributed to its incubation/prototyping/implementation (including on my
own site tantek.com) in the IndieWeb community before we brought it to
a W3C WG for broader review and consideration.

Happy to answer any questions, as well as provide a longer summary tomorrow
(PDT).

Thanks,

Tantek

On Thursday, November 3, 2016, L. David Baron <dba...@dbaron.org

[Tantek Çelik]

On Thu, Nov 3, 2016 at 8:22 PM, Martin Thomson <m...@mozilla.com> wrote:

> On Fri, Nov 4, 2016 at 1:25 PM, L. David Baron <dba...@dbaron.org> wrote:
>> W3C Editor's draft: https://webmention.net/draft/
>

> Wow, that is an extraordinarily wordy document for something that does
> so little.

It was a lot shorter at the IndieWebCamp community.

Extraordinary wordiness is often the consequence of taking something
to W3C, and having lots of issues filed that seem to need explicit
answers in the spec to various criticisms. Some of these are often
helpful!

> It's the first I've heard of this, but it's remarkably
> similar to (albeit much narrower than):
>
> https://www.w3.org/Protocols/HTTP/Methods/Link.html
> https://tools.ietf.org/html/draft-pritchard-http-links-00
> and recently:
> https://tools.ietf.org/html/draft-snell-link-method-12

Here's the explanation of "Why not HTTP LINK":

https://indieweb.org/Webmention-brainstorming#Alternatives

Including that in the spec would of course make it wordier still,
though it's reasonable to include it in the FAQ.

https://indieweb.org/Webmention-faq#Why_webmention_instead_of_pingback

No one has reasonably* asked for using HTTP LINK instead.

*AFAIK no one actually implements and deploys HTTP LINK - it was a
brainstorm that was never incubated with real implementations and
remains theoretical.

Do you know of any implementations, deployments, actual real world
uses of HTTP LINK?

> I wouldn't bother saying anything, though, it's just yet another specification.

Webmention is deployed and live on tens of thousands of Known and
WordPress sites, and many more smaller deployments of other
implementations.

Tantek

[Tantek Çelik]

On Thu, Nov 3, 2016 at 10:05 PM, Joe Hildebrand <jhild...@mozilla.com> wrote:
> The JSON reference really needs to be to RFC 7159, not 4627. (blocking, but trivial issue)

Will file an issue on that.

> 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)

> Pingbacks and trackbacks at least.

https://indieweb.org/Webmention-faq#Why_webmention_instead_of_pingback

> 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.

> 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.

Tantek

>> On Nov 3, 2016, at 7:25 PM, L. David Baron <dba...@dbaron.org> wrote:
>>
>> A W3C Proposed Recommendation is available for the membership of W3C
>> (including Mozilla) to vote on, before it proceeds to the final
>> stage of being a W3C Recomendation:
>>
>> Webmention
>> W3C TR draft: https://www.w3.org/TR/webmention/

>> W3C Editor's draft: https://webmention.net/draft/

>> deadline: Wednesday, November 30 (23:59 in UTC-05:00)
>>
>> If there are comments you think Mozilla should send as part of the
>> review, please say so in this thread. (I'd note, however, that
>> there have been many previous opportunities to make comments, so
>> it's somewhat bad form to bring up fundamental issues for the first
>> time at this stage.)
>>
>> -David
>>
>> --
>> 𝄞 L. David Baron http://dbaron.org/ 𝄂
>> 𝄢 Mozilla https://www.mozilla.org/ 𝄂
>> Before I built a wall I'd ask to know
>> What I was walling in or walling out,
>> And to whom I was like to give offense.
>> - Robert Frost, Mending Wall (1914)

[Joe Hildebrand]

> 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.

>> 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.

>> 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.

--
Joe Hildebrand

[Tantek Çelik]

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 <jhild...@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