Cross-site leaks edit
| Toolbox |
|---|
 | This peer review discussion is closed. |
I've listed this article for peer review since I would like to take a stab at bringing it to FAC early next year (think Jan/Feb tentatively). Any feedback for improvements are appreciated :) Thanks, Sohom (talk) 21:59, 1 December 2023 (UTC)
- @Sohom Datta: This has been open for over a month without comment. Are you still interested in receiving feedback? Z1720 (talk) 05:28, 2 January 2024 (UTC)
Comments from TechnoSquirrel69 edit
Why, hello there, Sohom Datta! :) Now here's that interesting peer review I've been looking for. Keep in mind that I have very little expertise in the web design and security areas, but hopefully I can provide a bit of perspective as an outsider looking in. Citation numbers from this revision.
- I would add a {{Use dmy dates}} or {{Use mdy dates}} to the top.
- Is it industry standard to write the term "XS-Leaks" with a capital L?
- Why are "CSS attributes" and "HTTP Cache" piped the way they are? CSS can just be linked normally, and it's not implausible that a layperson may not know what HTTP is, so I would just leave the second one at "Web cache".
- Rephrase "stateful cross-origin" per MOS:SEAOFBLUE.
- The lead is a little too brief to accurately summarize the prose, in my opinion. I absolutely understand that you want to keep the technical language to a minimum in this section, but not at the expense of abstracting away important information. For example, the types of attacks that can cause a leak are not mentioned at all.
- In § Background: link "... well-defined states".
- Javascript → JavaScript, throughout the article
- To isolate different web applications ..." What does "isolate" mean in this context?
- There's inconsistent usage of "web application" and "web app" throughout the article. As you may have guessed by the colors, I would go with the former.
- In § Mechanism: "URL" is linked on the third appearance of the word. However, linking on the first appearance will require a slight rephrase again per SEAOFBLUE.
- In § History:
interchangably called XS-Leaks - Also, there's no reason to give this statement an expiration date; why not just say that they've been known since 2000?
- This section has a lot of statements that go "researchers published an article in year " that are then cited to the article in question. The reader doesn't need to know about how the information was published, just that the information exists. I would rephrase these statements so that they more broadly describe the development of knowledge in the field.
- Un-italicize "Sudhodanan et al." and the like; the italics make it look like the researchers are the title of a work.
- Ctrl+F for as of phrases and replace them with {{As of}}, throughout the article.
- In § Types:
newer and older - Link "APIs". I'd also prefer a brief explanation of what they are, as I'm sure they're an important piece of the puzzle with these kinds of attacks.
- Link "Google Chrome".
- HTTP Cache → HTTP cache, in multiple places.
- What's "multi-keying"?
- I would restrict the use of code blocks only to text that actually appears in the source code somewhere, so the "example websites" should be italicized instead. Also, what's preventing us from using a phrase like "victim application" or "victim website" here instead?
- I would append
|30emto the {{reflist}} and {{refbegin}} templates so that the sources are rendered in consistent columns. - Someone has to say it, but the sources need to be sorted in alphabetical order by last name.
- In note 1: "socket connections" is a duplicate link.
- In citation 52: Lose the underscore.
Feel free to reply to my comments in line, and let me know if you have any questions! —TechnoSquirrel69 (sigh) 06:33, 4 January 2024 (UTC)
- Hey Sohom Datta, I'm just noticing some possibly unreliable sources in the article. Numbers come from this revision. Citation 27 is to a Medium article — unless the author Luan Herrera is a subject expert, I think it has to be removed as user-generated. Citation 5 is a link to Amazon Web Services, why is that source reliable here? Citations 20 and 74 are to Github posts; again, unless there's some special reason to believe they're reliable, I don't see how they can be included. I'm taking another look at the sources to see if there are any other problems, and I highly suggest you do the same before taking this article to FAC (where these issues could easily merit an oppose). —TechnoSquirrel69 (sigh) 04:31, 5 February 2024 (UTC)
- @TechnoSquirrel69 Citation 20 and 27 are infact blog posts by subject-matter experts and the citations are being used in a way where they satisfy ABOUTSELF. (The citations are to sentences that describe the cross-site leak exploits that they published). I have removed/replaced citation 74 with a reference to a research paper and a reference to the MDN documentation for the feature.
- Wrt to citation 5, it's some kind of resource to explain basic web security principles (particularly CORS) to AWS consumers. It's not the best source for anything AWS related, but it should be expected to be reliable about basic web security principles (which is what it is cited for). Sohom (talk) 05:43, 5 February 2024 (UTC)
- I will take a deeper look as well and try to see if there is anything worth swapping out. Sohom (talk) 05:44, 5 February 2024 (UTC)
- I'll take your word that the authors of the blog posts are reliable, but be prepared to have proof of that during the source review at FAC. Also, note that criterion 1c asks that sources be not only reliable but also "high-quality". You'll probably know better than me whether Amazon could be called a high-quality source in this situation, but it looks like a red flag to me as a non-expert looking in. I'm sure you'll get these issues taken care of; I just wanted to draw your attention to them. —TechnoSquirrel69 (sigh) 05:56, 5 February 2024 (UTC)