JangoSteve

All of your explanation (which is appreciated) just further describes the request smuggling, not how that ends up sending the slack cookies to the hackers server.

If you take all of this together, it's all leading to Slack's back-end server returning to the user's client a 301 response that tells the user's browser to send a new request to the hacker's domain. However, when the browser does this, it's to a different domain, so typically the slack cookies would not get sent with that request, unless I'm missing something.

The "Explanation of malicious request" section doesn't explain this, either. All it explains is that all this effort was to get Slack's server to send a 301 response to the user's browser pointing to the hacker's server, but then it glosses over any information about how the cookies are getting sent with a single sentence, "and all cookies (including 'd') get redirected there too.... :("

My question is, how?

Is something going on where Slack's back-end servers are explicitly setting response headers that allow their cookies to be sent to the hacker's domain? Is there some additional vulnerability that's allowing the browser to send the cookie across domains on a 301 redirect?

Can someone explain the redirect/cookie-stealing part of this? I read through the post explaining request smuggling, and then re-read their exploit description, and the request smuggling part all makes sense. However, I don't fully understand the significance of the 301 in relation to the browser sending the attacker's server the cookie with the request.

If the back-end server is already proxying whatever request it receives from the front-end proxy server, why was it necessary to first get it to redirect an HTTP 1.1 header to an https request? The only thing I could think of was that maybe it has something to do with getting the unencrypted cookie, but according to their description, the forwarded request with the cookie doesn't happen until after the redirect to https anyway.

I know I'm missing something obvious here.

But isn't the problem with isolating parts of the image at the optical level that you can't later undo it? It seems like at least one of the advantages to everything being in focus is that you can isolate whatever you want in post-processing. Cameras are already doing this, they just require multiple lenses and thus more space and material to do it.

To be fair though, that's kind of life. The originators of any given thing always get remembered as the originators, despite how long they worked on it compared to anyone else since. This isn't just code. I mean, 30 years from now, George Lucas will still be remembered as the creator of Star Wars, even though by then I'm sure the writers at Disney will have produced 20x more stories around it, and Stan Lee/Jack Kirby will still be remembered as the creators of the characters others have already built upon and adapted since then. Even the USA has had far more people build and mold the country into what it is since the founding fathers. It's just one of the hallmarks of our society I think to romanticize and glorify the original creators of works.

I think reducing everyone to "you are not special" status is a pretty weak solution that probably wrongs more people than it rights. And I think egos are a pretty weak reason to do it.

But is it a long stretch from the claim: "Non-exhaust emissions (NEE) are particles released into the air from brake wear, tyre wear, road surface wear and resuspension of road dust during on-road vehicle usage."

Resuspension of road dust is literally one of the 4 things they defined as the NEE they're measuring.

> As you say YC admission or raising funds from investors isn't a measure of business success...but then again I haven't seen a tech unicorn that hasn't been funded by investors.

There is a difference between a company getting investor funding and the investor funding being a significant measure of success.

There are plenty of unicorns that didn't raise money until well after they were already considered a success. A couple examples off the top of my head would be:

* Github - first round was a $100mil series A at a $650mil valuation about 5 years after founding.

* Atlassian - first round was a $60mil round 8 years after founding.

I'm sure there are plenty more that are easier to find once you know what you're looking for.

Thanks! I had no idea.

They've already done that. They're called the Facebook and Messenger native apps for Android and iOS. Conveniently, the Facebook mobile web app shows you Messenger notifications but won't let you read them without installing the native Messenger app, or visiting the Facebook on a desktop browser, despite the fact that direct messages have a much simpler interface than the rest of Facebook and that it used to be possible to view messages in the mobile web app, so they push for native app usage pretty hard already.

I'm not sure they'd see desktop browser warnings as much of an existential threat considering 94% of their advertising revenue comes from mobile [1].

[1] https://s21.q4cdn.com/399680738/files/doc_financials/2019/Q2...

I'm going to make a guess here from my own unrelated experience trying to debug problems in live systems. It is often much easier to detect that there is _some_ unusual activity present than it is to categorically define exactly which activity is legitimate versus which isn't.

