Live data from Hacker News

Show HN: Print a WiFi Login Card

wificard.io

301–310 of 347 posts

Re: Show HN: Print a WiFi Login Card

#301
post #299

Earlier quoted context omitted.

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.

You can still hide the data in "folders". /foo/bar/baz/buz can be totally dynamic on the server.

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"

Re: Show HN: Print a WiFi Login Card

#302

> 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

I wonder if this could be a browser extension

Re: Show HN: Print a WiFi Login Card

#303
post #299

Earlier quoted context omitted.

You can still hide the data in "folders". /foo/bar/baz/buz can be totally dynamic on the server.

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"

Note that the "offline" mode in devtools doesn't kill any websocket connections. It may have other holes i'm not aware of also.

Re: Show HN: Print a WiFi Login Card

#306
post #299

Earlier quoted context omitted.

You can still hide the data in "folders". /foo/bar/baz/buz can be totally dynamic on the server.

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"

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.

Re: Show HN: Print a WiFi Login Card

#307
post #34

qrencode -t utf8 'WIFI:T:WPA;S:network;P:password;;'

If you want some interactivity (bash): read -rp "SSID: " ssid read -rsp "Password: " pass echo -e "\n" qrencode -t utf8 "WIFI:T:WPA;S:$ssid;P:$pass;;" echo "SSID: $ssid" Even better, generate a PDF with emojis and all! #!/usr/bin/env bash out="${1:-wifi-card.pdf}" read -rp "SSID: " ssid read -rsp "Password: " pass echo -e "\nGenerating PDF..." { cat SSID: $ssid Password: $pass Point your phone's camera at the QR Code…

Note to anyone blindly cutting and pasting this, the final EOF needs to be alone on the line with no indentation (VSCode did me a disservice and formatted it poorly which confused the hell out of shellcheck but left me learning something today, which was nice).

Re: Show HN: Print a WiFi Login Card

#309

> 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

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.

Just some JS call like "startStatic()". At that point, all network activity is shut down for good, and the page gets a badge.

Re: Show HN: Print a WiFi Login Card

#310

> 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

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-bundle...

[2]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP

[3]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Fe...

Post reply on HN