Quantcast

keygen and client-certificates document available

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

keygen and client-certificates document available

Travis Leithead-2

Hi folks!

 

In September, Tim posted about <keygen> [1] which started a conversation about it on this list. The TAG has since met and discussed this topic, and we now have a document published with our latest thoughts. This document has our rough consensus at this point, and we additionally welcome feedback from you. As such, we’ve put the doc in a Repo [2] that has an issue tracker, so feel free to open issues against this document and we’ll do our best to resolve them. Thanks!

 

Keygen and client certificates document: http://w3ctag.github.io/client-certificates/

 

[1] http://lists.w3.org/Archives/Public/www-tag/2015Sep/0000.html

[2] https://github.com/w3ctag/client-certificates

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Melvin Carvalho


On 30 November 2015 at 23:21, Travis Leithead <[hidden email]> wrote:

Hi folks!

 

In September, Tim posted about <keygen> [1] which started a conversation about it on this list. The TAG has since met and discussed this topic, and we now have a document published with our latest thoughts. This document has our rough consensus at this point, and we additionally welcome feedback from you. As such, we’ve put the doc in a Repo [2] that has an issue tracker, so feel free to open issues against this document and we’ll do our best to resolve them. Thanks!

 

Keygen and client certificates document: http://w3ctag.github.io/client-certificates/


+1 Excellent work!

I particularly liked section 4.  "This principle is correctly applied to resources such as cameras and microphones in WebRTC and Geolocation, which all ask for permission from the user before enabling access". 

In this context, that made a lot of sense to me, and seems to be the path to a solution.
 

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Anders Rundgren-2
In reply to this post by Travis Leithead-2
On 2015-11-30 23:21, Travis Leithead wrote:

Hi folks!

 

In September, Tim posted about <keygen> [1] which started a conversation about it on this list. The TAG has since met and discussed this topic, and we now have a document published with our latest thoughts. This document has our rough consensus at this point, and we additionally welcome feedback from you. As such, we’ve put the doc in a Repo [2] that has an issue tracker, so feel free to open issues against this document and we’ll do our best to resolve them. Thanks!

 

Keygen and client certificates document: http://w3ctag.github.io/client-certificates/

 

[1] http://lists.w3.org/Archives/Public/www-tag/2015Sep/0000.html

[2] https://github.com/w3ctag/client-certificates


As a response to Tim Bernes-Lee's posting this appears to be an excellent document.

However, the removal of <keygen> only represents a very small tip of a much bigger iceberg which (among many other things) include a wide range of applications using client-based crypto-keys like the (in the EU) quite popular eID-schemes.  The latter have never bothered with <keygen> or Microsoft's counterpart "CertEnroll" since they don't meet their requirements.

Anyway, lots of applications (probably several thousand), recently hit a brick-wall when extensions like NPAPI and ActiveX were deprecated.  Fortunately, most of them found new life outside of the Web, typically in the form of Android and iPhone "Apps".

For eID (which "only" comprises some 100M users),  several people within W3C/FIDO sphere claim that FIDO/U2F compensates for this loss of functionality of the Web.  Rather than debating whether this is for real or not, Microsoft and Google should consider writing a document showing your vision of how such systems would be architected.

Regards,
Anders Rundgren
User and developer of eID-systems
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Noah Mendelsohn
In reply to this post by Melvin Carvalho
Not making substantive technical content, but just wanted to say I'm
delighted to see the TAG working through drafts like this. As others have
said, t's very well written, and as someone who is not a security expert I
found it very educational and overall very helpful. Thank you!

Noah


Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Noah Mendelsohn

On 12/2/2015 4:54 PM, Noah Mendelsohn wrote:
> Not making substantive technical content, but just wanted to say I'm
> delighted to see the TAG working through drafts like this.

Argh...the perils of speech recognition: I meant to say:

I am not making a substantive technical COMMENT, but just wanted to say I'm
delighted to see the TAG working through drafts like this.

If anyone thought I found the draft to be content-free, I apologize. On the
contrary, it's terrific.

