16:33:49 RRSAgent has joined #wicg 16:33:49 logging to https://www.w3.org/2022/09/16-wicg-irc 16:33:51 present+ 16:33:52 lbasdevant has joined #wicg 16:33:55 btsavage has joined #wicg 16:33:56 chair: kleber 16:33:58 tprieur has joined #wicg 16:33:59 abissuel has joined #wicg 16:34:00 russStringham has joined #wicg 16:34:02 present+ 16:34:02 present+ 16:34:03 present+ 16:34:06 present+ 16:34:06 wseltzer has joined #wicg 16:34:08 present+ 16:34:10 present+ 16:34:14 drojas has joined #wicg 16:34:17 present+ 16:34:18 present+ 16:34:19 scribe: cwilso 16:34:24 wbaker has joined #wicg 16:34:25 present+ 16:34:26 zakim, this is FLEDGE 16:34:26 got it, cwilso 16:34:28 present+ 16:34:33 present+ 16:34:49 Theo_Warren has joined #wicg 16:35:12 kleber: [slide deck] : SLIDE_LINK 16:35:36 ...I would like to talk through what is same and different between FLEDGE and PARAKEET 16:35:50 charlieharrison has joined #wicg 16:36:23 ...shared goal: support ad targeting via multiparty process 16:36:52 ...ad targeting based on contextual, ad-specific, user-specific information 16:37:00 "just like the world we live in today" is a strange goal statement 16:37:02 ...no ability to recognize user across multiple websites. 16:37:10 eriktaubeneck has joined #wicg 16:37:43 ...user-specific info all stored on-device 16:38:17 ...use case of app-ads is one of our goals, so may be stored "by OS" 16:39:32 ....shared JS API to support these goals 16:39:33 sysrqb has joined #wicg 16:39:46 Custom Audience is def the standard term for the ad tech/buyer side understanding of this if we're up for a name change. 16:40:13 ...willingness to support Privacy-enhancing technologies 16:40:31 ...mechanism for rendering chosen ads (fenced frames) 16:40:48 ...mechanism for reporting auction outcomes 16:41:04 ...(Aggregate Reporting API) 16:42:03 q? 16:42:13 ...questions before I go on? 16:43:23 ...so, what's different: 16:43:45 ...1) what "servers equipped with Privacy-Enhancing Tech" can do 16:43:55 ...2) How much computation needs to be done on-device 16:44:08 ...3) what scope of user-specific info can be used in ad selection 16:44:34 ...these 3 things are heavily interrelated; could look at this number different 16:44:44 s/different/differently 16:45:21 ...let's go through each of these three things during this talk. 16:46:04 ...1) what PET servers can do. both proposals have changed over time; we once thought this could be entirely on-device 16:46:28 ...adtech folks pointed out realtime data is actually key (e,g., if ad budget has run out!) 16:46:53 ...or keeping ads from running on sites they find objectionable 16:47:21 ... if a browser is going to touch a server, how do we protect privacy? 16:47:52 ...in OG FLEDGE, servers could only be implemented in privacy-preserving ways 16:48:11 I'm not convinced that real time data is essential, but I can see that there is a preference for it. we could work on both budget and safety questions through other means if there was interest 16:48:28 ...OG PARAKEET relied on browser-run servers to see but not store data; would proxy a noisy version to adtech servers 16:48:47 joel: yes. proxy would sufficiently anonymize 16:49:06 kleber: right. Neither of these stories turned out to be realistic. 16:49:48 ... at scale 16:50:59 ...where we are today: on FLEDGE, browsers can contact servers but only on verifiable builds in Trusted exec environment, still can't store data or user profile, but okay because verifiable. 16:51:18 npd, it has to be "near" real time (for the unsafe ad placement problem, probably a few hours would work) 16:51:43 ...on PARAKEET, noisy ranking, must have substantial noising and response caching 16:52:16 ... both rely on privacy enhanching technology servers. 16:53:01 ...on how much computation needs to be done on-device: P has always said little is done on-device. F has changed a lot more; used to be very on-device-heavy. 16:53:16 dmarti, I'm glad to hear there is renewed industry interest in reducing the harms of ads on unsafe sites. it feels a little suspicious that this problem has newly come up in the context of why we can't adopt a privacy-friendly system. 16:53:21 Shivani__ has joined #wicg 16:53:27 ... now have sandboxed code execution inside server. 16:53:50 ... maybe: DSP bidding and SSP auction may move to TEEs? 16:54:20 ... this would help on devices such as phones 16:54:29 we could try to explore other mechanisms for blocking dangerous ads or blocking ads from dangerous sites. safebrowsing, e.g. has update mechanisms 16:54:46 ...finally, gap #3: scope of user-specific information in ad selection 16:55:41 ... P: on-device ad targeting profile is based on web-wide data 16:56:07 present+ 16:56:20 ... F: bidding of each interest group (custom audience) is based only on data from a single site 16:56:36 ...so ad-targeting/machine-learning models cannot learn new information. 16:56:59 ...this is fundamentally more conservative, and certainly more limited that what goes on today. 16:57:14 q+ 16:57:20 ...there's a fundamental question here: is it ok to build a cross-site model? 16:57:36 ack erk 16:57:38 ack er 16:57:45 q+ 16:57:55 it sounds like both are using cross-site data, but Parakeet would be combining data from multiple sites, whereas Fledge would be crossing just from one site to another 16:58:00 eriktaubeneck: (clarification) 16:58:12 theowarren has joined #wicg 16:58:33 q+ to ask what happens if users click on ads 16:59:11 npd, thank you -- we have rapidly pausing advertising in general as an advertiser requirement but this needs to be clearer to include rapidly pulling ads from a specific set of problem sites https://github.com/w3c/web-advertising/blob/bdd3224672cde1bb8543ddec798a6ca69ac61a4a/support_for_advertising_use_cases.md#pausing-advertising 17:00:13 vq? 17:00:25 q+ to ask about potential user control differences between FLEDGE & Parakeet targeting 17:00:35 ack aram 17:01:06 aram: wondering on ? of DSP operations: has there been a lot of feedbakc from DSPs and SSPs? Seems like they might be unwilling to move to a different domain they have less control over. 17:02:05 kleber: we have heard that. I will say: you're right, the bidding operation may contain their company's secret sauce, so they might not want it running in-browser, where i might be reverse-engineered. Not everyone agrees about this. 17:02:25 ... some privacy advocates say putting in the public is better. 17:02:51 joel: the big thing adtech doesn't want to do is reveal bids to users, since it would affect the auction. 17:03:33 ...the bids themselves can't be revealed in the clear, but lockign them in th TEE is likely okay. 17:04:12 aram: the publisher typically plays the bidders against each other. publishers want to monitor the bidding in realtime. 17:04:25 joel: I think we can do that in the TEE too. 17:04:45 ...you should be able to run a more fair auction. 17:04:59 aram: sounds fine, though that doesn't seem to be in the model here. 17:05:49 kleber: this is a difference between the transparency necessary when shipping to the device vs in TEE; but the on-device bidding does occur in worklets that are not allowed to leak out to the page. 17:06:20 aram: publishers could deploy those workletst? 17:06:25 kleber: sure. 17:06:48 ... in FLEDGE version of TEEs, there's no difference in capabilities between on-device and shipped to the cloud. 17:06:58 martinthomson has joined #wicg 17:07:21 q+ btsavage 17:07:41 ack btsavage 17:08:23 benjamin: in isolated worklet, what is the flexibility you have in mind? Originally you could write arbitrary code, but now this is DSL or custom logic that has restrictions? 17:09:08 kleber: in FLEDGE, it's arbitrary code execution. This gets to a bunch of issues that makes shipping to TEE in cloud appealing. 17:09:25 q+ 17:09:32 ...as Martin pointed out in talk on Tuesday, keeping info isolated on a phone can be quite difficult. 17:10:20 ...there are tradeoffs in both directions. 17:10:21 q- 17:10:31 ack npd 17:10:31 npd, you wanted to ask what happens if users click on ads 17:10:45 npd: one privacy concern we might have is about the use of information, particularly when it is off-device 17:11:02 (worth noting that the on-device process has also faced some trust issues between the bidders, publishers and ad tech vs the device system owners, either the OS or Browser folks) 17:11:08 ... concerned about limiting disclosure to when you click on ads 17:11:18 ...I don't think I usually click on ads. 17:11:28 q+ 17:11:30 q+ 17:11:43 kleber: in F, model is every ad that's going to be shown, rendering URL of ad needs to be sent to device. 17:12:00 ... cannot be influenced by info stored locally (on-device user profile) 17:12:23 ... more than that, subject to a k-minimum check 17:12:36 ...explicitly to try to prevent info leakage at time of click 17:13:27 ...essentially, there's no more info transfer at click time than if the user clicked on a link from the site they were on to the ad site. 17:13:53 npd: I think you're saying all the info is transferred aback to the ad site? 17:14:05 kleber: no, only to k-anonymous levels. 17:14:10 ...no user-specific data. 17:14:27 npd: has to be selected to be shown, but not clicked? 17:14:31 kleber: yes. 17:14:35 q+ to ask about advantages to moving off device for DAI? 17:15:14 vq? 17:15:46 npd: in both cases, it seems all the ad data is revealed when you click 17:16:02 kleber: the fact that you were shown an ad is certainly revealed, yes. 17:16:19 ... but this isn't the same question is "can you build a cross-site model" 17:16:25 s/is/as 17:16:30 q+ reply about clicks 17:16:51 btsavage has joined #wicg 17:16:54 q? 17:16:58 q+ 17:17:02 ack erik 17:17:07 vq? 17:17:46 npd: could simply not share this 17:18:02 q+ to ask about k-anonymity 17:18:16 kleber: that would remove significant utility from this. information disclosure; it's about leakage over time. 17:18:19 npd: could mitigate disclosure risks on click by these selected/targeted ads not being clickable 17:18:21 q? 17:18:48 ack theo 17:18:48 theowarren, you wanted to ask about potential user control differences between FLEDGE & Parakeet targeting 17:19:40 theo: on point 3: the difference between F and P's models. F's model registers you in an interest group. one of failure modes of targeting is when you've already bought something. 17:19:53 ... P seems to not have the same kind of affordance. 17:19:54 q+ to suggest that cross-site on-device profiles are probably not ok because it gets leaked on click. 17:20:37 joel: there's no signal that says "Stop showing this". 17:21:15 ...parakeet would like to be able to give the signal to the DSP "don't show this ad" 17:21:25 ...not in current P spec 17:21:44 kleber: but in the P model you don't know who "this user" is - you could only do this to a cluster of users 17:22:16 zakim, close the queue 17:22:16 ok, cwilso, the speaker queue is closed 17:22:36 q- 17:22:41 q- to 17:22:59 I would love to see the more detailed proposal about the functionality of users choosing not to see this ad any more 17:23:22 kleber: takeawy theo points on: in F model, there's an answer to "why did I see this ad", in P model, the mixing of data makes that more difficult. 17:23:29 ack russ 17:23:50 npd I think it is likely the ad interaction more common than clicking the ad intentionally lol. Just the current system of ad tech makes it so these processes don't work 17:23:57 russ: re: #3 - a publisher knows what the context on the page is, and who the user is directly. 17:24:03 ... can't they just show ads directly? 17:24:47 kleber: of course, first-party ad placement is totally ok; if you have that, you don't need this mechanism. Although having on-device storage, even for first-party ads, cross-site frequency capping might be useful. 17:25:10 s/ cross-site/ this enables features like 17:25:11 AramZS (IRC), totally, and I think it's a promising set of functionality to make work for user privacy interests, and an improvement over the status quo (where it does seem like that functionality doesn't work) 17:25:32 s/features like/features like cross-site 17:25:51 ack aram 17:25:51 AramZS, you wanted to ask about advantages to moving off device for DAI? 17:26:26 aram: the android mention raises an interesting point - dynamic ad insertion - but we probably don't have time to get into this deeply. 17:26:29 theowarren has joined #wicg 17:26:49 ....I'm wondering if either of these proposals could support those scenarios - e.g. podcast ads 17:27:35 kleber: when there's a cloud-based TEE, yes, seems like it could. still have problem of what fenced frames is trying to solve, preventing site from getting access to user profile 17:27:44 vq? 17:27:57 ack btsavage 17:28:08 hjrchung has joined #wicg 17:28:18 benjamin: how would you train an ML model in this case? 17:28:50 kleber: if we put all this together, we'll need to figure out this answer. 17:29:36 joel: [has an answer the scribe can't capture that quickly :P] 17:30:23 ack jyasskin 17:30:23 jyasskin, you wanted to suggest that cross-site on-device profiles are probably not ok because it gets leaked on click. 17:31:00 jeffrey: suggestion of an answer to #3: based on nick's observation, a link click would lead to some ad data, 17:31:09 kleber: no, just that the ad was selected 17:31:45 jeffrey: but some data is revealed. so it seems like there needs to be some limit on the number of ads 17:31:56 kleber: yes, though that just slows down the rate of leakage 17:32:03 jeffrey: is this documented?' 17:32:07 kleber: not yet. 17:32:32 it seems like it could be small but very revealing pieces of information. not just that it's uniquely identifying, but the properties themselves (that the user visited plannedparenthood.org etc.) 17:32:56 s/SLIDE_LINK/https://docs.google.com/presentation/d/1QQgrm4oaRRRBr1gfvKj7D8rS2EW8kRgRUHPscvR8BNo/edit#slide=id.g15545e7b627_0_127 17:33:07 link to slides: https://docs.google.com/presentation/d/1QQgrm4oaRRRBr1gfvKj7D8rS2EW8kRgRUHPscvR8BNo/edit#slide=id.g15545e7b627_0_127 17:33:23 rrsagent, make log memberonly 17:33:38 rrsagent, make minutes 17:33:38 I have made the request to generate https://www.w3.org/2022/09/16-wicg-minutes.html cwilso 17:33:42 rrsagent, make logs member 17:34:12 cpn has joined #wicg 17:34:20 zakim, this is First Part Sets 17:34:20 got it, cwilso 17:34:37 zakim, open the queue 17:34:37 ok, cwilso, the speaker queue is open 17:35:00 Yves has joined #wicg 17:35:01 svaldez has joined #wicg 17:35:04 dmarti has joined #wicg 17:35:04 johannhof has joined #wicg 17:35:05 sidsahoo has joined #wicg 17:35:09 abissuel has joined #wicg 17:35:12 present+ 17:35:48 present+ 17:36:06 present+ 17:36:10 present+ 17:36:27 present+ 17:36:36 https://goo.gle/fps-meeting-notes 17:36:40 kleber has joined #wicg 17:36:42 present+ 17:38:02 Hong has joined #wicg 17:38:46 zakim, who is hre? 17:38:46 I don't understand your question, cwilso. 17:38:50 zakim, who is here? 17:38:50 Present: tomayac, cwilso, elias_selman, ErikAnderson, lbasdevant, btsavage, abissuel, russStringham, tprieur, AramZS, npd, jyasskin, wbaker, weiler, dmarti 17:38:53 On IRC I see Hong, kleber, abissuel, sidsahoo, johannhof, dmarti, svaldez, Yves, cpn, hjrchung, btsavage, martinthomson, Shivani__, eriktaubeneck, charlieharrison, wbaker, drojas, 17:38:53 ... wseltzer, russStringham, tprieur, lbasdevant, RRSAgent, PaulJensen, Zakim, AramZS, ErikAnderson, jyasskin, bkardell_, christianliebel, Rossen, leaverou, DerekNonGeneric1, 17:38:58 ... Mike5Matrix, Github, npd, tomayac, Dongwoo, DerekNonGeneric, hober, sangwhan, astearns, cwilso, dougt_, tobie, iank_, krit, bigbluehat, hadleybeeman, Travis, rbyers, scheib 17:39:25 oh, wow, that worked 17:39:33 sarahheimlich has joined #wicg 17:40:15 present+ 17:41:55 eriktaubeneck_ has joined #wicg 17:43:04 It is interesting to me that this has introduced a whole new idea: 17:43:10 "A multi domain site" 17:44:20 q? 17:44:48 I don't want to delay the conversation, but as I've noted on some github issues, I don't see how these changes would benefit users 17:45:17 AramZS: On the contrary, I think "a multi-domain site" was a thing that already existed, and until 3p cookie removal nobody needed to give it a special name, it was just a website 17:46:33 those would both be great comments to be on the record (i.e. Nick, you should ask on the queue) 17:46:40 I guess some people might have talked about "I want to search for this on US Google, not on France Google" in a very small set of situations, but it has been a multi-domain site all along 17:47:12 Kleber: I don't think even most users of 3p would think of it that way. I agree that maybe a few people doing multi-national-TLD maybe, but a lot of people who used 3p for this type of stuff we're not so much thinking of a "multi-domain site" as they are thinking about a "multi-site user". 17:47:26 kleber, indeed, the whole point of having different domain names for different countries may have been explicitly indicating to users that these were different contexts, with different languages or policies 17:47:30 q+ 17:47:39 Queue is on the google doc dmarti 17:48:02 (added you to the queue on the Google doc dmarti) 17:48:35 Outside of country code variants domains don't really think of themselves as multi-domain sites and users def don't with a very few very popular exceptions. 17:48:35 Google doc is here: https://docs.google.com/document/d/10dMVqt2x8otohdJx4AZYccdX5Hp_lrxlT7QAO2adcfE/edit# 17:48:54 I just saw a comment on the Zoom from Tim. Can someone remind people not to do that? 17:49:53 It is particularly fascinating to establish this as a term because advertising usually renders domains as wanting to be intentionally different. Unbundling of sites to multiple domains was specifically done in order to avoid the idea of thinking of themselves as "united" in order to have separate targeting. 17:49:55 my notes on gov.uk: https://github.com/WICG/first-party-sets/issues/102 17:50:14 removing the eTLD thing is a good start. removing all of the subsets would be better. 17:51:27 +1 to what Nick is saying here 17:51:43 I still have yet to see an iteration of this proposal that is not better solved by going out in the marketplace and spending the time and money to tell site-owners to merge their domains and I'm not sure these use cases are going in the right direction on that. 17:59:49 seefeld_ has joined #wicg 17:59:51 is the purpose improving user prompts? or is it about the user expecting to combine their data between all these sites? 18:07:18 perhaps I'm just still not getting it, but it feels like "associated domains" is clearly different sites that will combine data for user-hostile reasons, but hey, the harm is limited to 3 domains at a time (for now) 18:07:53 Even worse the sets are, by design, intended to have different privacy models/tos than the rest of the set as far as I understand? 18:08:35 Seems real bad. 18:08:35 Like we should not be allowing systems that do not share the same understanding of privacy or the user's data and where it should go to share that users data, right? 18:09:15 for what it's worth, that can happen currently with different paths on the same domain now 18:09:23 Would you be okay with what you said if those sites passed a storage access prompt? 18:10:35 Sure but that risk grows when we increase security cross domain and then use this as a tool to lower that security. 18:10:48 If the web makes a new promise of privacy to the user and then goes 'oh no, *wave hands* except over here' then our capacity to gain and retain user trust with these measures is injured. 18:10:59 +1 18:17:57 Do we have time in this agenda for discussions about governance? 18:19:40 martinthomson worth hoping on the queue 18:22:15 ShivaniSharma has joined #wicg 18:24:39 sarahheimlich has joined #wicg 18:26:22 I keep hearing "maintain status quo" in discussions this week. We should really have a long discussion about whether that is something we want. 18:26:29 Because I'm fairly sure that I don't want that. 18:26:40 Yes. Same 18:28:19 kleber has joined #wicg 18:28:33 "Keep websites working"? 18:28:45 Certainly something I want 18:30:12 is the purpose to meet user expectations, or to improve prompts, or is to prevent website breakage? 18:30:13 "Status quo" obviously has to be understood in context here. We all agree things need to change (we could just not do Privacy Sandbox instead). 18:30:31 Helen meant maintaining the status quo as a contrast to companies updating their privacy policies / branding in response to a "policy" that may change in the future. 18:30:35 I don't think the status quo anyone is worried about here is 'websites load and are readable and users can interact with them' there is a very different status quo under discussion. 18:31:13 npd (IRC): don't understand how those are competing requirements 18:31:40 Blindly maintaining the status quo, as martinthompson suggests, is not necessarily a goal. Ensuring the web continues to be a viable platform for the world, yes. 18:33:02 Notes doc: please sign yourself in: https://docs.google.com/document/d/1RefoawfEnLkGLzGp_zzyy3PJuYI7EtzY5jYTfJo_3c0/edit# 18:36:10 ~ 18:36:15 s/~// 18:37:55 Notes doc: please sign yourself in: https://docs.google.com/document/d/1RefoawfEnLkGLzGp_zzyy3PJuYI7EtzY5jYTfJo_3c0/edit# 18:38:51 jwaterman has joined #wicg 18:40:53 It's really nice to hear someone say that about video permissions prompts. We've been saying that for years. 18:41:14 reillyg has joined #wicg 18:41:22 present+ 18:41:26 Yves has left #wicg 18:50:54 "none of them can egress the data from your machine" is a strong claim 18:51:08 what evidence do you have in support of that claim? 18:52:00 theowarren has joined #wicg 18:52:39 kleber has joined #wicg 18:54:58 q+ to ask about constraining domain of input to immutable functions 18:56:45 q+ to ask about side-channel leakage 18:59:47 ah I see the queue is not being handled in irc :-) 19:00:47 so far, I have only gotten a link that I haven't read: https://cseweb.ucsd.edu/~dstefan/pubs/stefan:2012:addressing.pdf 19:11:05 lgombos has joined #wicg 19:11:51 cwilso: I don't know how IRC note-taking works with many sessions all back-to-back like this — is there any way to make an edit to the notes from the FLEDGE/PARAKEET session? 19:12:01 q- dmarti 19:12:05 q- theo 19:12:10 q- kl 19:12:21 zakim, close the queue 19:12:21 ok, cwilso, the speaker queue is closed 19:12:36 Those notes say "npd: could simply not share this", but what Nick actually said was "could simply not allow clicks on the ads" 19:12:59 npd: fyi 19:16:21 CAPTCHA-to-fingerprint pipeline 19:17:33 I just want to have it on the record that we don't - as a general rule - care about sites consuming CPU 19:24:00 I am nervous that browsers would impose policies on these UIs that are so strict (e.g. in the fontpicker case) that innovation is either too difficult or simple enough that we could extend the existing APIs 19:24:40 e.g. some ranking function 19:27:18 AramZS has joined #wicg 19:41:18 yoav has joined #wicg 19:41:19 laka has joined #wicg 19:42:12 Uchi has joined #wicg 19:42:18 present+ 19:42:19 Zakim, start meeting 19:42:19 RRSAgent, make logs Public 19:42:20 please title this meeting ("meeting: ..."), AramZS 19:42:26 estade has joined #wicg 19:42:48 meeting: WICG - Web Monetization meeting 19:43:04 present+ 19:43:07 present+ 19:43:11 present+ 19:43:12 igarashi_ has joined #wicg 19:43:35 present+ 19:43:35 scribe: estade 19:43:50 present+ 19:44:49 laka: we have a spec implemented in extension and native mobile browser and agreement from Chromium to allow us to implement experimentally 19:45:34 laka: currently in i2p after a lot of feedback 19:45:49 laka: extension has usage from thousands of sites 19:45:58 laka: time to start implementing natively 19:47:29 laka: not sure whether to move forward with webkit prototype, chromium prototype, or breaking up extension. Which is best for moving this from community group to WG? 19:48:31 yoav: these seem like orthogonal concerns 19:49:33 yoav: a standard is a deliverable of a WG. Before the spec becomes a standard, one of the things you need is multiple implementations. But creating the WG doesn't require an implementation done, and writing an impl into Chromium doesn't require a standard or WG 19:49:43 yoav: these processes are not necessarily linked. 19:49:58 present+ 19:50:15 jyasskin: but for mozilla and (sometimes) safari need working groups 19:50:31 jyasskin: btw what is a provider 19:50:43 laka: provider pays a page on behalf of user. 19:52:04 laka: spec is written to allow various possible relationships, e.g. a third party provider that has a relationship with the payer and the payee, or a case where the provider is the payer i.e. user 19:53:00 laka: may be an edge case, but as a power user I want to be the provider 19:53:26 laka: back to wg - what happens after we put together a charter 19:53:53 jyasskin: socialize it to w3c staff 19:54:25 laka: we have worked with Ian 19:55:14 laka: shopped it around with Google and they probably won't object but not sure if they will abstain 19:55:36 laka: Moz has been hardest to pin down an opinion 19:55:56 laka: apple and chrome see this as complementary to paymentrequest 19:56:14 jyasskin: doesn't seem like it should be objectionable to Mozilla 19:56:33 laka: we're not sure who's going to fill the gap Peter left when he left Mozilla 19:57:03 laka: ad people might object because it can be a way to replace ads 19:57:25 aaronzs: most common use case is actually both, pay + show adds 19:57:59 aaronzs: most publishers have had a way to accept payments and/or show ads so it shouldn't be seen as a new threat to advertisers 19:58:33 aramzs: most common use case is actually both, pay + show adds. most publishers have had a way to accept payments and/or show ads so it shouldn't be seen as a new threat to advertisers. 19:58:58 aramzs: publishers will like it and advertising networks won't be bothered by it. 19:59:41 jyasskin: why new WG instead of adding to web payments? 19:59:59 laka: because they mostly focus on a page asking for money/single transactions 20:00:21 laka: this API is for passive ways to pay. No interaction should be required unless it's user-initiated. 20:00:54 jyasskin: other tipping providers might object as potential competitors (patreon etc) but they're probably not members 20:01:03 laka: io is a member 20:01:19 jyasskin: don't need to assume competitors will object 20:01:44 yoav: competitors may like seeing the market grow, also competitors have to have a real reason to object 20:02:23 https://www.w3.org/groups/wg/payments/ipr <- who'd care about adding this to Web Payments 20:02:44 aramzs: horizontal review - should be concerned about privacy, a11y groups' opinions 20:03:12 aramzs: at least a preliminary look should be solicited 20:04:29 jyasskin: on technical aspects of WG design --- in a CG, any contributor gives patent considerations. In a WG, any member of the group gives patent considerations. One reason to get into web payments is to be sheltered by their patent umbrella 20:04:39 laka: not familiar with patent considerations 20:05:29 laka: interledger has no patents, only a trademark on the name interledger. So does anything in this spec require patent protection? 20:05:38 jyasskin: you should talk to a lawyer before making such claims 20:06:41 laka: back to next steps. What's the most valuable next step to get this into the standard, implementation? 20:06:50 jyasskin: get more users. That motivates implementors. 20:08:22 aramzs: you may not need a specific number of users. But testimonials from users may help. 20:09:24 yoav: wicg gives you contribution guarantees that allow people to contribute to the spec. It's not a traditional community --- it's an umbrella community group. It would be ideal to have a web monetization CG to show that there are many parties beyond interledger who wish to see this in the wild 20:11:21 yoav: there may be one bar for landing code in Chromium, and a higher bar for actually shipping. The risk of the feature being shipped, going unused, being deprecated and removed must be weighed against potential benefits. So showing users and providers and thriving ecosystem exists is key. 20:13:03 laka: this makes me think it's more important to break up the extension than try to implement in chromium. It's going to be easier to keep adding users via extension rather than getting users to flip an about:flags entry 20:14:49 yoav: you could do both simultaneously if you had the resources 20:14:56 laka: probably only have resources for one or the other 20:15:31 jyasskin: proving that it's a good idea via growing the user base seems like the top priority 20:16:29 laka: coil (provider) doesn't make much money from this, interledger makes none (tis a foundation) 20:17:09 laka: coil has other income streams such as Twitch integration 20:17:33 jyasskin: that's another reason to focus on users first. 20:17:53 laka: who's interested in continuing to participate? 20:17:57 aramzs: I am 20:18:54 aramzs: let's connect on slack. https://www.w3.org/wiki/Slack 20:19:04 q+ 20:20:23 npd: this is great because it enables alternative business models on the web 20:20:46 laka: thank you for the help and constructive feedback 20:20:59 npd: potential for decentralization, funding for sites, and possibilities like better privacy support in different business models 20:21:46 laka: please refer to spec on github for feedback going forward 20:22:19 laka: how does WICG feel about continuing to host the spec in WICG / webmonetization 20:22:44 laka: as we move to a WG 20:22:57 yoav: probably best to move it to w3c 20:23:47 aramzs: if you do the repo move correctly, github will automatically redirect the old URL 20:24:14 laka: so long and thanks 20:24:41 rrsagent, create the minutes, please 20:24:41 I have made the request to generate https://www.w3.org/2022/09/16-wicg-minutes.html yoav 20:25:27 zakin, end meeting 20:25:35 zakim, end meeting 20:25:35 As of this point the attendees have been tomayac, cwilso, elias_selman, ErikAnderson, lbasdevant, btsavage, abissuel, russStringham, tprieur, AramZS, npd, jyasskin, wbaker, weiler, 20:25:39 ... dmarti, kleber, reillyg, Uchi, yoav, estade, igarashi_ 20:25:39 RRSAgent, please draft minutes 20:25:39 I have made the request to generate https://www.w3.org/2022/09/16-wicg-minutes.html Zakim 20:25:41 I am happy to have been of service, yoav; please remember to excuse RRSAgent. Goodbye 20:25:45 Zakim has left #wicg 20:27:37 zakim, start meeting 20:29:15 Zakim has joined #wicg 20:29:22 zakim, start meeting 20:29:22 RRSAgent, make logs Public 20:29:23 please title this meeting ("meeting: ..."), yoav 20:29:29 meeting: File System Access API 20:29:33 chair: yoav 20:31:22 jsbell has joined #wicg 20:31:24 martinthomson has joined #wicg 20:31:35 present+ 20:32:09 dmurph has joined #wicg 20:32:09 dcrousso has joined #wicg 20:32:10 ayui has joined #wicg 20:32:13 nina has joined #wicg 20:32:14 scribe+ 20:32:19 jesup__ has joined #wicg 20:32:36 present+ 20:32:39 present+ 20:32:42 topic: WICG File System, File System Access 20:33:24 Files on the web are complicated - File API (blobs, files, filereader). After - file AIP - directories & system API, sandboxed file system, now origin private file system (wednesday topic) 20:33:36 synchronous file system, not a good idea 20:33:45 Then directories upload - not standardized, issues 20:33:55 Only 27 red marks from respec 20:33:56 Directories & systems API -> moved to FileSystem API by Mozilla 20:34:10 also not standardized 20:34:28 Then File & Directories API -> gave us drag& drop, not w3c, not official, but implemented by all browsers kinda 20:34:31 confusing! 20:34:31 coincidentally, 3 red marks on one, times 9 red marks on the other, equals 27 red marks on the next 20:35:00 presentation link: https://docs.google.com/presentation/d/1r48bKVJze8E9rHhWG6Ioeyiri0kEuBQRTF6WaCwuiLs/edit?resourcekey=0-pYZw4AzM68ARpZMRjMDUuQ#slide=id.p 20:35:40 @martinthomson Coincidence? I think not... ;-) 20:36:05 So we have pieces of File API and File & Directories Entries API. New -> File System API which supports origin private file system 20:36:10 Where do we go from here? 20:36:40 File System Access API - enable power web apps that allow interaction with files on user's device 20:37:25 simplifying use-cases - seems to unify old file system API functionality into this new API (see all of the old specs / ways to read & acquire files, this unifies them) 20:37:41 FileSystemHandle - modern, promise-based interface, modern 20:38:11 OPFS (origin private file system) split off into WHATWG spec 20:38:25 and part is in WICG 20:39:08 ideally we can unify to WHATWG 20:39:21 jbroman has joined #wicg 20:39:26 See slides for all use-cases now solved by File System Access API 20:39:50 Use-cases: https://docs.google.com/presentation/d/1r48bKVJze8E9rHhWG6Ioeyiri0kEuBQRTF6WaCwuiLs/edit?resourcekey=0-pYZw4AzM68ARpZMRjMDUuQ#slide=id.g1557d7d31ce_0_170 20:40:04 capability summary: https://docs.google.com/presentation/d/1r48bKVJze8E9rHhWG6Ioeyiri0kEuBQRTF6WaCwuiLs/edit?resourcekey=0-pYZw4AzM68ARpZMRjMDUuQ#slide=id.g1557d7d31ce_0_123 20:41:08 editing, enumerating, async interfaces. /streams, persisting handles to IDB, moves, change events, async alternative to SyncAccessHandles. WASM things around sync file access & maybe add async access to these types of things from main thread 20:43:01 talking about how to support in-place writes and safe browsing checks at the same time. Copy-on-write for being able to write to a swap file before swapping to the final file written on `.close()` 20:43:36 Use cases! VSCode. IDEs. Office applications (spreadsheet apps, slideshow apps). Graphics editors & drawing tools. Video game level editor tools 20:44:43 How do we do this in a way that protects user privacy & security? Having a handle to a file does NOT mean having access to a file. UA controls this, and can decide between RW, Read-only, and give user control about what they are giving site access to. E.g. expiring permissions, transparency, revoking, etc 20:46:02 theowarren has joined #wicg 20:46:11 API has been in incubation for a while, first version a couple years ago. Stuff things being hammered out - remove(), move(), unique id (to help de-dup files) 20:46:32 present+ 20:46:40 Trying to make the API more usable, prevent permission fatigue. 20:46:47 Ensuring OPFS can co-exist with local file system 20:46:48 RRSAgent, please generate the minutes 20:46:48 I have made the request to generate https://www.w3.org/2022/09/16-wicg-minutes.html reillyg 20:47:38 New capabilities - file system change events. Better support for long-running file operations (large download can be exposed to user, user can cancel, etc) 20:47:47 End of presentation 20:48:17 q+ 20:48:40 sauski: When giving directory access, this is for entire folder tree? 20:48:45 and symlinked files? and hardlinked files? 20:48:46 asully: yes 20:48:52 ack christianliebel 20:48:55 q+ 20:50:11 christianliebel: Want to stress important of API, thank you. For use-cases - there are also use-cases where you can not or must not exfiltrate data. One case, models are so big you cannot access through internet, or user data so big that you cannot load them off the file system. The API was very handy here to access & use this large data. This is the most important API that is currently not supported on all platforms. If it would be, then it 20:50:11 would be a huge leap forward for web applications. 20:50:25 nina has joined #wicg 20:50:59 EricAnderson: What is the thinking on persistent permission? With installed PWAs? Slide not having a high-performance cross-site data channel, is that related? 20:51:07 benmorss_ has joined #wicg 20:51:27 ErikAnderson: like /etc ? 20:51:39 ... I've also had some website indicating they want to do stuff with a well-known directory like a user's documents folder. The site wants to indicate the 'well known directory' it is interested in, where the user wouldn't need to be presented with a full file prompt? 20:51:45 or ~/.ssh 20:51:47 https://wicg.github.io/file-system-access/#enumdef-wellknowndirectory 20:51:56 Like "documents" as defined there 20:52:38 asully: Biggest request is for persisted permissions. Right now, after you get the file & refresh page, that permission is gone. the ACL is gone when the browsing context goes away. The UA can decide when these persist. When you refresh, maybe you don't reset permissions, but maybe 1 month from now, the access might go away. We want access to match user's intent. 20:52:40 oh, that's probably better, though I don't know that I think it is entirely safe 20:52:43 Dangerous folders are blocked: https://wicg.github.io/file-system-access/#wellknowndirectory-too-sensitive-or-dangerous 20:52:59 ... we have definitely explored things like using signals like installation to indicate persistence with that site. 20:53:02 tomayac: seems like a job for life right there 20:53:02 Yes, it terrifies me a bit. I think it would need to probably be an installed app or otherwise having some much higher trust indicator. 20:53:20 ErikAnderson: yeah, once you have "installed" something, I think we can do a lot more 20:53:39 We've discussed this a lot internally... I'd really wonder how long people think permissions should persist 20:53:50 after tab closure 20:53:53 q+ 20:54:04 ... with regards to permanent access like Photos app having access to photos directory, there is a field in the API called 'start in', which allows the dev to set the default directory. Not currently planning on exposing a way to .... 20:54:18 ack ErikAnderson 20:54:29 martinthomson: You also cannot get direct access to ~/Downloads, just subfolders to prevent it to become a location for supercookies… 20:54:47 ... We are currently blocking 'documents' directory to prevent abuse (not give access to important folder like that) 20:55:27 ... The start-in field can also specify a previous directory that was used / returned by the API 20:56:09 ErikAnderson: Interested maybe in "If installed, then what?" maybe later 20:56:10 Downloads is also scary from a DLL planting attack perspective. Lots of installers are susceptible. 20:56:19 martinthomson: Concurrent access to file, how do you manage that? 20:57:04 asully: For the access handles API (OPFS), that is exclusive, so no worries there. Outside that, creating more copies of writable file stream creates multiple swap files. 20:57:33 martinthomson: So when the swap is closed, it overwrites the file. Last one to close wins? Yes. 20:58:02 ... If the native application has a handle on the file, and is actively using it, and the file swaps in to 'gain the mark of the web', are we confident that the native application is going to recognize the mark of the web now? 20:59:02 asully: Something we haven't explored is file locking. There are some concepts, but in flux. One thing that we have explored - you can't say "this file is locked, you cannot access". Mostly advisory locks. If a native app ignores, can't bother. We have thought about adding advisory locks 20:59:25 martinthomson: Does the browser respect the advisory locks? Yes. Is that required in the specification? 20:59:35 asully: No, that is in flux, we are exploring file locking still 21:00:02 jsbell: To clarify, exploring file locking for the OPFS, but locking outside the OPFS, nothing is in the spec about that, and unclear that we would. 21:00:14 asully: That is something that we could specify, taking/respecting advisory locks 21:00:29 EricAnderson: If the file is read-only on windows, what would happen? 21:00:39 asully: The site would immediately reject a readwrite request to that file. 21:01:00 s/EricAnderson/ErikAnderson/ 21:01:23 ErikAnderson: are the read/write flags a property of the directory? 21:01:49 ErikAnderson: If a file on disk doesn't have a mark of the web, and then open using this API writes to it, are we expecting browsers to add 'mark of the web'? 21:01:59 asully: Yes 21:02:08 q? 21:02:15 q- 21:02:53 martinthomson: How do you manage symlinks that go elsewhere? (We don't follow them). And if it's a hardlink? 21:03:12 reillyg: Because we use a swap file, it deletes the old file and puts the new version there. 21:03:59 ... if on windows, if you have a file open, you can't overwrite a file that is open. So it would fail in different ways. As long as the other application still had it open, there wouldn't be a conflict, because it would still be old file / new file 21:04:41 jbroman: Permission question.. (answer is that we copy permissions to new file from old file) 21:04:57 reillyg: This is done when the swap file was created, not when swap file is swapped 21:05:15 asully: This is not specified at the moment 21:05:36 also owner, ACLs, extended attributes, etc 21:05:41 jsbell: This might not be spec but just normative behavior description on a per-os basis. 21:06:00 jsbell: If we are wrong and some MUST be specified, then we will 21:08:04 martinthomson: There are things that are part of the files that we can reason about, but there is state that exists outside of the files (applications, in users heads, etc) that needs more consideration as well. 21:08:06 ... We have struggled with reasoning about how people think about files as they change. mark-of-the-web helps, but when you are talking about arbitrary files in filesystem with established expectation of their role in people's lives, it makes it difficult to know if this is safe to do (permission prompt aside). Don't want to put too many security consequences behind a 'yes'. 21:08:17 q+ 21:08:34 jsbell: Definitely dichotomy between old world where all native apps could do anything, and now native applications are winding back a lot of that access 21:09:03 q- 21:10:05 martinthomson: We have a reasonably good understanding about consequences of downloading a file into a downloads folder. We have OSs with understanding of what that means, has warnings, etc. For files that have existing presence in applications & user expectations that pre-exist interactions on the web, it changes from something that I'm using from applications X, to something that could have been touched by the web in some way 21:10:47 tomayac: So the concern is that there is a file maybe in a subtree that was granted access to a web app, and that web app could have changed that sub-tree file and that change was a surprise to the user? 21:11:18 q+ does this may crypto locker attacks more accessible? 21:11:29 martinthomson: Yes that is an example. I don't know how to manage that, maybe we need to learn about what people expect, mark of the web, other paradigms for the OS, etc. Those sorts of questions are what I'm interested in. 21:11:43 theowarren_ has joined #wicg 21:11:47 q? 21:12:22 q+ does this make crypto locker attacks more accessible 21:12:43 martinthomson: Both write and read have implications 21:13:27 theowarren_: Started career when crypto locker attacks common. Is that not more accessible with this API? You grant access access to a folder, and then bam, now it's gone & encrypted. Is that reasonable? 21:13:53 asully: Yes. We have safeguards around things like trying to write an .exe. Trying to help users from doing a bad thing 21:14:09 can I write a bash script on windows, which might then enter the path in a WSL image? 21:14:25 how good is the protection against writing executables? 21:15:07 theowarren_: Not a ton of guards on directory case then? At which point in the flow of granting write access to a directory do we have a way to tell the user 'maybe don't do this'? 21:15:48 martinthomson: Warnings don't fix this problem. If consequences have that magnitude, then we shouldn't do this. 21:16:13 q? 21:16:23 benmorss_: What about just downloading executables and executing? corporate enterprises protect this. 21:16:39 q+ 21:16:53 benmorss_: There requires similar level of concern of writing an .exe to directory access, then. 21:17:08 (which can be done from downloads?) 21:17:27 theowarren_: Do we have safebrowsing protections here? 21:17:57 jsbell: We also have done things in the past for directory upload, where when you are uploading / reading more than 10 files, then we show additional prompting. Room for more exploration here. 21:18:24 jesup__: There is also the fact that users have years of experience about downloading from web is dangerous. They don't have that about these prompts. 21:18:57 asully: The prompts are a user-agent implementations 21:20:23 tomayac: Concern here is about the wrapper being write-able. There used to be 3 prompts to access files in a folder. But it makes sense that if you grant access to folder that it might be bad. At the same time we have input-type file-webkit-directory, can read entire filesystem. There is a status quo of things being bad. If the spec says that user agents can make some directories writable, but user agents can have directories read-only, then 21:20:47 ... we would be in the same place as now. But, VSCode usage would be very annoying - you have to grant access to every file in a folder etc. 21:21:51 theowarren: Am more concerned about the 'write' scenario. 21:22:45 dmurph: Are warnings like "hey this is trying to delete folder" or "trying to write to a lot of files" sufficient for making this better? 21:23:00 theowarren: I think we should start more with that, yes. 21:23:21 benmorss_: Well we should try to figure those out now here! 21:24:01 reillyg: We don't really know what the user's mental model is here, we can do a lot to imagine what the user's model might be, but we need to accept that we are going to need to be reactive to what actually happens in the world when this is available. 21:24:31 theowarren: Are we tracking that? 21:25:03 q? 21:25:22 ack tom 21:25:28 estade: So the different between this and downloading an executable is that users have already done that? 21:26:26 theowarren: There is browser UX and a lot of existing user education and mitigation at the OS level for stuff that ends up in the downloads folder. Like windows defender for things put in the downloads folder. 21:27:21 benmorss_: Help us make it better 21:28:06 martinthomson: The path for us implementing this is possible, but the argument that this isn't much worse than the current state isn't persuasive. 21:28:40 AramZS has joined #wicg 21:29:18 dcrousso has joined #wicg 21:29:19 q+ 21:29:57 reillyg: Open, save back to file, is something that users expect. The model now of opening file, and then explicitly choose to overwrite it by choosing it all over again (or have it get put into downloads folder), is asking a lot. Attempting to help users keep their data in the location they originally selected seems rather valuable. This can fit into a more simplified version of interaction. VS a directory where when you are opening a 21:30:20 ... directory, you aren't saving over the whole directory. So it is more difficult to create a clear flow of saving a set of files back to a directory. 21:31:16 asully: Closing thoughts, I would argue that yes write is a lot more scary than read, but I tried to express in first few slide, files are complicated right now. If a user agent only exposes the read-only version of the API, that ONLY makes developer's lives easier. 21:31:25 theowarren: I agree 21:31:33 ack dc 21:32:30 +1 to the speaker from webkit 21:32:30 dc: I don't think anyone is disagreeing that the current file flow is bad. I don't like that websites are now the one writing to the file, and I don't trust websites doing that. I think improving the experience seems orthogonal. Opening up this side-channel scares us. 21:33:03 RRSAgent, please generate the minutes 21:33:03 I have made the request to generate https://www.w3.org/2022/09/16-wicg-minutes.html reillyg 21:33:11 zakim, end the meeting 21:33:13 As of this point the attendees have been jsbell, christianliebel, tomayac, reillyg 21:33:13 RRSAgent, please draft minutes 21:33:13 I have made the request to generate https://www.w3.org/2022/09/16-wicg-minutes.html Zakim 21:33:15 s/dc/dcrousso 21:33:17 I am happy to have been of service, cwilso; please remember to excuse RRSAgent. Goodbye 21:33:22 Zakim has left #wicg 21:33:38 Zakim has joined #wicg 21:34:00 rrsagent, make log public 21:34:30 zakim, this is WICG - Storage Buckets 21:34:31 got it, cwilso 21:36:26 benmorss__ has joined #wicg 21:37:05 present+ 21:37:11 scribenick: jbroman 21:37:15 scribe+ 21:37:20 present+ 21:37:26 present+ 21:37:37 slides: https://docs.google.com/presentation/d/1LwLYZjGq0tVwvttJzmBqjJ1ijJb2JZ5X-q-AZcN6kbU/edit?usp=sharing 21:37:42 estade: welcome 21:38:22 ... storage buckets is a meta-API in the storage space, not a new way of storing data 21:38:29 ... a better way to organize data stored by other APIs 21:38:49 ... a few goals; the primary one is to allow authors to store their data in a way that minimizes the chance of important data being evicted due to low storage space 21:38:56 ... currently, when there is storage pressure, the UA evicts data 21:39:05 ... e.g., evicting all the data for c.com 21:39:27 ... this means that a.com, b.com have no reason to worry about their usage, except for their own quota 21:39:46 ... navigator.storage.persist blocks all of your storage from being evicted 21:39:55 ... but it's a large hammer -- not all of your data is that important 21:40:07 ... buckets allow authors to express relative importance of their data 21:40:33 ... there's also the goal that data management be less manual than it is now 21:40:47 ... want data that a site might want to be store can be managed en masse in a more simple/ergonomic manner 21:41:03 ... storage APIs don't have to reinvent the wheel 21:41:14 ... without buckets, there is one big bucket 21:41:28 ... with buckets, within each bucket is data associated with one or more storage APIs 21:41:36 ... it should be possible for the UA to be smarter about eviction 21:41:56 ... rather than clobbering all of one origin's data, particular buckets are evicted 21:41:59 ... e.g., email client 21:42:21 ... two broad kinds of data: messages in the user's inbox, synced from server; drafts that a user is working on which are not yet stored on the server 21:42:31 ... right now, they compete for quota 21:42:51 ... when a site runs out, it cannot store any more drafts; if the site is evicted, all the drafts are thrown out 21:43:09 ... with storage buckets, a site could specify that a local cache of remote data is put into a bucket that's okay to evict 21:43:29 ... the local data that's not cached anywhere goes into a "drafts" bucket, where the site specifies that it is more important, please do not evict 21:43:39 ... eviction and durability: 21:43:53 ... generally going to be a correlation between whether something can be evicted and whether you want it to be durable 21:44:17 ... another motivating example: storing all of the data for a single user in one bucket, data for another user in another bucket (multi sign in case) 21:44:28 ... when a user signs in, the site can easily toss out all of the data associated with that user 21:44:38 ... rather than having to do so for each API 21:44:50 ... example: and important bucket 21:45:31 ... durability -- whether when there's a write, it's a synchronous write to minimize chance of data loss due to power loss by flushing to disk, at a performance cost 21:45:40 ... persisted -- whether this data should be subject to eviction 21:45:49 ... of course, the UA is allowed to reject these policies -- they're best-effort 21:45:56 ... but it should let the site know whether the policy succeeded 21:46:10 ... for example, a UA might restrict the ability to persist data to certain sites, or require a user permission 21:46:26 ... when persisted, can only be deleted by site or user explicitly, not to free up space 21:46:29 hober: that doesn't seem great 21:46:41 ... if there's sufficient storage pressure, something's got to go 21:46:51 ... if everybody says persisted: true, there's a race to the bottom 21:47:01 estade: 1) every site is still subject to a quota 21:47:23 ... 2) user agent is encouraged to place some sort of restriction on the kind of sites that can persist data, not arbitrary sites on the drive-by web 21:47:35 hober: even on those sites that get that most of the time, it's only most of the time 21:47:44 ... if circumstances are extreme enough, the browser _will_ evict you 21:47:53 estade: it's best-effort in that if you request it, you may or may not get it 21:47:59 ... if you do get it, you won't be evicted 21:48:10 hober: can't tell at creation time that extreme circumstances will exist a month from now 21:48:19 estade: these policies are designed to future-proof storage APIs 21:48:25 ... they actually both come from existing policies 21:48:33 ... you can already use navigator.storage.persist to get the same behavior 21:48:41 ... applies to all storage APIs, just couldn't previously do it per-bucket 21:48:49 hober: did it have the same [persistence] guarantee? 21:49:00 jsbell: currently implemented in Firefox and Chromium-based browsers 21:49:09 ... Firefox shows a prompt; Chrome relies on site engagement heuristics 21:49:23 ... because sites have stored a lot of data, or general OS space crunch, browser has to make a choice 21:49:54 ... don't remember Chrome's current behavior, but Android if the device is low on space, will show UI to help users clean up 21:50:12 estade: on a mobile device, you might be warned you have no space, can go into app settings to clear app space at the OS level 21:50:25 ... similarly, the UA can have a dialog that shows how much space each site is using and delete it 21:50:31 ... but it won't be deleted without user interaction 21:50:48 hober: I expect UAs to want the ability to treat persisted: true as "I'll try much harder than for other storage, but if I can't, game's over" 21:50:55 jsbell: in that case, Chrome will interrupt the user and ask them 21:51:06 estade: we don't intend to closely spec the eviction algorithm 21:51:14 ... it's possible another UA could behave differently 21:51:28 ... e.g., some UA might decide durability should be some heuristic 21:51:35 hober: I agree; you started with "must" 21:51:42 estade: more assertive than I intended 21:52:08 jsbell: original iteration for navigator.storage.persist -- if persist is granted, sites should be able to assert to the user that data they store locally won't go away 21:52:28 estade: it will lead to a poor UX if it's something they and the app expect to not magically go away 21:52:44 ... if a native app uses too much space, the OS doesn't go around deleting data automatically 21:52:49 ... that's the idea here 21:53:06 ... durability is a string that has too values; persisted is a boolean 21:53:12 ... these are chosen to match pre-existing storage APIs 21:53:26 ... another thing you can do with storage buckets is manage your own quota 21:53:40 ... sites are limited in how much they can store, and are motivated to stay under that limit or their app will stop working 21:53:58 ... they may have bucket which is less important than another bucket, they don't want it to take up all the space, so they can give it a quota 21:54:16 ... expiration also improves ergonomics; data will automatically be deleted at that time, subject to certain guarantees 21:54:20 ... can delete an entire bucket 21:54:23 ... APIs are promise-based 21:54:38 ... has integration with Clear-Site-Data, can use header to delete a bucket 21:54:56 ... counterintuitively, service workers can be in buckets even though they're not affected by quota 21:55:12 ... if serviceworker relies on data in bucket, no sense spinning it up only to find that data is gone 21:55:22 ... lets you tie semantically-related parts of your app together 21:55:28 ... right now, we're implementing in Chrome 21:55:38 ... there are parts of the API you can use, and parts that are silently unimplemented 21:55:58 ... by EOQ4, will be ready for broader adoption and testing 21:56:06 ... in some sort of trial that developers can check out 21:56:14 ... we're here to get feedback 21:56:30 dhuigens has joined #wicg 21:56:33 q? 21:56:50 ... Q&A; we have some questions of our own as starters, but welcome questions from others too 21:56:51 q+ 21:56:58 q+ 21:57:05 hober: can you call .delete to delete the default bucket? 21:57:21 estade: default bucket has a reserved name 21:57:25 ... there are four policies 21:57:31 ... some can be changed after creation, some not 21:57:47 ... open question whether you can open or operate on the default bucket, e.g. deleting it 21:58:05 ... haven't decided one way or another, but probably don't want to allow changing default bucket's policies 21:58:28 hober: I can imagine a site wanting to intentionally restrict itself with quota, for instance 21:58:44 ... e.g. setting a policy over a large website that we'll only use 10 MB 21:58:53 estade: they could do this with buckets, never using default bucket 21:58:56 hober: harder in an existing codebase 21:59:11 estade: one of the primary motivators would be to make it easier to migrate to using buckets 21:59:17 ... without substantially changing your existing code 21:59:31 ... don't currently have a way to migrate data from one bucket to another 21:59:35 ... probably "yes, with restrictions" 21:59:44 ... expiration is pretty much guaranteed 22:00:03 ... we have to look at our own implementation and verify that there's no way that this will break assumptions 22:00:16 ... if you can open the default bucket -- 22:00:26 ... you can get at that data using the existing APIs without buckets -- 22:00:40 ... there's a lot of things that touch the default bucket currently; need to think about all the ways these interact 22:00:48 ... there are probably some legitimate use cases 22:00:53 ack dhuigens 22:00:56 dhuigens: this seems useful 22:01:16 ... as far as I understand, current policies are per-site 22:01:25 ... if you have different origins, you have to coordinate storage usage between them 22:01:46 ... this seems useful for that, to be able to say mail can this amount or % 22:02:02 ... I think it might be useful to have more granular persistence indictions 22:02:13 ... for example, if you have some data that's expensive to compute, but you could recompute it 22:02:25 q+ 22:02:30 ... you might want to say "this is less important than that data, but more important than that data" 22:02:41 ... maybe an integer priority instead of a boolean? 22:02:54 ... possibly out of scope, but even for items within an IndexedDB 22:03:06 ... e.g., a cache ordered by date -- recent items are more important than older items -- but maybe too complicated 22:03:13 estade: good point re. integers 22:03:26 ... might add complexity to the API and it's unclear if these integers are well-calibrated across sites 22:03:34 ... e.g., do you delete priority 9 across sites at the same time? 22:03:38 ... don't want sites to compete 22:03:46 dhuigens: purely within one site 22:03:58 ... start with lowest priority data within that site first 22:04:17 ... I do also see the value of a boolean guarantee 22:04:26 ... so you can promise to the user 22:04:33 jsbell: re. IndexedDB 22:04:48 ... buckets is one of the ways we want to solve that, without having part of the IndexedDB going away at any time 22:04:49 ack christian 22:05:06 christianliebel: StorageManager/persist also works in WebKit 22:05:14 ... really like this, it makes developer's lives much easier 22:05:22 ... e.g., deleting per-user storage on logout 22:05:32 ... encryption -- is there any update? is it still planned? 22:05:48 ... developers are concerned that if someone has access to their site, don't want all their storage to leak: 22:06:06 ayui: not in our MVP, want to think deeply about it 22:06:17 ... especially with more use cases 22:06:24 ack erik 22:06:30 ErikAnderson: +1 on the statement about persisted attribute might be a bit coarse 22:06:50 ... don't know if integer priority is the right thing, or some optional explicit signal, like "this bucket is needed for offline experience" 22:06:52 q+ 22:06:56 ... vary behavior for an installed PWA 22:07:08 ... don't know the right set, but suspect app developers could indicate 22:07:30 estade: user agent could take into account "is this an installed PWA", "how recently has this been used" 22:07:56 ... certainly some site from 2 months ago shouldn't be allowed to take up space under storage pressure over PWA you use every day 22:08:11 ErikAnderson: feels like there might be a few buckets and an app might have a preference about what goes away first 22:08:20 ack jsb 22:08:31 jsbell: browser quota management and eviction is radically different across browsers today 22:08:38 ... hopefully that means we're innovating, not locked in 22:08:43 ... but that's why we're treading carefully here 22:08:56 ... Pete from our DevRel team wrote an article 22:09:31 ErikAnderson: I know on Windows, Disk Cleanup Wizard has a pluggable model for apps that may want to opt into helping the user free up disk space 22:09:44 ... should a ServiceWorker get a callback and a limited amount of time to free up space? 22:10:11 dmurph: in Japan in 2019, Andrew Sutherland from Mozilla and us whiteboarded to come up with a v0 prototype 22:10:17 ... wondering if Mozilla is still involved or not 22:10:34 estade: that is a question we have for the group; we haven't been in contact lately 22:10:52 ... we would like to reopen those avenues of feedback and see how much interest there is from other vendors, including Mozilla 22:11:25 ... our other questions for the group: 22:11:31 ... other important use cases that might shape the API? 22:11:39 ... what seems missing? there's some feedback about encryption, granularity 22:12:12 ... you can also get a lock out of a bucket, which is perhaps an ugly duckling compared to quota-managed APIs, but along the lines of ergonomics/organization 22:12:19 ... bucket is being used as a namespace for the lock 22:12:53 Pete's article, btw: https://web.dev/storage-for-the-web/ 22:12:59 ... if people find that useful, great; it's perhaps unintuitive because you might assume it has something more to do with the bucket 22:13:20 ... one thing we haven't thought through the implications of is nested buckets 22:13:45 ... we've talked about one app with multiple users, multiple apps, multiple kinds of data -- but if these add together, you might want nested buckets 22:14:14 ... opens up questions like "are these policies nested?" "what if an outer one is not persistent but an inner one is?" 22:14:30 ... doesn't seem insurmountable; if we get signal that this is useful, it would be helpful to us prioritizing 22:14:59 ... longer format of this can be found by reading our explainer 22:15:04 ... including alternatives considered 22:15:22 ... feedback so far is great; please keep it coming 22:15:23 https://github.com/WICG/storage-buckets/issues 22:18:33 rrsagent, make minutes 22:18:33 I have made the request to generate https://www.w3.org/2022/09/16-wicg-minutes.html cwilso 22:18:40 rrsagents, make log public 22:18:47 rrsagent, make log public 23:30:39 yoav has joined #wicg 23:32:21 Zakim, end meeting 23:32:21 As of this point the attendees have been hober, AramZS, cwilso 23:32:22 RRSAgent, please draft minutes 23:32:22 I have made the request to generate https://www.w3.org/2022/09/16-wicg-minutes.html Zakim 23:32:27 I am happy to have been of service, yoav; please remember to excuse RRSAgent. Goodbye 23:32:31 Zakim has left #wicg 23:32:41 jsbell has joined #wicg 23:32:44 Zakim has joined #wicg 23:32:50 present+ 23:33:25 dcrousso has joined #wicg 23:33:48 zakim, this is WICG - Isolated Apps 23:33:49 got it, dmurph 23:34:05 RRSAgent, please generate the minutes 23:34:05 I have made the request to generate https://www.w3.org/2022/09/16-wicg-minutes.html reillyg 23:34:21 dhuigens has joined #wicg 23:34:38 scribe+ 23:34:48 Presenting: https://goo.gle/tpac2022-isolated-web-apps 23:36:07 reillyg: observation - developers seem to want to build applications using web technologies even when they aren't published on the web. e.g. electron, react native, nodejs, dino 23:36:29 ... also API experience & knowledge sharing. New APIs are being created, but also adopt web APIs because developers like consistency 23:36:47 igarashi has joined #wicg 23:36:53 present+ 23:37:19 ... We also see some applications need protection from compromise of their infrastructure. E.g. Signal. They used a Chrome App, which is like an extension that acts like an app. They liked that, and they don't like that we are deprecating that. 23:37:50 ... why? Because on the web you can make a code change at any time, and you don't have protections against a compromised infrastructure. They liked the explicit update step. 23:38:34 ... 3rd, there are some capabilities that are too powerful for the web platform trust model. Open lack on consensus on this - device APIs, WebUSB, etc. Although some things fully just don't make sense & is less trustworthy than other kinds of applications. 23:39:04 reillyg: Proposal: Standardize an alternative model for distributing web content which provides stronger trust signals and robust integrity protections. 23:39:56 ... First way to do that is packaging. You need to be able to package your content for integrity. It seems like installation is a prerequisite for integrity always. This has to happen before the application is launched. 23:41:32 ... We are doing this in a web bundle, but we are doing this in a different way than other proposals. These are signed. (different than signed exchanged). The bundle is signed, the things contained are not. So you can look at an entire bundle and say that this thing is a unified version of an application, verified to a developer, and can have signings from other sources of trust. 23:42:32 ... Because they are in packages, we don't give them http/s scheme. We are not trying to recreate a way of loading content over https, we recognize that because these things are coming from a package the user installed from somewhere else, it's not an origin. in the isolated-app:// scheme, each bundle is it's own origin in that scheme. 23:42:45 ... Update is an explicit step that replaces the bundle on the same origin. 23:44:14 ... Integrity: There is a default content security policy and trusted types are required. All permissions are off by default. If you are going to use a policy controlled feature, you must declare this up front. 23:45:34 ... Isolation: All existing site isolation work still applies. Storage is isolated from other web content. They cannot be iframed, and must be launched from the 'standalone' desktop UI. The identity of the application that the user will understand is more about the name and icon of the application. 23:46:18 ... navigations into the applications work more like launching a native app. You can only launch the app in ways the application declared that it could be launched (declares entry points). Out of scope navigations just jump into the OS default browser. App loses control of that window. 23:46:53 ... Open for discussion! 23:46:55 q+ 23:47:13 q+ 23:47:18 ack dhuigens 23:48:31 dhuigens: Thanks for thinking about this, applies to Proton as we are using client-side encryption in all web apps. Maybe one thing still missing is some mechanism to ensure that a given version of a given web app is the same for everyone that accesses it. It would be nice to have certificate transparency or binary transparency so security researcher can look and verify. is that in scope? 23:49:46 reillyg: The current proposal doesn't mandate a particular way of .... The one that is current prototyping in Chrome, simple, you install the app, and it will only update locally. For testing. One option, probably initial for how this work work, is something more akin to code signing on Windows or MacOS, where the developer registers with the vendor and can notarize the application. So signed by third party service, and create a record for 23:50:08 ... which versions of the application exist. Can also create a rule like versions must be mono-atomically incrementing. 23:50:22 q? 23:50:44 ... A less simple version implements certificate transparency ideas, some distributed stuff [scribe didn't hear], but those asks are a goal we have. 23:50:46 ack dcrousso 23:51:03 dcrousso: Is there at all plans for any way to allow the bundle to mark itself as completely isolated from the network? 23:51:06 marcosc has joined #wicg 23:51:12 marcosc has left #wicg 23:51:29 reillyg: That's a great question, that is the first question we got when we published the explainer. Not currently possible, but seems feasible/reasonable. 23:51:46 ... Currently you can make network requests, but you cannot load code / executable content from outside. 23:52:32 q+ 23:52:39 ... But you could feasibly say you can only load things from the bundle. That would be reasonable. It makes me a little nervous because there are just so many places where the web can make network requests. But given that the origin of these things is cross-origin from the entire web, that's cross-origin, and it's restriction-engine would already be working. 23:52:44 marcosc has joined #wicg 23:52:51 ... classic example is 'pdf converter' or things like that. 23:53:12 q+ 23:53:25 q- 23:53:40 ... so that is a really plausible opportunity for building network blind applications. You could event imagine that you could design an API to have more control over the network access? 23:54:15 ... The hardest thing to fix right now is navigation-based data leaks. If there is no CSP for navigation.... but I think I was talking to someone on the Chrome security team that this was a thing that people were thinking of as an option, so if that is made then that could be used here. 23:54:18 ack dhuigens 23:54:22 q+ 23:54:23 q+ 23:55:00 dhuigens: One minor comment, opposite with CSP. If we just allow https for sandboxed iframes but not for blob urls, then that kind of incentivizes putting stuff on https and making external requests in some sense. 23:55:16 ... for example, email client showing email in sandboxed iframe. Being able to show a blob url there would be useful. 23:56:29 q? 23:56:37 reillyg: I agree, we do want... there is a tradeoff we want to make around script-generated content. We want developer to be able to put all script in the bundle, but there are always ways for developers to execute script that is fetched from a CSP. This could also be something that the trust authority could have a policy about this - they don't sign / distribute apps that have network access or something... 23:57:28 ... manifest fields that let you extend the CSP in explicitly that aren't really dangerous but need to be specified. One example is nonces 23:57:41 Penelope_ has joined #wicg 23:58:19 ... CSP the headers AND together instead of OR together. Forget explicit example - I think CSP nonce, like an analytics script, then you would have to add that to the existing header, you can't add an additional header with that additional thing in it. So it may make sense to have a place to add a specific set of attributes to CSP, but you have to get into the details. 23:58:25 ack dcrousso 23:58:38 dcrousso: What is the imagined used case for 3rd party iframes? Why? 23:59:00 RRSAgent, please generate the minutes 23:59:00 I have made the request to generate https://www.w3.org/2022/09/16-wicg-minutes.html jsbell 23:59:25 reillyg: I think that would be reasonable to disable that for most use cases. The reason for 3rd party iframes is... will have to get back with an example. 23:59:44 dcrousso: Yes this seems like this is a kind of contradictory to proposal.