- afaik no openai or anth model weight have been leaked to date
- confidential computing and trusted execution environments (TEEs) are the strongest primitive yet invented to prevent model weight exfiltration. there are other techniques. like bandwidth limiting of GPU workers and key sealing. but none as strong as those afforded by confidential computing and TEEs
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!
> 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.
> 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.
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.
In the past, I built two of the world's largest YouTube to MP3 converters. In doing so, I learned the hard way 1) that distributing content at scale globally is painful and _expensive_ and 2) that I hate ads. So I built Arc.
It's a two-sided content exchange. On one side, websites buy a faster, 10x cheaper peer-to-peer CDN. On the other side, websites make money without ads by contributing bandwidth to the peer-to-peer CDN. Arc connects the two, like Airbnb connects guests and hosts.
As bandwidth capacity grows around the globe, we find ourselves in a world where people can share bandwidth both beneficially and imperceptibly. We see glimpses of that already today: Amazon shares bandwidth with Amazon Sidewalk, Microsoft shares bandwidth with Windows updates, etc. We build Arc for this world -- a post-adblock world -- to give sites a better, more ethical way to support themselves that doesn't bombard users with ads, suck up their personal data, and preserves their privacy.
- For sites that monetize with Arc, we mandate that Arc's widget remains visible and intractable in the lower left corner of your website so users can learn about Arc and, if they so desire, opt out. (See https://arc.io/faq#can-i-move-modify-or-hide-arcs-widget) Additionally, Arc never activates on cellular connections; Wi-Fi and ethernet only.
- If you elect to opt out (two clicks in Arc's widget), you're opted out of all sites with Arc.
Please email me if you'd like an invite code to take Arc's CDN for a spin: [email protected]. It's 10x cheaper than Fastly, AWS, Google, etc. (See http://arc.io/cdn/). And I'd love to hear your thoughts! Feedback is how good products become great.
Arc plays nicely with adblocks. And users are always presented (via Arc's graphical widget that sites can't hide) the option to learn about Arc and opt out in two clicks/taps if they so choose.
Yep! Browser-to-browser peer-to-peer connections are established over WebRTC, data (fragmented, encrypted file pieces) flow over the WebRTC data channel, and the data is encrypted in transit with DTLS.
Hey! I'm Ansgar. I build Arc. The impact is negligible. Notably, Arc never uses cellular connections -- both to preserve battery life and never use cellular data. Wi-Fi (or ethernet) only. And all activity ceases as soon as the tab with Arc is closed.
- confidential computing and trusted execution environments (TEEs) are the strongest primitive yet invented to prevent model weight exfiltration. there are other techniques. like bandwidth limiting of GPU workers and key sealing. but none as strong as those afforded by confidential computing and TEEs
- see https://confidential.ai/docs/confidential-computing-primer for a primer on confidential computing
- using confidential computing and TEEs to protect model weights in use is an area of active research
note: i work on confidential.ai