Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redesign forms, verify link ownership with rel="me" #8703

Merged
merged 11 commits into from
Sep 18, 2018

Conversation

Gargron
Copy link
Member

@Gargron Gargron commented Sep 16, 2018

Summary:

  • Redesign forms to
    • Make better use of space horizontally
    • Use labels instead of placeholders
    • Add quick navigation to preferences page
    • Reorder site settings thematically
    • Improve how settings pages look on mobile
  • Add link ownership verification via rel="me"

How does link verification work? When a profile is updated, the local as well as remote servers (independently) check the links for the presence of a link-back with rel="me" attribute to the user's profile. If so, a timestamp of the check is saved.

Why is rel="me" required? Because intent matters. It is much easier to sneak a plain link on someone's website. For example, in a WordPress comment, or through a Mastodon boost, or a Tumblr reblog. However, custom rel attributes are usually not allowed in those. On the other hand, profile links set by the owner of a page can and do contain this attribute.

What does this give us? This is not a silver bullet. Nothing beats checking someone's government identification documents. However, that approach is closed off to federated platforms. It would not scale if done properly, it would be awful for privacy, and the most naive approach would be subject to trivial spoofing. So, this is the next best thing. If you have a personal website that people know is official, proving the ownership of that site is the same as proving your identity.

Why aren't you using DNS cryptography? An HTML link is the lowest possible barrier to entry. Editing DNS and messing with public keys would exclude a lot of, if not most non-technical people, and as such I do not consider those approaches worth the implementation time right now.

References:

To some extent:

Verified links:

image
image

Forms redesign:

image
image
image
image
image
image
image
image
image
image
image
image

@Gargron Gargron added the work in progress Not to be merged, currently being worked on label Sep 16, 2018
@Gargron Gargron added the ui Front-end, design label Sep 16, 2018
@lfuelling
Copy link
Contributor

lfuelling commented Sep 16, 2018

A TXT record for alternative verification would be nice. For example I wouldn't like having to add a link to my profile on the index of my GitLab instance and stuff like that.

Verifying multiple profiles is already possible with the current method. There should also be a way to confirm one link with multiple accounts using DNS. (comma separated links?)

@Gargron
Copy link
Member Author

Gargron commented Sep 16, 2018

The complexity with doing DNS verification comes from the fact that each link needs a special verification string, so the field must be saved before that string can be given to the user for copypasting, which means the actual verification must be done in a yet another step (+ wait for DNS propagation)

Don't forget that each server must verify on its own. I don't see how the user could have any control over when the checks happen, currently it's just tied into when the profile has been updated.

@ClearlyClaire
Copy link
Contributor

DNS verification could work in a similar fashion, listing domain or URLs to be honest. Although we probably want to check what kind of standards or proposed standards there already are for this.
A small issue I have with that scheme is that the info could get outdated. This is partially addressed by the title displaying the time at which it was verified, but this is not directly displayed. Furthermore, I see no place where that verification is renewed?