Noah



Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Melvin Carvalho


On 3 December 2015 at 02:30, Noah Mendelsohn <[hidden email]> wrote:

On 12/2/2015 4:54 PM, Noah Mendelsohn wrote:
Not making substantive technical content, but just wanted to say I'm
delighted to see the TAG working through drafts like this.

Argh...the perils of speech recognition: I meant to say:

I am not making a substantive technical COMMENT, but just wanted to say I'm delighted to see the TAG working through drafts like this.

If anyone thought I found the draft to be content-free, I apologize. On the contrary, it's terrific.

Regarding the section on improving the user experience.

If I may give an example of a user experience I encountered today using this technology with a brand new android phone.

Perhaps I am mistaken, but as a user, when viewing that popup my natural instinct was to hit the "install" button.  However, this opens a file system dialog that I found confusing, as I was expecting to use my cert to authenticate.  What I had to do was cancel and go back.

Simply hitting "Allow" would have taken me through authentication, with the single certificate that I had installed.  But that was less obvious to me.

Some general suggestions:

- Make "Install" type functionality less close to the OK / Cancel type buttons.  Or not have it on that page at all.

- Allow the user to remember their choice.  Although the dialog implies the choice will be remembered, it does not seem to be.

- Make the text slightly less verbose and technical, if possible, more in line with popups for geolocation, camera use or notifications.

The user experience in modern browsers is generally of quite a high standard.  If perhaps some of the designers of other widgets could have some time to look at these type of interactions, and give feedback, small tweaks might lead to a much improved user experience.
 

Noah



Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Martin Thomson-3
In reply to this post by Travis Leithead-2
On 1 December 2015 at 09:21, Travis Leithead
<[hidden email]> wrote:
> Keygen and client certificates document:
> http://w3ctag.github.io/client-certificates/

Does the TAG have consensus that <keygen> (and friends) is worth
replacing?  It seems like there are plenty of approaches that can
support similar use cases, some of which have considerably more
momentum (see Fido for instance).  Is anyone signed up to do work on
this?

The document is unclear on what recommendation it makes regarding
<keygen>-and-co right now.  I could infer from all the activity that
the subtext is a plea to retain the busted feature until a replacement
is ready, but that's not clear to me from reading the document.  I
think that's a very important part of the statement.  If the TAG has
consensus on this point, I'd like to hear that.

I'm disappointed that the TAG thinks that user permission is all that
is needed to install a cross origin correlator.  I realize that this
is a highly contentious aspect of <keygen>: very important to some,
one of the worst aspects to others.  Either way, I don't think that
there is any question you could sensibly ask a user that would
convince me that the answer you got constituted informed consent.

On a less serious note, I think that the characterization of CryptoKey
is inaccurate.  An asymmetric Crypto-Key with an unexportable private
key might be usable for authentication, though other forms are
definitely unsuitable.  The opt-in protection isn't therefore a
non-issue.  I also believe that it is possible to generate keys in
secure storage with the WebCrypto API (Firefox might already if there
is a suitable device, but I'm not sure).

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Anders Rundgren-2
On 2015-12-04 09:47, Martin Thomson wrote:

> On 1 December 2015 at 09:21, Travis Leithead
> <[hidden email]> wrote:
>> Keygen and client certificates document:
>> http://w3ctag.github.io/client-certificates/
>
> Does the TAG have consensus that <keygen> (and friends) is worth
> replacing?  It seems like there are plenty of approaches that can
> support similar use cases, some of which have considerably more
> momentum (see Fido for instance).  Is anyone signed up to do work on
> this?

Since Microsoft have already removed their counterpart to <keygen> from
Edge, this question seems fairly relevant :-)


> The document is unclear on what recommendation it makes regarding
> <keygen>-and-co right now.  I could infer from all the activity that
> the subtext is a plea to retain the busted feature until a replacement
> is ready, but that's not clear to me from reading the document.  I
> think that's a very important part of the statement.  If the TAG has
> consensus on this point, I'd like to hear that.

The only clear consensus is removing this feature, not updating it.


