Heh, well it is an old picture, I'll see if I can't get a better one made. I didn't join IT for my looks though so hopefully it doesn't stand in the way of your enjoyment of the content.
No, it doesn't. I was just kidding. It was the first thing that caught my eye. No worries, it seems the white-knight brigade is out to defend your honor though.
I thought it was pretty obvious that you were just kidding, but it's the sort of comment that is hard to interpret correctly, and anyone who missed the jovial tone would have thought it was pretty mean.
To be fair, most of the bad correspondence was from 2014. Their new representative 'Leigh' appears to be doing excellent work.
Also we're still happy users of Slack, I would just never trust them with secrets :-).
It probably means that they're not prioritising vulnerability reports. Which is their prerogative honestly, but it doesn't make researchers happy to work with you.
The biggest 'fault' here I think lies squarely with HackerOne.
They should've enforced their own guidelines and given me the option to publish in their system after 180 days. But I still don't have that option.
The 180 day guidance you reference falls under a "Last Resort" clause when "... the Response Team [is] unable or unwilling to provide a disclosure timeline". (which, at first glance, might not have been the case here?)
These "Last Resort" scenarios have not yet been fully codified. As a safety precaution, the workflow is still initiated manually with support as these scenarios are extremely rare and littered with edge cases. We've been learning a lot from studying disclosures like this one and you can expect to see the "Last Resort" workflow codified in the product in the future.
Now that the report has been Resolved, you should see the normal disclosure options available. Please always feel free to send me a note if you have any questions or feedback on our disclosure workflows - especially if we don't support your preferred route.
Don't forget that it should ideally be cryptographically random. If the sequence is predictable (like based on an auto incrementing number or on time) then you might still be able to guess a 256-bit number.
* CSP is actually the header that most security professionals are the most excited by (in my experience) as it gives you more control over what resources are and are not allowed.
Especially when you're thinking of a future where you want to securely 'mash up' content, being able to set policies is essential.
* XFO, it you're doing API first there really is very little reason to frame a page. Maybe Twitter style widget support? But in that case you can have a separate URL for that.
* XCTO, yes, welcome to the 'organic' web :p
* HSTS, the first connect is difficult, maybe one day via DNSSec? But I must confess to know very little about DNSSec.
I wasn't saying HSTS is useless, just pointing out one of the issues with it. I think HSTS a great thing!
With XFO, doing something like adding 'reddit.com/' before the domain to see if it's been submitted becomes much more computationally intensive on reddit's side if they can't just put it in a frame. This is where I run into issues mostly, with tools such as that. That said, there are other things it could do (take me to a submit page or a discussion page instead of framing the page). And frames suck anyway, so there is that.
I can see the usefulness in CSP, I just feel like it's a band-aid on larger problems.
As for XFO, I specifically said that that was my opinion and my experience. I even give a specific example: adding reddit.com/ before the domain of hackernews, for instance, won't let reddit put it in a frame (in order to put the reddit toolbar above it). I've only ever encountered tools such as that breaking because of XFO.
Also, it's my user-agent, it's suppose to do what _I_ want it to do, not what the content author wants it to do, and I can't find a way to disable honoring XFO.
For CSP, one example of a larger problem would be excepting and storing unsanitized input. If it's going out to the user as (otherwise executable) javascript, are there other places that you're placing unescaped user-submitted data that could be an issue (a sql statement perhaps or the API to a site who trusted you to sanitize things (although they shouldn't)?).
The irony is not lost on me, we have a saying in the Netherlands "the carpenters doors are the creakiest".
Also we don't use them all the time yet even for customers, this blog post (and an accompanying internal training next week) is meant to remedy that.
Unfortunately, as the web stands today, for our developers I do advocate including it by default, unless a specific use-case comes up to not include it.
While for a simple content page allowing for framing should be okay, the truth is very very few pages are actually purely content. As soon as you have something like a comment form there is a chance that framing it could be used to reveal some private information (autofill / password manager leakage).
And who is going to manage what pages are framable and what aren't? The customer would need a UI and training and developers can't always see what will be hosted on a page.
Also, as an advertiser I would very much like you to visit the full page instead of trying to view it through some limited frame, cutting off the sidebar with ads.
As an author that doesn't write publicly all that often, thank you for your kind words.
Lots of feedback is amazing in that it helps me grow, but the occasional compliment from a stranger does feel really really good.
I've read that phrase (or derivations of it) multiple times, like the "Programming is hard" phrase, but can't find a reference for you. I've updated the article to say "one of" to at least weaken the statement.
I agree that, while massive (multi MLOC) webapps can be very complicated, it's certainly no theoretical physics for instance.
Thank you for your time and feedback, have any more feedback?
It's a nice overview. I could see myself referring to a document like this as a convenient checklist when beta testing projects just prior to go-live.
If I was to find fault, it would be that the TL;DR section is a little redundant as in it's effort to be succinct (which the main body of the article achieves anyway), you end up dumbing the content down to a point where it's not actually expressing anything useful at all. But that's just my opinion and I may well have missed the point of the TL;DR. :)
