bokand/web-annotations

web-annotations's Issues

Blocking annotations by origin feels like CSP

Is there a reason this aspect of the problem shouldn't be solved with Content Security Policy, which already provides great ways of limiting the origins which can be used to fetch subresources (which it feels like these functionally are)?

This document is annotated! (Evaluators should be aware.)

As shouldn't be a surprise to anyone, this document, which proposes support for annotations, is itself annotated. For those unfamiliar with the idea of annotation, and for those wishing to see how others have annotated it, I suggest that you follow this link which, in many browsers, will allow you to see the annotations made using the Hypothes.is annotation system even if you don't have an account for that system.

I would like to suggest that the document should be updated to notify readers of at least the Hypothes.is annotations and also to suggest that links to annotations made with other systems should be provided as responses to this issue.

Ideally, any annotation browser support that may grow from this effort will support existing open standards. As mentioned elsewhere, the relevant standards appear to be those defined by the W3C Web Annotation Working Group.

Explicitly list the creator/consumer groups intended

This is a super-interesting space to play in, but exactly who is publishing what to where drastically changes many aspects of it, from the content model to privacy considerations to abuse potential. We should explicitly figure out what groups we're addressing, and how. I've given this a little thought, and initially identified five possible broad groups which each have distinct models:

1: Website -> Public

This is basically "footnotes for the web". People have dabbled in this area for decades but never gotten far enough to be a serious effort. It's pretty high value, imo, but very difficult to do right. There's significant a11y considerations, and form-factor issues-- the ideal display for a footnote is completely different for a desktop, a phone, and a printed page. Browsers doing the heavy lifting here, with a clear semantic role and linkage, and default display customized to the form-factor, could bring a lot of value to what is currently a drastically underserved space.

Privacy and abuse potential is nil here; this is identical to any other content on the page.

The hardest part here will be figuring out how, and how much, pages are able to style their footnotes from the default. Likely this'll involve some work with OpenUI for specialized opt-ins that let the page take over displaying when they want to.

1A: Small Group Blessed By The Website -> Public

This is a possible blending of (1) and (4), where a website can bless a public annotation source as applying to their page by default. Example would be articles with commentary from staff.

Theoretically this is handleable by just giving everyone access to the CMS (at which point it collapses to (1)) and that might be sufficient (or relying on CMSes to integrate the ability to consume annotation sources and bake them in). It might also be handleable by just letting the site ask users to subscribe to a public annotation source they point to. But if we have annotation controls exposed by the browser to let users show/hide annotation streams individually on a page, I think it makes sense to let a page request an annotation source in their metadata, and possibly toggle it on or off by default.

2: Personal -> Personal

Private notes for personal use, attached to some notion of browser identity and available cross-device via browser sync. I've wanted this for a long time: leaving notes on people's Twitter profiles about why I followed or blocked them; leaving notes on tech articles about what worked or didn't; etc.

Theoretically this can be (and is) done via extensions today, but it's problematic in several regards:

1. Notes are either stored on-device, losing cross-device sync, or they're stored on servers controlled by the extension, losing privacy and gaining a dependency on the company surviving (which has a pretty bad track record; every reference on the Moz wiki page is now dead).
2. Not available on all form factors; extensions don't work on mobile, where people do most of their computing.
3. Requires giving the extension read/write access to every page, which is a huge abuse vector.

Abuse potential is nil, since it's self-generated and self-viewed, equivalent to just taking notes on a notepad next to the screen. Privacy is nil beyond the existing browser-sync privacy issues.

3: Small Group -> Itself

Examples include spouses sharing notes with each other, study groups annotating info pages, moderation groups in a community leaving notes to each other on particular pages/users, etc.

If this is opt-in, direct abuse potential is nil, similar to any group chat. You'll join groups with people you like, and can leave whenever you want if they get abusive.

However, the design must ensure the list is private with approval; anyone who knows your email address (or whatever identifier) shouldn't be able to sign up without notice. This, then, means you have to be careful not to create a new communication channel in the form of invites and/or join requests, because every comm channel will be used to spam and abuse. Possible idea is silent double-approval, where both an invite from A->B and a request from B->A must be received, with no notice of either, and only when they both exist is the invitation auto-approved.

