This content isn't visible to code executing over there on Wikipedia.

One concern I have is that this setup is vulnerable to cross-site request forgery.

Specifically, if a content provider doesn't validate the passed origin against a whitelist (which I'm assuming that in general you'd hope they wouldn't, in order to allow any clients to access the content opportunistically) then this protocol allows anyone anywhere to stick an iframe in their page which retrieves and stores access tokens for later use.

Of course, the difficulty here is that the line between a legitimate IIIF-compatible client and an attack is very blurry. Indeed, wanting arbitrary IIIF clients to be able access resources from arbitrary content providers is in direct tension with preventing this sort of attack.

The core of the problem is that the cookie lifetime is assumed to be the only limit on how and when someone can get a new access token. But cookie lifetimes are often very long indeed. In a more conventional setting, you'd arrange for the client to send some kind of CSRF-protection token with cookie-authenticated requests, where the CSRF lifetime is bound to the lifetime of the session, which can be decoupled from the lifetime of the cookie (by, for example, requiring that the session is kept alive by visits to the auth service). The goal would be to be able associate a specific access-token retrieval with a specific user action, such as a login or clickthrough as you've defined above. But that doesn't address questions of how this would work for kiosk or external mode.

<hobbyhorse>Given we're passing long-lived credentials around in HTTP bodies, I'd be inclined to make this a requirement of the specification, much as OAuth 2.0 requires TLS.</hobbyhorse>

Unless you have a good reason not to, I'd be inclined to make the response format compatible with the OAuth 2.0 token response format, which would imply lower_underscored names rather than camelCase names.

Granted, if this makes the response format inconsistent with other JSON responses that are part of the IIIF specifications, then maybe this isn't the greatest idea.

This isn't true for session.close() — only .commit() will explicitly commit, whereas .close() will issue a ROLLBACK before returning the connection to the pool.

Every single one of these is just about mapping some user input to a user object.

As mentioned above, we can address this straightforwardly with a single function which knows how to map a string to a user object.

Right now, it is true that a userid with a non-hypothes.is domain part cannot be a valid userid. This code appears to be simply asserting that invariant.

Clearly, the work we're describing here is going to change that, so this code will need to change.

Our "userids" are RFC7565 account URIs.

Section 4 of that RFC deals with the scenario of usernames containing the at symbol, and requires that they be percent-encoded.

I think that if we have to deal with this (and we probably don't, at least in the near term) this is probably a better approach than allowing multiple literal '@' symbols in userids.

Just to emphasis again for anyone else reading this: this isn't necessarily true. We can impose whatever constraints we like on third-party usernames at this stage.

I think this is the right solution. Specifically, I think we should define two mappings:

1. From a userid to a "user display string", in which the users from the default authority (hypothes.is) get mapped to bare usernames, and other users to username@authority.
2. From a "user input string" to a userid, in which strings with an @ are assumed to be qualified username@authority strings, and other strings are assumed to be default authority usernames.

So, in the examples you've given, these would all be valid:

• /search?q=user:seanh
• /search?q=user:seanh@hypothes.is
• /search?q=user:snhmnd@elife.org
• /users/seanh/activity
• /users/snhmnd@elife.org/activity

👍

As mentioned above, this isn't necessarily true. We can simply say by policy that '@' is not a valid character in a username.

Yep. Good point.

We can restrict anything we like by policy. Of course we can't restrict what people send us in principle, but in practice we can: at least for now we have a direct relationship with our partners and can negotiate with them on what a valid username looks like.

hello

testy test

Hmm. Not sure this is going to work. npm doesn't seem to respect +... style version numbers.

We might have to go with incrementing integers like 0.31.0-dev.1, 0.31.0-dev.2, etc.

An apt description of the PDF file format.

Amazingly, this exact scenario is already described in some detail on tvtropes.org.

We are all shocked. Shocked!

It would be hard to overstate the difference this makes to the technical difficulty of the launch.

This is the most pitch-perfect parody of academic presentation style I've ever seen.

Annotating from test2.html.

I'm not sure this is a glitch so much as designed behaviour (although whether it is the correct behaviour is a different question -- IMO quite clearly not).

This page already has Hypothesis on it -- via the WP plugin. That plugin includes https://hypothes.is/embed.js on the page, which in turn adds a <link rel="sidebar" ...> tag to the page which the sidebar uses when it starts up.

The chrome extension also looks for this tag and is finding the production one first.

Good catch. It's not missing but it is served with the wrong mimetype, which is what's causing this issue.

We didn't implement this -- it's the browser's default behaviour.

The Chrome badge doesn't currently update in real-time. This was agreed as out of scope for the first version.

If you can come up with a minimal test case for this, that would be great, because it's a bug. I'm not able to replicate it locally at the moment.

Sorry, but I have no idea what this section is trying to say...

The problem here is that you were too clever :)

