Legality of Cannabis by U.S. Jurisdiction

GA Review[edit]

Article (edit | visual edit | history) · Article talk (edit | history) · Watch

Reviewer: RoySmith (talk · contribs) 23:05, 7 November 2023 (UTC)[reply]

@Sohom Datta: Starting review now. Just for your information, I'm broadly familiar with web security, but not an expert in this particular topic. RoySmith (talk) 23:05, 7 November 2023 (UTC)[reply]

PS, I see you're already working on this, which is great. To reduce confusion, all my comments will be against Special:Permalink/1183951373. RoySmith (talk) 00:23, 8 November 2023 (UTC)[reply]
Sounds good, I'm going through the more easier ones to start with, and will look into the more complicated ones(for example defining a execution context) Sohom (talk) 01:01, 8 November 2023 (UTC)[reply]
@RoySmith I've gone ahead and addressed most of the issues. Wrt to the code snippet issue, as mentioned below, my understanding is that the license under which the paper was published allows for the reuse of the code with attribution. Let me know if there are any other concerns with the current version :) Sohom (talk) 21:31, 8 November 2023 (UTC)[reply]
Sounds good. I'll try check in on this tomorrow and hopefully wrap this up in the next couple of days. My one question at this point, now that I know the cited paper is CC-BY 4.0, is why you made the minor changes to the code snippets that you did? Why not just show the code exactly as it's shown in the paper? RoySmith (talk) 00:49, 9 November 2023 (UTC)[reply]
Most of the changes are to make the code more closer to how a actual vulnerablity exploit might look and some are to make the code fit inside the 20em space. For example, for a cross-origin page the { mode: 'no-cors' } values must be included for the request to succeed. Similarly, the comments at the top of the JS code snippet demonstrate that the attacker needs to create a empty iframe before setting the load event handler. (A non-empty iframe might not fire a load event in certain browsers). Some of the URLs have been shortened so that it fits inside the sidebar as well as the performance.now() statements rearranged for the same reason. Sohom (talk) 09:21, 9 November 2023 (UTC)[reply]
I only have a few minutes before I need to run, but I see several problems here. As I noted above, I'm not a web security expert, but I do know enough to understand that subtle changes to code sometimes have profound effects, especially when you're looking at ephemeral things like execution timings and the observable effects of caching.
Basically you're saying, "Trust me, the changes I made won't make a difference", which is WP:OR. I feel strongly that if you're going to present these snippets, you should present them exactly as in the paper, down to the placement of line breaks and semicolons, since (mind-bogglingly) this is significant in javascript.
As for making the code fit into a 20em space, I wouldn't do that either. You don't know what display hardware the end-user will have. They could be viewing it on a mobile phone. Then could be listening to it with a screen reader. The more you try to fine-tune the display with the fancy wikitable formatting, the more chance you're just making it worse for users not using the same kind of display you're using. I would just run it in-line with the main text instead of trying to force it to the margin with floatright. Using syntaxhighlight as you're doing is good, as is the nowrap directive, but mostly just let the browser handle the layout. RoySmith (talk) 14:40, 9 November 2023 (UTC)[reply]
I disagree with it being called original research, most of the changes are within reason and could be cited to specific JS standards etc. (in fact the code given in the paper is invalid if run without any changes and will throw a syntactic error ☹). However, I do understand your concerns with changing the code and have changed it to be the exact same as copied from the paper :) Sohom (talk) 15:05, 9 November 2023 (UTC)[reply]
@RoySmith I ended up creating a new section for the example and putting the example in there (borrowing from how Rust (programming language) does things). I have added some new text, but for the most part, the code remains the same except for 1 small change (the addition of async) that fixes a syntactical issue with the code in the paper. Let me know if there are any other issues. Sohom (talk) 11:02, 11 November 2023 (UTC)[reply]
My apologies for not getting back to this sooner. In any case, I like the current presentation. The fact that the published paper shows code which is invalid did throw me for a loop. I'm OK with the change you made, but please add a note somewhere explaining why the code you're presenting is different from what's in the source. Consider the case of a reader trying to follow along in the code; when they get to where your code differs from the cited paper's, they won't understand why it doesn't match up unless you explain what's going on. RoySmith (talk) 12:09, 11 November 2023 (UTC)[reply]
@RoySmith Added a note at the top of the snippet pointing out that a minor modification was made (and why and what it is) Sohom (talk) 12:24, 11 November 2023 (UTC)[reply]

