Hacker Newsnew | past | comments | ask | show | jobs | submit | grun's commentslogin

similar project https://github.com/trailofbits/claude-code-devcontainer


hey fam. i wanted to stop mousing around on Google. in turn, i accidentally made something i use all day every day

if you also like keeping your hands on the keyboard, give it a try; it could click for you, too (pun intended)


PeerCDN was too early; the web wasn't ready yet.

For example, to intercept network requests to serve them from the peer-to-peer network, a <![CDATA[ tag had to be inserted into the <head> of the document to block rendering of the subsequent document. Then, once the document had finished downloading, the page HTML was manually rendered so all assets (eg JS, CSS, images, etc tags) could be loaded via JS instead of the browser natively. This was both slow and resulted in empty white pages on load. Now? We have the Service Worker API. (https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...)

I'm not as familiar with Peer5's tech stack, so I can't speak there. But hi Shachar!


Great questions!

> How does the website possibly detect that I'm on a cellular network when I'm a) use Firefox (which doesn't implement the NetworkInformation API) and b) use a VPN to either a data center or my home server?

Yep. An IP lookup is also done to see which AS the user is on. Eg an AWS IP vs a T-Mobile IP.

We also do this to detect when people tether, as when tethering Chrome will report a Wi-Fi connection via the NetworkInforamtion API but it's Wi-Fi on top of an underlying cellular connection.

> There's also the massive privacy issue: other people will know what websites you visit by simply using the P2P system

All cached data is both fragmented and encrypted. When a node sends data to another peer, it's an encrypted fragment of a file and the sender doesn't know 1) what data it's sending nor 2) which website that data is being sent for.


Great question! All cached data is both fragmented and encrypted. When a node sends data to another peer, it doesn't know 1) what data it's sending nor 2) which website that data is being sent for.


Of course! Shoot me an email at ansgar@arc. =]


As a user, yep. But doing so as a website gets your Arc account banned and your websites blacklisted.


> There's no mention on the FAQ page how it prevents from a fake user sending malicious scripts across the network as well.

All content is fragmented, encrypted, and hashed before it's distributed across the network. If a peer ever receives a file piece from a peer and that piece's hash doesn't match the expected hash, it's dropped along with the connection to that peer.


> All content is fragmented, encrypted, and hashed before it's distributed across the network. If a peer ever receives a file piece from a peer and that piece's hash doesn't match the expected hash, it's dropped along with the connection to that peer.

So, depending on the hashing algorithm, an adversary could use a hash collision to circumvent this, right?


Very! The lifetime of nodes is actually quite a bit longer than 5 minutes as the tab doesn't need to be foregrounded (which Google Analytics and others report as the end of the 'session'). That, and when a node comes online, it joins the network with the cache contents it had filled previously. So it joins the network warm, not cold and needing to be filled.


Interesting.

Is the cache shared between all the websites that install this product?

What happens to a HTTP request to a browser whenever they close their tab, is it retried on another browser?


Not quite. =] Arc coordinates and synchronizes across tabs (via an iframe). So Arc behaves identically whether you have one open tab with Arc or 100.


Aren't tabs supposed to be sandboxed?


Origin should be sandboxed rather than tabs, isn't it?


Sounds like the iframe is used to glue sandboxes together


Nicely done.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: