lukewarlow
commented
1 year ago Thanks for this! This is a great help for me to get started properly thinking about the nuances!
Open ArthurSonzogni opened 1 year ago
lukewarlow
commented
1 year ago Thanks for this! This is a great help for me to get started properly thinking about the nuances!
lukewarlow
commented
1 year ago Gonna add answers to this comment as I think of the answer to them and then once the answers are fleshed out I'll transfer it across to the explainer and / or spec.
What entity "stores" the data? Is it per-document, per-tab, per-origin, per-domain, etc... I guess this is going to be per-origin because we want some kind of persistency over navigations.
per-origin is the intention. This is in the intro in the explainer but I will make sure it's clear when editing.
What about iframes? I have read issues 8, but it is still unclear to me:
Does an iframe have some kind of persisted state it can use if the document in the parent frame doesn't override? What about the interactions with Storage partitioning?
- What about the interactions with the planned portals? They are some kind of document in an iframe, but it could become top-level document too.
- What about the interactions with the planned FencedFrame. I know they have some "mode" where they guarantee there are no mean of communications in between the two documents across the boundary.
- Can a document in an iframe provides an override? Does it propagate above/below in the frame tree?
- There are also iframe credentialless to think about. I don't really have concerns about them.
These are all good questions that I will copy across to the iframes issue for further thought on.
My thoughts are if the parent document has the ability to communicate with the iframe then we should opaquely pass the override through (that is to say the override will apply but navigator.preferences wont reflect it in the iframe).
If the iframe doesn't have communication with the parent document then I think generally the override won't apply in any form. Unless we can guarantee it can't communicate in any way to use that for fingerprinting.
As for whether an iframe can set it's own override that is an interesting question and one I think warrants a whole issue on it's own. #20
What about popups?
- How does it fit with last week intent about partitionning popups?
- In particular what about
Cross-Origin-Opener-Policy: same-origin. I know it guarantees documents from the two side aren't going to influence each other.
- In particular, what about the planned
Cross-Origin-Opener-Policy: restrict-properties? @camillelamy might have an opinion.
I imagine this will be similar answer to iframes. If the page and the popup can communicate then the override will apply, if not then it won't. WIll make an issue for this specifically too as I'm sure there will be nuance to discuss. #21
How does an override propagate?
- Can a document "listen" for change? Would it be useful?
window.matchMedia will reflect the computed state (so override if it exists or browser default if not) you will able to listen using matchMedia.
- With a multi process architecture, the update is going to take some time. Do we have to ensure the events are properly ordered with some others? Maybe properly ordered with PostMessage? Maybe it doesn't matter and we can keep it it user-agent specific. I don't know.
I'm unsure on exactly what is meant wrt the second point. I imagine this is something we can probably keep as internal details.
What happens when the user-agent's global preferences are updated?
- Does the current document "see" the update if it doesn't provide an override?
Yes if there's no override the document can see the update using window.matchMedia the same as they currently can. Once an override is applied window.matchMedia will reflect the override so the global preference will no longer be visible.
Some sites have their override only apply until the global preference next changes, this wouldn't be possible using the API as it currently is so it's definitely something to think about.
- Does the user's agent's update overrides the origin's overrides?
As mentioned above currently no. Some sites have their override only apply until the global preference next changes, this wouldn't be possible using the API as it currently is so it's definitely something to think about.
- What about the user asking the user-agent to "clear" all the website data?
If the user clears all site data it's my intention that these preferences would be cleared along with everything else.
lukewarlow
commented
1 year ago https://github.com/WICG/web-preferences-api/blob/main/SECURITY-AND-PRIVACY-SELF-REVIEW.md here is a (mostly) complete security and privacy self review.
Nice feature! I can't wait to see it implemented. This would have been handy for me in the past. Thanks for working on this!
I came here to prepare some preliminary web platform security/privacy reviews after Chrome's intent-to-prototype was posted. There are some ambiguities / open questions. Here is a list of questions I had in mind:
[x] Could you fill out the Security/Privacy questionnaire? This might help.
[ ] What entity "stores" the data? Is it per-document, per-tab, per-origin, per-domain, etc... I guess this is going to be per-origin because we want some kind of persistency over navigations.
[ ] What about iframes? I have read issues 8, but it is still unclear to me:
[ ] What about popups?
Cross-Origin-Opener-Policy: same-origin. I know it guarantees documents from the two side aren't going to influence each other.Cross-Origin-Opener-Policy: restrict-properties? @camillelamy might have an opinion.[ ] How does an override propagate?
[ ] What happens when the user-agent's global preferences are updated?
I did not think about it for long. I hope this will end up with something easy to understand:
I don't intend every questions to be replied inline. Feel free for the ones you want, or you can edit my post and cross the checkbox when the explainer contains an answer.