Lead[edit]

  • The two hatnotes (see Cross-site scripting and see Cross site request forgery) seem contrary to WP:RELATED. I use hatnotes like this when it's likely somebody would have guessed at an article title and ended up in the wrong place. I don't think anybody looking for either of those would have typed "cross-site leaks" into a search box. This isn't a WP:GACR, but consider if you could handle this better in the body.
  •  Done Both of them are now in the see also section, and I was iffy about them anyway. Sohom (talk) 18:47, 8 November 2023 (UTC)[reply]
  • MOS:LEAD says Apart from basic facts, significant information should not appear in the lead if it is not covered in the remainder of the article. Things I see in the lead that aren't mentioned anywhere in the article include "XS-Leaks", "browsing session", "side channel", "cache timing information"
  •  Done I have restructured the text to include the words in various areas in the article (or rephrased them). Sohom (talk) 12:20, 8 November 2023 (UTC)[reply]
  • first discovered by researchers at Purdue University it's hard to prove something was the first. The body says as far back as 2000 which is a better way to phrase this, since it allows that there may have been earlier papers.

Background[edit]

  • two primary components: a web browser and multiple web servers. "one or more web servers"?
  • via the HTTP protocol and socket connections that's usually true, but doesn't have to be. I'd throw "typically" in there somewhere. You could say that the rest of this article assumes that's the case.
  • render a web application I'm not sure "render" is the right verb here. Deliver? Implement?
  •  Done Deliver seems like a better word choice :) Sohom (talk) 12:20, 8 November 2023 (UTC)[reply]
  • executing HTML, CSS or Javascript You certainly execute javascript. I'm not sure "execute" is the right verb for HTML or CSS, however.
  •  Done reworded, the correct verb appears to be "rendering" Sohom (talk) 21:28, 8 November 2023 (UTC)[reply]
  • transitions in between, just "transitions between", I think?
  • These states are often synced..., I'm not sure what this is trying to say, but "synced" doesn't seem like the right word.
  •  Fixed Removed that sentence, I don't see it in the source and I think I might have confused this with a source that was talking about only COSI attacks.
  • To provide isolation and security of maybe, "To securely isolate"?
  • You should describe what an "execution context" is.
  •  Partly done I'm not to happy with the way I (and the research papers) have done this, since it effectively offloads the definition to the concept of a web origin, which I wish was a blue link :( I'm gonna try and see if I can simplify this. Sohom (talk) 12:20, 8 November 2023 (UTC)[reply]
  • A specific web application drop "specific"
  • cannot reach into a different web app's execution context I think you mean "cannot reach into another execution context". If I've got two windows open on the same URL, it's the same web app, but different execution contexts.
  •  Not done this is intentional, since execution context here refers to the origin and not tabs :) Sohom (talk) 12:20, 8 November 2023 (UTC)[reply]
  • arbitrarily gain information that's an odd phrase. Is "gain" the word that's used in the sources? If not, then maybe "learn" or "obtain", or even "infer" might be better?
  • The sources say "interact" which is what I am going to go with here. I also did a bit of cleanup in the citations since one sentence in the middle should have been cited to the XSinator paper. Sohom (talk) 18:47, 8 November 2023 (UTC)[reply]
  • Define what you mean by "attacker origin" and "victim origin".
  • I've opted to go for "attacker web app" and "victim web app" instead. But let me know if further definition is required. Sohom (talk) 12:20, 8 November 2023 (UTC)[reply]
  • This can lead to the attacker accessing sensitive information about a user's previous browsing habits. "activity" instead of "habits"? And any information you get that you're not supposed to have is inherently "sensitive".

Mechanism[edit]

