Thanks. Sorry, I don’t know the technical definitions of these terms. Can we do a concrete example? Say we have ampcache.example hosting news.example’s content. Will packaging make sure that the browser treats news.example as first party and ampcache.example as third party?
-
-
1/2 The request for ampcache.example/news.example.package will send first party cookies for ampcache.example. (Since it doesn't yet know it's getting a package.)
1 reply 0 retweets 1 like -
Replying to @jyasskin @johnwilander and
2/2 Then as the browser loads the resource and realises it's a package, there's the equivalent of a redirect to news.example (though without any connection to news.example or cookies sent anywhere), after which ampcache.example is now third-party.
1 reply 0 retweets 1 like -
Got it. Thanks! This redirect, is it (intended to be) handled as a real redirect in the browser, creating a new context? Is ampcache.example in control of the URL to an extent where a tracking ID can be added there and later picked up when ampcache.example is third-party?
1 reply 0 retweets 0 likes -
Yes, news.example gets it's own context. (Ampcache.example didn't get a JavaScript context at all.) We're discussing whether and how the news.example context should know how it was distributed.
1 reply 0 retweets 1 like -
Replying to @jyasskin @johnwilander and
E.g. we might expose "You were distributed via ampcache.example/news.package." We can't provide the content of an arbitrary header, although I think I haven't written that constraint down in a useful place.
1 reply 0 retweets 0 likes -
Replying to @jyasskin @johnwilander and
Oh, and the URL is exactly what news.example signed. Any changes could be an attack vector even ignoring tracking.
1 reply 0 retweets 2 likes -
This is starting to sound like a significant step forward for privacy and the AMP cache. If that's the case, you should highlight it as a feature (maybe you have and I've missed it) and make it a goal of packaging, i.e. no added tracking capabilities for the cache provider.
1 reply 0 retweets 7 likes -
It's great to hear you say that. I've added a reminder to follow up on this once I'm back from parental leave in November. I'm probably going to need to ask you for more detail on what constitutes a tracking capability.
1 reply 0 retweets 4 likes -
The design makes cache providers strictly less powerful than traditional CDNs as they can't rewrite content without origin assistance. That's very much a goal
1 reply 0 retweets 4 likes
Note that cache providers still know what's in the cache -- they can decode packages like anyone else -- so it's time-shifting TLS's integrity guarantee but not confidentiality
-
-
Replying to @slightlylate @jyasskin and
John, while Jeffrey is on paternity leave, I and Alex will be more than happy to catch up at TPAC and IETF 103 if you are around.
1 reply 0 retweets 2 likes -
Replying to @KenjiBaheux @slightlylate and
Unfortunately, I’m not going to TPAC this year. Paternity leave coming up shortly.
We should go through terminology and current status of tracking with AMP caches. Once we know we’re on the same page, we can hash out tracking capabilities (or the lack there of) of packaging.2 replies 0 retweets 4 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
& Web Standards TL; Blink API OWNER
Named PWAs w/
DMs open. Tweets my own; press@google.com for official comms.