Usually, this is because you can easily detect some of the anomalous behavior but not all of it. So you'll have some activity which is obviously anomalous, some which is obviously legitimate, and some which could be either. And sometimes when you've detected some that are obviously anomalous, most of the rest of the activity ends up being in the category of "could be either" with almost none left in the obviously legitimate.

So from Google's point of view, I'm sure they ban the account so that they 1) don't end up paying a lot of money to users for the "could be either" activity, and 2) don't need to keep expending server resources continuously categorizing and serving the obviously anomalous traffic.

I maintain some open source projects, and honestly, I've never considered chiming in on an open bug ticket rude. I also have never considered relating your experiences about my project on a forum rude, either. Don't get me wrong, I've had plenty of negative experiences with rude posts from users, but neither of these qualify to me unless the posts themselves are rude.

Something like this is fine with me: "I'm having this issue as well. It's unusable for me without this feature, because my use case is such that..." In fact, this is downright helpful, because I may be able to offer an alternative solution using already-implemented functionality.

Here's the same post, but rude and unhelpful: "I'm having this issue as well. This project is useless without this."

People often judge the merits of a project based on their own use-case and nothing more. If they can't use it for their use-case, they can't imagine any other use-cases where it's useful, and so the project is deemed useless (or some other hyperbolic, universal judgement of worth).

I once worked on a larger Rails project where we had decided to utilize Postgres views and materialized views to optimize the performance of parts of our application. This was about 7 years ago, so before Scenic existed to help with this (or at least before it was known). We had to manually manage the use of our views while keeping Rails apprised of the underlying schema through custom schema files and migration methods.

One of the main issues we had run into, in addition to all the complexity that comes with managing a cache and no longer being able to count on your db queries to return the latest information, was that our views had to be deleted and re-created for nearly every schema change (at least every schema change that affected the views, but we had so many views, this ended up being probably 90% of our schema changes).

We ended up overriding the standard Rails "up" and "down" migration methods to prepend the deletion of these views, append their re-creation, clean up after failed migrations, etc. I remember us spending a good amount of time across the team dealing with weird edge cases that cropped up from this. I also remember spending a fair amount of time training all the developers on these issues since almost no one on the team had experience using or dealing with database views. I assume managing migrations and schema of your views within Rails is all included in what Scenic does for you for free, since these hassles weren't mentioned in the article.

It's really nice to see something that handles all that complexity for you. However, that still leaves the standard and age-old caching issues with stale data. Another side effect was that they started being a bandaid for inefficient queries and data structures in the database, which is probably how we ended up with so many db views in the first place.

In the end, after probably 8 months of using these views, we decided to excise them from the application entirely and go back to optimizing our actual database queries. We got to delete a lot of custom code, our schema changes and migrations became simpler, our data became fresh again, and we got to reinvest that time into improving our underlying data structures and queries.

This probably is not an argument against using db views, but rather an anecdote of what can happen when you resort to them prematurely. If you have queries that are 100ms or more, there are probably more traditional optimizations you can find, such as restructuring your relational data, adding/removing indexes, etc. If you're actually trying to eliminate those last 10s of milliseconds from your queries though, as is shown in the article, I can see them being a good option.

Just to clarify my grandparent comment here, I was thinking "transformative work" when I said it was protected by Fair Use, not "derivative work" as I stated. So I was wrong!

To clarify my sibling response here, I'm acknowledging that statement was wrong. However, to say that _derivative_ works are "not at all" protected by Fair Use isn't entirely accurate either, as they absolutely can be depending on the the judgement and application of the four-point doctrine of Fair Use. The parent comment here cites part of the copyright law, but Fair Use, which I cited, is a core component of the same copyright law that limits the application of the section they cited.

I agree with almost everything you said. Fair Use is definitely protected though, as it's a core component of the US copyright law that helped shape the rest of the law, not an exception or amendment that was added later. Copyright basically couldn't exist as we know it without Fair Use. However, it is definitely subjective and always evaluated on a case-by-case basis, though there are often precedents set which help you understand the likely judgements of Fair Use before you're in court.

I was definitely being imprecise with my wording though, as I was thinking about a _transformative_ work when I read their attorney say "derivative" work, where a transformative work is a type of derivative work that is protected by [subjective] Fair Use.

