And surely not all links are HN-worthy. So it is more logical to "watch" HN, and once it gets posted, enable the comment section. or "add to HN" to comment.
It mentions being derived from Pingback (http://www.hixie.ch/specs/pingback/pingback), which IIRC was at least a spiritual successor to Trackback, so I don't think you're missing anything.
(Which makes me want to look closely at the security/verification parts of the spec, since Trackback was essentially a system for letting spammers spray whatever content they wanted all over your Web site. I wrote a thing about that back in 2005: http://www.anthillcommunities.com/archives/001653.html)
I have considered adding that to my static website generator. When a new blogpost is added, post it to HN immediately, remember the link to the submission, and link to it with a caption like "Comments" at the end of the post.
It's probably best to completely avoid all third-party resources in most cases. You never know if the service will still be around a few years later, or even worse the service could be taken over by a malicious actor.
I'd extend the restriction to third-party APIs as well. Instead of hitting third-party services directly, consider proxying all requests. Aside from protecting the user's privacy, it makes it easier to switch out the underlying implementation if the need arises. Oh, and it lets you avoid CORS, which developers still occasionally screw up with.
> even worse the service could be taken over by a malicious actor
This particular problem is partly mitigated by subresource integrity (hashes of third party resources you put in the html tag).
For my money, there are plenty of situations where third-party resources are acceptable. Ultimately that is basically what a CDN is, which most serious websites rely heavily on (often sharing their SSL certs).
You almost always have a business relationship with your CDN that’s serving your content. You often don’t have that relationship with random third parties you Script src or link href in
Nothing 3rd party is safe, ever - by safe I don't strictly mean malicious, but random, backwards-incompatible, breaking changes as well. Convenient, yes, fast, yes, safe: no.
14 comments
[ 3.0 ms ] story [ 41.8 ms ] thread[^1]: https://www.w3.org/TR/webmention/
(Which makes me want to look closely at the security/verification parts of the spec, since Trackback was essentially a system for letting spammers spray whatever content they wanted all over your Web site. I wrote a thing about that back in 2005: http://www.anthillcommunities.com/archives/001653.html)
I'd extend the restriction to third-party APIs as well. Instead of hitting third-party services directly, consider proxying all requests. Aside from protecting the user's privacy, it makes it easier to switch out the underlying implementation if the need arises. Oh, and it lets you avoid CORS, which developers still occasionally screw up with.
This particular problem is partly mitigated by subresource integrity (hashes of third party resources you put in the html tag).
For my money, there are plenty of situations where third-party resources are acceptable. Ultimately that is basically what a CDN is, which most serious websites rely heavily on (often sharing their SSL certs).