I've not looked into it but I suspect this uses eligibilityd, the same thing that does the location based checks to see if EU users can use 3rd party app stores.
From what I remember it uses a combination of things like your current GPS location, your SIM cards reported country and more to determine what country you're really in to restrict certain features.
So it's not as simple as swapping your location in settings, or even traveling to somewhere in the EU, theres a certain sticky-ness to what your device thinks is your current country.
It'd be nice if there was a sandbox attribute you could add to inline <svg> tags, like the <iframe sandbox> attribute that'd let you opt out of all the potentially "dynamic" stuff inside of an SVG like scripts and event handlers, or even just literally sandbox the entire thing from accessing the "parent" HTML page's context/cookies/etc just like an iframe.
I'm sure it'd just open up a whole other can of worms though... not to mention having to wait for browsers to actually support it.
The real solution here is definitely CSP + basic sanitisation though.
Most of the aspects the author was critiquing are actually just regular CSS features, they simply don't want any external requests. Effectively they want inlined SVGs to be treated like how the browsers treat IMG-embedded SVGs (no scripting or external requests loaded).
Sanitization-wise it's already possible to strip scripting from SVGs and anything else you want, it's just that a library like DOMPurify to avoid ballooning in size doesn't include say a preset to handle the extra parsing necessary to make them behave like browsers treat IMG embeds, so it's up to devs to add their own.
But yeah, a world where a simple attribute to achieve the same effect as an IMG embed but for inlined SVGs would be nice.
Exactly. It's not a good solution where you have to read a bunch of steps to do to make SVG safe, where you're worried you forgot one. Instead there should be a straightforward <svg exec="false"> or whatever that simply and comprehensively disables the unsafe features.
Think of prior technologies like display postscript and .doc, where a data format ended up a with big problems from its embedded "exec" type features.
Thankfully if you have CSP you don't need even basic sanitization, which is useful because most of the problems in this article are demonstrations of how simple sanitization isn't simple at all.
I dont see how that could work, as an <svg> tag in html is not a document boundry. How can you prevent it from accessing a parent doc when its not a separate document.
> How can you prevent it from accessing a parent doc when its not a separate document.
By turning it into a document boundary when you use the sandbox attribute, kinda similar to loading an svg file inside of an <img> tag.
and yeah you could get 90% of the way there with an iframe srcdoc, but I was imagining some kind of cross between an <iframe> sandboxed into its own origin, and an <img> where it still has its own intrinsic size.
but it was mainly just a throw away thought, I've not really thought it through much deeper than that.
The main use case I was thinking of is being able to use an inline SVG, but with external resources inside of it (like say a CSS background image using url(...)) in such a way that it ends up loading that embedded content in a cross-origin anonymous way and blocking all embedded scripts. That way someone can't make requests to CSRF exploitable URLs by setting an embedded images to something like example.com/my-submission/favourite
But also so that setting up a CSS transform: scale(10000) can't take over the entire viewport, it'd be constrained to an iframe-like boundary (exactly like an <img>) but still remain as an inline SVG, sort of like an <iframe srcdoc>. So scripts on the parent/host HTML document can still manipulate it like the rest of the DOM, but the inner <svg> elements are all "inert" for want of a better word.
Actually I don't know off the top of my head what happens with an SVG file inside of a <img> when it references external images (either cross-domain or not.) I know scripts and animations get disabled, so I'd take a guess and say some CSS gets blocked too.
Again I've not really thought terribly hard about it, or if it's actually useful at all, and I'm betting it'd be filled with even more foot-guns than there are right now. I'm just thinking out loud.
This is not sufficient to stop XSS, because an attacker can redirect users to file.svg URL as the top-level document, bypassing restrictions of <img>.
If you're going that route, add CSP headers on HTTP level to disable scripting, and/or host the SVG on a separate domain that has nothing valuable, or use data: URLs.
It's not quite the same, but I've moved to using *.localhost for all my local web dev work. All modern browsers will resolve *.localhost to 127.0.0.1 internally. No need to setup any DNS resolvers or edit your hosts file.
But that only really helps you when you're dealing with websites in a browser, and when you want the address to resolve back to your local machine. So it wont help you with other programs like python/wget/etc or any calls you make to getaddrinfo()
The best part is that *.*.localhost is also supported, so you can finally just replace *.com for your prod domains with *.localhost.
ArchiveBox now uses this feature by default in the latest version to finally offer unique per-snapshot domain isolation, so we can safely replay archived JS without risking compromise of your whole archive.
Such an awesome feature, the barrier to do this used to be prohibitively high but now it "just works".
Just tried it on my Mac and sadly it doesn’t seem like it. I’m still on Sequoia, so possibly it does it on Tahoe, but probably unlikely. That’s a shame.
It’d be nice if someone on the Safari team added this though to match Chrome and Firefox!
> But that only really helps you when you're dealing with websites in a browser, and when you want the address to resolve back to your local machine. So it wont help you with other programs like python/wget/etc or any calls you make to getaddrinfo()
Yeah I've been doing this as well. I know it's a minor nit, but I wish that TLD was shorter. I've used *.local in the past but that has bitten me too many times.
Haven't had an issue yet, with a team scattered across US, Canada and UK. I'm sure it's possible - but so far we've been using this for about 3 years with no hiccups.
Little bit saddened the sqlite provider doesn't use the SQLite archive format under the hood. Seems like it'd be a good fit for what they're trying to achieve + give you an easy way to create/extract the files out of the virtual file system.
The sqlar schema is missing some of the info thats being stored atm, but there's nothing stopping you from adding your own fields/tables on top of the format, if anything the docs encourage it. It is just a sqlite database at the end of the day.
I'm not sure why the Falkirk Wheel keeps getting posted to HN, but hey I'm not gonna complain!
I'll repost what I shared last time though, there's another much older boat lift on the canal network that solves a similar problem of transporting boats from the canal up and down to a river, but built with Victorian engineering instead (though it's been retrofitted a few times) called the Anderton Boat Lift, and it's worth a visit!
Just a guess but why do I get the feeling it’s because someone who setup sei.co.jp in Azure Entra (aka Azure AD) some how managed to add/claim the domain “example.com” against their companies tenant.
It’s clearly not using the DNS records for discovery because they don’t exist, the only other option I can see is some weird fall through or hard coded value and it seems like an odd one to pick.
From what I remember it uses a combination of things like your current GPS location, your SIM cards reported country and more to determine what country you're really in to restrict certain features.
So it's not as simple as swapping your location in settings, or even traveling to somewhere in the EU, theres a certain sticky-ness to what your device thinks is your current country.
Edit: bit more info on eligibilityd here https://theapplewiki.com/wiki/Eligibility#eligibilityd
reply