Dan: Took a look. change itself is fairly small. Using use with a document without an ID, so it grabs the whole thing. Should we use it at all? Main issues are that fetch integration isn't defined, and there's a history of security issues. I'm not personally familiar with those. Cross-document stuff might come to mind, and browsers I've tested on don't load at all cross-document. Can fork-bomb too. This doesn't affect that. Seems fairly innocuous. I'd propose that this change is fine, but caution that when doing too much with use in the future, prefer to fix the existing spec questions around Fetch integration.

Martin: Does this uniquely make DoS attacks worse, or just another version of it that you'd get with <g>?

Dan: It's really easy now, with the current thing. Their thing doesn't add anything.

Martin: [fork-bombs himself]

Jeffrey: Your opinion sounds reasonable to me. I think Xiaocheng had concerns, so can you work with Xiaocheng to write a consensus comment?

Dan: Will do.

Dan: Back-and-forth in the github thread. Good point by Xiaocheng about not extending problematic features. So it's nuanced here. There's at least one real problem with <use> in general, a DoS attack. Is there a nuance that we're missing: not all usage of the feature is problematic. Example in design principle was alert(). With <use>, there's a malicious use, and the use we're targeting here isn't actually bad in any way.

Martin: Difficult for me. Collectively, we have a responsibility to ensure that browsers aren't vulnerable to the DoS attack in general. Question is whether this is building on top of something that's busted enough that we could ask the proponents to do something about it. I don't think so. They're just using <use> in the way it always had been. They're not making the problem worse by adding more ways to activate the bug. But we should ask them to say they're aware of the problem, and that it's pretyt serious. Obviously that sites that don't want to break browsers won't trigger it, since they'll test. But there's a resource exhaustion issue, and we'd like them to spend the time to think about it and try to find a way to deal with it. I think browsers should stop trying to infinitely render SVG once it's not working.

Marcos: Like scripts locking up.

Martin: But we have protections against scripts. The SVG renderer is just YOLO.

Xiaocheng: Do we think of it as making the web worse if a slightly problematic feature gets increased usage? So increased number of affected users.

Martin: Don't think so, because the non-abusive cases vastly outnumber the abusive uses. Browsers have a responsibility to do something about this. But i'd open a security bug and see what happens.

Xiaocheng: What are the benefits for end-users of allowing this new kind of <use>?

DanC: For end users, it's mostly a no-op. For developers, say I get an SVG from a designer, but to reference it I'd need to add an ID. Save the developer time. Doesn't change anything for the end user.

Xiaocheng: So no direct impact.

Jeffrey: Developers are still the second part of the priority of constituencies, so it's worth helping them.

Martin: Potential benefits: if someone has an SVG that you want to use. Can just use it without having to change the structure.

DanC to write a comment.

Martin: Tantek found an HTML include system from a long time ago, and pointed out that you can use SVG's <use> in the same way.

DanC: I did some more research on how you can exploit SVG <use>. Many have been patched, but there are dragons. We should caution folks to be careful. If people are spending time, they should fix issues like the unspecified Fetch integration. Despite the overall weirdness, this is a straightforward improvement.

Martin: Do you think there are problems with viewport or other things? If the image contains content outside the viewport, is it the image or the viewport that's pulled in?

Jeffrey: I feel like that's not a difference between whole-SVG and fragment.

Martin: It is because the whole SVG has a viewport, while the fragment doesn't. Don't know what the right answer is.

Jeffrey: But they do have to specify it. Ah, they have "if the referenced element defines a viewport (i.e., if it is a ‘svg’ or ‘symbol’)" in the spec. (https://svgwg.org/svg2-draft/struct.html#UseElement) So I think it was already defined.

Jeffrey: I think we should give Xiaocheng a chance to give feedback, and then post. Let's say he has until Wednesday.

DanC: Should I post or have a full TAG member post.

Martin: We should own it.

Jeffrey: I'll check Wednesday and then post it.