3/3 Does that help at all?
-
-
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 reply 0 retweets 0 likes -
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
-
-
Replying to @slightlylate @jyasskin and
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
1 reply 0 retweets 2 likes -
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 - 2 more replies
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.