Some concerns in CDNs when adding new image formats
Some concerns about adding new information (width/height) which makes things difficult to ensure this is not public visible– but for public resources these should be public visible
Fixing this situation would allow more public static embedded resources to expose timing resources which will help RUM providers
Other use cases? Martin
Martin: No use cases, feedback on desk, later
Proposal
Issue whatwg/html/issues/8143
A single (new) response opt-in for public resources
Can't override `ACAO: *` semantics or value
No request opt-in
Lol meme on new header
Proposal
“Access-Control: public” (bikeshed)
Header on the Response of the public resource
tell the browser it's OK to expose..
Pass CORP/TAO check, even if the request was not set
Open Questions
Bikeshed on name
Should these also expose Headers?
Should it work with “fetch(request, { mode: “no-cors” })” ?
Yoav: Not sure, I don’t see issues here, Dominic mentioned it yesterday
Footgun mitigations
Maybe if cache-control: private etc are set, we can assume the header was wrong?
Martin: What happens if someone does not put “Access-Control: public” but still wants a public resource, mixed signals?
Francois: What about data that changes?
Martin: Thats “Max-Age”
Artur: Public resource, static, doesn’t change… could we include a hash of the resource that has to match?
Martin: We already make folks do this for web socket etc, jump through hoops, means you have to understand the content exactly, but the header is dynamic– can be difficult for a server to do
Yoav: Plus there is the content-negotiation angle, where the hash will differ based on the “Accept” header…
Artur: Okay, so the resources can differ after all?
Artur: If things change, language etc, if we expose those to be readable cross site, that could be a leak.. Want to prevent accidental exposure
Martin: Correct, that is the primary concern here.
…In cases where you “Vary” based on things, e.g. “Vary: Cookie”, we should consider those “mixed signals” and turn this feature off
Yoav: This is not something that happens often, but Cache-Control: Private
Martin: …or no-store does
Martin: We may even want to insist that “Cache-Control: Public” is set
David Baron: Some of these headers are about describing things about the resource… some are about requesting specific behaviors… may be advantages to having headers that are clearly things about the resource, like, we didn’t use and creds to generate this… just because it is so hard to reason about security props of these things
…seems in some ways safer to make developers factual statements about things and implementers use that, rather than request specific security properties
…one example from the wild that is a mixed example, Access-Allow-Origin: * is designed to state not behind a firewall, the rules are very complicated because of design, but the name does not make that very obvious at all
…I’m not advocating a particular solution here, just a comment about some existing work in this space
Yoav: Is the primary concern about naming here?
David: In some ways it's about naming, but related to Martin's comment about various headers contradicting others… Cache-Control: private is a description of BEHAVIOUR not resource, and so this feels a weaker statement as compared to this which is about RESOURCE
Yoav: Okay, I agree, but at the same time, if the declaration of the behaviour and resource are contradictory, we probably should assume its contradictory, and fallback to assume the safer fallback so devs dont shoot selves in foot
Martin: That's why we should explicitly require setting a specific way
Yifan: (Chrome Web Security - lyf) We talked about Cookies today, what about URL queries?
Yoav: For sure, these are very common. Is there a reason not to consider them public?
Arthur: Just to note, a resource is less likely to be public with query parameters
David D: These are purposely attached so not an accidental leak.. No concerns…
Yifan: Would these resources be allowed to access local storage?
Yoav: If it is a script, then yes.
Yifan: Are they isolated from the document? No…
…They would not be. Local Storage would specifically be an issue if the public resource which is cross-origin potentially being able to access the memory data of the local storage of the main document as they are in the same process and not isolated from each other.
Yoav: as discussed yesterday, this does not give the embedding context any more information other than resource timing, but there was a concern related to iframes which the resource timing data is exposed up to parent document
Yifan: would a public static resource be able to become an iframe/frame?
“CORP: cross-origin” issues?
…we end up embedding it in … don’t have site isolation, more risk of spectre
Yoav:
In the context of CORP it goes beyond a declaration of the resource itself…
Camille: The proposal here would not take precedence over ? options, we still respect ? then we do not bypass … and … CSP frame ancestor… Good indication that the resource is not quite public in fact
Yoav: Another thing to include in the Foot-gun mitigations
Ian: Giving example of a Twitter example that starts not customized, but then uses JS to customize itself. Initial response vs runtime values.
If the initial response is completely decoupled…
Martin: The way Twitter serves content: completely generic to every request, then they followup at runtime to customize, fetches that follow are private.
Camille: May be reasonable just based on TAO?
Francois: Even public resources may change based on some identification. Even public open data can fall into DDOS so sometimes they require a token and be allowed to reject? Perhaps based on usage. May still need to know the origin of the request to know if it is legitimate.
…Many CDNs need to do this, to verify that you are a legitimate user
…I guess there are many ways to do that, request may result in an error message response, is this something that the page can get?
Yoav: Should we only respect this for 200 OK
Martin: …
Michal: ...
Charlie: … What if you use a Cookie just for a specific use case
Charlie: We should make sure footcut mitigations aren't killing the use cases. Let's be careful about that, use with limit
… +1 to query parameter concern, super common to embed use data this way, that kind of footgun should be considered.
… Maybe it suffices to bikeshed on naming to make this far more scary. Response should not have any user data at all: proposal “Has-User-Data: no”
… similar to network annotations in Chrome code, have to state what the network reply will contain (e.g. wont have user data)
Yoav: Sure, I’m fine with any name
Ian: Footgun, do we need to consider private networks? Credentials, but also network type is private data? Are we excluding resources on private network addresses from allowing to declare themselves public?
Camille: There is actually an effort Private-Network-Access… envision a way, direction, to treat as public on private IP addresses, not to relax security, but to have enhanced security
…some things may actually be more public-like than private-like, and want to opt-in to all the extra checks
…what we have so far, we thought it would be so easy, and there would be few harder use case… but… we found that there were some very interesting cases when it comes to proxies. People do use proxies, especially in China, to bypass firewall.. Mixing private and public resources in the same pages, because only some of the resources are bypassed, some are not blocked by the wall..
…we may find that resources which are private (IP) are marked as public, and only private because it was accessed by a proxy at some point.
…perhaps we can use this to help distinguish, but I dont think we can use private network to make the distinction
Yifan: Depends if … IP address might be different?
Camille: Suggest we also add to spec to consider also implementing private network access ?
Camille: On Naming, based on Web Platform Sec in Chrome, we want to make sure w e convey to users what we are doing with this… making the resource completely unsafe, bypass a bunch of policies… any new policies this thing will come up, and we will have to discuss this and say this is meant to bypass… for example … If we had had this in the past we would have used it
…We may in the future say that this is meant to opt out of everything. So maybe the name needs to be something like “Unsafe-*”
Yoav: I am not personally convinced that the word “Unsafe” is the correct word, but it makes sense to bikeshed on this topic
Camille: right, it doesn’t have to be just that one word
Yoav: Charlie’s recommendation “Has-User-Data: no” is the right direction – but lets run user surveys to figure this out
Camille: Likely what will happen from SEC perspective is that this is considered unsafe, and we will end up disabling any future features
David D: (Chrome security) first +1 to Cammile
.. We're defining a header whose meaning will change over time, and we need to be aware of that
… On Query Params,... I don’t see the footgun potential on that. On headers, should this be equivalent to Access-Control-Expose-HEader: *.. I would say it shouldn't’, because a resource can be public-static but headers can expose private information (e.g. debugging info)
Reply: (martin thomson) don't do headers
Artur J: (Google security team)... we need to consider that it is easy to mis-apply a header to a resources. Lots of applications are dynamic, multiple resources go through a common handler
…the saving grace for CORS is that one error is not quite enough… I really see a footgun potential here. Cannot be mitigated by namng: It can sound really scary, but it will be enticing and developers will mis-apply it for the value it gives and not realize what the implications are.
… so much of the response is based on user state but is not itself user state, so its hard to get the language right always
… the mitigations we have been discussing so far, both prevent the footguns but also reduce the value
…e.g. If we ignore cookies , then we can't use this on domains with cookies, if we force hash, then we exclude dynamic responses
… but what if we layer both.. E.g. no cookies means it has to match, if it has cookies, …
… maybe if we do some combination of strategies we can cover a larger overall surface area, still making it more difficult to misconfigured
Yoav: seems complex, but it may have a slot in some set of use cases, e.g. cookie-less domain use cases
Martin: if we restrict to cookie-less domains, we will find there are enough folks with demand for this that are not applicable, that we’ll just be back here again
…perhaps the specific suggestion to a? Seems interesting
Yoav: this seems generally hard, because you do not want to ask folks to spray cross-origin attributes over every tag, and background images don't even have that, at the same time the image case is on a cookie-less domain
… then if you do have a cookie, maybe you need some other restrictions
… lets look at it from different angles and see which mitigations would work
Martin: People are “almost cookie-less” use cases quite often, e.g. the DDOS use case, attach a nearly useless cookie is stuck everywhere (just for request count tracking)
Yoav: will have to study more close
Francois: Perhaps we can have “cookie does not contain user-data”
Martin: …but they do
Camille: we don’t know if the response wont have user data in the response
Artur: Trying to figure out, if we wanted to adopt this at google.com
… google.com uses cookies, so we could use this.
… gstatic.com we could maybe use this
… on that domain there are lots of static script images etc
… but we would like to use a hash to prove that the resources dont change
… could also want to apply this to large script that is dynamically generated, we would need to apply the hash after resource is totally dont, poor for perf
… [...] maybe annotation request for this resource should not carry cookies?
… may not be practical, but it would give us the properties we would need… give devs the tools to load things safely
Yoav: Perhaps we could load these with CORS and loaded credentials… if you do need cookies but confidence not exposing data, this is what CORS credentials is for
… another thing about hashes, there is a cost when generating, but also when consuming, especially images (scripts and styles?)
Martin: Need to be able to abort work if it doesn’t match?
Artur: Okay maybe a hash of only the first 100 bytes, <laughter>
Francois: what do you gain on computing a hash
Artur: same as access-control: allow-origin, the value is that you have to explicitly write server-side code that is easier to mess up than to get right… and fails by default.
… instead of just blindly applying a header by accident
Charlie: Indeed, a static header is too easy to apply broadly
… it's almost like a simple proof-of-work thing, maybe you need to mine some coin on each request
Ian: I understand
Martin: Who is familiar with the Web Sockets handshake?
… We did something similar there, and it was so un-ergonomic that we are not replacing it.
… in my experience dvs to go Stack Overflow and will copy anything to jump through hoops to get it done
… appreciate that we want to ensure devs are making a conscious choice… but [..]
… perhaps how many hoops we require devs to jump through should depend on the nature of the promise we make here, especially as it relates to the future of changes/promises of what this will entail
Eric: What you are saying is “I don't care if this is read across origins”
Martin: Right, but we need to make sure, when we are shaving between “make it easy” and “lets not make it to easy” we need to take this into account. This is scary, people will make a mistake if its too convenient
… to be said, its convenient to make lots of these things already
Eric: I agree with Martin over the issue of the hash… just making it less easy to do as some warning, will be almost immediately negated via plugin authors… and soon most requests are doing it
… this doesn’t achieve any of the goals
Camille: Concerns from Sec/privacy, because we are modifying resources and guarantees, for example ??? , XO iframes, fenced frames
… for sec/privacy we are trying to set how all this context works… as these become more widespread…???
…maybe as we think about safeguards now, we may maybe have had those environments in mind
… example fenced frame… you get a temporary and ephemeral particution and cookie store.. Bypass many security policies already… but we allow it because its ephemeral
… maybe its fine to omit specific security mitigations
Yoav: Just when there is this specific opt-in?
Camille: Right, maybe we don’t need to do any extra checks, because its already so restricted here.
Francois: Cannot use Fenced frame exclusively, example…
Yoav: It’s not limit to FF but that we don't need extra constraints
Camille: … as these special contexts become more widespread… maybe we don't care about footgun mitigations as much any more?
… because these contexts are already footgun protection
Yifan: Should we set HTTPS only for this?
Yoav: Sure?
Marin: if its sent over HTTP may as well treat all resources with this anyway :P
Erin: ??
Camille: We had to mark the whole page as unsafe when coming over http
…let's not break mixed content…
Martin: If you explicitly put on a response in the clear, that one thing, but if someone places this over the resource, that opens a new set of concerns
… would be safest if http no longer existed
<agreed>
… let's continue as if it didn’t exist
Camille: Lets restrict to secure context, to motivate adoption further
Yoav: sure, maybe, but the injection attacks are incentive enough
…
Arthur: [?] partitioned cookies
Camille: lets look at the future of the web… partitioned cookies, storage, frames, etc… maybe in thai world we dont care as much about the footguns
Arthur: well the failure case is still the the request was made without creds, but …[
<Sorry, missed scribing last few minutes of dialog>
Final Idea: Path reflection
If you want the URL of the resource to match path specified in the header… will prove that the resources matches what they had in mind when they set the header