I also agree with you though that I wouldn't even necessarily consider this a transformative work of the other map, as that assumes he started with the other map. But just starting with the same facts, which aren't copyrightable, and following standard cartographic conventions while exercising the author's own artistic expression into the final rendition would just be a separate work entirely.

My comment is definitely an oversimplification that takes into account the rest of the context of the article which outlines all the differences which makes the author's work transformative enough to count. You're right that derivative works aren't a straight up protected use as my comment stated. However, "Not at all" is wrong, because derivative works are protected within the doctrine of Fair Use provided the work satisfies enough of the four-rule doctrine to qualify [1]. Transformative works are a subset of derivative works which are protected [2].

EDIT:

[1] https://www.copyright.gov/fair-use/more-info.html [2] https://foundrylawgroup.com/copyright-copywrong-what-are-der...

Derivative works are protected by Fair Use.

I thought you were going to point out this line:

> Lester Freundlich, an attorney for the MTA, told Berman in an email Wednesday that his subway map was “clearly a derivative work of MTA’s current version of the Vignelli subway map.”

The MTA's attorney literally calls his map a "derivative work" which is something that's protected by Fair Use. When I read that in the article, I immediately thought that the artist's response should have been, "Thanks for clarifying that it's clearly a derivative work; so you'll drop the claim now?"

EDIT: For anyone reading this without additional context, I should clarify, derivative works are protected as long as they're transformative, which this seems pretty clearly enough so to count. So, it's less a point that being a derivative work itself means it's protected, than the point that being a derivative work doesn't mean it's not protected like the MTA's attorney seemed to imply.

> Parents only call you when they are unsure of something. The problem is when the scammer manage to convince them everything is normal, which is exactly what they are good at.

> if you think it's naive for your users or loved ones to call you when they have the slightness doubt about something...

I think you just affirmed their point. You're acknowledging they only call when they have even the slightest doubt. They're saying that is exactly the problem, because they won't call when they have no doubt that everything is normal.

I agree. A returning visitor is someone who visited your site before and now they're back again. The "return" in returning visitor is the fact that they left and came back.

What they're talking about is usually described as tracking unique sessions. So, I would see the use of the referrer as a low-complexity, less reliable, but more privacy-friendly way of tracking unique sessions.

I created one a while ago called Dynatable. It's currently a jQuery plugin, but we already have a vanilla JS rewrite mostly done, so that'll be coming soon.

https://www.dynatable.com/

Something I still don't understand about the OAuth flow is how it's _not_ training users to be more easily phished for actual usernames and passwords. The very first step is "If you are not logged into the third-party, display a login-form from the third-party."

The thing is, you never really know off-hand if you're logged into the third-party (provider) or not without opening a second tab and going directly to the third-party's site, since you're always getting logged out after various timeouts, cookie-clearing, browser-closing, and computer-restarting events.

What prevents an OAuth client application from displaying an OAuth process that shows a fake login form, which looks identical to the provider's login form, to get the user to enter their provider username and password before they realize the URL is off? It seems like it trains users that it's normal for websites to launch a Gmail login form and this is perfectly safe.

Wait, did the goalposts actually move at all? The original post said:

> There are a lot of people with degrees FROM credible institutions, but very little in terms of currently being researchers in the field AT credible institutions.

You responded literally saying that the institutions are credible:

> Is Harvard Medical School an institution you recognize and trust? Columbia? Monash? McGill?

That wasn't the original objection; they even said in their objection that the institutions are credible. I don't understand how the goalposts moved.

They often are correlated though. Better brakes mean you can stay on the accelerator longer before braking, which means you usually have higher maximum velocity and faster lap times (faster lap times are literally higher average velocities, so this makes sense).

I'm not a lawyer, but this actually makes sense to me. The copyright on the page is to copyright the page as a whole. When you update the page at all, the new page would be copyright when you update it, and while the old page was copyrighted before then, you're no longer showing that page and so you would no longer show the old page's copyright date.

As a result, the copyright became a decent heuristic for seeing how recently the page has been updated. Then I think some people, recognizing the use of the copyright as a heuristic, would then update the copyright without updating the page just to make it seem like the page has been updated recently. That's easier than actually updating the content of the page, and the only downside is giving your page a more recent copyright date in the notice. I'm not sure what this does to any copyright disputes though, but I think most people consider copyright disputes more unlikely than someone perceiving a page negatively due to the older copyright date.

