kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
griff_ has quit [Quit: griff_]
griff_ has joined #sandstorm
griff_ has quit [Quit: griff_]
griff_ has joined #sandstorm
nicoo has quit [Remote host closed the connection]
nicoo has joined #sandstorm
griff_ has quit [Quit: griff_]
frigginglorious has joined #sandstorm
<ill_logic> I don't know if this was mentioned before, but what if there's a big red warning for users that an app is no longer considered secure?
<ill_logic> At least for an interim? It's an intermediate nudge to get people to update their apps. But if people really need it they can use it.
<JacobWeisz[m]> I mean, I'd rather use an app with some styling broken than one that isn't secure.
<ill_logic> Oh if it's just css then sure.
<JacobWeisz[m]> And for the majority of apps which aren't broken by these changes, I'd rather not have a not-secure warning when it works fine in the more secure mode.
<JacobWeisz[m]> I think like the worst we are looking at is the math functions for a couple apps.
<JacobWeisz[m]> That probably aren't core functionality to begin with.
<ill_logic> BTW I mentioned a while ago the idea of having a test suite that covered all apps in the store. People didn't think it would be valuable.
<ill_logic> Not that I think it should be a priority, but I think this is an example of where it could be helpful. Some changes in Sandstorm could affect apps in surprising way.s
<JacobWeisz[m]> I think it's mostly the amount of work for the benefit with our available resources there. We don't break the app platform often.
<ill_logic> An issue of priority then, okay.
<JacobWeisz[m]> The two major changes Ian has PR'd are big technical debt items that once cleared out should leave us in a long term much better place... but do cause some immediate breakage.
<isd> Yeah, I don't anticipate having to break apps for security reasons being a recurring theme for long.
frigginglorious1 has joined #sandstorm
frigginglorious has quit [Ping timeout: 256 seconds]
frigginglorious1 is now known as frigginglorious
<mnutt> I've been a little out of the loop, I take it there's a security issue that will require apps to update?
<isd> Most apps should be fine (I tested davros, you're good)
<isd> And the issue isn't really news -- just getting around to closing some of the known, documented holes.
frigginglorious has quit [Read error: Connection reset by peer]
<TimMc> CSP?
<isd> Bingo.
<mnutt> ah ok
<mnutt> that's great to see
<mnutt> nice to have a technical restriction that enforces the way apps are _supposed_ to work, anyway
frigginglorious has joined #sandstorm
<isd> Yeah. What prompted me to do it was the mailing list thread in which ocdtrekkie had not even noticed that the app he was packaging was pulling in stuff from a CDN; ill_logic pointed it out.
<TimMc> How cool would it be to have a report-only mode where the framing warns you about all the "naughty" stuff the grain is doing?
<isd> I was like "This should fail loudly"
<mnutt> extremely old versions of davros were pulling in Google Fonts and I didn't actually notice until turning on CSP
<TimMc> (I half-remember some conversation about this, come to think of it...)
<isd> TimMc: Most stuff doesn't break badly for it to seem worth the trouble. For images/audio/video I'm thinking of using csp reports to do an email-style "some images were blocked for your privacy [click to show images]" style UI
<isd> badly enough
<isd> The PR does add an (undocuented) config option to sandstorm.conf to turn the CSP back off -- which we'll remove after a grace period -- in case somebody has a private app that is horribly broken and they come to us asking for more time to port their app.
<TimMc> That would be pretty amazing.
<TimMc> It would require a page reload, right?
<isd> Yeah. So if you click the button it would refresh the contents of the iframe with a relaxed CSP.
<mnutt> is this is a CSP set on the top-level sandstorm request which would filter down to the grain request, or CSP on the grain request itself?
<isd> Right now this is only applied to the grain itself -- it doesn't make any CSP changes to Sandstorm's primary domain
<mnutt> because davros' CSP is slightly more restrictive than sandstorm's, ideally there'd be a way to enforce the extra restrictions
<mnutt> awesome, thanks
<isd> np
<JacobWeisz[m]> I am glad that after these two PRs, I can be reasonably confident grains are self-contained.
<isd> ocdtrekkie: I think you may want to wait on the csp report/popup for that conclusion.
<JacobWeisz[m]> Not that anyone was maliciously using httpGet that we know of... but it was possible.
<isd> tracking pixels are a thing.
<isd> Also, I think webrtc is still a possible vector?
<JacobWeisz[m]> True. Though apps will work without external scripts, which is mostly what I was thinking of there.
<isd> (and I'm not sure how to block webrtc, if we can...)
<isd> Yeah, it should be harder to miss un-obfuscated attempts.
<JacobWeisz[m]> I am always afraid when using old software for instance that some outside dependency on someone's server will shut off and things will be sad.
<JacobWeisz[m]> We should file issues on apps you found client side script loading.
<JacobWeisz[m]> Many may be abandoned anyways, but if the issues are filed people can potentially be notified that we know these will see breakage soon.
<isd> +1
<isd> afaik all of the breakage is listed in the comment I left.
<TimMc> I'm delighted to see Sandstorm finally growing into its promise as a secure environment.
frigginglorious1 has joined #sandstorm
frigginglorious has quit [Ping timeout: 256 seconds]
frigginglorious1 is now known as frigginglorious
frigginglorious has quit [Read error: Connection reset by peer]
frigginglorious has joined #sandstorm
frigginglorious1 has joined #sandstorm
frigginglorious has quit [Ping timeout: 260 seconds]
frigginglorious1 is now known as frigginglorious