4 ms·
wow, we are literally working this problem right now, and I made an off hand comment that it'd be nice if Figma shared how they did their plugins. thank you for
by gfodor 7y ago
wow, we are literally working this problem right now, and I made an off hand comment that it'd be nice if Figma shared how they did their plugins. thank you for this!
edit: having now read the article, this is amazing, lots of get insights here. one question to the author if you are reading: it seems like it would be a worthy idea to open source the 500 line, security-sensitive interface Realm-shim. Selfishly, we would use it, but also, we (and surely others) would add eyeballs to it to ensure it's correct. Since it's a small slice of the system, and agonistic to the product itself, it seems unlikely to be part of any kind of technical competitive advantage. Any plans to do so?
- yuchi 7y agoLet me DuckDuckGo it for you: https://duckduckgo.com/?q=javascript+realm+shim https://duckduckgo.com/?q=javascript+realm+shim
- rudi-c 7y agoI think he's asking about the layer we built on top of the shim to copy objects in and out of it. It's open-sourceable, we can consider it.
- derp_dee_derp 7y agothink about this for a second: your competitor is asking to copy your work. If I were you, I wouldn't assume good intentions especially considering you are just a start up and in a race for marketshare. If it were up to me, I would set a date a year or two in the future and then open source it then, but only AFTER you have a large enough lead against your competitors in the market. There is no reason that I can see to open source the secret sauce of your entire product.
- gfodor 7y agowe're not competing with Figma (though we are happy customers), and we already open source everything we do, we're Mozilla.
- yuchi 7y agoI see only now your reply (I’m the “let me DDG it for you" guy). Sorry for my unelegant answer!
- Me1000 7y agoEven if they were a competitor, it's still something worth sharing. I wish more companies shared technology that made software more secure. We're kinda of all in this together. Security shouldn't be a feature or a competitive advantage, it should be a standard practice that all developers follow and participate in. Everyone benefits when software is more secure.
- somebadguy 7y agoMoron
- gfodor 7y agothanks!
- cxr 7y agoHey, Greg. Former Mozillian here. Mozilla's very own Allen Wirfs-Brock started work on this sort of thing back in 2011 or so, called jsmirrors. The idea at the time was to inform the design of some reflection/sandboxing APIs that might make their way into the TC39 spec, but nothing really came of it. Several years later I had a use case, only with security being the foremost concern, so I did a bunch of redesign and implementation work on that, including bugfixes and adding good handling of primitives. So there's already code available (around ~1100 here) for the kind of membrane described in the Figma post. (At least it's halfway there; Allen's original work let you poke remote objects by way of serializing to JSON, and I neglected that area since it wasn't useful to my immediate use case and would have slowed me down--it sounds like you'd might need to stick something like that back in. For my own use as a consumer, I just ended up instead leaning on implementation-dependent details that I knew I could rely on from the way SpiderMonkey was hosted in Gecko.) This was born in Mozilla, so it's already MPL2, and there wouldn't be any licensing issues. Caveat: only ever targeted ES5, so changes for new JS features like proxies, symbols, and other ES6+ stuff almost definitely violates some invariants, but I couldn't tell you offhand whether that could manifest as security issues. The tests still pass. Poke at it if you want: cd /keybase/public/crussell/projects/jsmirrors && npm test ... or double click tests/harness.app.htm and point it to the jsmirrors/ directory if you aren't comfortable giving unfettered access to arbitrary pieces of code you find on the Internet (and you shouldn't be).