Would love to hear about what security problems you had.
2 Likes
There are two particular vectors that are painful
- Playing sound, so people could create really annoying topics
- Consuming high CPU by running stuff in tight loops with timers
Maybe the embed should have a mode where it runs nothing until the user opts in?
4 Likes
Yeah, or defaulting to the non-Result tab by default, be it HTML, JS, or CSS. That way the user has to select Result to get it to run.
Having a âclick to playâ mode would be ideal, as part of the embed. That is, an embed that only runs when the user initiates the action.
4 Likes
Ah yes! I just wanted to make sure they werenât really security concerns. Obnoxiousness concerns are pretty bad too though ;).
You arenât alone here. Ello decided to write their own thingy (Embetter) for embeds so that they are only loading ALL embeds on-demand. Gitter has also asked us about sound-suppression.
I totally agree that click-to-play is a great plan. Especially for oEmbed, where the whole point is that ANY Pen can be embedded and itâs directed to make it easy for user-generated-content kind of scenarios. And we can leave alone the kinda âstandardâ embed for people who are, like, writing blog posts and want to demo their stuff more directly.
Weâll work on that and get back to you.
6 Likes
it sure will 
let us know when/how and we can turn it back on
2 Likes
Hey Team!
Weâve worked on a fix for this: click-to-play, as you suggested.
We havenât deployed it yet, but it would be how all oEmbed embedded Pens would behave.
-
When the embed loads, you get a (very lightweight) placeholder with the title of the Pen and author and such. Plus a big âRun Penâ button.
-
If anywhere on there is clicked/tapped, it loads the embed.
Thus, no unexpected sound, no unexpected crazy CPU use, no going to a page with a zillion embeds and feeling the lag, etc.
That work for you?
12 Likes
Sure does! Sounds great
1 Like
Ok!
This has been deployed now. Everything feels pretty solid. Definitely let us know if thereâs anything else youâd need, to get us enabled again 
1 Like
Does this apply to all existing codepens, or does it have to be a brand new codepen? As we whitelisted it at our instance and Iâm not seeing the improvements.
@techapj can you turn codepen embeds on by default in the oneboxer now? It should be safe as they are all click-to-play per above.
1 Like
I think the way oEmbed works is that it does the oEmbed request once ever, when the content is published, than just stores what it got back forever. So it maybe wonât affect all existing embeds but only newly-posted ones.
Iâll drop a test here:
2 Likes
Further review indicates it is the .background-overlay background not being taken into account
Seems both Firefox and IE have a problem with these
background: -webkit-radial-gradient(center, ellipse cover, rgba(0,0,0,0.5) 20%, rgba(0,0,0,0.85) 100%);
background: radial-gradient(center, ellipse cover, rgba(0,0,0,0.5) 20%, rgba(0,0,0,0.85) 100%)
Because when I put
background: #ccc;
via Developer Tools in both browsers, Iâm able to get a background that is more representative of what I see in Chrome.
Ahh yep!
Fixed that now, was a little mixup with the autoprefixer. Just checked firefox again, and its all good.
4 Likes
Okay, codepen is now whitelisted by default in onebox:
https://github.com/discourse/onebox/commit/74713c3e09459428ff070e562d5b4aacd31c3d4b
5 Likes
Thatâs wonderful. Thanks for all the feedback and help and responsiveness.
3 Likes
It still dosent work⌠Did somone get a fix?
Letâs see:
http://codepen.io/ge1doot/full/MypKyq
Looks just fine to me, no idea what youâre talking about.
3 Likes