4 ms·

Indeed. As the author puts it "sometimes you know something is very likely to be needed". Let's have a look: <link rel=prefetch href=url> What's going o

by cxr 5y ago

Indeed. As the author puts it "sometimes you know something is very likely to be needed". Let's have a look: <link rel=prefetch href=url> What's going on here, for the test case given? It's introducing tight coupling (or it already exists, and you're trying to capture a description of it to serve to the browser) to an external resource. It's not that prefetch is broken, it's that to desire to be able to gesture at the existence of a resource outside your organization's control, while insisting that it's so important as to be timing-critical, is like trying to have your cake and eat it, too. As mentioned in similar comments, the observed behavior for this particular test case is potentially a problem if you are building Modern Web Apps by following the received wisdom of how you're supposed to do that. There are lots of unstated assumptions in the article in this vein. One such assumption is that you're going to do things that way. Another assumption is that the arguments for doing things that way and the plight of the tech professionals doing the doing are universally recognized and accepted. From the Web-theoretic perspective—that is, following the original use cases that the Web was created to address—if that resource is so important to your organization, then you can mint your own identifier for it under your own authority. Ultimately, I don't have a lot of sympathy for the plight described in the article. It's fair to say that the instances where this sort of thing shows up involve abusing the fundamental mechanism of the Web to do things that are, although widely accepted by contemporaries as standard practice, totally counter to its spirit.

horsawlarway 5y ago
I understand what you're saying, but I fundamentally disagree with you. The issue is that you're immediately deciding that domain X and domain Y are different entities. In practice, I find that there are a HUGE number of use cases where two domains are actually the same organization, or two organizations that are collaborating. There is basically no way to say to the browser - I am "X" and my friends are "Y" and "Z", they should have permissions to do things that I don't allow "A", "B", and "C" to do. --- We actually have a functioning standard for this on mobile (both iOS and Android support /.well-known paths for manifests that allow apps to couple more tightly with sites that list them as "well-known" (aka - friends) The browser support for this kind of thing is basically non-existent, though, and it's maddening. SameSite would have been a PERFECT use case. We're already doing shit like preflight requests, why not just fetch a standard manifest and treat whitelisted sites as "Samesite=none" and everything else as "Samesite=lax"? Instead orgs were forced into a binary choice of none (forfeiting the new csrf protections) or lax (forfeiting cross site sharing).
- cxr 5y ago
  > but I fundamentally disagree with you ["We actually have a functioning standard for this on mobile"] I wouldn't expect any less. https://quoteinvestigator.com/2017/11/30/salary/ https://quoteinvestigator.com/2017/11/30/salary/ > In practice [...] There's your problem. Try fixing that.
  - Spivak 5y ago
    Moving everything under a single domain makes no sense for the use-case of cross-organization sharing though. Domain as as the root identity on the web is just broken and there's no way to make it work. mysharedhosting.com/customer1 mysharedhosting.com/customer2 Two separate identities. Is it even possible to let the browser know that they should be segmented? Nope. customer1.mysharedhosting.com customer2.mysharedhosting.com How about this? No again, not without getting yourself on the suffix list which is just a hack. mycompany.com joinmycompany.com Can you tell the browser that these are actually the same and shouldn't be segmented? Nope!
    - tatersolid 5y ago
      This makes more sense and doesn’t dilute your brand, improves SEO, and helps protect against phishing by making your customers and staff look for a single known-good domain: https://mycompany.com/join
  - horsawlarway 5y ago
    Your take is wrong. Having a domain is identical to having a driver's license: This org says I am "X". It is fundamentally different from uniquely identifying me. I am still the same person if I give you my library card - a different ID from a different org that says I am "Y".
    - cxr 5y ago
      Nah, the problem is definitely on your end. > Having a domain is identical to having a driver's license: This org says I am "X". Nope. You just described two different documents. http://horsawlarway.example/drivers-license.html http://horsawlarway.example/drivers-license.html http://horsawlarway.example/library-card.rdf http://horsawlarway.example/library-card.rdf It's very odd the position you're taking here, given the sentiment in your other tirade about being digital sharecroppers to Facebook and Google <https://news.ycombinator.com/item?id=27369652 https://news.ycombinator.com/item?id=27369652>. Your proposed solution is dumping more fuel in their engines—which is why it's the kind of solution they prefer themselves—and completely at odds with e.g. Solid and other attempts to do things thing would actually empower and protect individual users. I'm interacting with your digital homestead, why are you so adamant about leaking my activity to another domain?
