ActivityPub Viewer

A small tool to view real-world ActivityPub objects as JSON! Enter a URL or username from Mastodon or a similar service below, and we'll send a request with the right Accept header to the server to view the underlying object.

Open in browser →
{ "@context": [ "https://www.w3.org/ns/activitystreams", { "ostatus": "http://ostatus.org#", "atomUri": "ostatus:atomUri", "inReplyToAtomUri": "ostatus:inReplyToAtomUri", "conversation": "ostatus:conversation", "sensitive": "as:sensitive", "toot": "http://joinmastodon.org/ns#", "votersCount": "toot:votersCount", "litepub": "http://litepub.social/ns#", "directMessage": "litepub:directMessage" } ], "id": "https://infosec.exchange/users/saraislet/statuses/109426796659015479", "type": "Note", "summary": null, "inReplyTo": "https://infosec.exchange/users/saraislet/statuses/109426613081652784", "published": "2022-11-29T11:13:28Z", "url": "https://infosec.exchange/@saraislet/109426796659015479", "attributedTo": "https://infosec.exchange/users/saraislet", "to": [ "https://www.w3.org/ns/activitystreams#Public" ], "cc": [ "https://infosec.exchange/users/saraislet/followers" ], "sensitive": false, "atomUri": "https://infosec.exchange/users/saraislet/statuses/109426796659015479", "inReplyToAtomUri": "https://infosec.exchange/users/saraislet/statuses/109426613081652784", "conversation": "tag:infosec.exchange,2022-11-29:objectId=25209978:objectType=Conversation", "content": "<p>How to secure a Content Distribution Network (CDN):</p><p>1. If you don&#39;t have servers, no one can steal them. This approach is upsetting to executives; do not recommend.</p><p>2. If you don&#39;t connect servers to the internets, the servers are safe from most anything other than physical theft. The &quot;Network&quot; part of CDN is missing.</p><p>3. If you don&#39;t store data, your CDN is safe from data theft. The &quot;Content&quot; part of CDN is missing. The CDN may still be a vector for pivoting into other systems in your infrastructure, or could be used as a botnet or for griftocurrency miners, or as a cost center for other departments to use as an example. Hopefully a good example.</p><p>4. The less sensitive your data, the less risk you take on. But public data doesn&#39;t mean zero risk: What could an attacker do if they put malicious content on your CDN? Anything from CSAM to ransomware JavaScript that clients download and run.</p><p>5. You&#39;re gonna want to log things. Network flow logs, audit logs, system logs, error logs, access logs, logs logs logs, everyone wants a log. Depending on your business, logging which IP address requested what resource may be important data to collect. That non-sensitive data from #4? Connecting any ID to that in a log now makes that sensitive data. Don&#39;t play games with &quot;well it&#39;s not THAT sensitive&quot; nor &quot;but we hashed it so it&#39;s anonymized&quot;. Bring that stinky diaper straight to Legal, Privacy, then Cryptography — in exactly that order, do not pass Go, do not collect $200.</p><p>6. Don&#39;t keep logs or data or packages or services or features you don&#39;t need, don&#39;t provide access you don&#39;t need, don&#39;t trust anything you don&#39;t have to. The fewer features you support, the less data you keep, the less data that touches a drive (or swap, or memory) in the first place, the better you can design your CDN from the ground up to be more resilient and more secure.</p><p>7. Do not under any circumstances assume that #6 will never change. Know what&#39;s coming down the road. Don&#39;t fall for the classic software blunders by over-engineering against all possible futures.</p><p>8. Do not under any circumstances assume that any one layer of controls is sufficient. You may accept the risk, with awareness and intent—but never assume. You will thank me when #7 bites you and you have an extra layer of winter clothing. You&#39;re welcome.</p><p>&quot;I thought you said that your dog doesn&#39;t bite&quot;<br />&quot;He doesn&#39;t! That is not my dog!&quot;<br />- The Pink Panther Strikes Again</p>", "contentMap": { "en": "<p>How to secure a Content Distribution Network (CDN):</p><p>1. If you don&#39;t have servers, no one can steal them. This approach is upsetting to executives; do not recommend.</p><p>2. If you don&#39;t connect servers to the internets, the servers are safe from most anything other than physical theft. The &quot;Network&quot; part of CDN is missing.</p><p>3. If you don&#39;t store data, your CDN is safe from data theft. The &quot;Content&quot; part of CDN is missing. The CDN may still be a vector for pivoting into other systems in your infrastructure, or could be used as a botnet or for griftocurrency miners, or as a cost center for other departments to use as an example. Hopefully a good example.</p><p>4. The less sensitive your data, the less risk you take on. But public data doesn&#39;t mean zero risk: What could an attacker do if they put malicious content on your CDN? Anything from CSAM to ransomware JavaScript that clients download and run.</p><p>5. You&#39;re gonna want to log things. Network flow logs, audit logs, system logs, error logs, access logs, logs logs logs, everyone wants a log. Depending on your business, logging which IP address requested what resource may be important data to collect. That non-sensitive data from #4? Connecting any ID to that in a log now makes that sensitive data. Don&#39;t play games with &quot;well it&#39;s not THAT sensitive&quot; nor &quot;but we hashed it so it&#39;s anonymized&quot;. Bring that stinky diaper straight to Legal, Privacy, then Cryptography — in exactly that order, do not pass Go, do not collect $200.</p><p>6. Don&#39;t keep logs or data or packages or services or features you don&#39;t need, don&#39;t provide access you don&#39;t need, don&#39;t trust anything you don&#39;t have to. The fewer features you support, the less data you keep, the less data that touches a drive (or swap, or memory) in the first place, the better you can design your CDN from the ground up to be more resilient and more secure.</p><p>7. Do not under any circumstances assume that #6 will never change. Know what&#39;s coming down the road. Don&#39;t fall for the classic software blunders by over-engineering against all possible futures.</p><p>8. Do not under any circumstances assume that any one layer of controls is sufficient. You may accept the risk, with awareness and intent—but never assume. You will thank me when #7 bites you and you have an extra layer of winter clothing. You&#39;re welcome.</p><p>&quot;I thought you said that your dog doesn&#39;t bite&quot;<br />&quot;He doesn&#39;t! That is not my dog!&quot;<br />- The Pink Panther Strikes Again</p>" }, "attachment": [], "tag": [], "replies": { "id": "https://infosec.exchange/users/saraislet/statuses/109426796659015479/replies", "type": "Collection", "first": { "type": "CollectionPage", "next": "https://infosec.exchange/users/saraislet/statuses/109426796659015479/replies?min_id=109426852597881201&page=true", "partOf": "https://infosec.exchange/users/saraislet/statuses/109426796659015479/replies", "items": [ "https://infosec.exchange/users/saraislet/statuses/109426852597881201" ] } }, "likes": { "id": "https://infosec.exchange/users/saraislet/statuses/109426796659015479/likes", "type": "Collection", "totalItems": 41 }, "shares": { "id": "https://infosec.exchange/users/saraislet/statuses/109426796659015479/shares", "type": "Collection", "totalItems": 15 } }