There's some additional UI challenges here, because people creating notes will want to be able to swap whether a note is personal, or in a given group. Also, when you see a note you'll need an indication of what you're seeing it from.

Also, maintaining the groups is probably something browsers or other identity providers would have to take on for themselves, with at least a little community management (designating some people as capable of giving invites, others as capable of adding notes, and others as just readers). Doable, just needs some careful work.

I suspect this is the hardest group to target, overall, but it's valuable and deserving of thought.

4: Small Group -> Public

Examples include extensions like Shinigami Eyes (annotates transphobic twitter accounts), fact-checkers, etc.

Mode here is fully public - anyone can subscribe without approval if they know the URL or whatever.

This is, essentially, just RSS. We don't have to do any management ourselves, we just have to know how to consume annotation feeds and display them. We might actually want to use RSS as a bare-bones transfer format, but probably also want a more efficient format with better delta updates, as these can easily be enormous feeds.

Abuse and privacy are nil; they're exactly equivalent to an RSS feed you can choose to subscribe to or leave. Anti-abuse mechanisms on the public web are usually somewhere between "shitty" and "non-existent", but this isn't a new vector in any significant way.

5: Public -> Public

Notes left from the arbitrary public to the arbitrary public.

In short, don't. This is a horrific abuse vector that we can sink infinite money into and never get a proper handle on. It is impossible to moderate. We must not try. See #1 for more details on why this is impossible and deeply damaging when we inevitably fail at it.

---

These are all the basic usage scenarios I've been able to come up with so far. They're likely not complete.

Design for the Worst People

Hi, sorry if this isn’t the preferred way to raise concerns, but I didn’t see a contact address. I want to very, very strongly encourage you to consider from the outset the ways people can use this in horrific ways, and either find ways to prevent that, or else abandon the idea entirely.

When I say horrific ways, here are just a few scenarios — there are many, many more that could be posited.

• A company site is targeted by a vengeful ex-employee.
• An ex-employee’s site is targeted by a vengeful company/boss.
• An abusive stalker finds out the focus of their obsession has an anonymous blog. They immediately start annotating it with attacks, threats, etc.
• A political commentator comes to the attention of the worst of 4chan/8chan/whatever, which immediately starts a brigade to annotate their sites/articles/etc. with doxxing information, verbal abuse, links to or images of child pornography, and more.
• What will very likely happen to the web sites of political figures, especially those who are especially divisive, or are seen to be by their opponents.
• See previous, but for political dissidents.

It’s not enough to say “site authors can just turn off the annotation endpoints”: they may use a platform in the style of Wix or Substack, one which might automatically enable annotations without notice, and without making it possible/easy to disable them.

Furthermore, a site may persist long past an author has access to it. Think of all the Blogspot and LiveJournal accounts that were available for years after the creator lost interest. Annotations might be enabled in that post-interest phase, and then become the target of a brigade, with nobody available to deal with them.

None of these should be problems if annotations are entirely private in nature; that is, if annotations are notes a user can make for themselves that only they will ever see. As soon as you open this to others being able to see annotations, whether that’s the site maintainer or other users of a site or both, the social attack surface becomes enormous, and there is risk of real human costs, up to and including lives.

A suggestion - Sub Resource Integrity hashes for Web annotations.

Not necessarily something that needs to be in the first version of a web annotation feature, but I think it would be good to optionally include something equivalent to, two Sub Resource Integrity hashes. One for the section of content you are linking to (maybe including a CSS Selector to specify the specific content or just using the text fragment feature) so the annotation link can verify the content the annotation being loaded for is the same content the annotation was made for.
As an example, this could help with situations where a positive annotation on a product page could be miss used by the site owner switching the product for a different product.
If the hash verification fails when the site loads a report could be returned to the annotation site if the annotation was not completely embedded in the annotation link. That way the site serving the annotation data can also learn when Annotation links are no longer valid.
The second hash would be to verify the annotation being loaded is the annotation that was expected. This way it the site owner is embedding a specific annotation the site loading the annotation could also verify that the annotation it is loading for its users is the same annotation the developer has seen when testing, and prevent any possibility of the annotation site switching annotations with advertisements, based of the requester.