(I'm going to be on the road for most of the next week. I'll drop in on this as I have time and connectivity, but it may stretch out for the better part of the week)

  • relies on the attacker being able to ... under the adversary's control. I'm pretty sure you're using "attacker" and "adversary" as synonyms here, referring to the same actor. Normally in creative writing you want to use varied vocabulary to keep the prose interesting. In technical writing like this, I think you'll do better to stick to a fixed vocabulary, i.e. pick one of "attacker" or "adversary" (or whatever) and use that term consistently, in the style of Alice and Bob. The writing will sound a bit more stilted, but it'll be easier for a reader to follow.
  • Fixed, I personally was unsure as to which style to follow, will try to keep the vocalbulary the same when refering to the same thing. Sohom (talk) 14:50, 8 November 2023 (UTC)[reply]
  • by phishing the user to a web page link "phishing"
  •  Done Seperated the two links Sohom (talk) 14:50, 8 November 2023 (UTC)[reply]
  • While every method of including a URL in a web page can be combined ... I think you mean "can in theory be combined"?

History[edit]

  • known for over 23 years that will become stale next year. I'd just use the year, i.e. "have been known since 2000"
  • papers ... that describe attacks that leverage the HTTP cache were these attacks theoretical, or actual attacks observed in the wild?
  • I believe the attacks were theoretical at the time the paper was published (their research paper goes into how a attacker might measure the timing differences), however, they have since been used in the wild, most notably by terjanq in 2019.
  • Bar Ilan University detail a attack detailed (past tense)?
  • Explain what an "amplification attack" is
  •  Done I reworded the sentence to clarify that the extensive growing of the response is the amplification attack. Sohom (talk) 21:28, 8 November 2023 (UTC)[reply]
  • Link Christopher Evans -> Christopher Evans (computer scientist)?
    • Correlary to the above; take every person you mention and see if we have an article about them, in which case link to it.
  • I did try, but it seems like a lot of these people aren't well covered on Wikipedia. I'm gonna try and see if I have enough sourcing to create atleast a start article about some of these people (Chris Evans and Luan Herrara in particular) after this review.

Defences[edit]

  • Is it "Defences" or "Defenses"? The nav box uses the later, as does one of the sources you cite.
  • this approach was infeasible for any non-trivial website due to the nature of the web platform. you need to explain that.
  • are extensions to the HTTP protocol that focuses "focus"?
  • I'm not sure what to do with the two code snippets. They are clearly copied from Goethem et al, but with small changes (h1 instead of h2, etc). I'm going to ask around to see how that plays with copyright restrictions.
  • Van Goethem et. al. should be under the CC-BY 4.0 license based on the notice on the first page of the paper which according to my understanding should be compatible to the one used by Wikipedia, but I think a third-opinion would be great in this case as well :) Sohom (talk) 17:38, 8 November 2023 (UTC)[reply]

Preventing state changes[edit]

  • X-Frame-Options header more SEAOFBLUE

Making cross-origin requests stateless[edit]

  • "LAX+POST" in code style?

Completely isolating shared resources[edit]

  • One of the earliest and most well-known methods... if this was the earliest, maybe discuss it first?
  • major browser vendors such as the likes of Chrome, Brave I would drop the entire "major browser vendors such as the likes of" part.

Sources[edit]

  • I do agree with this in general, but I think the usecase here is that of the author is a subject-matter expert or the blog is used for uncontroversial self-descriptions. Luan's blog is cited in the paper Van Goethem et. al. to describe his exploit on the monorail bug tracker and the line this is immediately before talks about exactly that. The only real "thing" that this citation supports is the products in which he found the security issues in which falls under uncontroversial self-descriptions. -- Sohom (talk) 12:37, 11 November 2023 (UTC)[reply]
OK, that works. I can't find anything else to complain about, good job! RoySmith (talk) 14:09, 11 November 2023 (UTC)[reply]

Other WP:GACR[edit]

  • No copyright problems found
  • Article looks to be adequately sourced with in-line citations and except as noted above (Medium), to RS.
  • Breadth of coverage is appropriate.
  • No problems noted with neutrality or stability.
  • Illustrated with appropriately licensed media.