Instead of trying to create an unanchorable annotation through our API, you might want to create an annotation on a page you control and then change the content, as a user would experience it.

The issue is that you've created an annotation that isn't even returned by a search for the page you're on, because the "uri" field is legacy, and is now ignored in favour of the "source" field on individual targets.

hello, world!

My test annotation.

Test.

Seriously?

https://www.youtube.com/watch?v=HPPj6viIBmU

Performance matters! Even for malware.

ERK.

This seems like a bit of a leap of judgment on their part. An insider is not killed for failing, so two brand new outsiders won't be either?

Developer discovers bug in software that has to work otherwise he gets cement shoes. Shrugs and drives off.

Seems legit.

In general I'd get rid of many if not all of the "Other" fields. There are loads of free-text fields where people can put general complaints, but if you have lots of "Other" options you're just going to dilute the data you get from the other questions.

Ditto -- providing "Other" here is just going to mess with your data.

I reckon providing "Other" here is just going to mess with your data.

Gunner's form asks for the session that "offered you the most benefit", not for "which session you liked the most."

I think it's an important distinction.

This should surely be radio boxes not check boxes?

Get rid of the aggressive full-stop.

Get rid of the exclamation mark.

Is there any way this can be three <input> boxes rather than one big textarea? Current setup seems a bit daunting and you're more likely to get two or three items rather than one rambling screed.

Way too vague, IMO. What do you really want to know? If I Annotate is mixing shit up? If so, ask

Did I Annotate substantially change how you think about annotation? YES/NO/NOT SURE

We know this already from question 1.

This seems far too long to me. If you can get it down a screenful, people are far more likely to feel able to commit to filling out the form.

If you're unable to cut it down that far, I suggest making it very clear at the top of the form that every field is optional.

Engineering ladder -- a great set of descriptions of what it means to progress as an engineer.

Seems like an article worth reviewing when we dive into whatever changes need making to the fuzzy anchoring components.

And we're demoing Hypothesis.

So subtle you could easily miss it. This is a staggeringly important observation.

Programmers are smart, creative people. But when they channel their creativity into the software rather than the processes by which the software is created, they aren't working as a team, and that introduces risk.

Again, this seems like a minefield for legal interpretation. How does one determine when an administrator is creating a new dataset rather than modifying the existing one? Or, to be clear, exactly how much anonymisation/aggregation/sampling needs to be performed until the dataset is considered "disjoint" from the personally identifying dataset covered by the directives mentioned?

This poses a tricky problem for data administrators. Given the nature of digital information, it's not clear (to me, at least) if the directives currently in force require an administrator to consider possible advances in reidentification techniques.

Or, put more simply: is publication today which allows reidentification tomorrow considered responsible? What about today/next year, today/in ten years?

A highly problematic assertion if we don't know what we're counting as "anonymized." Luckily the relevant directive is strongly worded, defining anonymized data as that from which a "data subject is no longer identifiable," requiring that the data administrator consider

all the means likely reasonably to be used either by the controller or by any other person to identify the said person

Or, as Paul Ohm put it: "data can either be useful or perfectly anonymous but never both."

We should totally automate this step.