The use of "storage.googleapis.com" is probably because it's an "authority" domain that apps can't easily ban without side effects. Buckets can typically be used as a static site host where u can host a client side redirect, depending on how you set it up you can make it almost impossible for an app to ban a campaign in real time.
Instagram's URL Blackhole
21–30 of 52 posts
Re: Instagram's URL Blackhole
#22The use of "storage.googleapis.com" is probably because it's an "authority" domain that apps can't easily ban without side effects. Buckets can typically be used as a static site host where u can host a client side redirect, depending on how you set it up you can make it almost impossible for an app to ban a campaign in real time.
This has some good uses, by the way! VPNs and news websites that are blocked in Russia use it to either mirror content or redirect to the newest version.
Re: Instagram's URL Blackhole
#23How does Apple allow this? Here I thought the App Store was supposedly superior to the Android eco-system and that's why Apple justified the insane 30% tax on developers back then
Google Play was also 30%?
Re: Instagram's URL Blackhole
#24> CYBERSECURITY_PHISHING_FOA (likely Foreign Origin Actor)
That’s probably “Family of Apps” instead, referring to the family of apps that Meta owns (e.g. IG, FB, WhatsApp, etc)
Re: Instagram's URL Blackhole
#25How does Apple allow this? Here I thought the App Store was supposedly superior to the Android eco-system and that's why Apple justified the insane 30% tax on developers back then
Google Play was also 30%?
Yeah but Google always allowed you to bypass that by allowing users to install apps outside of their store. Whereas Apple pitched it as a security concern only to allow whoever paid them a nice fat commission
Re: Instagram's URL Blackhole
#26I want to thank you dear poster and author, I feel genuinely refreshed reading a short interesting post sans status quo topic. Waiting for the next part!
Right? It's so short and...just ends. Been too fatigued reading essays on just about everything. I loved this one.
Alas Medium interrupted my journey to that nirvana.
Re: Instagram's URL Blackhole
#27Earlier quoted context omitted.
Right? It's so short and...just ends. Been too fatigued reading essays on just about everything. I loved this one.
Alas Medium interrupted my journey to that nirvana.
I have blocked medium.com because of that. Same as the SEO spam dev.to.
It's actually interesting how often I end up seeing the uBlock 'blocked' page because of it. And how blind I end up being to the serp domains.
I of course can click the bypass button on a case by case basis.
Re: Instagram's URL Blackhole
#28Ironic the Apple App store allows a "phone antivirus" to exist.
Funnily enough that's given as an example of a prohibited type of app in their review guidelines.
@PlatoIsADisease (because dead comments can't be replied): the term WalledGarden has been a term for this and related concepts since long before marketing-speak had completed the takeover of the internet.
Re: Instagram's URL Blackhole
#29Ironic the Apple App store allows a "phone antivirus" to exist.
Almost unbelievable that they allow this - except of course they do, because scamware makes a ton of money via in-app purchase, and Apple gets 30%, so of course they do. I'm sure people will come out of the woodwork now to white knight for Apple and spin this somehow. But anything that offends their business model can be removed in minutes, while software that by its title violates the App Store rules is just here in…
I'm pretty sure that one made it through the review for some reason, you don't typically see these apps in the App Store.
Re: Instagram's URL Blackhole
#30It's fun and all, is there a way to safely host .html but does not allow rendering it? CORS? sec-fetch-dest, sec-fetch-mode and sec-fetch-site ? If storage.googleapis.com weren't operated by Google, the domain would be blocked by Google's "Safe Browsing" long time ago.
Serve it with content-type set to text/plain and browsers won't try to render it. You can try a random html file on github. If you click raw it'll get rendered as text.
This assumption has unfortunately led to countless security issues, at least in the past. The nosniff header (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...), was created because of this and should be added.
While this probably works, you should also add a restrictive CSP (using the sandbox directive).
Forcing the download (via Content-Disposition header) would likely be even better, but it is annoying for users.