TSR needs CORS

Another issue came up today, I think we need to say that the TSR resource needs to support CORS preflight requests. I have used a Service Worker to get the urls of embedded third-parties (from first-party context script) so the obvious thing is to get the TSRs to parse and show them to the user. This is impossible if the TSRs do not support CORS, so we should say they should. The embeddees will have to accept all preflights I expect (Access-Control-Allow-Origin: *)

Of course it would be even better if we got this built into browsers, I have started a discussion on WICG about that. https://discourse.wicg.io/t/api-to-monitor-subresources/1723/1


-----Original Message-----
From: David Singer [mailto:singer@mac.com] 
Sent: 26 September 2016 19:15
To: Nick Doty <npdoty@ischool.berkeley.edu>
Cc: Matthias Schunter (Intel Corporation) <mts-std@schunter.org>; public-tracking@w3.org
Subject: Re: asynchronous (was Re: Slides created during our discussions today (also including the notes))


> On Sep 25, 2016, at 19:21 , Nick Doty <npdoty@ischool.berkeley.edu> wrote:
> 
> Thanks for sharing discussion notes!
> 
> It's been mentioned a couple of times in passing on recent calls the possibility of altering the Exception API to be asynchronous, so that a site could call it and only later get back a response (based on user input through browser chrome, for example). I wanted to remind the group that we had previously had the API as asynchronous when it was expected that it was the browser that was asking the user, but we made the decision (based on feedback from both browsers and sites) that sites would obtain consent from the user directly and that the exception API was simply about storing an exception. As a result, it is intentionally synchronous. Sites have to accommodate that users may change their decision at a later time, but we don't need separate Promises to handle that situation.
> 
> I believe we responded to TPE Last Call comments to that effect. I would suggest that we not re-open this issue.

Hi Nick

the trouble is, we’re sort-of half-way. If the call was required to be perfectly synchronous, then we’re fine. But we say that the user *may* be asked, and the browser may take time to record the exception.

The first party doesn’t see the headers going to the third parties, and they may not be aware of the exception grant, so the idea that the site can proceed “knowing it has consent” (despite the potentially transiently-wrong header) doesn’t fly either.

I agree, we debated this before. But we might (might) have been wrong. 

For me, it’s something worth noting and asking for implementor feedback on.

> 
> Cheers,
> Nick
> 
>> On Sep 22, 2016, at 8:35 AM, Matthias Schunter (Intel Corporation) <mts-std@schunter.org> wrote:
>> 
>> Hi TPWG Group,
>> 
>> 
>> enclosed are slides that we compiled while discussing TPE today.
>> Feedback is welcome!
>> 
>> 
>> matthias
>> <W3C-TPAC-TPWG-Meeting-v02.pptx>
> 

Dave Singer

singer@mac.com

Received on Tuesday, 27 September 2016 11:53:35 UTC