Compact IRIs and URI schemes (not security)

[azaroth42]

As an email address is a URI, it would be @type:@id in the context.
If I define mailto as a prefix, I can manipulate the intended URI in the data. Whether that is for malicious purposes or not. Equally, content, icon, data are all URI schemes.

For example...

{
  "@context": {
    "mailto": "http://my.email.stealing.service/thanks/",
    "email": {"@id": "foaf:email_address", "@type": "@id"},
    "Person": "foaf:Person"
  },
  "@id": "http://person.org/",
  "@type": "Person",
  "email": "mailto:person@person.org"
}

I know the answer is "don't do that then" ... but ... could we extend the benefits of @protected to cover explicitly NOT defining a term:

{
 "@context":
  {
    "mailto": {"@id": null, "@protected": true}
  }
}

Then contexts could protect the definition of URI schemes they expect to encounter in their data, without wholesale collision prevention of banning every scheme.

(From discussion between @azaroth42 and @kasei)

[gkellogg]

Perhaps we could define a term with a null @id which was protected, which might work. But, to save from an injection attack would require defining all schemes as null.

It might look like this:

{
  "@context": {
    "mailto": {"@id": null, "@protected": true},
    "email": {"@id": "foaf:email_address", "@type": "@id"},
    "Person": "foaf:Person"
  },
  "@id": "http://person.org/",
  "@type": "Person",
  "email": "mailto:person@person.org"
}

The IRI Expansion algorithm would probably need a tweak to detect this. Of course, without changing anything, you could get the same effect using the following:

{
  "@context": {
    "mailto": {
      "@id": "http://my.email.stealing.service/thanks/",
      "@protected": true,
      "@prefix": false
    },
    "email": {"@id": "foaf:email_address", "@type": "@id"},
    "Person": "foaf:Person"
  },
  "@id": "http://person.org/",
  "@type": "Person",
  "email": "mailto:person@person.org"
}

[gkellogg]

Actually, that might not affect IRI expansion, but if we used @rubensworks interpretation, it might, and the expense of backwards compatibility. But, using @protected (and @prefix) requires @version: 1.1, so we should be free to define behavior here.

[azaroth42]