Another minor issue I have with this is that this requires you to basically advertise your other identities everywhere, while someone may want to have only one-way verification (e.g., I may have a “private account” that I don't want to advertise to other people, but that I want to verify as being the private account tied to my public account).

Finally, I would also extend this to @-mentions and allow to declare other identities in Mastodon itself. But that could be done in a subsequent PR!

@sivy
Copy link

sivy commented Sep 17, 2018

I think this is a pretty good solution! Not complicated UI-wise, and doesn't require the user's browser to do the validation work.

@sivy
Copy link

sivy commented Sep 17, 2018

@Gargron: how does the link verification get triggered?

@sivy
Copy link

sivy commented Sep 17, 2018

"ownership of this link was checked..." might be better as:

Ownership of the linked site by this user was verified on [date]

with the negative case being:

Ownership of the linked site by this user could not be verified as of [date]

Alternatively, no messaging on unverified links might also be better, so that no negative connotations are applied to links that are not intended or desired to be verified. Perhaps a checkbox representing "this is me, please verify" ("I own this site" ?) to signify verifiable links? could also cut down on effort verifying non-verifiable links.

I'm still not sure what I think about using "verification" language in this feature, given the baggage it carries from birdsite, but it is terminology that users understand.

@Gargron Gargron removed the work in progress Not to be merged, currently being worked on label Sep 18, 2018
@Gargron Gargron changed the title Verify link ownership with rel="me" Redesign forms, verify link ownership with rel="me" Sep 18, 2018
def link_back_present?
return false if @body.empty?

Nokogiri::HTML(@body).xpath('//link[@rel="me"]').any? { |link| link['href'] == @link_back }
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the XPath read //link[@rel="me"]|//a[@rel="me"]? The copy you've written mentions <a rel="me" but this won't match that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My bad, it should be a instead of link, not sure if link is worth checking at all, that would be a real rarity

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True, both link and a are valid for rel=me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I initially thought it was a “link” attribute and not a “a” attribute. Can't find the spec (if any) right now, but if link's in it, you should restore it, even if it “would be a real rarity”.

@Gargron
Copy link
Member Author

Gargron commented Sep 18, 2018

@ThibG Okay, both anchor and link tags will be checked.

@Gargron Gargron merged commit f4d549d into master Sep 18, 2018
@ykzts ykzts deleted the feature-verified-links branch September 18, 2018 15:17
Gargron added a commit that referenced this pull request Sep 18, 2018
Gargron added a commit that referenced this pull request Sep 18, 2018
* Fix performance regression in Account::Field#verifiable?

Regression from #8703

* Fix code style issue
Gargron added a commit that referenced this pull request Sep 18, 2018
UX-wise, people expect that saving the profile will re-check links even without changing fields content. Bug-wise, `@account` was undefined.

Regression from #8703
Gargron added a commit that referenced this pull request Sep 18, 2018
UX-wise, people expect that saving the profile will re-check links even without changing fields content. Bug-wise, `@account` was undefined.

Regression from #8703
koppepan1204 pushed a commit to koppepan1204/mastodon that referenced this pull request Oct 10, 2018
* Verify link ownership with rel="me"

* Add explanation about verification to UI

* Perform link verifications

* Add click-to-copy widget for verification HTML

* Redesign edit profile page

* Redesign forms

* Improve responsive design of settings pages

* Restore landing page sign-up form

* Fix typo

* Support <link> tags, add spec

* Fix links not being verified on first discovery and passive updates
koppepan1204 pushed a commit to koppepan1204/mastodon that referenced this pull request Oct 10, 2018
* Fix performance regression in Account::Field#verifiable?

Regression from mastodon#8703

* Fix code style issue
koppepan1204 pushed a commit to koppepan1204/mastodon that referenced this pull request Oct 10, 2018
UX-wise, people expect that saving the profile will re-check links even without changing fields content. Bug-wise, `@account` was undefined.

Regression from mastodon#8703
koppepan1204 pushed a commit to koppepan1204/mastodon that referenced this pull request Oct 12, 2018
* Verify link ownership with rel="me"

* Add explanation about verification to UI

* Perform link verifications

* Add click-to-copy widget for verification HTML

* Redesign edit profile page

* Redesign forms

* Improve responsive design of settings pages

* Restore landing page sign-up form

* Fix typo

* Support <link> tags, add spec

* Fix links not being verified on first discovery and passive updates
koppepan1204 pushed a commit to koppepan1204/mastodon that referenced this pull request Oct 12, 2018
* Fix performance regression in Account::Field#verifiable?

Regression from mastodon#8703

* Fix code style issue
koppepan1204 pushed a commit to koppepan1204/mastodon that referenced this pull request Oct 12, 2018
UX-wise, people expect that saving the profile will re-check links even without changing fields content. Bug-wise, `@account` was undefined.

Regression from mastodon#8703
@ChameleonScales
Copy link

ChameleonScales commented Nov 14, 2018

How long should we expect the ownership verification to take effect?

@ChameleonScales
Copy link

ChameleonScales commented Nov 14, 2018

Ok, so I deleted my link, saved, re-added it and re-saved and the green highlighting appeared instantly.
So I guess it only works if you add the link in your profile settings after you've added the rel="me" link in the website.

@tasn
Copy link

tasn commented Jul 22, 2019

I think it would be a good idea to add a 2-hop check?
What do I mean?
If a page has rel=me pointing to another page that's not a mastodon account, check if that page has rel=me to the mastodon account.

Use case?
Many websites such as Twitter and Github mark your homepage as rel=me and only let you add one such link to your profile. This means a Mastodon user looking to verify their Github page would need to change the e.g. Twitter URL to their mastodon account (instead of e.g. their home page) which is undesirable.
However, with the suggested change people can keep these links pointing to the user's website and have verification work.

I've encountered this issue with EteSync. Relevant links to see what I'm talking about:
https://www.etesync.com
https://mastodon.social/@EteSync
https://github.com/etesync
https://twitter.com/EteSyncHQ

@Gargron
Copy link
Member Author

Gargron commented Jul 22, 2019

@tasn I suggest opening a separate feature request for this!

@tasn
Copy link

tasn commented Jul 22, 2019

Done. #11391

Sorry for the noise.

yumetodo added a commit to yumetodo/mastodon that referenced this pull request Mar 1, 2020
Conflicts:
	Gemfile
	Gemfile.lock
	app/javascript/mastodon/features/compose/index.js
	app/serializers/initial_state_serializer.rb
	app/views/about/_registration.html.haml
	app/views/admin/settings/edit.html.haml
	app/views/auth/registrations/edit.html.haml
	app/views/shared/_og.html.haml
	config/initializers/omniauth.rb
	package.json

Look at f6df9d0 .
The diff is too difficult to read however,
in file app/views/auth/registrations/edit.html.haml,
`simple_form.labels.defaults.password` was suddenly replaced to
`simple_form.labels.defaults.new_password`.
This can be proved by this file on ef27a0b
which is a parent commit of that.

However, this replacement has been continued for about 3 years.
And there is no significant difference.
So, I decided not to recover this replacement.

ref:
- 1cd0497
- increments#8
- f4d549d
- mastodon#8703
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ui Front-end, design
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Verified users Redesign forms Per-instance verified users/checkmarks No URL in profile
8 participants