It was a trivial half-hour project that I sunk-cost-fallacied into a couple of hours. I wanted to embed LinkedIn into our recruiting lead qualification tool so that you don't have to open a new tab (it's right on the page in a two-pane display). It was enough of an improvement that people could just start their day, qualify some 10 leads, and then bang on with the day. We had a chap build it and it worked really well actually till SameSite became required on Chrome. Opening in a new tab was frustrating enough that people would feel like maybe doing a couple and then push it to the rest of the day and it would fall by the wayside against their "real job", so to speak. Besides, they'd be doing it feeling like an obligation which I don't think puts one in the right frame of mind.
Yeah, so I think this is pretty much the a kind of scenario the feature is designed to break - an essentially stock browser navigating to some site, that can then wrap a trusted site, and potentially be a stepping stone for phishing or other nastiness. Obviously, if you have detailed control over the client - everything goes! But for fairly standard browsers, you don't want to allow this kind of nesting; at least not when the two sites aren't cooperating (and clearly linkedin isn't).
It's possible there's some addon api to work around this, otherwise you'll need to use a proxy - which isn't too hard, really. Essentially: you need to have admin level control over the browser to allow this, or some other proxy; the browser won't allow a random website to see another site's cookies, even indirectly - which is by design.
So in your case: since this is a feature, not a bug - a trivial workaround looks unlikely.
