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.
But you can't make a link to https://your.domain/my_phishing_page.svg work as a phishing page using service workers unless you've pretty thoroughly pwned the site already. (And you can constrain what gets to run as a service worker using Sec-Fetch-Dest!)
I suppose an actual exception is Content-Disposition. If you want the user to save a file, you need to serve it with dest == document as far as I know.
> My first thought is "support a tiny subset of svg that probably still covers 90% of real-world use cases".
It sounds like the linked post was about someone using a blacklist instead of a whitelist. It doesnt matter how tiny your subset is if you allow through stuff you don't recognize.
For the most part svg is safe. The dangerous parts are pretty obvious - script tag, image tag, feImage tag, attributes starting with on, embedding html in <foreignObject>, DTD tricks, namespace tricks, CSS that loads external stuff (keep in mind also presentational attributes. Its not just style attribute/tag).
These aren't really SVG specific issues. They are all pretty standard XSS that apply to html and are very well known vectors.
Like this post didn't even mention presentational attributes, like how cursor attribute can contain a url that gets loaded. Or any of the other tricky parts of svg sanitization, like using dtd to bypass things.
One think to keep in mind is that firefix is probably a pretty hard target. Everyone wants to try and hack a web browser. One assumes the low hanging fruit is mostly gone.
I think the fact this is even a conversation is pretty impressive.
Probably you're right, but given the browser usage-distribution, I reckon most hackers wouldn't care about firefox at this point and solely concentrate on chrome. I reckon firefox users are on average, more tech savvy and given a hack, would be able to help themselves/find out about the hack quicker than the average chrome user.
> So wouldn't we want more military service members making bets
Who is the "we" in this sentence?
Yes, insider knowledge makes the prediction market more accurate (albeit at the cost of being less "fair"). However US government doesn't want prediction markets to accurately predict the timing of their secret military operations. Hence the arrest.
I mean, surely everyone in the middle east knew a war was on the horizon. Obviously not the exact plan or day, but it wasn't a secret that usa was gearing up for a war.
I imagine they were pissed. I dont think anyone likes being in the middle of a war. Nonetheless in the weeks leading up it was clear USA was moving massive amounts of naval assets into the region. It was on the news 24/7. I'm sure everyone in the military would have been able to read the tea leaves that something was going down soonish, even if they didn't know precisely what or when.
Reddit's also famous for NSFW content. There are also stories about harrasing people who post in the "wrong" subreddit (e.g. political subreddits that are the opposite view).
reply