8 ms·

> Your WiFi information is never sent to the server. This makes me think that we could use some flag that identifies purely static websites. Like next to the g

> Your WiFi information is never sent to the server. This makes me think that we could use some flag that identifies purely static websites. Like next to the green https lock there is a sign that this website can not send data to any server

abahlo 5y ago
That would me amazing
secureleaf 5y ago
This a great idea but it would be difficult to implement. Sure, it would be easy to catch (and block) HTTP requests other than OPTIONS and GET. But even a GET request can be used to send data. Just pack the data you want to send in the query string and voila.
- outericky 5y ago
  So don’t allow GET with query params. You want the static moniker? It has to be static. No server interaction after load, and no sending any data during load.
  - city41 5y ago
    You can still hide the data in "folders". /foo/bar/baz/buz can be totally dynamic on the server.
    - ericfrederich 5y ago
      How about after load, that tab automatically goes completely offline. Users can manually do this in Chrome on a tab by tab basis by using developer console and setting Throttling to "Offline"
      - richthegeek 5y ago
        Note that the "offline" mode in devtools doesn't kill any websocket connections. It may have other holes i'm not aware of also.
      - city41 5y ago
        That sounds more promising. The site might be able to store data and then send it the next time the page is loaded. I think at the end of the day, a malicious dev could probably find a workaround to most implementations. Might just be better to vet out sites and use reputation to state they are truly offline.
        ericfrederich 5y ago
        I hear what you're saying, but I also believe this to be a solvable problem
    - codethief 5y ago
      Or in the subdomain, using "DNS exfiltration": https://twitter.com/rsobers/status/1293539543115862016 https://twitter.com/rsobers/status/1293539543115862016
      - city41 5y ago
        That's an interesting exploit, thanks for sharing.
- pkulak 5y ago
  Just some JS call like "startStatic()". At that point, all network activity is shut down for good, and the page gets a badge.
steviedotboston 5y ago
I wonder if this could be a browser extension
Ajedi32 5y ago
I think something like that might be feasible in the future with things like web bundles[1] and content security policy[2]. In theory you could have a site loaded as a bundle and a CSP that blocks everything not loaded through the bundle, effectively cutting off all network access. You'd probably also need some sort of Feature-Policy[3] that prohibits access to any form of persistent storage so sites can't just save data until the next non-CSP-protected page load and transmit it then. [1]: https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html https://wicg.github.io/webpackage/draft-yasskin-wpack-bundle... [2]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP [3]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Fe...
quickthrower2 5y ago
What if it didn't send anything to the server. Today. But stored it in local storage. And sends it next week when you come back.
- runeks 5y ago
  Don't allow that. When a site registers as "local", which gives it the "local" badge, do not allow the site to switch back to non-local. Perhaps the site could be allowed to update itself. But this update function should not have access to any local/client state.

abahlo 5y ago

That would me amazing

secureleaf 5y ago

This a great idea but it would be difficult to implement. Sure, it would be easy to catch (and block) HTTP requests other than OPTIONS and GET. But even a GET request can be used to send data. Just pack the data you want to send in the query string and voila.

outericky 5y ago
So don’t allow GET with query params. You want the static moniker? It has to be static. No server interaction after load, and no sending any data during load.
- city41 5y ago
  You can still hide the data in "folders". /foo/bar/baz/buz can be totally dynamic on the server.
  - ericfrederich 5y ago
    How about after load, that tab automatically goes completely offline. Users can manually do this in Chrome on a tab by tab basis by using developer console and setting Throttling to "Offline"
    - richthegeek 5y ago
      Note that the "offline" mode in devtools doesn't kill any websocket connections. It may have other holes i'm not aware of also.
    - city41 5y ago
      That sounds more promising. The site might be able to store data and then send it the next time the page is loaded. I think at the end of the day, a malicious dev could probably find a workaround to most implementations. Might just be better to vet out sites and use reputation to state they are truly offline.
      - ericfrederich 5y ago
        I hear what you're saying, but I also believe this to be a solvable problem
  - codethief 5y ago
    Or in the subdomain, using "DNS exfiltration": https://twitter.com/rsobers/status/1293539543115862016 https://twitter.com/rsobers/status/1293539543115862016
    - city41 5y ago
      That's an interesting exploit, thanks for sharing.
pkulak 5y ago
Just some JS call like "startStatic()". At that point, all network activity is shut down for good, and the page gets a badge.

steviedotboston 5y ago

I wonder if this could be a browser extension

Ajedi32 5y ago

I think something like that might be feasible in the future with things like web bundles[1] and content security policy[2]. In theory you could have a site loaded as a bundle and a CSP that blocks everything not loaded through the bundle, effectively cutting off all network access. You'd probably also need some sort of Feature-Policy[3] that prohibits access to any form of persistent storage so sites can't just save data until the next non-CSP-protected page load and transmit it then. [1]: https://wicg.github.io/webpackage/draft-yasskin-wpack-bundled-exchanges.html https://wicg.github.io/webpackage/draft-yasskin-wpack-bundle... [2]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP [3]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Feature-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Fe...

quickthrower2 5y ago

What if it didn't send anything to the server. Today. But stored it in local storage. And sends it next week when you come back.

runeks 5y ago
Don't allow that. When a site registers as "local", which gives it the "local" badge, do not allow the site to switch back to non-local. Perhaps the site could be allowed to update itself. But this update function should not have access to any local/client state.