> I'm disappointed that the TAG thinks that user permission is all that
> is needed to install a cross origin correlator.  I realize that this
> is a highly contentious aspect of <keygen>: very important to some,
> one of the worst aspects to others.  Either way, I don't think that
> there is any question you could sensibly ask a user that would
> convince me that the answer you got constituted informed consent.

What you and the TAG (indirectly) are saying is that it is perfectly OK if an IdP
like Google asks the user "'acme.com' is requesting authentication do you agree?",
but totally wrong if coming from a built-in browser UI like a certificate selector.


> On a less serious note, I think that the characterization of CryptoKey
> is inaccurate.  An asymmetric Crypto-Key with an unexportable private
> key might be usable for authentication, though other forms are
> definitely unsuitable.  The opt-in protection isn't therefore a
> non-issue.  I also believe that it is possible to generate keys in
> secure storage with the WebCrypto API (Firefox might already if there
> is a suitable device, but I'm not sure).

Anders


Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Graham Leggett
In reply to this post by Martin Thomson-3
On 04 Dec 2015, at 10:47 AM, Martin Thomson <[hidden email]> wrote:

> I'm disappointed that the TAG thinks that user permission is all that
> is needed to install a cross origin correlator.  I realize that this
> is a highly contentious aspect of <keygen>: very important to some,
> one of the worst aspects to others.  Either way, I don't think that
> there is any question you could sensibly ask a user that would
> convince me that the answer you got constituted informed consent.

“This website wants to use your location, do you allow this?”
“This website wants to use your camera, do you allow this?”
“This website wants you to create a new identity, do you allow this?”

> On a less serious note, I think that the characterization of CryptoKey
> is inaccurate.  An asymmetric Crypto-Key with an unexportable private
> key might be usable for authentication, though other forms are
> definitely unsuitable.  The opt-in protection isn't therefore a
> non-issue.

The opt-in protection breaks keygen completely.

Think of a man-in-the-middle between a browser and a CA. The man-in-the-middle sends poisoned javascript that tells the browser to create a key with no protection, and then allows that key signing request to be forwarded to the CA. The CA issues a certificate against this request in good faith believing the key is secure, when it is not.

There are two kinds of crypto we want to do on the web:

- Crypto that protects the server’s interests. Think copy protection.
- Crypto that protects the client’s interests. Think document signing, non-repudiation, authnz.

There is no way that code that is obtained from a server can be trusted to operate in the interests of the client. The server can _initiate_ a request for the client to do something, but the mechanics of doing this has to be built into the client.

> I also believe that it is possible to generate keys in
> secure storage with the WebCrypto API (Firefox might already if there
> is a suitable device, but I'm not sure).

It is not possible, no, and requests to make it possible have fallen on deaf ears.

Regards,
Graham



Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Graham Leggett
In reply to this post by Travis Leithead-2
On 01 Dec 2015, at 12:21 AM, Travis Leithead <[hidden email]> wrote:

In September, Tim posted about <keygen> [1] which started a conversation about it on this list. The TAG has since met and discussed this topic, and we now have a document published with our latest thoughts. This document has our rough consensus at this point, and we additionally welcome feedback from you. As such, we’ve put the doc in a Repo [2] that has an issue tracker, so feel free to open issues against this document and we’ll do our best to resolve them. Thanks!

I urge people to take this process seriously, so we don’t have another repeat of the crypto.signText() fiasco that Firefox caused last year:


TL;DR: 

"So far people seem to think this is a good idea” to remove the crypto.signText() function without any research into the people it impacts, and without any replacement technology offered. In the process they DoSed online banking in Bulgaria and Argentina, the Spanish Public Administration and Belgian Supreme Administrative Court.

Firebox was forced to revert the change, and then implement an add-on as follows, which for a long time was offered unsigned (!!!!): https://addons.mozilla.org/en-GB/firefox/addon/signtextjs/

What I expect to happen is that a suitable and agreed replacement is built and widely deployed BEFORE anyone tries to remove keygen. Chrome mobile lacks keygen, which is how I was alerted to this embarrassing mess to begin with after a user complained.

Regards,
Graham

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Martin Thomson-3
In reply to this post by Graham Leggett
On 4 December 2015 at 22:20, Graham Leggett <[hidden email]> wrote:
>> [...]  Either way, I don't think that
>> there is any question you could sensibly ask a user that would
>> convince me that the answer you got constituted informed consent.
>
> “This website wants to use your location, do you allow this?”
> “This website wants to use your camera, do you allow this?”
> “This website wants you to create a new identity, do you allow this?”

One of these things is not like the other ones...  What is a new
identity?  You make it sound like I'm going into the witness
protection programme.

>> On a less serious note, I think that the characterization of CryptoKey
>> is inaccurate.  An asymmetric Crypto-Key with an unexportable private
>> key might be usable for authentication, though other forms are
>> definitely unsuitable.  The opt-in protection isn't therefore a
>> non-issue.
>
> The opt-in protection breaks keygen completely.
>
> Think of a man-in-the-middle between a browser and a CA. The man-in-the-middle sends poisoned javascript that tells the browser to create a key with no protection, and then allows that key signing request to be forwarded to the CA. The CA issues a certificate against this request in good faith believing the key is secure, when it is not.

Unfortunately, WebCrypto already permits this kind of "attack" (i.e.,
getting a certificate for a key you "control").  However, opt-in
protection have to prevent the installation of a certificate for keys
that didn't have protections.  I think that means that keys would have
to have no usages (and perhaps a new one, but I suspect that would
draw the ire of Mr. Sleevi).

> There is no way that code that is obtained from a server can be trusted to operate in the interests of the client. The server can _initiate_ a request for the client to do something, but the mechanics of doing this has to be built into the client.

I'm not sure where you are headed with this one.

>> I also believe that it is possible to generate keys in
>> secure storage with the WebCrypto API (Firefox might already if there
>> is a suitable device, but I'm not sure).
>
> It is not possible, no, and requests to make it possible have fallen on deaf ears.

Have you tested this?  I don't have a PKCS#11 device handy, but I do
believe that NSS uses them when they are available.  I can probably
find out, I guess.

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Henry Story-4

> On 5 Dec 2015, at 10:00, Martin Thomson <[hidden email]> wrote:
>
> On 4 December 2015 at 22:20, Graham Leggett <[hidden email]> wrote:
>>> [...]  Either way, I don't think that
>>> there is any question you could sensibly ask a user that would
>>> convince me that the answer you got constituted informed consent.
>>
>> “This website wants to use your location, do you allow this?”
>> “This website wants to use your camera, do you allow this?”
>> “This website wants you to create a new identity, do you allow this?”
>
> One of these things is not like the other ones...  What is a new
> identity?  You make it sound like I'm going into the witness
> protection programme.

I don't think Graham was claiming that his exact wording was the right
one. Finding the right wording, the right interface and symbolism and
methaphors for this is a task that would presumably involve designers
writers, and many others.

If one is just creating a key to be used with HTTP Signatures [1]
then one may ask the user if he wishes to add a Key to his KeyChain.
If one is adding some form of credential, one may ask the user if he
wishes to add the signed statement by S that P. ( eg by the DMV that
you have a drivers licence ).

Then on reaching a resource that requires authentication the resource
can describe what types of credentials are needed for authentication.
The User Agent should then be able to present those credentials that
match and ask the user if he wishes to use it. The user may then also
want to set policies to automate this process.

Given how far User Interfaces have evolved in the past 30 years, from
the command line, to smart phones interacted with using gestures, it
seems that the argument that something cannot be done, is the one
where the burden proof lies on those that claim something to be impossible.

Henry

[1] https://tools.ietf.org/html/draft-cavage-http-signatures-05
which I have now implemented on the client and server using
WebCrypto


Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Mark Nottingham-2
In reply to this post by Martin Thomson-3
On 4 Dec 2015, at 7:47 pm, Martin Thomson <[hidden email]> wrote:
>
> On 1 December 2015 at 09:21, Travis Leithead
> <[hidden email]> wrote:
>> Keygen and client certificates document:
>> http://w3ctag.github.io/client-certificates/
>
> Does the TAG have consensus that <keygen> (and friends) is worth
> replacing?

Section 5 starts:
  "The keygen element should be replaced by a new API better suited for modern day application requirements."

By "and friends", do you mean client certificates? That would be a much broader discussion.


>  It seems like there are plenty of approaches that can
> support similar use cases, some of which have considerably more
> momentum (see Fido for instance).  Is anyone signed up to do work on
> this?

What do you mean by "work" in this case -- FIDO obviously has a number of people working on it (soon including folks from your fine employer, as I hear it).

Generally, the TAG shies away from advocating for adoption of particular proposals (outside the ones we generate ourselves, of course). That said, we're happy to expound upon the architectural implications of various things, and FIDO is on that list; see <https://github.com/w3ctag/spec-reviews/issues/97>.


> The document is unclear on what recommendation it makes regarding
> <keygen>-and-co right now.  I could infer from all the activity that
> the subtext is a plea to retain the busted feature until a replacement
> is ready, but that's not clear to me from reading the document.

Please don't infer what the TAG thinks from what people other than TAG members say on the TAG mailing list.

For that matter, be extremely careful about inferring what the TAG thinks from what TAG members say, unless they explicitly say it's a TAG position.


> I think that's a very important part of the statement.  If the TAG has
> consensus on this point, I'd like to hear that.

*nod*


> I'm disappointed that the TAG thinks that user permission is all that
> is needed to install a cross origin correlator.  I realize that this
> is a highly contentious aspect of <keygen>: very important to some,
> one of the worst aspects to others.  Either way, I don't think that
> there is any question you could sensibly ask a user that would
> convince me that the answer you got constituted informed consent.

Ah, "informed consent" again.

I don't necessarily agree that you can't ask the question in a useful way; while it may be that people who genuinely don't care will click through, people who do care will take advantage of the opportunity. What's important is to have defaults that respect the user, and assure that we don't put users in situations where the services they want are held hostage until they give a permission (this can't be prevented, of course, but it shouldn't be encouraged by the design).

We seem to be getting better at that.

What does concern me personally is the number of questions that can be asked; I think one of the key things we need to watch is the complexity of the mental model that people have for the Web. If you need to know 400 different ways that your privacy might be affected by how you use a browser, people tend to give up -- either on controlling their privacy or the Web.

So, I'm sympathetic to the idea that even with permission, a cross-origin correlator might not be the right thing here. However, we haven't got to that, yet.

Cheers,

--
Mark Nottingham   https://www.mnot.net/





Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Anders Rundgren-2
On 2015-12-06 00:44, Mark Nottingham wrote:
> On 4 Dec 2015, at 7:47 pm, Martin Thomson <[hidden email]> wrote:
>>
<snip>

>> Does the TAG have consensus that <keygen> (and friends) is worth
>> replacing?
>
> Section 5 starts:
>    "The keygen element should be replaced by a new API better suited for modern day application requirements."
>
> By "and friends", do you mean client certificates? That would be a much broader discussion.

If this wasn't the underlaying issue (orgin-unbound client certificates = useless/dangerous/etc),
<keygen> would probably have been updated years ago.

Since such a discussion has no chance of getting anywhere (=consensus with respect to
vendors versus the "market"), the only working long-term solution is removing this part
from the browser and "let people do what they want to do" like they currently do with
Android and iPhone "Apps".

The recent buy-in by Mozilla and Microsoft to Chrome's Native Messaging [1]
system makes both <keygen> and client-certificate support in Chrome a non-issue.
It has already been put in production by the Estonian government for eID support.

Anders

1] https://lists.w3.org/Archives/Public/public-webappsec/2015Oct/0071.html


Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Martin Thomson-3
In reply to this post by Mark Nottingham-2

On Dec 6, 2015 10:44 AM, "Mark Nottingham" <[hidden email]> wrote:
> >
> > Does the TAG have consensus that <keygen> (and friends) is worth
> > replacing?
>
> Section 5 starts:
>   "The keygen element should be replaced by a new API better suited for modern day application requirements."

My question was a different one. It was: is an improved version of keygen-etc the right architectural fit for the web? It's this "modern day application requirements" part that interests me.

> By "and friends", do you mean client certificates? That would be a much broader discussion.

I meant the MIME types and the effects that downloading them cause. These usually get rolled in, but I think that they are more important.

> >  It seems like there are plenty of approaches that can
> > support similar use cases, some of which have considerably more
> > momentum (see Fido for instance).  Is anyone signed up to do work on
> > this?
>
> What do you mean by "work" in this case -- FIDO obviously has a number of people working on it (soon including folks from your fine employer, as I hear it).

I mean "work" in the sense of activity that would potentially move toward an actual deployment of the imagined replacement: writing specs or code. And by "this" I mean the replacement for keygen.

> Generally, the TAG shies away from advocating for adoption of particular proposals (outside the ones we generate ourselves, of course). That said, we're happy to expound upon the architectural implications of various things, and FIDO is on that list; see <https://github.com/w3ctag/spec-reviews/issues/97>.

I am interested in learning the outcome of discussions on the various architectural approaches. I'm glad to see that the general area is getting some attention, it's definitely important.

> Ah, "informed consent" again.
[snip]
> We seem to be getting better at that.

Yes, I agree. Part of that is expecting a high standard. :)

> So, I'm sympathetic to the idea that even with permission, a cross-origin correlator might not be the right thing here. However, we haven't got to that, yet.

That's reassuring, but my reading of the statement is less nuanced than that: cross origin is a goal, and it is ok to do that if you get permission.

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: keygen and client-certificates document available

Daniel Appelquist-4
Hi folks – as interesting as this discussion is, I'd like to try to focus some attention back on the document that Travis produced. We are trying to assemble some specific feedback there via our issues register in Github (https://github.com/w3ctag/client-certificates/issues). If you've got specific issues on this document, can I please ask you to open an issue there.

Thanks,
Dan

On Sun, Dec 6, 2015 at 10:57 AM Martin Thomson <[hidden email]> wrote:

On Dec 6, 2015 10:44 AM, "Mark Nottingham" <[hidden email]> wrote:
> >
> > Does the TAG have consensus that <keygen> (and friends) is worth
> > replacing?
>
> Section 5 starts:
>   "The keygen element should be replaced by a new API better suited for modern day application requirements."

My question was a different one. It was: is an improved version of keygen-etc the right architectural fit for the web? It's this "modern day application requirements" part that interests me.

> By "and friends", do you mean client certificates? That would be a much broader discussion.

I meant the MIME types and the effects that downloading them cause. These usually get rolled in, but I think that they are more important.

> >  It seems like there are plenty of approaches that can
> > support similar use cases, some of which have considerably more
> > momentum (see Fido for instance).  Is anyone signed up to do work on
> > this?
>
> What do you mean by "work" in this case -- FIDO obviously has a number of people working on it (soon including folks from your fine employer, as I hear it).

I mean "work" in the sense of activity that would potentially move toward an actual deployment of the imagined replacement: writing specs or code. And by "this" I mean the replacement for keygen.

> Generally, the TAG shies away from advocating for adoption of particular proposals (outside the ones we generate ourselves, of course). That said, we're happy to expound upon the architectural implications of various things, and FIDO is on that list; see <https://github.com/w3ctag/spec-reviews/issues/97>.

I am interested in learning the outcome of discussions on the various architectural approaches. I'm glad to see that the general area is getting some attention, it's definitely important.

> Ah, "informed consent" again.
[snip]


> We seem to be getting better at that.

Yes, I agree. Part of that is expecting a high standard. :)

> So, I'm sympathetic to the idea that even with permission, a cross-origin correlator might not be the right thing here. However, we haven't got to that, yet.

That's reassuring, but my reading of the statement is less nuanced than that: cross origin is a goal, and it is ok to do that if you get permission.

Loading...