4 ms·

In principle, that's something that could be allowed without giving access "to" Google/the site owner—even allowing the site author to provide their own functio

by cxr 2y ago

In principle, that's something that could be allowed without giving access "to" Google/the site owner—even allowing the site author to provide their own functions for formatting and drawing the values—and thus could be allowed for _any_ website. Designing and implementing it is a fun technical problem, so it's a wonder why it wasn't, considering the motivations of a typical programmer (and those at Google especially).

wrs 2y ago
How would you make an API accessible on the browser side but prevent the return values from being sent to the server? Somebody would surely find a way to use it for user fingerprinting. Edit: I guess if you only want to make a local debug tool, you could make it callable only from a completely isolated sandbox. Maybe?
- deleted 2y ago
  [deleted]
- derefr 2y ago
  > How would you make an API accessible on the browser side but prevent the return values from being sent to the server? Create an API for starting a "performance-metrics visualization Service Worker", that takes two things from a page as input: 1. the service-worker script URL 2. the handle of a freshly-allocated WebGL Canvas (which may or may not already be attached to the DOM, but which has never yet received any WebGL calls.) This Canvas will have its ownership moved to the Service Worker, leaving the object in the page as only an opaque reference to the Canvas. The resulting Service Worker will live in a sandbox such that it 1. doesn't have network access, 2. can receive postMessage calls, but not make them; and 3. doesn't have any write access to any storage mechanism. Other than drawing on the Canvas, it's a pure consumer. Also, obviously, this special sandbox grants the Service Worker the ability to access this performance API, with the metrics being measured in the context of the page that started the Worker. The Service Worker is then free to use the info it gathers from making perf API calls, to draw metrics onto the moved Canvas. It's also free to change how/what it's drawing, or quit altogether, in response to control messages posted to it from the page. The page can't introspect the moved Canvas to see what the Service Worker has drawn. All it can do is use the Canvas's now-opaque handle to attach/detach it to the DOM.
  - TekMol 2y ago
    The worker could still send the data back to the page via side-channels. For example by using up resources like the cpu, the gpu or ram in timed intervalls. The page would then probe for the performance fluctuations of these resources and decode the data from the pattern of the fluctuations.
    - derefr 2y ago
      If a page can already deduce performance fluctuations all on its own, then you don't need a special access-limited performance API, do you? Just have the page do whatever you're imagining could be done to extract this side-channel info on the performance of the host — and then leak the results of that measurement over the network directly. (I imagine, if such measurements done by pages are at-all distinguishable from noise, that they are already being exfiltrated by any number of JS user-fingerprinting scripts.)
      - TekMol 2y ago
        A page can deduce performance fluctuations. It just needs to do the same calculation multiple times and measure the times. The issue with the API is that it provides specifics about the CPU like "Apple M2 Max". If you give this info to a worker, the worker can encode it into a side-channel and send it to the page.
        derefr 2y ago
        I imagine you could "solve" this (for a painful and pointless value of "solve") by 1. only allowing the Service Worker to do constant-time versions of operations (like the constant-time primitives that cryptographic code uses), and 2. not allowing this special Service Worker the ability to ever... execute a loop. But at that point, you've gone so far to neutering the page-controlled Service Worker, that having a page-controlled Service Worker would be a bit pointless. If the Service Worker can only do exactly one WebGL API call for each metric timeseries datapoint it receives, then the particular call it's going to be making is something you could predict perfectly in advance given the datapoint. So at that point, why have the page specify it? Just let the browser figure out how to render the chart. So I revised the design to do exactly that: https://news.ycombinator.com/item?id=40929284 https://news.ycombinator.com/item?id=40929284
- oooyay 2y ago
  The browser has CORS and CSRF to sandbox similar activities to this.
- deleted 2y ago
  [deleted]
