4 ms·

These are good questions and I think there's more than one answer that's worth exploring. I think that the privacy problems caused by shared caches could be so

These are good questions and I think there's more than one answer that's worth exploring. I think that the privacy problems caused by shared caches could be solved, without simply prohibiting them altogether. Like, what if you only use the shared cache after N different web sites have requested the same module? But if we really can't get around that problem, then I think another approach worth exploring is for there to be some sort of curated repository somewhere of Wasm modules that are popular enough that browsers should pre-download them. Then the existence of the module in a user's browser doesn't say anything about what sites they have been to. Versioning is a problem, yes. If every incremental minor release of a language runtime is considered a separate version then it may be rare for any two web sites to share the same version. The way the browser solves this for JavaScript is to run all sites on the latest version of the JS runtime, and fully commit to backwards compatibility. If particular language runtimes could also commit to backwards compatibility at the ABI level, then you only need to pre-download one runtime per language. I realize this may be a big cultural change for some of them. It may be more palatable to say that a language is allowed to do occasional major releases with breaking changes, but is expected to keep minor releases backwards-compatible, so that there are only a couple different runtime version needed. And once a version gets too old, it falls out of the preload set -- websites which can't be bothered to stay up to date get slower, but that's on them. This is definitely the kind of thing where there's no answer that is technically ideal and people are going to argue a lot about it. But I think if we want to have the web platform really support more than just JavaScript, we need to figure this out.

thenameipicked 3y ago
I think a better model would be for the site itself to provide the modules, but the browser will hash and cache them for the next site that may want to use the same module. This way, there's no central authority that determines what is common enough. This model does not allow for versioning. For this model, it would be risky to allow it (one website could provide a malicious model that infects the next site you visit).
wizzwizz4 3y ago
> Like, what if you only use the shared cache after N different web sites have requested the same module? That would still let websites perform timing attacks to deanonymise people. There's no way to verify that "N different websites" isn't just the same website with N different names. Though, we could promote certain domains as CDNs, exempt from the no-shared-cache rules: so long as we added artificial delay when it "would have" been downloaded, that'd be just as safe. We're already doing this with domains (HSTS preload list), so why not CDNs? Web browser developers seem to labour under the assumption that anyone will use the HTML5 features they've so lovingly hand-crafted. Who wants something as complicated as: <details> <summary>Eat me</summary> <p>Lorem ipsum and so on and so forth…</p> </details> when we have the stunning simplicity of: <div class="MuiPaper-root MuiPaper-elevation MuiPaper-rounded MuiPaper-elevation1 MuiAccordion-root MuiAccordion-rounded MuiAccordion-gutters css-1aj41gs"> <div class="MuiButtonBase-root MuiAccordionSummary-root MuiAccordionSummary-gutters css-1oqimao" tabindex="0" role="button" aria-expanded="false" aria-controls="panel-content" id="panel-header"> <div class="MuiAccordionSummary-content MuiAccordionSummary-contentGutters css-l0jafl">Eat me</div> <div class="MuiAccordionSummary-expandIconWrapper css-1fx8m19"> <svg class="MuiSvgIcon-root MuiSvgIcon-fontSizeMedium css-vubbuv" focusable="false" aria-hidden="true" viewBox="0 0 24 24" data-testid="ExpandMoreIcon"> <path d="M16.59 8.59 12 13.17 7.41 8.59 6 10l6 6 6-6z"></path> </svg> </div> </div> <div class="MuiCollapse-root MuiCollapse-vertical MuiCollapse-hidden css-a0y2e3" style="min-height:0px"> <div class="MuiCollapse-wrapper MuiCollapse-vertical css-hboir5"> <div class="MuiCollapse-wrapperInner MuiCollapse-vertical css-8atqhb"> <div aria-labelledby="panel-header" id="panel-content" role="region" class="MuiAccordion-region"> <div class="MuiAccordionDetails-root css-u7qq7e">Lorem ipsum and so on and so forth…</div> </div> </div> </div> </div> </div> Example modified from https://mui.com/material-ui/react-accordion/ https://mui.com/material-ui/react-accordion/. Though, in fairness, the developer UX is much better: <Accordion> <AccordionSummary id="panel-header" aria-controls="panel-content"> Eat me </AccordionSummary> <AccordionDetails> Lorem ipsum and so on and so forth… </AccordionDetails> </Accordion> Maybe the problem isn't the libraries. Maybe the problem is us.
- troupo 3y ago
  The problem is the libraries. Browsers are still mostly incapable of delivering usable workable building blocks especially in the realm of UI. https://open-ui.org/ https://open-ui.org/ is a good start, but it will be a while before we see major pay offs. Another reason is that the DOM is horrendously bad at building anything UI-related. Laying out static text and images? Sure, barely. Providing actual building blocks for a UI? Emphatically no. And that's the reason why devs keep reinventing controls. Because while details/summary is good, it's extremely limited, does not provide all the needed features, and is impossible to properly extend.

