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!
29 replies
29 recasts
207 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
0 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
jtgi
@jtgi
Yeah, they're too big. > why giant base64 Saves money and time, I don't have to store anything on disk. Just return a string to `<meta property="fc:frame:image" content="base64/....". But I'll implement proper png support; the design is sensible.
1 reply
0 recast
0 reaction
