blockstack-browser
blockstack-browser copied to clipboard
stacks-archive
More reliable social proof method
Proposal for making social proofs less likely to break
Problem
- We perform strict DOM parsing on social website pages that are almost guaranteed to change and break our code over time.
- When a social website does change and break our code, its broken for everyone until we get a fix rolled out.
- Our parsing code must be strict (and prone to breaking) due to social websites allowing comments/replies which can be attack vectors for faking proofs.
- Misaligned incentives: these large social platforms purposefully perform DOM obfuscation for the purpose of fighting adblockers, and thwarting web scraping done for various nefarious reasons such as spamming, gray market data analytics, development of unauthorized scraping-based APIs, etc.
- Non-purposeful DOM obfuscation occurring as a result of using common web tooling that generate dynamic class names, arbitrary elements, minification, etc.
Solution
Use the embeddable/iframe urls.
- These are embedded in countless 3rd party websites with specific sizing and display layouts. The social platforms are less likely to make drastic changes to the structure of these pages.
- These pages do not contain comments/replies which allow us to perform much more fuzzy/resilient parsing.
Implementation
We should not have to change any design/UX in order to get at these embeddable post URLs.
The user follows the existing instructions, pastes in the same URL, and the browser code performs the DOM parsing to get the iframe src url, and stores this new url in profile.json.
This DOM parsing is is just as brittle and breakable as existing code, however, it only needs to be performed one time when the user does a social proof setup.
These means that when a social website changes its DOM and breaks our code, the only consequence is that new social proof setups are broken until we get a fix out. This is much better than a social website proof breaking for everyone until we get fixes rolled out.
We should of course maintain backwards compatibility with existing social proof URLs by storing these new ones in a new field in profile.json.
As a bonus, during a browser update, it could automatically perform work to upgrade the old urls to the new urls.
Related https://github.com/blockstack/blockstack-browser/issues/1779
Ping @kantai @hstove @yknl for discussion
I think this would work great for some of the social media accounts.
The user follows the existing instructions, pastes in the same URL, and the browser code performs the DOM parsing to get the iframe src url, and stores this new url in profile.json.
The embed iframe src URL might not exist in the DOM. This is the case with instagram posts. The iframe src is generated dynamically.
Another issue is that for link formats that don't include the username, DOM parsing is still needed to retrieve the username for verification.
It looks like with instagram there is a directly derivable iframe embed endpoint:
https://www.instagram.com/p/{postID}/embed/captioned/
But yeah some of the sites I'm sure will not be so straightforward.
link formats that don't include the username, DOM parsing is still needed to retrieve the username for verification.
I think most of the endpoints will not include the username. But the DOM parsing to retrieve it can be much more fuzzy than existing method. Essentially the only requirement is verifying that the username is not contained within the caption/post string (to prevent faking proofs).
For many end points this is probably as simple as checking if the <head> contents contain the username.