Alternatively, instead of fixing these issues by making the incognito mode detection break, they should fix them by making regular mode look like incognito mode. Suddenly, all readers are blocked from reading NYTimes for half a day while they scramble to remove it from their site. Then they can start teaching sites that relying on hacks isn't a viable, sustainable strategy.

> I'd love to see companies actually do the right thing and not talk about it;

Was this being intentionally ironic? If companies do the right thing and don't talk about it, then you won't see it. They could be doing it right now, and you'd have no way to know.

I'm not sure the author was berating the photographers for ruining the view for others. I read it as revealing the hypocrisy of the photographers shouting at kayakers for doing the thing they were currently doing themselves.

Thanks, I appreciate that!

In the abstract sense, I would say we are, in that it's the primary benefit of what we've built versus textual searching like you get with PubMed or Google Scholar. For example, if you were to search for a specific variant like BRAF V600E in Google Scholar or PubMed, you'd need to search for every way that the variant can be described in text, such as p.V600E, p.Val600Glu, c.1798T>A, C1798A, etc. Furthermore, you'd need to then read the results to determine which are specifically referencing the V600E variant in the BRAF gene, versus mentioning the V600E variant in one of the other genes mentioned in the paper.

We've already done that work ahead of time, figuring out which variants belong to which genes in papers, normalizing all the different nomenclatures used for variants so that you can do a single search for your variant and remove the need to think about how authors could have referenced it.

We do the same with taking into account all the different ways authors can talk about genes, diseases, clinical contexts, meanings and interpretations, etc.

I don't know if that answers your question. I guess it depends on what you mean by knowledge graph, since there seem to be a few different ideas of what that entails.

> They still made the contract - and it was even their lawyers who wrote the contract and spend hours poring over it. If I order truck loads of landscaping material to be delivered to my house and I later learn that it wasn't such a great price, you better believe I'm now stuck with that material and the bill.

At first, I thought you were talking about the general social or implied contract between a retailer and consumer, in the general sense. But if you're talking about the explicitly written contract that the lawyers wrote, which is the Conditions of Use, then the allowance for pricing mistakes is right there in the "Pricing" section of the contract, including a description of what happens in such events:

https://www.amazon.com/gp/help/customer/display.html?ie=UTF8...

> With respect to items sold by Amazon, we cannot confirm the price of an item until you order. Despite our best efforts, a small number of the items in our catalog may be mispriced. If the correct price of an item sold by Amazon is higher than our stated price, we will, at our discretion, either contact you for instructions before shipping or cancel your order and notify you of such cancellation. Other merchants may follow different policies in the event of a mispriced item.

In the posted video, they said it was required for Medicaid.

For what it's worth, I'm not sure about the actual paper itself, but the posted article makes it seem like no one knew that TH588 was not primarily acting as an MTH1-inhibitor.

> “This is an exciting paper for two reasons,” says David Pellman, associate director for basic science at Dana-Farber/Harvard Cancer Center, who was not involved in the study. “First, Yaffe and colleagues make an important advance for the rational design of drug therapy combinations. Second, if you like scientific mysteries, this is a riveting example of molecular sleuthing. A drug that was thought to act in one way is unmasked to work through an entirely different mechanism.”

Since my startup compiles all genomic knowledge from the published literature, of course the first thing I did was search the literature. The first article that comes up with a quick search for MTH1 and TH588 was from 2014 [0], which basically says TH588 is a first-class MTH1-inhibitor effective in treating certain cancer cells. Then in 2016, another article says that's not its primary mechanism of effectiveness [1]:

> In particular, we identified tubulin as the primary target of TH287 and TH588 responsible for the antitumor effects despite the nanomolar MTH1-inhibitory activity in vitro.

Tubulin of course is part of the mitotic spindle which the posted article claims was discovered as the actual target upon which TH588 acts.

I've found around 10 other papers between 2016 and 2018 that further conclude that TH588 doesn't act primarily as an MTH1-inhibitor.

[0] https://www.ncbi.nlm.nih.gov/pubmed/24695224 [1] https://www.ncbi.nlm.nih.gov/pubmed/27210421