Content
@
0 reply
4 recasts
4 reactions
Varun Srinivasan
@v
Frames are now privacy preserving! Your IP address is no longer visible to frame authors. All requests are proxied via Warpcast's backend servers to keep your clients private. A few caveats: - This change just went live, there may be bugs - Clicking a button will expose your username (but not IP) h/t to @sds!
28 replies
27 recasts
307 reactions
jtgi
@jtgi
hey v, base64/png encoded images are no longer loading through the proxy. 500 image request url. Dead end debugging on my side. - Old frames (not thru the proxy) still load fine. - Validator doesn't use proxy, have to test in-feed. - tried with tiny base64 no luck
1 reply
0 recast
0 reaction
jtgi
@jtgi
example url: https://glass.cx/test-proxy Click the thumbnail to view source. This strings are admittedly long (14974 chars), but I tried with tiny ones also and they failed.
1 reply
0 recast
1 reaction
Shane da Silva
@sds
We were hesitant to add support for data URIs since they have been used to construct attacks. [1] Can you help us understand why you want to return a 14.6KB base64-encoded string instead of 11KB raw PNG byte stream? [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs#security_issues
2 replies
0 recast
0 reaction
Shane da Silva
@sds
Sorry, I'm realizing that an advantage is you don't need to "host" a separate endpoint to serve the image—it's included directly in the document. Let me discuss with the team and see where we stand.
1 reply
0 recast
0 reaction
Shane da Silva
@sds
Following up here, @jtgi, looks like we should be able to pass through a certain subset of data URIs (specifically ones for common image/* MIME types). That change has been deployed. Let us know if you're still seeing issues? And thanks for raising.
0 reply
0 recast
0 reaction
