Editor, Joe Edelman
Abstract: New protocols and data exchange formats are presented to address issues in link recommendation and “feeds” relevant to users' social, location-based, and time-based situations. The aim is to create a broader, more inclusive, and more user-driven ecosystem around recommender systems and feeds. A new HTTP header ("X-Situation") is proposed, along with a cryptographic proof format ("application/relevance-claim+json") for content providers / activity providers to publish traffic and review data that establishes contextual relevance for use by recommenders. Political avenues for achieving adoption are discussed. One application regards an open web response to facebook newsfeed. (v0.3.3, parts still naive)
Empowering uses of the web—like Kickstarter and DIY.org—are growing fast, but television- and tabloid-like uses—YouTube, BuzzFeed—are growing even faster. Which will colonize more of humanity? In 2025, will more of us be working on creative projects, or watching youtube suggested videos? We like to pretend this is about human nature, but to a great extent what we do online is about what we see—about feeds and recommender systems, and whether they are accountable first to our desires for ourselves, or to advertisers and "engagement" metrics.
In particular, the example of television bears watching out for. Television is the story of powerful networks, powerful advertisers, mostly weak content providers, and extremely weak end users.
Avoiding such a fate for the Internet means being wary when points of algorithmic "curation" (or in TV parlance, "programming") appear which have millions or billions of people attached. Facebook's Newsfeed and YouTube's Suggested Videos are the clearest current examples, but there are many.
We need to make sure that the ecosystem around these recommender services is aligned with the true interests of the end-user. In particular, the following parties need to form more flexible and accountable relationships: (1) recommender systems and feeds like facebook newsfeed and google now, (2) "content/activity provider" websites that propose activities to users like youtube, meetup, and instructables, (3) review, rating, and engagement metrics providers like yelp, bitly, quantcast, the sharing sites, etc, and (4) the users themselves and their agents, like Chrome and Pocket.
We think it's possible to align the internet recommender ecosystem to the users' true interests, and we here present web client technology, standards, and open data solutions to this problem, with notes about the political means to create adoption. The key idea is that of holding recommendations/URLs/activities to a standard of high contextual relevance or meaning w/r/t an individual users' situation and desires for their lives.
It takes data to recommend meaningful activity. When we have little understanding of the users' actual situation and desires, or about how to contribute to them, we can only recommend popular links and "top picks." The internet becomes a popularity contest. In order to overcome this, we need: (a) a model of the context that users are in when they are using the web or apps, including location, social context, and their desires for their time; and (b) open information about what material is truly relevant to various contexts and people, rather than merely clickbait.
It is therefore of interest to devise both: (a) precise serialization formats for users' contexts and time-desires, and (b) cryptographically secure systems for proving that the data at a URL was reported helpful by one or more individuals in various contexts, insofar as this is possible.
These systems must be secure, given the incentive for URL owners and App providers to want their URLs, Apps, and App notifications to seem relevant in more situations than they really are. The user's time and attention is all that they have, and these proofs are its defense.
Currently, companies like Quantcast use demographic and psychographic information to predict what different people will reliably click on or purchase. We propose to use information about a users' situation and context to enable prediction (by third party recommendation engines, browser plugins, etc) of what different people will find to be time well spent. These systems are similar in structure and purpose, even to the point of involving some of the same inputs, like other users' clicks, views, and scrolls. We differ in desiring an ecosystem of open, secure data, competing recommender systems, user control, and a broad focus on self-reported lives well lived.
Most estimates of contextual relevance on the web are rudimentary, and don't necessarily establish that a link or notification was actually helpful. Nonetheless, it is of interest to ask how we could securely prove that the following rudimentary signals actually occurred for distinct humans in particular situations:
- user clicked headline
- user scrolled to headline and clicked
- user viewed/read/scrolled to bottom/watched to end
- user liked/shared/recommended broadly
- user bookmarked for later review
We would also like to encourage more sophisticated measures:
- user returned to resource intentionally
- user scheduled/invited/forwarded to friend
- user attended/used and reviewed positively
- user shared, reviewed, or forwarded after significant elapsed time
- user futuremarked (defined below)
- user explicitly reported as comparative Time Well Spent
Currently click and view data for websites can be a hoarded and valuable resource. Facebook, for instance, does not publish click data about headlines on newsfeed. Google doesn't publish which of its recommended links have long read times. Services like Alexa and Compete.com make only the broadest aggregate data available, and quantcast charges for it.
Websites that are in the public benefit, that are activity providers, or that already have high indirect traffic, may have an interest in publishing aggregations of their click, view, and review data in an open, secure format, if it means an increase in traffic from recommender systems.
We believe there is an opportunity to disrupt this closed-engagement-data situation with open data, standard formats, and client-side support for the production and verification of proofs of relevance. Recommender algorithms should have the widest possible pool of data on which to act, and activity-source sites like DIY.org and Meetup.com should be able to leverage their proofs of relevance in an open market of recommenders.
Proving that a particular click or a view duration occurred and involved a human in a self-reported situation is straightforward with the simplifying assumptions of client-side support, a trusted DHT database, and an agreed-upon identity system, and—like the Neilsen ratings—the data can be of use to millions even if it is initially only recorded by thousands. It makes sense to start with cryptographically secure claims of relevance made by a small number of early adaptors that auth into a trusted system, and gradually relax these constraints.
We are exploring how to aggregate this information for exchange in an anonymous but cryptographically verifiable form. We are optimistic about an approach using homomorphic encryption.
The issue of how to get the highest possible relevance signal from a single user bears some consideration. Clearly we sometimes read entire articles or watch entire videos that, if given a redo, we might choose to have skipped.
Indeed, at least in retrospect, we evaluate time choices on the margin and in relation to opportunity costs. If we discover that another event was going on or discover a new hobby, we might suddenly come to regret time choices we made in the past, before that discovery.
The only time choices that are safe from this kind of downward reevaluation are those where the comparison is done at the time of review, and for which the reported value of the time-choice is high enough as to dwarf the search costs and expected outcome of further comparison. These are the activities that are Time Well Spent, in an absolute sense.
While this may seem like a high bar for web activities, the truth is that activities which meet this criteria abound: many of our most treasured time-choices are reported as comparative Time Well Spent: time with our children, camping with best friends, a good cry, a quiet moment sipping tea and writing in one's journal... these kinds of activities are reported as clear wins even in a broadly comparative context.
Only by supporting these strong proofs of relevance can we hope to bring web use up to this standard.
There are many kinds of link relevance. Advertisers on facebook use demographic and psychographic information together with the users' likes and their friends' likes to pick links to display. Newsfeed itself uses recent behavior of friends together with general engagement metrics like the ones we propose above. Google uses keyword searches both for advertising for its main results page, together with a raft of engagement and other trust metrics.
All of these user-specific measures have biases: keyword search is biased towards directed, intentional actions, especially research and purchases. Activities and URLs that are not about directed research or purchasing will see lower incidence of recommendation because search engines do not have information about other aspects of situational context. Recommendation based on friends' activities is biased towards "the news of the day" and away from anything individual or directed. Recommendation based on demographic and psychographic information is biased towards least-common-denominator exploitation of human interests or susceptibility.
After a year of experimentation with over 3000 subjects and a variety of different situational framings, we have settled on a framing based on neighborhood-level location, sociographic information (e.g., information about friends' availability, proximity, and willingness), and a small set of keywords we call time-desires, which capture what most people want to fill their lives with (e.g., "quality time with friends and loved ones", "learning", "time outdoors", "exercise", "quiet time", "creative projects", and "the unknown").
The situation descriptor we're proposing is small enough to be used as an HTTPS header or forms autofill field, and can answer questions like:
- Is the user out on the town, if so, what neighborhood?
- Are they with, or do they wish to invite, a friend?
- How much free time do they have?
- What kinds of activities and friendships are important to them this week?
- Are there certain interests or skills they specifically wish to follow or learn about this week?
For example:
X-Situation: sfo art time_with_friends:3h,0.4,0.2
(in SF, wants to spend time with friends, has an interest in
art, has a close friend they often do things with)
Many websites and startups are underrepresented in newsfeed and elsewhere because of the current lack of accountability and good data in recommender systems. Meetup, EventBrite, DIY, Instructables, Skillshare, CouchSurfing, and many more companies would see greater traffic if recommender systems like newsfeed were able to provide highly contextually relevant results.
There are also underdog recommenders, like Google Now and Twitter Discover, that have an interest in differentiating their suggestions from those of newsfeed and youtube suggested videos.
Finally, there is a growing consumer awareness movement about internet addiction, too much time staring at our devices, and the need to switch off to turn on.
We believe the time is right for an alliance that creates the kind of open data and interoperability that will help users in the long run.
We're gathering a community with experience in web standards, crypto, etc to improve this spec. There's a twitter account you can follow and a google group you can join. This doc is on github, so send a pull request with your changes.
Thanks (so far) to Colleen McKenzie and Will Brown for detailed feedback and notes. And thanks to Tristan Harris, Bret Victor, Tom Chi, Jonathan Harris, Aza Raskin, and Dan Mosedale for motivating and clarifying discussions.
When a URL-addressed resource is first published there will be little or no review information about it, and recommender systems will not be able to make a decision based on proofs of relevance. It is therefore advisable for page authors to be able to provide hints to recommenders about which situational contexts their resource is relevant to.
"Doables" is our name for a small metadata vocabulary with which an HTML5 page can be marked up (via the <meta> tag) or a region on a page can be marked up (using microdata's itemtype= and itemprop= attributes) as containing an activity which might be recommended in certain situations.
A page or a page region that specifies an activity has a basic type (using the schema.org or Open Graph vocabularies for things like "book", "video", "game", "event", "creative project" etc). It also has:
- a set of verbs (a how-to video can be "viewed" or "done")
- for each verb, a set of situations in which it might be appropriate; for instance, when the user has 5 minutes available for learning, or when they are in SF looking for sunshine
- optionally, further instructions, durations, and facilitating URLs for each verb
Example Format:
<meta property="og:type" content="music.song" />
<meta property="doable:listen:takes" content="3 minutes" />
<meta property="doable:listen:recommend_for" content="downtime" />
There is an open question as to which client-side app might take on the challenge of organizing situational, context-aware browsing. One possible direction is that time-management interfaces like Pocket / Google Keep / Reading List take some of the burden off the web browsers.
The futuremark standard combines "read it later" / Google Keep / Pocket / Reading List type uses with aspirational calendaring ("I want to run 3x/wk") and traditional calendaring, and provides these services with a common URL scheme.
A futuremark is like a bookmark, but is reserved for things the users has said they really want to fill a part of their life with. Futuremarks can be generated by applications and websites for anything the user may wish to resume (e.g. planning a trip, writing a document), periodically reschedule (e.g., yoga classes from a provider), or periodically re-engage with (e.g. exercise suggestions).
Example Format:
futuremark://exercise?
suggestions_url=http://www.yelp.com/search?find_desc=exercise+park%26find_loc=%%
&suggestions_desc="Suggestions from Yelp for Parks to exercise in"
&image=http://example.com/images/runner.png