thenameipicked 3y ago

I think a better model would be for the site itself to provide the modules, but the browser will hash and cache them for the next site that may want to use the same module. This way, there's no central authority that determines what is common enough. This model does not allow for versioning. For this model, it would be risky to allow it (one website could provide a malicious model that infects the next site you visit).

wizzwizz4 3y ago

> Like, what if you only use the shared cache after N different web sites have requested the same module? That would still let websites perform timing attacks to deanonymise people. There's no way to verify that "N different websites" isn't just the same website with N different names. Though, we could promote certain domains as CDNs, exempt from the no-shared-cache rules: so long as we added artificial delay when it "would have" been downloaded, that'd be just as safe. We're already doing this with domains (HSTS preload list), so why not CDNs? Web browser developers seem to labour under the assumption that anyone will use the HTML5 features they've so lovingly hand-crafted. Who wants something as complicated as: <details> <summary>Eat me</summary> <p>Lorem ipsum and so on and so forth…</p> </details> when we have the stunning simplicity of: <div class="MuiPaper-root MuiPaper-elevation MuiPaper-rounded MuiPaper-elevation1 MuiAccordion-root MuiAccordion-rounded MuiAccordion-gutters css-1aj41gs"> <div class="MuiButtonBase-root MuiAccordionSummary-root MuiAccordionSummary-gutters css-1oqimao" tabindex="0" role="button" aria-expanded="false" aria-controls="panel-content" id="panel-header"> <div class="MuiAccordionSummary-content MuiAccordionSummary-contentGutters css-l0jafl">Eat me</div> <div class="MuiAccordionSummary-expandIconWrapper css-1fx8m19"> <svg class="MuiSvgIcon-root MuiSvgIcon-fontSizeMedium css-vubbuv" focusable="false" aria-hidden="true" viewBox="0 0 24 24" data-testid="ExpandMoreIcon"> <path d="M16.59 8.59 12 13.17 7.41 8.59 6 10l6 6 6-6z"></path> </svg> </div> </div> <div class="MuiCollapse-root MuiCollapse-vertical MuiCollapse-hidden css-a0y2e3" style="min-height:0px"> <div class="MuiCollapse-wrapper MuiCollapse-vertical css-hboir5"> <div class="MuiCollapse-wrapperInner MuiCollapse-vertical css-8atqhb"> <div aria-labelledby="panel-header" id="panel-content" role="region" class="MuiAccordion-region"> <div class="MuiAccordionDetails-root css-u7qq7e">Lorem ipsum and so on and so forth…</div> </div> </div> </div> </div> </div> Example modified from https://mui.com/material-ui/react-accordion/ https://mui.com/material-ui/react-accordion/. Though, in fairness, the developer UX is much better: <Accordion> <AccordionSummary id="panel-header" aria-controls="panel-content"> Eat me </AccordionSummary> <AccordionDetails> Lorem ipsum and so on and so forth… </AccordionDetails> </Accordion> Maybe the problem isn't the libraries. Maybe the problem is us.

troupo 3y ago
The problem is the libraries. Browsers are still mostly incapable of delivering usable workable building blocks especially in the realm of UI. https://open-ui.org/ https://open-ui.org/ is a good start, but it will be a while before we see major pay offs. Another reason is that the DOM is horrendously bad at building anything UI-related. Laying out static text and images? Sure, barely. Providing actual building blocks for a UI? Emphatically no. And that's the reason why devs keep reinventing controls. Because while details/summary is good, it's extremely limited, does not provide all the needed features, and is impossible to properly extend.