Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub's post-CSP journey

githubengineering.com

Post reply on HN
Print view View original

11–20 of 60 posts

Re: GitHub's post-CSP journey

#11

Post by rcfox »

Ericson2314 wrote: post #10
dfc wrote: post #8

Earlier quoted context omitted.

At a certain point you need to set a baseline expectation of your audience in order to communicate effectively. Do you think they should also explain exploitation, img-src, the mechanics of parsing unmatched quotes, javascript or CSRF? The target audience of the article knows what CSP stands for and most likely has been reading the other entries along this journey.

And I had thought it was communicating sequential processes for a second

I was hoping it meant "constraint-satisfaction programming".

Re: GitHub's post-CSP journey

#12

Post by rcfox »

dfc wrote: post #8
jaredsohn wrote: post #2

The article says CSP seven times in the first two paragraphs without saying what it stands for; it would be much more readable if they did. (It stands for content security policy for those wondering.)

At a certain point you need to set a baseline expectation of your audience in order to communicate effectively. Do you think they should also explain exploitation, img-src, the mechanics of parsing unmatched quotes, javascript or CSRF? The target audience of the article knows what CSP stands for and most likely has been reading the other entries along this journey.

I would expect them to expect their readers to look up concepts that are unfamiliar. Throwing around overloaded acronyms without definition makes that difficult.

Re: GitHub's post-CSP journey

#13

Post by ptoomey3 »

wsh91 wrote: post #3
jaredsohn wrote: post #2

The article says CSP seven times in the first two paragraphs without saying what it stands for; it would be much more readable if they did. (It stands for content security policy for those wondering.)

To that end, it might be worth spelling out in the title here. I got my hopes up thinking it was about https://en.wikipedia.org/wiki/Communicating_sequential_proce... .

Funny enough, I tried doing exactly that when I submitted the post to HN this morning: https://news.ycombinator.com/item?id=13437920. But, unfortunately, my submission wasn't the one to make the front page .

Re: GitHub's post-CSP journey

#14

Post by tlrobinson »

dfc wrote: post #8
jaredsohn wrote: post #2

The article says CSP seven times in the first two paragraphs without saying what it stands for; it would be much more readable if they did. (It stands for content security policy for those wondering.)

At a certain point you need to set a baseline expectation of your audience in order to communicate effectively. Do you think they should also explain exploitation, img-src, the mechanics of parsing unmatched quotes, javascript or CSRF? The target audience of the article knows what CSP stands for and most likely has been reading the other entries along this journey.

Anecdotally, I was aware of both Content Security Policy and Communicating Sequencial Processes, and first thought of the latter.

I figured it out by the end of the first paragraph though.

Re: GitHub's post-CSP journey

#15

Post by chias »

niftich wrote: post #7

A very detailed post which talks about their collaboration with security consulting firm Cure53 to identify various fairly novel exfiltration techniques, and attempt to adjust their Content-Security-Policy or some aspect of their application to try to mitigate it. This could be a great resource, and is certainly a valuable 'lessons learned'. But I was also overwhelmed. There's a quip that security is a losing battle,…

They're interesting and often-overlooked techniques, but are not novel. You can read a more about these sorts of attacks and other similar ones in 2011 writeup "Postcards from the post-XSS world"[0]

[0] http://lcamtuf.coredump.cx/postxss/

Re: GitHub's post-CSP journey

#17

Post by peteretep »

dfc wrote: post #8
jaredsohn wrote: post #2

The article says CSP seven times in the first two paragraphs without saying what it stands for; it would be much more readable if they did. (It stands for content security policy for those wondering.)

At a certain point you need to set a baseline expectation of your audience in order to communicate effectively. Do you think they should also explain exploitation, img-src, the mechanics of parsing unmatched quotes, javascript or CSRF? The target audience of the article knows what CSP stands for and most likely has been reading the other entries along this journey.

You are getting downvoted because in complaining we are below your technical baseline, you've ironically revealed you're not familiar with the rather more interesting CSP.

Re: GitHub's post-CSP journey

#18

Post by niftich »

dfc wrote: post #8
jaredsohn wrote: post #2

The article says CSP seven times in the first two paragraphs without saying what it stands for; it would be much more readable if they did. (It stands for content security policy for those wondering.)

At a certain point you need to set a baseline expectation of your audience in order to communicate effectively. Do you think they should also explain exploitation, img-src, the mechanics of parsing unmatched quotes, javascript or CSRF? The target audience of the article knows what CSP stands for and most likely has been reading the other entries along this journey.

I think this comment raises a very good point and I struggle to see sure why it's proving so unpopular so far.

It's true that the submitted blog post doesn't expand the CSP initialism -- this has been acknowledged as an oversight by the author and the post will be edited, as it's simply good practice as recommended in several style guides [1][2][3][4].

But the post's very first sentence links to a previous entry about the same subject; there, the topic is explained to readers who may not be familiar with it. There is simply no reason for a follow-up post, which this submission is, to repeat the explanations given by its predecessor. Meanwhile, a reader approaching the post with confidence about its topic will have realized rapidly what it is and isn't about.

So given the intense disagreement, what approach would have been preferable?

[1] http://amastyleinsider.com/2011/11/04/cheat-sheet-for-abbrev... [2] http://www.chicagomanualofstyle.org/16/ch10/ch10_toc.html [3] https://www.rfc-editor.org/materials/abbrev.expansion.txt [4] https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style

Re: GitHub's post-CSP journey

#19

Post by radicalbyte »

peteretep wrote: post #17
dfc wrote: post #8

Earlier quoted context omitted.

At a certain point you need to set a baseline expectation of your audience in order to communicate effectively. Do you think they should also explain exploitation, img-src, the mechanics of parsing unmatched quotes, javascript or CSRF? The target audience of the article knows what CSP stands for and most likely has been reading the other entries along this journey.

You are getting downvoted because in complaining we are below your technical baseline, you've ironically revealed you're not familiar with the rather more interesting CSP.

My thoughts exactly.

We should prefix the security CSP with an m (for mundane) to differentiate it with the interesting CSP :)

Re: GitHub's post-CSP journey

#20

Post by lubomir »

tlrobinson wrote: post #14
dfc wrote: post #8

Earlier quoted context omitted.

At a certain point you need to set a baseline expectation of your audience in order to communicate effectively. Do you think they should also explain exploitation, img-src, the mechanics of parsing unmatched quotes, javascript or CSRF? The target audience of the article knows what CSP stands for and most likely has been reading the other entries along this journey.

Anecdotally, I was aware of both Content Security Policy and Communicating Sequencial Processes, and first thought of the latter. I figured it out by the end of the first paragraph though.

And then there's also Constraint Satisfaction Problem.
Post reply on HN