marcosdumay 5y ago
Hum... The resource is not that important to me. I'm just the author of the current page, and are letting the browser know that users are very likely to want that resource. You are attributing a lot of intention into a mechanism. You don't know if it's a 3rd party tracker or the news link in a discussion page. The proposal at the article is actually quite good, since I should always know very well if it will load into a frame or a link.
- vlovich123 5y ago
  I could be wrong but it seems to me that any cross-domain prefetch that uses the “document” option from the article is potentially privacy-violating and can reintroduce the same leaks that necessitated the original segregation. A.test prefetches b.test/visited_a.js, b.test/unique_id.js, and log(n) URLs that bisect unique_id.js so that you can search the cache for the unique id. Have to be careful to balance performance and “this is useful to me” with abuse prevention at scale. It’s also important to realize we have to tread carefully with browser features that seem useful as the graveyard of deprecated features that didn’t survive privacy attacks is quite large.
  - marcosdumay 5y ago
    Well, if so it's a problem, because the article says that Chrome and Safari handle prefetch exactly that way. But I don't see that problem. On this case the a.test domain can not see what is on the cache, only b.test sees it. (At least by what I understood.)
  - jameshart 5y ago
    What's the privacy violation risk here? A doesn't learn anything through those prefetches about whether or not the user has previously cached any B resources (because A never sees the timing or result of its prefetch requests - it doesn't even know if the browser attempted them). B obviously knows what resources A prefetched because they were requested from B in the first place. And if A wants to pass information to B, they don't need to do a complex prefetch dance, they can just load an img src. So I don't see any way for A or B to learn anything about the user's behavior on one another's site without the other site's cooperation?

by cxr 5y ago

horsawlarway 5y ago

I understand what you're saying, but I fundamentally disagree with you. The issue is that you're immediately deciding that domain X and domain Y are different entities. In practice, I find that there are a HUGE number of use cases where two domains are actually the same organization, or two organizations that are collaborating. There is basically no way to say to the browser - I am "X" and my friends are "Y" and "Z", they should have permissions to do things that I don't allow "A", "B", and "C" to do. --- We actually have a functioning standard for this on mobile (both iOS and Android support /.well-known paths for manifests that allow apps to couple more tightly with sites that list them as "well-known" (aka - friends) The browser support for this kind of thing is basically non-existent, though, and it's maddening. SameSite would have been a PERFECT use case. We're already doing shit like preflight requests, why not just fetch a standard manifest and treat whitelisted sites as "Samesite=none" and everything else as "Samesite=lax"? Instead orgs were forced into a binary choice of none (forfeiting the new csrf protections) or lax (forfeiting cross site sharing).

cxr 5y ago
> but I fundamentally disagree with you ["We actually have a functioning standard for this on mobile"] I wouldn't expect any less. https://quoteinvestigator.com/2017/11/30/salary/ https://quoteinvestigator.com/2017/11/30/salary/ > In practice [...] There's your problem. Try fixing that.
- Spivak 5y ago
  Moving everything under a single domain makes no sense for the use-case of cross-organization sharing though. Domain as as the root identity on the web is just broken and there's no way to make it work. mysharedhosting.com/customer1 mysharedhosting.com/customer2 Two separate identities. Is it even possible to let the browser know that they should be segmented? Nope. customer1.mysharedhosting.com customer2.mysharedhosting.com How about this? No again, not without getting yourself on the suffix list which is just a hack. mycompany.com joinmycompany.com Can you tell the browser that these are actually the same and shouldn't be segmented? Nope!
  - tatersolid 5y ago
    This makes more sense and doesn’t dilute your brand, improves SEO, and helps protect against phishing by making your customers and staff look for a single known-good domain: https://mycompany.com/join
- horsawlarway 5y ago
  Your take is wrong. Having a domain is identical to having a driver's license: This org says I am "X". It is fundamentally different from uniquely identifying me. I am still the same person if I give you my library card - a different ID from a different org that says I am "Y".
  - cxr 5y ago
    Nah, the problem is definitely on your end. > Having a domain is identical to having a driver's license: This org says I am "X". Nope. You just described two different documents. http://horsawlarway.example/drivers-license.html http://horsawlarway.example/drivers-license.html http://horsawlarway.example/library-card.rdf http://horsawlarway.example/library-card.rdf It's very odd the position you're taking here, given the sentiment in your other tirade about being digital sharecroppers to Facebook and Google <https://news.ycombinator.com/item?id=27369652 https://news.ycombinator.com/item?id=27369652>. Your proposed solution is dumping more fuel in their engines—which is why it's the kind of solution they prefer themselves—and completely at odds with e.g. Solid and other attempts to do things thing would actually empower and protect individual users. I'm interacting with your digital homestead, why are you so adamant about leaking my activity to another domain?

marcosdumay 5y ago

Hum... The resource is not that important to me. I'm just the author of the current page, and are letting the browser know that users are very likely to want that resource. You are attributing a lot of intention into a mechanism. You don't know if it's a 3rd party tracker or the news link in a discussion page. The proposal at the article is actually quite good, since I should always know very well if it will load into a frame or a link.

vlovich123 5y ago
I could be wrong but it seems to me that any cross-domain prefetch that uses the “document” option from the article is potentially privacy-violating and can reintroduce the same leaks that necessitated the original segregation. A.test prefetches b.test/visited_a.js, b.test/unique_id.js, and log(n) URLs that bisect unique_id.js so that you can search the cache for the unique id. Have to be careful to balance performance and “this is useful to me” with abuse prevention at scale. It’s also important to realize we have to tread carefully with browser features that seem useful as the graveyard of deprecated features that didn’t survive privacy attacks is quite large.
- marcosdumay 5y ago
  Well, if so it's a problem, because the article says that Chrome and Safari handle prefetch exactly that way. But I don't see that problem. On this case the a.test domain can not see what is on the cache, only b.test sees it. (At least by what I understood.)
- jameshart 5y ago
  What's the privacy violation risk here? A doesn't learn anything through those prefetches about whether or not the user has previously cached any B resources (because A never sees the timing or result of its prefetch requests - it doesn't even know if the browser attempted them). B obviously knows what resources A prefetched because they were requested from B in the first place. And if A wants to pass information to B, they don't need to do a complex prefetch dance, they can just load an img src. So I don't see any way for A or B to learn anything about the user's behavior on one another's site without the other site's cooperation?