amluto 2y ago
Those hypothetical programmers at Google could start by doing a Manifest V4 that would be like V3 but actually useful and privacy-respecting. I’ll believe it when it happens.
ranger_danger 2y ago
Why not just ask for permission when needing that sort of data?
- austhrow743 2y ago
  Some people wont give it and then they will have less data.

by cxr 2y ago

wrs 2y ago

How would you make an API accessible on the browser side but prevent the return values from being sent to the server? Somebody would surely find a way to use it for user fingerprinting. Edit: I guess if you only want to make a local debug tool, you could make it callable only from a completely isolated sandbox. Maybe?

deleted 2y ago
[deleted]
derefr 2y ago
> How would you make an API accessible on the browser side but prevent the return values from being sent to the server? Create an API for starting a "performance-metrics visualization Service Worker", that takes two things from a page as input: 1. the service-worker script URL 2. the handle of a freshly-allocated WebGL Canvas (which may or may not already be attached to the DOM, but which has never yet received any WebGL calls.) This Canvas will have its ownership moved to the Service Worker, leaving the object in the page as only an opaque reference to the Canvas. The resulting Service Worker will live in a sandbox such that it 1. doesn't have network access, 2. can receive postMessage calls, but not make them; and 3. doesn't have any write access to any storage mechanism. Other than drawing on the Canvas, it's a pure consumer. Also, obviously, this special sandbox grants the Service Worker the ability to access this performance API, with the metrics being measured in the context of the page that started the Worker. The Service Worker is then free to use the info it gathers from making perf API calls, to draw metrics onto the moved Canvas. It's also free to change how/what it's drawing, or quit altogether, in response to control messages posted to it from the page. The page can't introspect the moved Canvas to see what the Service Worker has drawn. All it can do is use the Canvas's now-opaque handle to attach/detach it to the DOM.
- TekMol 2y ago
  The worker could still send the data back to the page via side-channels. For example by using up resources like the cpu, the gpu or ram in timed intervalls. The page would then probe for the performance fluctuations of these resources and decode the data from the pattern of the fluctuations.
  - derefr 2y ago
    If a page can already deduce performance fluctuations all on its own, then you don't need a special access-limited performance API, do you? Just have the page do whatever you're imagining could be done to extract this side-channel info on the performance of the host — and then leak the results of that measurement over the network directly. (I imagine, if such measurements done by pages are at-all distinguishable from noise, that they are already being exfiltrated by any number of JS user-fingerprinting scripts.)
    - TekMol 2y ago
      A page can deduce performance fluctuations. It just needs to do the same calculation multiple times and measure the times. The issue with the API is that it provides specifics about the CPU like "Apple M2 Max". If you give this info to a worker, the worker can encode it into a side-channel and send it to the page.
      - derefr 2y ago
        I imagine you could "solve" this (for a painful and pointless value of "solve") by 1. only allowing the Service Worker to do constant-time versions of operations (like the constant-time primitives that cryptographic code uses), and 2. not allowing this special Service Worker the ability to ever... execute a loop. But at that point, you've gone so far to neutering the page-controlled Service Worker, that having a page-controlled Service Worker would be a bit pointless. If the Service Worker can only do exactly one WebGL API call for each metric timeseries datapoint it receives, then the particular call it's going to be making is something you could predict perfectly in advance given the datapoint. So at that point, why have the page specify it? Just let the browser figure out how to render the chart. So I revised the design to do exactly that: https://news.ycombinator.com/item?id=40929284 https://news.ycombinator.com/item?id=40929284
oooyay 2y ago
The browser has CORS and CSRF to sandbox similar activities to this.
deleted 2y ago
[deleted]

amluto 2y ago

Those hypothetical programmers at Google could start by doing a Manifest V4 that would be like V3 but actually useful and privacy-respecting. I’ll believe it when it happens.

ranger_danger 2y ago

Why not just ask for permission when needing that sort of data?

austhrow743 2y ago
Some people wont give it and then they will have less data.