OAuth has become the de facto standard for authorization and authentication on the web. Nearly every company with an API used by third party developers has implemented OAuth to enable people to build apps on top of it.
While OAuth is a great framework for this, the way it has ended up being used is …
IndieAuth, the extension to OAuth 2.0, was developed by Aaron Parecki and implemented by multiple people in the IndieWeb community, including myself.
The problem has been that people conflated it with the service Aaron created as a reference implementation, which implemented IndieAuth for people who didn’t have it by using the OAuth services of sites like Twitter and Github to bootstrap the service.
Aaron succeeds here in finally conveying a point it took me a long time to understand, and partially only by reading and implementing one of these.
Was pleased to see the founder of Home Assistant, a product I use, tweeting that he would adopt this in that product. Looking forward to seeing what people come up with.
Vouch is an extension to the webmention protocol. Webmentions usually have two parameters…source and target. Target is the URL on your website that the Source URL is linking to.
The vouch parameter is a third URL to help the target determine whether or not they should accept the webmention. This should block automated spam and aid in moderation.
Several people have implemented receiving vouches. It is relatively easy to look at a vouch URL and see if it links to a third-party who you have approved of in the past. While there are more advanced things you can do, that is the basic summary of the protocol.
The harder part, and less implemented by others is sending of vouches. Where do you find people who have been approved by people you have approved of? It would really help if we had some more discussion on this.
So, at the Indieweb Summit, we talked about this a bit, after which I implemented a primitive Vouch receiver. My solution was to use a manually curated domain whitelist that I’d previously built as my source for acceptable domains.
There are some suggestions on where to get this list. Several people generate a list from referrers. This sent me down the road of looking as to whether I’d want to implement refbacks to add more mentions to my website…except there is a lot of noise. Refbacks are basically the same as webmentions, except the source is gleaned from the referrer header that sites send when a page is accessed.
Even if I have a list of sites that I approve of, I would have to crawl them to find links from them to other sites. So, I think we should all help each other out on this.
That means we need to post our list of approved domains somewhere on our site. That used to be quite popular. It was called a Blogroll. It was sites you read, followed, or recommended. There are other terms for it. But, this is a perfect place to get a nice list, and if we publish them, then we can help the Vouch cause.
But the problem is, how do you tell a Vouch receiver where your list is. There are some brainstorming items about blogrolls and following/follower lists
Follower lists marked up with rel=”follower” or rel=”following”
Follow posts would create an h-feed of follow posts that could be used to generate a list. You can have a specific page on your website, but there isn’t a way to indicate this to someone looking for it.
There is rel-directory, which is the reverse direction. It indicates that the link is to a directory in which the current page is listed. What we seem to be missing is a property that says that a page is a feed of followers that can be placed inside an h-card or on a home page.
u-follow-of is a proposed property that indicates that an h-entry is considered a follow post, which is a post indicating you have followed someone, then a feed of follow posts could be parsed and read by a reader. If you add in the XFN relationships to that, you can build even more detail.
The reverse relationship would, in theory, be u-follow, which would be a URL to the follow post of the current URL(the thing being followed).
Feeds are identicated by rel=”feed” to link from your homepage to those feeds. But there is a lack of indicating what type of feed it is, such as rel=”blogroll” or rel=”following”. I’m not sure, and need more discussion about what to use for this.
But, this has the ability to solve a lot of problems. Imagine I…
Post Follow posts when I follow someone
Use this to generate a blogroll/followers list
Send webmentions when I follow someone so they can build relationships
Use that list as a vouch list. Use other people’s blogrolls/followers lists as a means to generate vouch lists…which reduces the implementation cost of Vouch.
Needs work, but suddenly I want to do Follow posts.
Portland Union Station
Somewhere 35000 feet over Montana on JetBlue flight 236 to Seattle.
Hi there, can you tell me please if Webmention collects any personal data on my blog? Maybe you heard of the GDPR in Europe, we have to declare if someone collects personal data… Thanks for your help!
I am very well aware of it, as a contributor, though I don’t live in the EU. And the author/creator of the plugin lives in the EU. The latest version adds some information on this into the plugin to try and make it clearer, but we continue to try to improve. Will try to clarify…This is a bit of a long explanation, but I feel that others may ask this question and want to try to help with the answer.
Disclaimer: Some of this is my interpretation and opinion. Anything technical is a fact as I understand it.
A webmention consists of two properties. A source URL and a target URL. So, when I link to a page on another site, a webmention is sent to that page if it supports it, telling it that I linked to it. The webmention plugin on the target side then generates and displays a link showing that site name(which it extracts from the title of the page) linked to that posts. Even under GDPR, linking to another site is not a personal data violation. Therefore, that is fine.
Now, there is a debate as to whether storing the IP address of the webmention is storing data. Webmention doesn’t actually need to do it…but WordPress does it for new comments by default. WordPress itself is looking into anonymizing that data to avoid the issue, and even though I myself don’t agree with that interpretation of the GDPR for personal use, as it doesn’t add anything to the presentation, I was going to, when the new functions are added, ensure they are applied to webmentions, which is a type of comment.
If you are concerned about data collection, the second plugin, Semantic Linkbacks, which is separate, is not required. But, I think the experience of Semantic Linkbacks is worth installing. Semantic Linkbacks reads the URL of the page that sends you the webmention for more information.
So that means it goes and looks at your page for your site name and author name, and instead of the generic page title, it tries to format your webmention as a better comment. It finds the name of the author of the page, the site name, title, etc.
But, webmentions require affirmative action. You have to link to me. Someone has to send one. If you didn’t want that outcome, why install the plugin that has this feature? So, if you have a privacy policy, you probably should outline that you receive webmentions and what you do with them…namely, display them.
So, the data that Semantic Linkbacks extracts does include information if your site is marked up to support it. So, if your author image is marked up as such, it will note this so it can display it. The image on your site is one you yourself chose to represent you. Same with the other information. It is basically trying to represent the link you made to the site accurately.
Any site that receives webmentions should respect any request to remove their display or purge the information. But webmention itself allows for this. If you send another webmention, it will update. So, if you take down the page, send another webmention and it will purge the comment. There’s even a form built into the Webmention plugin for that.
Under GDPR t0 my understanding, you have a right to see what data a site has on you and get a copy of it…we have that covered because the data is a copy of the page you yourself created. You have the right to correct incorrect data…there’s the update webmention functionality.
And if we didn’t, WordPress is building in tools for data export, deletion, and anomymization…regrettably though, they use email address as a way to extract comment and user data…something the plugin doesn’t collect.
I won’t speak for Matthias Pfefferle, who authored the plugin and has been kind enough to put up with my submissions to it, but he’s given me the impression that he takes this very seriously. And even though I don’t agree with the way people seem to be applying GDPR concerns to this, I respect their concerns enough to try to address them through plugin enhancements that will allow better controls over this.
As another side note, the WordPress Core team, who is scrambling to add GDPR tools to WordPress itself, didn’t consider Pingbacks and Trackbacks, built into WordPress, to be something to address as a GDPR concern to my knowledge. Webmention functions the same way as those two in terms of what it does, although it is a newer specification.
Watching the Google I/O Keynote. They are saying Hey, Google a lot. Had to mute my Google Home.
I admit to a certain amount of frustration on the subject of privacy lately. It seems, in all aspects of my life, both personal and professional, the new data privacy regulations that the EU rolls out May 25th are a theme in every discussion.
I don’t live in the EU, and I know that the European view on privacy is very different than the American one. Anything I say below is my opinion.
I am also an archivist and librarian by education, if not by profession. We learn about the past by reading the materials of the day. The fact that email is so easy to keep and delete makes things difficult for us to archive for the future. Does the right to privacy mean we lose the ability to look back, because we don’t want to remember?
Historical concerns aside, let’s think about today. In the majority of states in the US, only one party partipating in a phone call is required to record a conversation and even post it. Privacy is very lopsided. There is no such thing as absolute privacy.
For me, keeping a copy of communications I was a party to is perfectly acceptable. My website is where I keep my copy. It is not covered by privacy regulations. I have no business agenda there. I will not sell your data or use it for anything else but archiving that conversation.
The thorny issue is whether or not I have the right to display that information publicly. This is because I am, in some cases, copying that data from another service. For example, Twitter or Facebook. Those services got permission to store that information and you have the right to manage it. But you may not know that I have copied it to ask me to remove the public display of your image.
But how is that different than someone creating a screenshot of the post? Which was public information at the time?
As a private individual, I think it is mandatory that I post a policy about what I do. And that I will hide or remove information on request. As a developer of Indieweb tools, I think I should give people the option to not store information if they so choose.
So, I am going to build the tools for people to not collect data. I am going to stop what I am working on and do some of this right now. But I still will. I am going to try to better secure that data. I am going to be clearer about it. That is the lesson I can take away from this and should. That we need to think about privacy impact.
I hope those who are more concerned about this tell me through my site they don’t want me to share our public conversations that they were happy to put in a public forum. I will then restrict them to my eyes only.
In Indieweb terms, I support webmention deletion. If the original source changes and you send a webmention, my site should remove or update my copy.
Disclosure: Your responses to this may be captured for archival purposes. Please advise me if there is an issue.
Originally intended to showcase a privacy-centred implementation of emerging social web technologies – with the aim to present a solution not initially motivated by legal requirements, but as an example of privacy-aware interaction design – my “social backfeed” design process unveiled intricate challenges for Indieweb sites, both for privacy in general and legal compliance in […]
I have been thinking about this issue a lot. GDPR seems to be everywhere, and I’m not sure that storing information on interactions is a privacy issue, but I want to respect people’s concerns. GDPR or not, I do not think this is a use case the law intended to prevent.
You use the WordPress suite of plugins. And being as I’m as regular contributor, there are a few ideas I’ve floating that I think are a good start, and invite you to contribute more.
Add text to the Webmention form that explains how to use it to delete a mention. Since the form can be used without supporting webmentions on your own site, this is something that should be made clear.
Add Setting to not display avatar/photo
Add ability to edit mentions, to correct inaccurate data.
Add setting to store more/less data.
Add privacy policy to plugin for those who install it and add text/link to webmention form.
Explain how to request a takedown of information.
Periodically poll/refresh sources.
Allow a different level of processing for ‘native’ webmentions vs backfeed run through a service like Bridgy.
This doesn’t solve all of the problems necessarily, but I think these ideas are a good faith effort in that direction.
The eighth annual gathering for independent web creators of all kinds, from graphic artists, to designers, UX engineers, coders, hackers, to share ideas, actively work on creating for their own personal websites, and build upon each others creations.
I’ve decided to take a different direction for the Bridgy plugin for WordPress. I’ve never quite been able to explain to people it doesn’t actually do anything. It’s a user interface for the Bridgy service. I’ve decided that the best thing to do is to is to change the approach radically.
Bridgy is a service that integrates with various sites…Facebook, Flickr, Twitter, Github, and sends back comments, likes, etc to the original copies of the same posts on your site. There are a few similar services I’ve integrated with. It also has a feature called Publish where it allows you to syndicate your posts to those services.
This is something of an arms race, as APIs change all the time. Sometimes, there is no official established API. Ryan Barrett, the creator of Bridgy, announced in a blog post this week that due to Facebook API changes scheduled to take effect on August 1st, the Publish features of Bridgy for Facebook would be discontinued at the same time.
I’m writing this partly to lay out my plan in my mind as I’m working on writing this now. I’ve gone through a few different versions of this idea before settling on this.
The Bridgy plugin consists of two parts: The first part is a UI that is added to the post editor that consists of a series of checkboxes, and the corresponding code that triggers the same action from a post made over Micropub. The second part was added last summer, and is basically a registration page for registering for Bridgy.
I’ve opened an issue for discussion on whether I should move the second part into the main Indieweb plugin. Newcomers to the Indieweb could install the plugin, register for Bridgy inside it, and instantly start getting backfeed from other sites.
That brings us to the first part. The checkboxes. They will need to be rewritten, if I want them to continue, for the new post editor, Gutenberg, at some point. But, I don’t just want to syndicate via Bridgy. I want to syndicate to anywhere I can or choose to integrate in, both using the WordPress post editor and Micropub.
So, I’ve decided to integrate the top level of this, the logic that gets a request for syndication from the post editor or Micropub, inside Syndication Links.
Syndication Links displays icons which link to syndicated copies of posts. You’ll see them on this post. I keep adding in integrations to other plugins as people ask. I have Mastodon Auto Post, Keyring Social Importer, Medium, Social Network Auto Poster, and a few more. And I’ll likely continue to look at plugins that syndicate to other sites, figure out where they store their data, and display it as part of this plugin.
But now, this second part will expand the plugin into this territory of being a middleman for actually syndicating content. This is similar to what I did in Simple Location, where I have a series of providers for weather, location, maps, etc. and anyone could write a plugin(though only I have so far) that adds another provider.
To start, the first provider I’ll be including will be a rewritten version of Bridgy Publish, as well as my plan to add Indienews, as both are triggered by sending a webmention to a site.
At the point that I finish the alternative with feature parity to the existing code, I will discontinue development on the separate Bridgy plugin. It will mean one less plugin to maintain. Anyone who does not want to use the new features in Syndication Links…they will be off by default to start with.
It also means that, if I wanted to, I could add native publishing support for services in future. While there are certainly no end of Twitter/Facebook/etc plugins for WordPress, none of them quite understand syndicating a favorite to Twitter doesn’t mean a new tweet, it means something else. I can continue to write integrations for other plugins, or add new providers myself.
Not saying I’m going to do that. I’m only committing to what I’ve said above.
Finally, to all of you who liked the Bridgy Publish plugin…I’m curious to hear your comments on this. Bear in mind, I built the Bridgy Publish plugin to use it, and I still never migrated myself over to it. I would like to finally leave what I am using, and this would mean I could change providers without changing interfaces if I ever add something in future.
Part of my own project for this week, while taking off for the holiday, was to complete work on an Indieauth endpoint for WordPress.
IndieAuth is a layer on top of OAuth 2.0, a standard that grants websites or applications access to their information on other websites but without providing passwords.
OAuth is already being used by a variety of services…Login with Facebook or Login with Google options on sites are usually OAuth based. The difference is that for IndieAuth, users and clients are all represented by URLs.
Authorization Prompt for Indieauth for WordPress
So, why did I want to build one? A few reasons. The most popular use for a IndieAuth server as authentication for Micropub clients. Micropub is a standard for creating posts using third-party clients.
WordPress is moving toward deprecating their post interface in favor of a totally new one called ‘Gutenberg’. As a long time WordPress user, the focus on this concerns me as it does not necessarily represent my needs or desires as a user of the platform. So, I want to have options.
Currently, OAuth servers for WordPress of all types are limited. The REST API, which was heralded with much optimism, lacks an OAuth authentication method. In fact, it lacks any built-in authentication options other than the WordPress login for external authentication.
There is an incomplete project for an OAuth2 server for WordPress I did get some useful ideas from, however. I also have to thank Aaron Parecki, who wrote a book on OAuth2 and wrote the Indieauth specification, for reviewing my work and giving lots of feedback.
What I’ve built, with help, is a working IndieAuth authentication method that works for the REST API, among other things.
Since I wanted this to be widely adoptable, I needed to make sure of a secure implementation, and I think the results are a good initial version. There is an opportunity for further refinements and improvements, but it means that WordPress users are no longer dependent on Indieauth.com, the reference implementation of the spec which uses OAuth providers like Github and Twitter to authenticate.
This leads to my hopes for the future. There are people working on Micropub clients for Android. And if any of them pans out, or my own mobile options, I could easily post notes to my site from wherever I am using tools that are much more flexible to my needs than are available now, the culmination of nearly 4 years of moving toward this point, on and off.
The success for me will be able to read something on my phone, and quickly share that to my site. Or have a thought and quickly share it to my site, without having to spend so much time setting it up I think better of it.
There are still pieces that need work to achieve that, but this is a major piece knocked off.
This narrative is exactly as written in 1999. No corrections have been made to any grammatical mistakes I may have made in 1999. Any items in italics are editor’s notes, circa 2016. The journal includes a film log and the pictures are captioned as per my notes in the log.Stepping off the plane in Krakow
Sunday, April 11th, 1999 – Krakow, Poland
Arrived in Krakow around 4PM local time, 10AM EST. Was bussed from plane to airport where I went through customs and waiting around for our luggage, I met our guide, Peter, and got on the Orange Bus, 105.
I recall that Krakow did not seem equipped for a 747, and they had a single man driving the luggage cart and unloading it, then going back for more. And when we tried to assist in unloading, we were stopped by the armed guards. In 1999, the airport had less than half a million enplanements. It had over 4 million in 2015. The airport has a variery of discount carriers, and a new terminal opened in 2015. The older terminal is being remodeled.
Jewish Quarter – Isaac Synagogue
We arrived in the Jewish Quarter of Krakow and walked to the Isaac Synagogue, which is over 300 years old and now a museum. We all davened minchah there and Chaim Lauer spoke of his feelings and mentioned the Song of the Day for Wednesdays. Then one of the Rabbis, a survivor, I think it was Moskowitz, spoke of his feelings, of how all Jewish buildings would someday be in Israel. He quoted off the wall on which fading words were written from the Midrash.
He urged us to experience and capture a moment. We then sang Kol Haolam Kulo, which was written in Krakow, and returned to the bus.
The Isaac Synagogue was built in 1644 in the Kazimierz district of Krakow. The synagogue was funded by Isaac Jakubowicz, aka Isaac the Rich, who is buried in the Remuh Cemetery. The Gestapo destroyed the interior of the building during the war, after which it was used by a theater company, an exhibition space, and ultimately renovated. I cannot recall the details of who allegedly wrote Kol Haolam Kulo in Krakow allegedly. The words are based on a quote from Reb Nachman of Breslov. I believe the composer of the tune we sung was Shlomo Carlebach.
Spending some time working on integrations. Specifically, integrating data from my home automation systems into my website. In previous iterations, I have added support for weather to posts…but not directly from my own weather station. Added support for location, but not directly from my own phone’s location.
I am trying to decide how far I want to go. For example, in addition to actual coordinates, I have a property for my location that allows for the following options: At Home, Just Left Home, At Work, Just Left Work, Just Arrived Home, Away, and Extended Away. do I want to actually identify where I am, either with granular or general location just because I can? Or do I just want to add context to a post when I’m saying something else.
There are lots of other integrations I’m looking to do, for various reasons. There is a lot of data I’d like to store in my site that you won’t be able to see, for historic and future purposes.
This is a problem people may have solved on other sites, but I’m trying to solve it for myself. Especially since anything I post on my site is syndicated elsewhere.
Aaron Parecki (Aaron Parecki)