@prefix: false, @protected: true would mean that the term can never be used as a prefix, right? The actual @id is irrelevant, as it will never be expanded (unless it's used as a property). That might be sufficient, as the restrictions could be defined in scoped contexts, so as to not pollute the global space for things like icon or content, but protect them where they are used as a URI scheme.

{
  "@context": {
    "email": {
      "@id": "foaf:email_address",
      "@type": "@id",
      "@context": {
        "mailto": {
          "@id": "http://never.used.uri",
          "@prefix": false,
          "@protected": true
        }
     }                                  
  }
}

[gkellogg]

Currently, it would mean that it can’t be used to create a Compact IRI, but would still be used when expanding. In 1.1 mode, we may want to change that.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

Compact IRIs #177
Rob Sanderson: link: #177
Rob Sanderson: if you define a term that’s the same as a URI scheme
… then you’ll have problems
… so there are schemes that are very likely to be used in values
… like mailto: which could be high jacked in this scenario
… we could fix this by being able to protect URI schemes that are in use
… by making it possible to set certainly ones to null
… so, for instance, you could also set them within certain properties–like foaf:mailbox
… and then protect them to keep upstream ones from overriding mailto:
… so this means we don’t need to put all possible URI schemes in the spec
Dave Longley: not enough time to consider it :/
Rob Sanderson: and context authors can limit the damage to specific spaces where it could be damaging
… so, something to think about over the week

[dlongley]

Another option to consider could be a mechanism by which to say "no prefixes"/"no CURIEs" in the instance data (they can only be used in the context). Or an option such that prefixes may only be used when expanding with the vocab flag set to true (wouldn't this cover the above mailto: case at least since it is expanded using a base mapping not any vocab one?). Anything with a : in it (in the appropriate places) would be interpreted as an absolute IRI instead.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: If <code>@prefix:</code> false works, then we can turn 177 into a best practice. If not, then 177 becomes an issue to improve <code>@prefix</code> to allow it.
• ACTION: test if <code>@prefix:</code> false without <code>@id</code> works as expected (Pierre-Antoine Champin)

View the transcript

3.2. Compact IRIs and URI Schemes
Ivan Herman: #177
Rob Sanderson: we discussed this a few weeks ago, but only to point of introducing the issue.
… hopefully people have thought about it
… the issue is that IRI schemes that don’t start with // are seen as compact IRIs
… e.g., icon:… is seen as a compact IRI not a full IRI
… we could define these as undefined (rather than a prefix)
… this approach adds a little security without banning all non // schemes
Ivan Herman: I don’t fully understand - so in your example in the issue, what’s the role of protected
Rob Sanderson: avoids someone stealing the meaning of prefix (e.g., mailto:)
Benjamin Young: the goal is to allow continued use of these kinds of IRI prefixes
Rob Sanderson: having it in the context seems a good solution since it allows you to specify only the scope where you use the scheme rather than everywhere
Benjamin Young: yes, it is good to scope this
Pierre-Antoine Champin: it seems to me the protected approach would not be very efficient
… I’m not sure I fully grasp the use cases, but it seems you still get around protected
… the only way to really protect against redirection of mailto: is to protect the individual properties (e.g., email)
Rob Sanderson: so you say that email values not to be expected
Pierre-Antoine Champin: not sure this requires anything additional since we already have prefix
… seems a matter of best practice
Ivan Herman: in the example you have two approaches nul and prefix=false
Rob Sanderson: probably prefix=false, this works well since we already have prefix
Ivan Herman: do we?
Rob Sanderson: issue 76
Rob Sanderson: ref;: w3c/json-ld-api#76
Pierre-Antoine Champin: a more efficient protection would be { "email": { "@id": "http://example.org/emailAddress", "@type": "@id", "@protected": true, "@context": { "mailto": { "@prefix": false } } }
Rob Sanderson: proposal was made to add prefix with 3 allowed values (one of which would be false, as required by issue 177)
… the issue in doing this was that you need to have an @id, which is why we might still need @id null
… seems like we shouldn’t need that if prefix: false
… Pierre-Antoine, does prefix: false already sufficient?
Pierre-Antoine Champin: not sure
Ruben Taelman: doesn’t seem to work right now
Rob Sanderson: but maybe it protects against intentional mischief
… anyone willing to take action to verify that prefix: false does work or can be made to work?
Pierre-Antoine Champin: okay, put this action on me
Action #2: test if @prefix: false without @id works as expected (Pierre-Antoine Champin)
David I. Lehn: find it a little hard to understand the attack line here
… if we assume all contexts are a risk, seems a bigger problem
… protect should be more about extension and override
Rob Sanderson: we have run into this issue with regard to content being incorrectly expanded
Benjamin Young: not directly on point, but it feels like a lot of our issues have had to do with managing context intermingling
… we may need to zoom out a little
… while there are issues here it seems like its about trust of contexts, ownership of contexts, etc.
… this fragility that is still there is where we may have issues with security and privacy reviews
… I sometimes feel like we’re applying pressure to the wrong part of the ecosystem
… it’s not clear the role and motivation of the actors
… so maybe we need a broader view
… would not be an issue if you always trusted the context file you reference
Rob Sanderson: not certain about that. If you define mailto: you need to undefine it elsewhere in your instance
Benjamin Young: so this is partly about remixing within instance / context
Rob Sanderson: I think at least we need to determining how prefix: false works without @id or @id: null
… need to be able to treat these as resource IRI when you want to
Ivan Herman: I share bigbluehat’s concerns in a general way
… for this issue you are asking if prefix: false solves current issue
… since prefix is a 1.1 key, we need it to work as we want and so if it’s not working that way now, let’s make it work
Pierre-Antoine Champin: the questions becoming: is it possible (i.e. not over-complicated) to implement @prefix to work like this
Rob Sanderson: the action should allow us to do this
Pierre-Antoine Champin: i just realized during discussion we have already introduced redefining a term that looks like an IRI because no useful use case for doing this
… in a way this desire to limit prefixes that are sometimes used as schemes
… not clear how critical the use cases are
… may confuse users to say some IRIs cannot be anything else, but some could be compact IRIs in disguise
Ivan Herman: does this mean we should have a list of prefixes that are schemes?
Pierre-Antoine Champin: no, trying hard not to say that
… current rule is scheme://
… and this is clear cut, non-ambiguous
… it might be confusing to do this for non // schemes
Rob Sanderson: so our approach is to leave this to context authors rather than trying to maintain a universal list
… this will almost certainly come up in security horizontal review
… it would be nice to solve or improve it
… if prefix: false works, we’re done
Proposed resolution: If @prefix: false works, then we can turn 177 into a best practice. If not, then 177 becomes an issue to improve @prefix to allow it. (Rob Sanderson)
Rob Sanderson: +1
Ivan Herman: +1
Ruben Taelman: +1
Pierre-Antoine Champin: +1
Rob Sanderson: otherwise we have to improve prefix: false so it does work
Tim Cole: +1
Adam Soroka: +1
David I. Lehn: +1
Benjamin Young: +1
David Newbury: +1
Resolution #3: If @prefix: false works, then we can turn 177 into a best practice. If not, then 177 becomes an issue to improve @prefix to allow it.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

2019-06-07-action2: test if @prefix: false without @id works as expected (Pierre-Antoine Champin) #87
Benjamin Young: issue #87 w3c/json-ld-wg#87
Benjamin Young: born from #76 w3c/json-ld-api#76
Ivan Herman: original-original: #177
Benjamin Young: next two issues are related
Pierre-Antoine Champin: some background: it was possible to define certain URI schemes as prefixes
… leading to confusing them with the start of CURIs
… I tried to alter @prefix to avoid this
… but that turns out not to be possible
… . so @prefix must be accompanied by @id
… even if you accept ruben’s alteration, it is still not simple
… @prefix is only used during compaction as a hint to the algo
… but never it is used in expansion
… to block interpretation as a CURI
… so doing this with @prefix would radically change the meaning of @prefix, to add an effect during expansion
… this thing will come back and bite other people than us
Adam Soroka: .. users would expect @prefix to work both ways
Pierre-Antoine Champin: but that may have real effects on implementors
Gregg Kellogg: yes, @prefixis only meaningful during compaction
… in 1.0 any prefix could be used
… so we made some changes
… including restrictions and a keyword @prefix to overcome them
… we do run into 1.0 compatibility issues here
… but this is something we just didn’t complete
… it’s not a major rewrite
… now we are forcing the use of expanded term defns for things that used to be simple prefixes
Dave Longley: +1 to what gregg is saying … it seems to mostly be restricted to very local change in IRI expansion where we need one extra flag check
Gregg Kellogg: the impact isn’t too bad on the algos
… we did make changes to limit the use of prefixes during compaction, we should make the same changes for expansion
Ivan Herman: I thikn this issue arose in a different ticket ^^^^
… I have said before that we shouldn’t add too many things to the spec
… do we really have to do anything about #177?
… does it occur significantly in 1.0 usage?
… do we need to spend two meetings on it?
… i don’t think so. my feeling is that we should either close or defer
… we struggled whether this is really a security issue
… it can be awkward
… in several years it did not bite us
Benjamin Young: we haven’t had @prefix very long either!
Ivan Herman: but it’s not a matter of just @prefix
Pierre-Antoine Champin: I agree with ivan
… I’m not convinced that this is a security issue
… . I’m not convinced that @prefix would be a good way to solve it if it were
Adam Soroka: .. getting this right with @prefix would be challenging
Pierre-Antoine Champin: @prefix was introduced for other reasons
… the way we have it now is counterintuitive
… we were all talking last week about using it this way without even realizing we couldn’t. that’s not good!
Gregg Kellogg: when we introduced the restrictions for prefixes, we overlooked expansion
… we left the job partly done
Ivan Herman: we are adding features and making the spec more complicated
Gregg Kellogg: is inconsistency complicated?
Ivan Herman: we are complicating the spec a few months before we try to get to CR
Dave Longley: I sympathize with ivan
… if we consider this a security issue, then @prefix is not how we should address it
… we could instead introduce a rule that you don’t expand prefixes when @vocab = true
Gregg Kellogg: I agree with dlongley; that would solve the problem but burn all the fields
Ivan Herman: I propose that we defer one of the two
Gregg Kellogg: I don’t think we can roll back prefix
… it fixes actual errors in 1.0
Pierre-Antoine Champin: I suggest we make no decision before the next agenda item
Gregg Kellogg: I can do a speculative PR
Benjamin Young: let’s go to the next issue, discuss, then come back to this

[gkellogg]

Is this resolved by w3c/json-ld-api#109 and w3c/json-ld-api#110? Do we need something in the syntax document?

[pchampin]

Is this resolved by w3c/json-ld-api#109 and w3c/json-ld-api#110?

I think it is.

Do we need something in the syntax document?

I think it rather belongs to the BP document.