#1 CSRF Is A Vulnerability In All Browsers - <AUTHOR> http://homakov.blogspot.com/2012/03/1-csrf-is-vulnerability-in-all-browsers.html First article that makes the point. <comment><USER4> Just in case it might be a problem for anyone: The article uses the CSRF vulnerability to log you out of all Google services (and says so in a PS at the bottom).

Don't open the article if you don't want to have to log in to Google again afterwards (might be a problem if you're using two-factor auth and you don't have your phone handy for instance).

<comment><AUTHOR> hm yep. should I hide that thing? hm.. Sorry guys in advance.

<comment><USER5> FWIW, Worked in firefox. Didn't work in Chrome or Opera.

<comment><USER6> Worked in Chrome for me on Vista (work comp).

</comment></comment></comment></comment><comment><USER7> CSRF isn't a browser vulnerability. It's a serverside application vulnerability.

To say otherwise is to say there there is some trivial policy, just an HTTP header away, that would allow IE, Firefox, and Webkit to coherently express cross-domain request policy for every conceivable application --- or to say that no FORM element on any website should be able to POST off-site (which, for the non-developers on HN, is an extremely common pattern).

There is a list (I am not particularly fond of it) managed by OWASP of the Top Ten vulnerabilities in application security. CSRF has been on it since at least 2007. For at least five years, the appsec community has been trying to educate application developers about CSRF.

Applications already have fine-grained controls for preventing CSRF. Homakov calls these controls "an ugly workaround". I can't argue about ugliness or elegance, but forgery tokens are fundamentally no less elegant than cryptographically secure cookies, which form the basis for virtually all application security on the entire Internet. The difference between browser- based CSRF protections (which don't exist) and token-based protections is the _End to End Argument In System Design_ (also worth a Google). E2E suggests that when there are many options for implementing something, the best long- term solution is the one that pushes logic as far out to the edges as possible. Baking CSRF protection into the HTTP protocol is the opposite: it creates a "smart middleman" that will in the long term hamper security.

This blog post seems to suppose that most readers aren't even familiar with CSRF. From the comments on this thread, he may be right! But he's naive if he thinks Google wasn't aware of the logout CSRF, since it's been discussed _ad nauseam_ on the Internet since at least 2008 (as the top of the first search result for [Google logout CSRF] would tell you). Presumably, the reason this hasn't been addressed is that Google is willing to accept the extremely low impact of users having to re-enter their passwords to get to Google.

Incidentally, I am, like Egor, a fan of Rails. But to suggest that Rails is the most advanced framework with respect to CSRF is to betray a lack of attention to every other popular framework in the field. ASP.NET has protected against CSRF for as long as there's been a MAC'd VIEWSTATE. Struts has a token. The Zend PHP framework provides a form authentication system; check out Stefan Esser's secure PHP development deck on their site. Django, of course, provides CSRF protection as a middleware module.

<comment><AUTHOR> I see some points but >CSRF isn't a browser vulnerability. It's a serverside application vulnerability. you didn't prove this one. CSRF is a browser vulnerability. ANd I don't care about another stuff you said further - <USER2> probably right that most popular frameworks have the protection out of box - <USER3> know it, no surprise here:). But I did pretty wide audit - only rails' protection looks really elegant. Hm.. probably I'm too much fan of rails, true.

And, please >Baking CSRF protection into the HTTP protocol is the opposite: it creates a "smart middleman" that will in the long term hamper security. Surely, I don't mean "Stop secure your apps from CSRF, it's not your problem". I just want to make browsers think about the issue as millions of developers have to. Because it is their issue, they are in charge. But we are fixing it on the backend(and we will have to for a next 10 years definitely)

<comment><USER8> CSRF is NOT a browser vulnerability. The browser is doing exactly what it's supposed to do: load content. The browser can not (and should not) attempt to identify the "evil" HTTP requests from the "good" ones. The browser's job is to make requests.

Now, you could argue the browser's job should be to implement security features as well. It does, after all, implement the same-origin policy. But, if you think about it, there is no good way for the browser to fix the CSRF issue. You can ask the user, which is what's suggested, but that never really works. They'll do one of two things: click "okay" _every single time_ , or stop using your browser.

I would guess well over half of all websites do one of the following: (1) load an external JS file, (2) load an external image, (3) load an external CSS file, (4) use an iframe which points to a different origin, (5) use a JS redirect, (6) use a meta redirect, or (7) open a new window.

The proposed "solution" to CSRF stops ALL of these use cases. The user would have to manually approve each and every one of them. Given that well under 1% of alerts would be true attacks, the user would almost definitely "okay" on the attacks as well: they would have been trained by thousands of other alerts that this is an acceptable thing to do.

There was a paper by Barth and Jackson on CSRF defenses where they propose an Origin header, but that's the extent to which security is implemented in the browser. It is fundamentally up to the web application for verifying the user did in fact initiate the request. No amount of code in the web browser can get around this fact.

<comment><AUTHOR> >I would guess well over half of all websites do one of the following: (1) load an external JS file, (2) load an external image, (3) load an external CSS file, (4) use an iframe which points to a different origin, (5) use a JS redirect, (6) use a meta redirect, or (7) open a new window. The proposed "solution" to CSRF breaks ALL of these uses.

You definitely kidding me. Please point out where in my post I said to deny ALL requests. I was talking about ONLY POST requests. Probably I forgot to add it :) So, I'm talking only about forms sending and GET is ok sure.

<comment><USER8> Either you do it for everything, or you do it for only POST and you end up missing half of the vulnerabilities. Correct me if I'm wrong, but your CSRF attack used a GET request, did it not? [1]

Web applications make state-changing operations on GET requests. You might not like it, but they do.

[1] <img src="<https://mail.google.com/mail/u/0/?logout> style="display: none;" />

<comment><AUTHOR> >Web applications make state-changing operations on GET requests. You might not like it, but they do.

but when developer made a mistake with GET it is 100% his problem - it's out of question. he should be punished :D

<comment><USER9> You're both just choosing different places to draw the line between _developer responsibility_ and _browser responsibility_.

<comment><USER7> That is like saying "you're both _just_ suggesting two totally different designs for the HTTP security model".

His model is wrong. Again: I assume he wants to know that, so, bluntness.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> _it took me a long time to understand the point behind CSR (cross-site requests) and CRSF fully enough to find them EXTREMELY malicious._

I think this is a very important line. The sense I get around most of my colleagues is that CSRF exploits are only something "bad programmers" get wrong. Of course, they're all rockstars who've never been exploited (yet/AFATK) so it's not like they need to spend a weekend or five paging through droll security papers. A little modesty would do us all well.

 _90% of developers just don't care and don't spend time on that._

Indeed. It takes time to learn, time to code, and unless you're working at a big shop, there's little pressure (or even acknowledgement of the need) to get this stuff right.

Keep up the good work OP.

<comment><USER11> CSRF is like a kafka-esque joke.

Here's my take away from every CSRF article:

 _A malicious site will load your site in an iframe, fill in your form and post it. Fixing it requires some a token in your form, but I can see you don't understand how an extra hidden field in your form will make a difference so you're clearly not going to handle it correctly. You're screwed. Go home._

As far as I can tell, CSRF should have existed since javascript & frames. How have the browser vendors not fixed such a huge insecure-by-design flaw?

<comment><USER12> The difficulty is _how_ to deny this happening.

Pages making GET requests across domains is so common and necessary that several technology standards would have to come together to propose a real fix. Every image or script loaded from a CDN. Anyone hosting their own static assets domains. Anyone using a plugin from Google, Facebook, Twitter, Disqus uses this ability.

The tech companies can't even easily create a system to whitelist sites allowed to embed them, because that would severely limit third party's ability to use their services freely and would introduce a huge performance bottleneck.

I haven't seen any particularly compelling solution to solving this. Things only guarded behind a GET request can be loaded by script, link, embed, object, img and iframe tags, and all of those have legitimate reasons for loading resources cross domain without requesting permissions for each one from the user.

<comment><USER11> I have no problem with cross-site GET requests because I know GETs should behave as 'read-only' anyway for lots of reasons.

What I don't get is how arbitrary cross-site POSTs with malicious values are allowed. As far as I can tell, anyone can post this form:

<form action="[http://bank.com/send_money><input](http://bank.com/send_money><input) name="to_account" value="SCAMMER-1234"></form>

Worse, one article will tell you to only allow Referrer == "bank.com", and then another will tell you that even that is no longer enough?!!!

Why can't we change the browser or the web server layer to prevent this by default?!

<comment><USER13> Browsers don't prevent it because there are legitimate uses for cross-domain posts. Good frameworks do prevent it with CSRF tokens.

<comment><USER11> I don't want the legitimate uses prevented. The default behavior should be to prevent, and the legitimate uses should explicitly opt-in. That way, you only have to do security analysis for those explicit points.

<comment><USER14> This to me is a server side issue- but that doesn't necessarily mean it's on the app developer. The behavior you're talking about can be set most servers directly, by adding the "X-Frame-Options" header into every request by default. Then exceptions would have to be made explicitly, by either the server admin or application developer. If anyone should change the default behavior (which I am not convinced is the case) it should be the server developers, not the browsers.

<comment><USER13> X-Frame-Options only prevents the page from being displayed in a frame. It doesn't prevent a page on another domain from submitting a POST request.

<comment><USER14> CSRF is solved very simply by using tokens for each field. If the attacking site can't load the other page, it can't pull the token out, and without the token the post gets discarded. If you've abstracted your form generation this should be super simple to add.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Am I correct in interpreting that the proposed fix would the be the same as the functionality provided by RequestPolicy (which he mentions in the post)? I've used it for quite a while now, and although it works well for me as a power-user (who is concerned about security), I can't imagine the confusion and pain a user will feel despite the message suggested.

Blocking resources loaded over separate domains breaks a lot of sites today. Few popular sites keep everything under the same domain (CDN´s, commentsystems, captchas and Facebook/Google/Twitter-resources, for example). <http://www.memebase.com> is probably the worst "offender" I've come across. Hacker News isn't one of them, which I'm happy to see.

Although if this was implemented I could see a lot of sites moving quickly to remedy this, reducing the alerts. It'd still be a pretty hard transition- period, though.

Want to see how much would break today (and if the fix would work for the average user)? Try: <https://www.requestpolicy.com>

<comment><USER16> As my other comment highlighted, disabling 3rd party cookies will prevent most CSRF. As an added bonus it will also increase your privacy by preventing some (but not all) cross domain tracking.

<comment><USER7> I'm not following (but I'm a little buzzed). What do third-party cookies have to do with CSRF? CSRF is a flaw in the victim application.

</comment></comment></comment><comment><USER17> Is a GET request in an iframe now considered a CSRF vulnerability? As far as I know, he hasn't actually done any cross site scripting. If i submit this as a link on hacker news and get a bunch of people to click it, have I forged a cross domain request as well?

<https://mail.google.com/mail/u/0/?logout>

<comment><USER18> Cross site scripting (XSS) is not the same thing as CSRF. If you were to do that, it wouldn't be a CSRF, because the action originated with the user.

Normally CSRFs are automatic, either in the form of an image (<img src="<https://...?logout> />) or an iframe src attribute. So, if you included the above image tag on your page, then it would be a CSRF, sometimes also called a Confused Deputy Attack.

</comment></comment><comment><USER19> Maybe this is a good time to ask:

I found an xss vulnerability in a website that can be used to cause noticeable problems (enough that fixing it should be a priority) so I contacted the developers behind the site and informed them what caused it, how to fix and an example of it in practice and why it's bad: they've done nothing in over a month. What do I do?

I guess the answer is "forget it", but I feel like if I don't _do_ anything someone malicious will discover the issue and cause harm to users of the website...

<comment><USER20> Is it a persistent XSS vuln or does it depend on malicious input being passed via the URL or POST?

It's persistent if it can be saved in a comment or on a profile, etc, and is much more dangerous if so. Non-persistent XSS realistically isn't too big a deal, most sites are vulnerable and it's usually only a problem if you're a big website and therefore vulnerable to phishing attacks.

<comment><USER19> I can link someone to a page and it can associate them with something they can then never disassociate themselves with. For example I could create an account, post illegal content (child pornography etc.) on the site then get people to click a link and forcibly associate their account with that content, which they are then tied to until a site administrator realises and fixes it. (edit: without them ever knowing)

Imagine if I could make you the author of this comment, it's like that.

</comment></comment></comment><comment><USER21> For those who didn't see the recent kerfuffle: This guy recently found and demonstrated a major Rails exploit on github. He seems to know a thing or two about security exploits.

<comment><USER22> Clarification: he didn't recently find the exploit. He's been making noises about it for a very long time and being ignored, so he took the (dubious, to some) step of using the exploit publicly and loudly, to draw attention to the problem.

<comment><USER23> Another clarification: He wasn't making noises for a long time with _GitHub_ and being ignored. His support responses were replied to nearly immediately (except where the timezone differences came into play). We take security reports very seriously.

We'd have preferred a more responsible disclosure, and I hope he (and others) are more careful about this in the future. Most reporters we get act very responsible, and we are always gracious (and even contract work from them in some cases) In his case, we saw activity that he didn't report to us, and suspended his account while we did a deeper investigation.

The Rails community and we still think that his proposed solution is not a good idea, but it did provoke exploration in some other ideas.

<https://github.com/rails/rails/issues/5228>

[http://techno-weenie.net/2012/3/19/ending-the-mass- assignmen...](http://techno-weenie.net/2012/3/19/ending-the-mass-assignment- party/)

<http://weblog.rubyonrails.org/2012/3/21/strong-parameters/>

<comment><USER24> I'm sorry, but why should he? If I find a major hole in SHA1 key handling, should I contact GitHub since you are users of it? Of course not.

<comment><USER7> "SHA1 key handling"?

Anyways, you misread him. All he's saying is that the delay Egor Homakov experienced was with the Rails dev team, not Github. Github's response to Homakov's finding was very fast.

<comment><USER24> I just pulled something out of my ass to fill in the gap. Was probably thinking of RSA.

</comment></comment></comment></comment></comment></comment><comment><USER25> My app's web site is built with Django. I use the built-in CSRF tools. (I should emphasize that my site is strictly HTTPS.)

In theory, no normal user will ever fail CSRF checks. In practice, tons of people have complained that they see Django's (very confusing) CSRF error page when they try to sign up for my service.

This was surprising to me; I thought we were _way_ past this point. Digging into it, I've learned that tons of people use extensions that muck about with cookies in ways that break Django's CSRF feature. I don't really know a way around it.

How common is this, in your experience?

<comment><USER26> Yeah this is something I run into often as I don't accept cookies from sites by default and don't send Referer header (both are required for django's CSRF middleware if over https). This is a good read if you are interested in the rational behind these decisions -> <https://code.djangoproject.com/wiki/CsrfProtection>

As far as a solution for your users, I'd just let them know that you require cookies to login (obviously) and if you are posting over https make sure they have the Referer header which can be forged to just be the domain and not the entire URL if they prefer. I use <https://addons.mozilla.org/en- US/firefox/addon/refcontrol/> set to forge for django sites.

<comment><USER25> Yeah, there are plenty of reasons to do what you're doing that seem fair to me. But at the same time, through no fault of yours, your requests are indistinguishable from potentially malicious ones. The whole thing is a mess, effectively a band-aid on top of deeper issues with HTTP's statelessness.

Also: that's a good link. Thanks.

<comment><USER26> If I'm blocking cookies/referer by default then the onus is upon me to enable them for sites that require them for stuff like this. I wouldn't worry about users who have this issue. Maybe customize django's CSRF failure page to say they need to enable both to use your service and call it a day.

<comment><USER25> I agree in principle. And I have built a custom CSRF page to help my potential customers out.

In practice, lots of my potential users don't even understand that their AdBlock/whatever extensions are mucking about with Cookies in ways that break things. It's a tough sell to tell someone who is thinking about trying your service: "sorry, I don't work with your browser the way it is" when so much of the rest of the world is either HTTP, not HTTPS, or simply has decided to punt on CSRF or be much more selective about it. It looks to them like _I'm_ the one that's broken.

Argh. It's no-win.

<comment><USER26> Humm.. I'm thinking you could write a middleware that checks for Referer over https and if not set, go ahead and set it to <https://yourdomain.com> That would allow you to continue to use CSRF middleware for the nonce check (just make sure yours is before theirs).

<comment><USER27> Except an attacker can strip a referer header: if you fail open like that, you leave yourself open to attack.

See [http://blog.kotowicz.net/2011/10/stripping-referrer-for- fun-...](http://blog.kotowicz.net/2011/10/stripping-referrer-for-fun-and- profit.html) for examples

<comment><USER26> In order to exploit this an attacker would need to be MITM on the network or on a subdomain by setting a wildcard cookie. The site would still keep the nonce check. I don't see any way around this without poking a tiny hole in the CSRF protection. Guess you gotta weigh the cost/benefit.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> This attack vector requires:

1) previous authentication to a service.

2) service which supports destructive actions as guessable URLs.

3) "third-party cookie" support in the user agent. [1]

4) a visit to a page with a malicious resource construct (an image, script, iframe, external style sheet, or object). Note that this resource could be generated by JavaScript, although this is not necessary.

Sadly, the first three criteria are widely met. If we are to systematically remove this threat, then we have to look at removing each in turn:

1) Previous authentication to a service can be mitigated by simply logging out when you are done, but this is inconvenient and requires manual user intervention. However, there is an interesting possibility to limit "important" services to a separate process - a browser, an "incognito" window, etc.

2) Services should be built with an unguessable component that is provided just prior to calling by a known-good API, probably with additional referrer verification.

3) It is my belief that disabling third-party cookies is the right solution here: users rarely, if ever, get value from third-party cookies. Denying them would allow API authors to write simpler APIs that do not have a secret component, and would allow users to maintain the same behavior and login to all their services from the same browser.

4) While it seems that little can be done on this front apart from releasing some chemical agent into the atmosphere that made people trustworthy and good, actually it may be possible for browser makers to do some simple analysis of resource URLs to detect possible hanky-panky.

[1] [https://en.wikipedia.org/wiki/HTTP_cookie#Privacy_and_third-...](https://en.wikipedia.org/wiki/HTTP_cookie#Privacy_and_third- party_cookies)

<comment><USER13> Third party cookie support isn't necessary. You could just use a link instead of an image.

<comment><USER28> Yes, that's the active form of the attack. To me, the passive form is far more pernicious (you are taking destructive action passively). At least with the active form you know that you've done something unintentional.

But this does imply that the final onus is on the programmers of services to design services that do not have guessable, destructive one-step inputs.

<comment><USER13> You could use a redirect, too.

</comment></comment></comment></comment><comment><USER29> Here's Google's reply to this particular "vulnerability": [http://www.google.com/about/company/rewardprogram.html#logou...](http://www.google.com/about/company/rewardprogram.html#logout- forgery)

<comment><USER30> I don't understand why Google say that this is an issue that can't be solved - why can't they use a CSRF token on their logout feature, either by switching to using a POST form or by appending a CSRF token to the query string?

<comment><USER31> That won't work without javascript, and then you need another URL to fallback to that'll respond to GET requests for non-javascript browsers. And then you could just XSRF the non-javascript URL.

[Disclaimer: I work at Google, but not on any area related to this]

<comment><USER30> I don't understand why this would need JavaScript - regular CSRF protection for POST requests works fine without JavaScript - why can't that be applied to the logout button?

</comment></comment></comment></comment><comment><USER32> I'm having a little trouble parsing this post. Is he saying he's discovered a variant of CSRF that cannot be stopped by using the Synchronizer Token Pattern? Or has he found something that a lot of site's protection patterns don't follow?

<comment><USER33> You seem to be familiar with the subject. I just read through CSRF and Token stuff on [1] and there's one thing I don't seem to understand.

What would prevent an attacker from open an _original_ site's page in an iframe and then have a script fill in and submit the form on it? In other words, say I am logged in into my bank's site. I then open a malicious page that has an iframe pointing at <http://bank/operations/move-funds> that contains a fund transfer form. Wouldn't this page include a correct CSRFToken, making the form readily submittable by a malicious script?

[1] [https://www.owasp.org/index.php/Cross- Site_Request_Forgery_%...](https://www.owasp.org/index.php/Cross- Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet)

<comment><USER34> This is prevented by only allowing frames to interact with each other if they're on the same domain. See (for instance) [http://msdn.microsoft.com/en- us/library/ms533028(v=vs.85).as...](http://msdn.microsoft.com/en- us/library/ms533028\(v=vs.85\).aspx)

</comment></comment></comment><comment><USER33> [ _repost from below_ ]

I just read on CSRF and its mitigation with Synchronized Tokens on [1] and there's one thing I don't seem to understand. What does prevent an attacker from open an original site's page in an iframe and then have a script fill in and submit the form on it? In other words, say I am logged in into my bank's site. I then open a malicious page that has an iframe pointing at <http://bank/move-funds> that contains a fund transfer form. Wouldn't this page include a correct CSRFToken, making the form readily submittable by a malicious script?

Can anyone comment? It damn sure looks like a big gaping hole that is virtually impossible to plug.

[1] [https://www.owasp.org/index.php/Cross- Site_Request_Forgery_%...](https://www.owasp.org/index.php/Cross- Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet)

<comment><USER27> Because a script (I assume you're referring to JavaScript) can't fill in a form on or read the contents of a third-party website. That's a violation of the same-origin policy.

CSRF tokens are a well-understood solution to this issue. In order to submit a valid request, you must include what is essentially a secret token that is on the page (although the secret token can just be your session ID). For an attacker to get that token, they would need to be able to do at least one of the following:

A. Guess it, by having you make multiple requests. (so you make the token long enough that it's infeasible to guess)

B. Be able to read it by intercepting the HTTP response or reading it in some way, in which case you have much larger security issues.

C. Be able to read the token in the HTTP request that the browser makes. Again, if an attacker can do this, your session is already compromised.

<comment><USER33> Right, the same-origin policy, thanks. Just found it after a minute of jsfiddling.

Now, let's say my script is not loading bank's page into an iframe, but rather fetches it with an ajax call. Wouldn't that page (again) include a valid CSRF token? Or is this mitigated by checking a referrer on the bank's side?

<comment><USER27> You can make but CAN NOT view the result of a cross-domain request via XMLHttpRequest unless the site specifically opts in to it. Same-origin policy again.

</comment></comment></comment></comment><comment><USER29> He logs you out of Google with a simple

</comment><comment><USER35> CSRF is a bit of a pain to work around but how much of a problem is it in the wild?

Most sites where this could do real damage (and have real gains for the attacker), banks etc are going to be well protected.

You could use it to comment spam a blog but that's going to be a crapshoot. Guessing which blog people are logged into etc, you would need very targeted attacks.

Sure , signing out of google is annoying but if you have lastpass or similar signing back in is pretty frictionless.

<comment><AUTHOR> >Most sites where this could do real damage (and have real gains for the attacker), banks etc are going to be well protected.

You think so. In "the wild" even serious systems are vulnerable #OpApril1

<comment><USER36> Why are you spacing out the "release" of your information? I assume you've found some CSRF vulnerabilities?

</comment></comment></comment><comment><USER37> RequestPolicy + NoScript are the big reason I have not switched to chromium.

In order for requestpolicy to block this it needs to be in a fairly locked down state too...

</comment><comment><USER38> A bit of a note regarding REST:

RESTful services are as vulnerable to CSRF as anything else. See [1] for more information (and I'm really sad that there's no second post, like mentioned). However, since RESTful services imply no state on the server (i.e. no token), the question is, how do you prevent CSRF attacks?

One really simple method is to deny all requests (on the server) with the application/x-www-form-urlencoded content type, and deny all multipart/form- data requests that include non-file parameters, which are the only two content types that can be sent from an HTML form. For your application, XMLHttpRequest can change the content type, and isn't affected by CSRF.

EDIT: Also, sort-of-related: I recommend you set the X-Frame-Options header too, in order to prevent clickjacking. Info at [2].

[1]: [http://blogs.msdn.com/b/bryansul/archive/2008/08/15/rest- and...](http://blogs.msdn.com/b/bryansul/archive/2008/08/15/rest-and-xsrf- part-one.aspx) [2]: [https://developer.mozilla.org/en/The_X-FRAME- OPTIONS_respons...](https://developer.mozilla.org/en/The_X-FRAME- OPTIONS_response_header)

</comment><comment><USER39> I had envisioned what I think is a more solid defense against CSRF ... I just haven't had time to build a proof.

Earlier commenters have noted that each request back to the server should include an unguessable token that cannot be derived by mining other pages on the site with cross-site AJAX requests.

My hypothetical solution is to embed that token in the prefix to the hostname after logging into the given site. The token would then be sent in the Host: header for all dynamic requests.

Step 1: You log in to www.somesite.kom.

Step 2: You are then forwarded to dynXXXXXXXX.somesite.kom where XXXXXXXX represents a unique, dynamically-generated token tied to your session.

The attacker must now know XXXXXXXX to properly form up a GET or POST request to attack your account.

The site itself could then use relative URL's for dynamic content or could use the appropriate templating system to ensure that any dynamic URL's ( either in HTML markup or script text ) contain the generated hostname.

</comment><comment><USER40> There is a HUGE vested commercial interest in the CONTINUATION of the insecure status quo, in which all the control is on the server side (hence, with the companies doing tracking and advertising using third party requests, rather than with the end user).

Furthermore, the players funding browser development all share strongly in that vested interest. (Even for Firefox, follow the money - and if Firefox did try to lock down without industry agreement, it would lose, which Mozilla knows).

So you will not see any change. This also explains the degree of heat directed at the suggestion that client behavior could be less insecure by default, with regard to third party requests.

This is not new. Much of HTTP as originally conceived actually dictated a great deal more user control over what happened. Those standards had to be compromised from the word go in order to reach the present state.

</comment><comment><USER41> Adding a extra token for protection against CSRF attacks will only work if is changed on each request. Some of the biggest sites out there do not do this. I know of one site in particular (I won't name it, but its HUGE) that generates a unique token every time a user logs in. The token doesn't change until the user logs out even if the user closes the browser and doesn't go back to the site for a week, the token will be the same. So it does its job, until somebody like me pokes around and finds a hole that will parse out that token, and generate a form that can make any request on behalf of that user in a iframe without that user knowing a thing. Evil yes, but I found this months ago, and it still works..and I haven't used it in anyway, besides a proof of concept.

<comment><USER13> You shouldn't be able to get the token from another domain, regardless of how long it lasts. How are you able to?

<comment><USER41> Im getting it on the same domain, but the request can be sent from any domain, as long as the user is logged in.

</comment></comment></comment><comment><USER42> If Google required a POST to log out (as it should be, since logging someone out is changing the session state and therefore not a "safe" GET-able request[1]), we could fall back to CORS as protection which removes the need for a CSRF token. Since the only way (I believe) to get a POST to fire cross- domain, without explicit user interaction through, say, a regular HTML form, is through JavaScript, the browser would refuse to make the request unless the CORS headers explicitly allowed it.

Still, using <form> buttons for logging out, consistently across the entire web, would take some effort. CSRF tokens are probably less intrusive.

[1]: [http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1...](http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1)

<comment><USER27> " _Since the only way (I believe) to get a POST to fire cross-domain, without explicit user interaction through, say, a regular HTML form, is through JavaScript, the browser would refuse to make the request unless the CORS headers explicitly allowed it._ "

I'm not quite sure what you're trying to say here. But you can make cross- domain POST requests in two ways, both involving JavaScript:

1\. Create an HTML form, use JavaScript to submit it.

2\. Use XMLHttpRequest to make a cross-domain POST.

<comment><USER42> Yes: "the only way [...] to get a POST to fire cross-domain [...] is through JavaScript".

The request would go against the same-origin policy, at which point CORS comes into play.

Edit: Ah, but creating a form in the DOM and submitting it via JavaScript... that one I hadn't thought of.

<comment><USER27> To fire automatically, yes: getting people to click on a button of their own free will is easy though.

</comment></comment></comment></comment><comment><USER43> "April fools day" will not be a good day for him to publish "secret stuff".

<comment><AUTHOR> why? seems perfect.

<comment><USER44> Many people will assume it's a joke, and not take you seriously - of course, at their own risk.

</comment></comment></comment><comment><USER45> Bravo! If you thought you were immune because you only visit "reputable" sites it'll make you think twice. I tried putting it in a incognito tab in Chrome and Google apps in a normal tab. That didn't log out, but if I put both google apps and this site in incognito tabs or normal tabs then it logged me out. Pretty important to log out of sites when you aren't using them. But, more important to fix my sites!

</comment><comment><USER46> I am hesitant to post this, because from experience, smart people frequently misread or misunderstand it, but:

The easiest first-step solution is just to check the HTTP Referer field, and check it matches your domain.

Yes, this is easily faked by someone crafting their own HTTP requests. This is /not/ easily faked by someone causing your browser to make requests, though. And it provides very good coverage against the attack here.

<comment><USER47> If you do that, you then have to make sure your app doesn't have any redirector anywhere or anything that writes Location. Almost all apps do. This is because you can get the site to insert the right referrer.

for eg. if the URL of the attack request is (both of these are close to real life examples that work(ed))

[http://www.site.com/mail/filter?create=*%2Cattacker%40hush.c...](http://www.site.com/mail/filter?create=*%2Cattacker%40hush.com)

usually the site will have a redirector on the login action, which takes the user back to the page that they were on after login, so you just use the attack URL as the redir URL

[http://www.site.com/login?return_to=%2Fmail%2Ffilter%3Fcreat...](http://www.site.com/login?return_to=%2Fmail%2Ffilter%3Fcreate=*%2Cattacker%40hush.com)

amazing how many login scripts still do the redirect even if the user is already logged in, or still do the redirect even if there is no real login

even if you do a javascript in-place login, there is usually a mobile version that has this pattern. I rarely meet a site that doesn't have a way to bounce between URLs and fake the referrer.

I guess the real conclusion is that these types of attacks are complicated and better understood fully than implying a single short solution - because the next response is always "but, if you do that, then" and so forth, like a matryoshka doll

</comment></comment><comment><USER48> I wonder what will happen to websites which use cross-domain post requests to log in securely, e.g. <http://example.com> submitting the login form to <https://secure.example.com>

<comment><USER49> If they are using tokens then this should be viable as long as the state is shared across servers.

</comment></comment><comment><USER50> I 100% agree - CSRF is a huge hack: basically telling programes to add CSRF to all their forms and requests shows that all these cookies and security measures in browsers are worth shit. It seems like the entire web security needs to be redesigned from scratch.

<comment><USER51> I agree that web security needs to be rethunk from the ground up, but I don't think it's fair to blame browsers for things that are fundamentally HTTP protocol and server app problems.

</comment></comment><comment><USER20> This is a problem with app developers, not browser makers. Applications should follow the HTTP spec and not do any persistent changes via GET.

The "I can log you out of Facebook/etc" trick is one of those techniques that script-kiddies love using on forums.

<comment><AUTHOR> read again, it's not about GET and google trick is just trick.

</comment></comment><comment><USER52> Google allows a logout from a GET request, on Chrome of all browsers? Is there a way to run browser tabs completely sandboxed regarding cookies/auth? (private browsing mode and running different browsers is a bit too clunky)

<comment><USER53> Chrome allows you to set up multiple user profiles; each one is isolated from the others. Like Incognito mode, it's per-window, not per-tab. I have one for GMail, one for Facebook, and one for everything else.

</comment></comment><comment><USER54> Okay, this is a good idea, but how would it handle legitimate requests to other domains?

Issues: \- some users would click allow anyway, so it doesn't completely solve the problem \- what about apps built using CORS.. etc

</comment><comment><USER55> Is this what's happening with "hacked" twitter accounts that don't ever seem to have had anyone access them or change the password and seem to suddenly start spewing bizopp spam for a day or two?

</comment><comment><USER16> Preventing this in the browser is actually pretty trivial for most sites. Simply block 3rd party cookies. If the site uses cookies to track sessions the request won't have your session cookie and won't work.

It's not up to browsers to prevent this. Just like how you can't rely on client side data validation you must always take proper precautions on the server. Browsers taking additional precautions to prevent this would be nice but it's not the whole solution and never will be.

Edit: If you're going to downvote this please leave a reply stating why. I don't understand an opposing point of view unless you use 3rd party cookies to track people across domains.

</comment><comment><USER56> Don't allow actions through GET, always use POST.

<comment><USER57> That doesn't solve it because the attacker can just create a <form> and auto submit it with js (or make a translucent submit button that is the size of the entire page if you have JS disabled).

<comment><USER38> For example:

          <form name="evil" method="POST" action="https://mail.google.com/mail/u/0/?logout">
          </form>

The massive button is left as an exercise to the reader ;-)

</comment></comment></comment><comment><USER58> Aren't you protected if you just use csrf tokens on sensitive POSTs? I thought it was good practice to always do that anyways.

</comment><comment><USER59> Are REST APIs susceptible in the same way? Or as long as we don't store our auth token on the client cookie we're ok?

</comment><comment><USER60> I'm having a bit of trouble parsing the post. Did he just discover CSRF and is trying to raise awareness? Or did he discover a new variant of CSRF that makes previous counter-measures ineffective?

For completeness, Rails guide covers these security holes [http://guides.rubyonrails.org/security.html#cross-site- reque...](http://guides.rubyonrails.org/security.html#cross-site-request- forgery-csrf)

</comment><comment><USER61> "Jeff Antwood" Entertaining read.

</comment><comment><USER62> Web is already too useless because people can't think about security in a decent way.

Still baffles me that i can't allow a script at one domain to automate something in another domain for me.

</comment><comment><USER63> WOW You've discovered absolutely new type of vulnerability! Awesome work! lol lmao

<comment><AUTHOR> no food for troll here

</comment></comment><comment><USER64> You realize you could be monetizing these security vulnerabilities, right?

<comment><AUTHOR> how? If I report nobody pays even 'thank you'.

<comment><USER64> Fuck reporting it, unless you're contractually obligated because they've retained you (or, if it's an open source project you like, and want to support). If vendors won't even listen to you, clearly they don't value your time or their product, or their customers.

You can sell security vulnerabilities to a variety of parties. If you want introductions, email me.

Some people view this as "wrong" in some ethical way, but meh. Money is good -- it can be exchanged for valuable goods and services. There have been a lot of arguments for "responsible disclosure", "anti-sec", "full disclosure", etc. over the years.

I'd draw the line at blackhatting yourself with the vulnerability, but just selling the info is legal. Generally, security companies are buyers, and their clients tend to be governments, generally western (USA).

<comment><AUTHOR> I've been black in the past, now I'm completely white hat.</comment></comment></comment></comment>


GitHub on applying Getting Real to their unfunded startup - <AUTHOR> http://37signals.blogs.com/products/2008/07/how-github-used.html

<comment><USER2> GitHub is the first app that actually makes me want to start new projects, open-source old projects, and get involved in other people's projects just as an excuse to use the site.

Big ups to defunkt, mojombo, and pjhyett for their work in this space.

<comment> a-priori Likewise here. GitHub has encouraged me to publish some side projects that otherwise would have lingered on my hard disk. Getting an email saying someone has started watching one of them is sure motivation to get my ass in gear and do some work on it. GitHub also worked splendidly for a recent freelance job.

Keep up the good work guys.

</comment></comment><comment><USER3> "They say it's hard to live in San Francisco and not take funding, but I beg to differ: out here it's easy to get lucrative consulting gigs and fill your bank account. Contract for someone else with funding, make some money, save it up, then spend it on your company. You don't have to sell your soul to a VC or live off of ramen. Just be smart."

Brilliant secondary effects of venture capital funding.

</comment><comment><USER4> GitHub is not only a stellar product, it is also changing the world.

SourceForge, RubyForge, and others should take note. This is a great model of how social code should be done.

</comment><comment><USER5> Chris and Tom are prolific hackers. I'm always amazed by the volume of quality code they produce. They definitely deserve all of the success they've achieved.

</comment><comment><USER6> From someone who has to deal with CVS on sourceforge, a HUGE THANK YOU to the GitHub crew!

Now I just have to convince the other developers to move the project to GitHub.

</comment><comment><USER7> i completely agree that this was a great article, and in the last 5 minutes it took to read i could feel myself wanting to get my side project off the ground that much more -- thanks for the boost guys!</comment>


Uber and Lyft granted an emergency stay - <AUTHOR> https://twitter.com/DaveLeeFT/status/1296519924618207232 <comment><USER2> It's far better to let CA voters decide in November how they want Uber/Lyft to be regulated on this issue.

Once that's done, the court can either continue the stay or enforce it depending on the outcome. Either way, democracy wins.

<comment><USER3> Direct democracy is bad. All one has to do is whip people into an emotional frenzy. Essentially you are arguing that the people should further circumscribe Individual rights like entering into a contract. Now people that made extra money, probably needed extra money, will be denied this option because the people will put the requirement of health benefits onto the contracting company.

<comment><USER2> We don't support democracy because it always produces the "right' answer, we support it because the alternative is authoritarian rule and violence.

Far better to have the consent of the governed, even when imperfect.

<comment><USER3> You can do this with a republic. California's direct democracy has shown itself time and again to be a bad idea. People vote emotionally. They approve expenses without requiring funding. They vote property taxes down. Ultimately you need the buffer of a republican system to cool heads.

</comment></comment></comment></comment><comment><USER4> This story is currently on the front page from a different source here: [https://news.ycombinator.com/item?id=24227340](https://news.ycombinator.com/item?id=24227340) .

<comment><AUTHOR> The story "broke" on this and another tweet. The Verge originally just posted the tweet but then updated to a full article.

Btw not criticizing this comment :D just adding context

</comment></comment><comment><USER5> This goes to show... if you burn enough VC money to get yourself into an IPO, you can leverage that "for the jobs"...

</comment><comment><USER6> This is disappointing..

</comment><comment><USER7> Every time a government is bullied by a corporation is just as disgusting as the last.

<comment><USER8> This feels like the inverse to me. Every traditional industry has gotten an exception carved out for itself in the law, this is basically just discriminate targeting of Uber and Lyft.</comment></comment>


A texture-mapped raycaster in 128 bytes - <AUTHOR> http://www.pouet.net/prod.php?which=63518 <comment><USER2>
        ; Wolf128 by Baudsurfer/rsi 2014 aka olivier.poudade.free.fr
        ; A 128 bytes interactive intro tested on XPSP3 and DOSBox
        ; Presented at Outline demoparty in Eersel/The Netherlands
        ; 256 bytes versions :
        ; http://www.pouet.net/prod.php?which=24755
        ; http://www.pouet.net/prod.php?which=3396
        ; P.S : click left mouse button to start moving in maze
        ; Greets to UkkO Ggn Fra Den and assembly language lovers
          org 100h
          mov al,13h
          int 10h
          les dx,[bx]
        A:mov cl,0ffh
        B:mov bl,cl
          not bl
          lea ax,[di-10h]
          mov bp,140h
          cdq
          div bp
          call G
          call G
          test byte [1dh],7
          jz C
          add dh,[1fh]
          sub bl,[1eh]
          jmp short E
        C:mov dl,[fs:46ch]
          sub bl,[si]
          test dl,40h
          jnz D
          add dh,dl
        D:add bl,dl
        E:shld bp,bx,10
          sub dh,[bp]
          mov al,dh
          and dh,bl
          or dh,ah
          and dh,20h
          loopz B
          xor al,bl
          xor al,ah
          db 0d4h,10h
          add al,10h
          stosb
          or di,di
          jnz A
          mov ax,3
          int 33h
          test bl,al
          mov [1dh],bl
          jz F
          mov [1eh],dl
          mov [1fh],cl
        F:in ax,60h
          dec ax
          jnz B
        G:xchg ax,dx
          sub ax,64h
          imul ax,bx
          add ax,[si]
          ret

<comment><USER3> Does someone know what "mov dl,[fs:46ch]" does? In win32, fs and gs point to some process or thread info blocks, but in DOS? I was never aware of anything regarding the fs register and DOS unless a dos extender was run or pmode was entered!

<comment><USER4> If memory serves me right, fs=gs=0 in DOS mode, and 46C is a tick counter of some sort.

And on a C64, addresses 53280 and 53281 change text background and border. Don't know why I remember these things.

</comment></comment></comment><comment><USER5> Something terrible and greatly upsetting seems to have happened in the comments, but I can't for the life of me understand what.

<comment><USER6> As CountHackulus says, basically "drama". If it amuses you for some reason, you might want to check out "Jason Scott - You're Stealing It Wrong! 30 Years of Inter-Pirate Battles" from Defcon 18. [http://youtu.be/QCAL_YgYiP0](http://youtu.be/QCAL_YgYiP0) The meat of the talk starts around 24min.

edit: while re-watching, I should warn you lots of foul language and some NSFW imagery

<comment><USER7> For some reason the link to all the scene lingo is down now. Is there a backup? Did it move? Do I need to be "in" something?

</comment></comment></comment><comment><USER8> Ah the Demoscene... This is the kind of stuff that got me interested in programming in the first place. :)

</comment><comment><USER9> The 1st place entry is apparently very similar, but trades interactivity for _sound_ and rather more psychedelic colours:

[http://www.pouet.net/prod.php?which=63517](http://www.pouet.net/prod.php?which=63517)

<comment><USER10> Same author.

</comment></comment><comment><USER11> These demos always amaze me. Can somebody enlighten me as far as the way the size is measured - does it typically include all of the assets such as music and textures? I was watching a few of the demos and it blows my mind that the audio would even fit in that amount of space, let alone the visuals.

<comment><USER12> Size includes everything. Usually the textures are procedural, but can be seeded so they're the same every time. Music is usually pretty easy to encode if it's a chiptune, loads of redundant data.

<comment><USER13> bemmu

Hopefully you see this, unfortunately your comment is dead.

Because I think your comment has value I will quote it here, please let me know if you'd like it removed.

"You can also have procedural music.

Viznut (a legendary Finnish democoder) did some experiments to see how short you could code something that still sounds at least interesting:

[https://www.youtube.com/watch?v=GtQdIYUtAHg](https://www.youtube.com/watch?v=GtQdIYUtAHg)

I also wrote piece of JavaScript that can play these programs in case you want to try create your own: [http://www.bemmu.com/music/index.html](http://www.bemmu.com/music/index.html) "

<comment><USER14> Thank you all, malnourish, bemmu and viznut -- now I understand how the 8bit synth works in Caustic on my Android tablet. Furthermore, I want to make my own music software on my Raspberry Pi and Adapteva Parallellas and this is the first real step on the path to that.

<comment><USER15> Make sure to watch some of the later videos too as viznut added some visualizations as well: [https://www.youtube.com/watch?v=tCRPUv8V22o](https://www.youtube.com/watch?v=tCRPUv8V22o)

<comment><USER14> Thanks for the link, very cool.

</comment></comment></comment></comment></comment></comment><comment><USER16> Man, wouldn't it be awesome if we'd had the public internet instead of just BBSes back when stuff like this was cutting-edge tech, instead of just a clever hack? Imagine if, say, C64 devs and hackers could do this kind of sharing instead of being limited to word-of-mouth.

</comment><comment><USER17> These kinds of ray casters are really cool, but at this point in time I don't care about how small the code base is, just make a really cool ray caster in JavaScript and don't worry about how big the code is (within reasonable limits)! I just want an awesome JavaScript ray caster library to be honest. :)

<comment><USER17> Looks like this comment of mine was irrevocably wrong and completely irredeemable. No apology is possible and I'm sorry for my very existence. Go social voting sites! Go internet culture! Yay.

<comment><USER18> A harsh response, yes. But frankly, what you said was harsh. An interactive raycaster in an executable an order of magnitude smaller than most networks' minimum transmission unit is an incredible accomplishment, and your response is to essentially drop trou and take a dump on it because teh w3b 4evaz.

<comment><USER17> What I said wasn't harsh, it just wasn't apparently enough genuflection and awe to appease the people that happened to be interested enough to check the comments on this link. I care about as much as I did yesterday, which is not nothing. You and everyone else who demands more will just have to deal with it.

<comment><USER19> No; if you don't appreciate something because you suspect you don't understand or lack context (as you expressed), you should just keep your mouth shut lest you sound like an idiot.</comment></comment></comment></comment></comment>


NYC Government Software Consultants Charged in $80M Waste, Fraud Scheme - <AUTHOR> http://www.democracynow.org/2010/12/16/new_york_city_consultants_charged_in

<comment><AUTHOR> a previous story about these folks (prior to the charges): <http://news.ycombinator.com/item?id=1221068></comment>


Porting to Emscripten - <AUTHOR> https://hacks.mozilla.org/2014/11/porting-to-emscripten/

<comment><USER2> One thing missing from the article: If you have a fullscreen mode, provide an alternative to the escape key for opening menus or whatever action you had bound to that key, because the browser interprets escape as a command to exit fullscreen mode. Plenty of the Humble Bundle asmjs games didn't get this.

</comment><comment><USER3> So when can we see Firefox ported to Emscripten?

<comment><USER4> While you are waiting: [http://badassjs.com/post/73526882798/webkit-js-its- happening...](http://badassjs.com/post/73526882798/webkit-js-its-happening- for-real-with-emscriptens)

</comment></comment><comment><USER5> I can't wait until the tooling gets to where I don't have to debug natively first.

I perticularly ran into issue dealing with unimplemented functions in some POSIX libraries. Then I tried to use the source maps in a debug build to find out when and where they were being used during runtime because they would stop the rest of the program. Unfortunately I couldn't compile the debug build because emscripten kept getting stuck in the linking phase (I had to force quit). I hope one day this all works as well as the Android NDK.

</comment><comment><USER6> This looked like great news until I came to "Heavy use of threads is also going to be a problem since Emscripten doesn't currently support them."

Sorry, this is a total showstopper for me. I'll check back when Emscripten actually lets me use more than 1/4 or 1/8 of the CPU.

<comment><USER5> According to this document Jukka Jylänki is working on it: [https://docs.google.com/spreadsheets/d/t3AwIGGaM-4Z9UZM2jpF6...](https://docs.google.com/spreadsheets/d/t3AwIGGaM-4Z9UZM2jpF6KA/htmlview?pli=1#gid=0)

<comment><USER7> Oooh - how did you come across that? I had an idea for a way to do this [https://groups.google.com/forum/#!searchin/emscripten- discus...](https://groups.google.com/forum/#!searchin/emscripten- discuss/marcosscriven/emscripten-discuss/gjjJcCF-Tz8/d1BtJjUuKOgJ)

</comment></comment></comment><comment><USER8> Shameless plug for my MIT licensed, experimental, mini C++11 multiplatform engine which has been designed specifically with emscripten in mind: [http://floooh.github.io/oryol/](http://floooh.github.io/oryol/)

</comment><comment><USER9> This is great news, it feels like the future is finally starting to arrive. Check this out: [http://jamesfriend.com.au/pce- js/](http://jamesfriend.com.au/pce-js/)</comment>


Persistant SSH Threats? - <AUTHOR> For the past few months my server has seen an SSH connection attempt about once a minute. There is no reason to SSH to my server as there is nothing on it except at static website.
The SSH connections are coming from seemingly random IP addresses, rarely from the same one twice.
Is anyone else seeing such connection patterns? <comment><USER2> Yes, it's normal. Just people scanning for SSH ports to attack.

What I did was take the IANA IPv4 address space list[1] and add firewall rules to drop packets to port 22 coming from /8's that I would never connect from. I'm in the US, so it made sense for me to drop connections from subnets assigned to RIPE, APNIC, etc. It didn't eliminate the problem, but it reduced the connection attempts considerably.

1\. [https://www.iana.org/assignments/ipv4-address- space/ipv4-add...](https://www.iana.org/assignments/ipv4-address- space/ipv4-address-space.xhtml)

</comment><comment><USER3> Yeah, it's common. I hide my critical services with pyknock[1] - it's a modern successor of port-knocking implementation, based on HMAC signatures rather than on simple port sequence.

[1] - [https://pypi.org/project/pyknock/](https://pypi.org/project/pyknock/)

</comment><comment><USER4> Related question that has crossed my mind: what is this risk exposure of a linux server that is accessible via the internet that has port 22 enabled, and only has users with --disabled-password set (requiring ssh connection)?

As a follow up, what is increased benefit (if any) if port 22 is only accessible by a certain IP address (e.g. my home address)?

<comment><USER5> I do something similar but added a knock daemon and changed the default ssh port 22 to something else.

 _So far_ I haven't had any issues, fail2ban works, and it seems safe.

I do have my home IP added to the whitelist and others set to drop.

I was told in a networking class this is the second best way to protect ssh other than not running ssh.

Any thoughts on this setup as well? Maybe oversights that I'm not seeing?

</comment></comment><comment><USER6> At least this can make for very exciting wallpapers?

[https://dev.to/lbonanomi/hello-worm-mapping-ssh-probes- with-...](https://dev.to/lbonanomi/hello-worm-mapping-ssh-probes-with-a-bash- script-3if7)

</comment><comment> m-p-3 Totally normal, make sure to use a secure mean of access like pubkeys, turn off normal password authentication, and optionally put fail2ban and totp[1]

[1]: [https://www.digitalocean.com/community/tutorials/how-to- set-...](https://www.digitalocean.com/community/tutorials/how-to-set-up-multi- factor-authentication-for-ssh-on-ubuntu-16-04)

IMPORTANT: If you do setup totp, make sure your server is actually syncing its clock with NTP, because if there is a significant time-drift you might be locked out from accessing SSH remotely.

</comment><comment><USER7> Welcome to the world of servers. There are these bots/scripts running all over the internet that are scanning for stuff like this and always trying to brute force into servers they can find and get in. The good news is that this is not only targeted at you. The bad news is that you cannot do much about them except ensuring that your servers are hardened and have the right security setup. There are tools like fail2ban etc. that can block those IP addresses but again, you cannot really stop them as you will get these hits from random IPs all over the world.

</comment><comment><USER8> Yes, for decades. Move SSH off of port 22 and you'll see far fewer attempts.

<comment><USER9> No idea why you are being downvoted, this is a solid advice. Masscan [1] claims to scan whole IPv4 Internet for a single port in 5 minutes. Moving to a random high port would increase scan time 64000-fold, to 7 months.

You'd still be advised to disable password-based auth and/or configure fail2ban, though.

[1] [https://github.com/robertdavidgraham/masscan](https://github.com/robertdavidgraham/masscan)

<comment><USER10> It's a bad idea, privileged ports are a thing for a reason.

[https://www.w3.org/Daemon/User/Installation/PrivilegedPorts....](https://www.w3.org/Daemon/User/Installation/PrivilegedPorts.html)

[https://adayinthelifeof.nl/2012/03/12/why-putting-ssh-on- ano...](https://adayinthelifeof.nl/2012/03/12/why-putting-ssh-on-another-port- than-22-is-bad-idea/)

<comment><USER9> You have a point there, but it's far, far from being so clear-cut.

Privileged ports is a measure to guarantee that daemon listening there was started with root privileges. Which is a useful guarantee on a shared server, less so on a single-purpose or personal server.

Plus, if you have an sshd started at boot, and already listening on a pre- defined high port, there is very little chance another program could bind to the same port, save crashing and racing the daemon.

Finally, in ssh protocol, server authenticates itself to the client, so even if by some trickery a bogus ssh server would bind to the same port, it will either need to access /etc/ssh/ssh_host_*_key, which are enforced to be root- readable only, or risk being trivially detected by a client comparing presented public key to that saved from last login in the ~/.ssh/known_hosts.

There are also some DPI firewalls, or just port-based firewall that can block ssh traffic on a non-standard port, but assuming we are talking about your own server, that should be easy to rectify too.

<comment><USER10> You understand the risks, but it's also a bad idea because it's effectively security-by-obscurity. I can port scan your host and find your SSH port in just a few minutes. Port knocking is better but still not foolproof unless you're doing some crazy 12-port sequence... And _not_ having hordes of chinese bots hammering on our SSH port makes us slip up and do silly things like leaving password auth enabled.

There's no harm in having connection attempts on your ssh port. Changing your port will not make you more secure against a dedicated attacker, and you just make things harder for yourself (and marginally less secure, for the reasons you mentioned) with no real benefit.

And like I mentioned in the other comment, just use SSH keys and disable password auth. It's not hard, and it's all it takes to thwart every bot that hits you on port 22. If you want to be more hardcore you can run fail2ban or firewall the port down to your country or whatever.

It's the equivalent of "I connect to my host via IP address instead of having DNS records because it'll be harder for them to find!".

<comment><USER11> Obscurity is just one more security tactic. Security by obscurity as the only defense is bad. As an additional layer to many defenses it is a sound choice.

You still paint camoflage on a tank.

</comment></comment></comment></comment></comment></comment><comment><USER12> That's normal, it's often referred to as background noise: [https://en.wikipedia.org/wiki/Internet_background_noise](https://en.wikipedia.org/wiki/Internet_background_noise)

It stems from automated port scans sweeping IP ranges looking for vulnerable/exploitable systems.

A simple way to address it is to use something like fail2ban to ban repeat offenders. Blacklist services like abuseipdb.com may help further, but ban with caution.

</comment><comment><USER13> Blacklistd (available natively on FreeBSD and NetBSD) are a good defense against these attacks. If you're using Linux you'll have to use fail2ban or something that scans log files for a similar. Using public key authentication and disabling password authentication is also a good idea.

</comment><comment><USER14> Yes, this is normal.

Any server exposed on the internet will be probed constantly by botnets.

</comment><comment><USER15> I notice the same thing: connections from random combinations of IPs/usernames.

Sadly, that comes with having a public accessible server: people wanting to hack their way in.

</comment><comment><AUTHOR> I have SSH disabled.

<comment><USER3> Are you Telnet or RDP person?</comment></comment>


Balsillie fears TPP will cost Canada billions - <AUTHOR> http://www.theglobeandmail.com/report-on-business/balsillie-fears-tpp-will-cost-canada-billions-may-be-worst-ever-policy-move/article27171764/ <comment><USER2> It is mentioned in the article that the Minister for International Trade, Chrystia Freeland, wanted Canadians to send her comments about it.

Here is her tweet about it: [https://twitter.com/CanadaTrade/status/662397645722361856](https://twitter.com/CanadaTrade/status/662397645722361856)

It would be nice if there was a website breaking down what exactly is bad about the TPP, complete with links back to the draft text and if people just replied back with that. I think something like genius.com would be useful for this purpose, but I don't have the knowledge to highlight what is bad.

Edit: Well, I'm getting started putting stuff up on Genius.com: [http://genius.com/albums/Transpacific-partnership-tpp- negoti...](http://genius.com/albums/Transpacific-partnership-tpp-negotiating- parties/Trans-pacific-partnership) .

Here is where the PDFs are: [http://www.mfat.govt.nz/Treaties-and- International-Law/01-Tr...](http://www.mfat.govt.nz/Treaties-and- International-Law/01-Treaties-for-which-NZ-is-Depositary/0-Trans-Pacific- Partnership-Text.php)

Another edit: I am just dumping the text for now. Not sure if I will get to formatting it nicely.

<comment><USER2> Update 10:47 AM EST: I put up chapters 0-30. I still have the annexes from chapter 2, 12, and 15 to do (I am doing them next). I made a few mistakes with chapter 20 (Environment), and I cannot delete them. I used the "Contact Us" link to ask to have those pages deleted. Here are the links to be deleted in case someone with links to genius.com is reading:

[http://genius.com/Transpacific-partnership-tpp- negotiating-p...](http://genius.com/Transpacific-partnership-tpp-negotiating- parties-20-environment-chapter-annotated)

[http://genius.com/Transpacific-partnership-tpp- negotiating-p...](http://genius.com/Transpacific-partnership-tpp-negotiating- parties-20-environment-ch-annotated)

[http://genius.com/Transpacific-partnership-tpp- negotiating-p...](http://genius.com/Transpacific-partnership-tpp-negotiating- parties-20-environment-annotated)

Edit: Initially, I had the chapters categorized as X (other), but I started changing them to Law. genius.com doesn't seem to let me change it after the fact.

Update 11:37 AM EST: It seems like I have hit a limit as to how many "songs" (chapters) an album ("document") can have. Any new ones I make do not appear in the album. I am going to have to stop for now since it will be hard to keep track. These are the two I made before I noticed:

[http://genius.com/Transpacific-partnership-tpp- negotiating-p...](http://genius.com/Transpacific-partnership-tpp-negotiating- parties-2-d-peru-tariff-elimination-schedule-annotated)

[http://genius.com/Transpacific-partnership-tpp- negotiating-p...](http://genius.com/Transpacific-partnership-tpp-negotiating- parties-2-d-singapore-general-notes-to-tariff-schedule-annotated)

Update 12:38 PM EST: No word yet on the issue with genius.com . I did find the contact information for Minister Freeland [1], and search page for Canadian Members of Parliament (you can search by postal code) [2].

[1] [http://www.parl.gc.ca/Parliamentarians/en/members/Chrystia-F...](http://www.parl.gc.ca/Parliamentarians/en/members/Chrystia- Freeland)

[2] [http://www.parl.gc.ca/Parliamentarians/en/Constituencies/Fin...](http://www.parl.gc.ca/Parliamentarians/en/Constituencies/FindMP)

<comment><USER2> Update 4:53 PM EST: I only managed to reformat the Preamble and Chapter 1. Still no word from genius.com about the issues I am having. I tweeted for the first time: [https://twitter.com/TeeAyKay/status/663830955971338240](https://twitter.com/TeeAyKay/status/663830955971338240) . I kept the language of the tweet neutral to see who participates. I know I am potentially opening the flood gates to abuse on genius, but hopefully the dry subject matter will keep the trolls away and attract people who can bring insight and foresee potential consequences. I am biased towards lawyers in this regard, but they might just be like too much of "I am not _your_ lawyer" to participate.

Thanks, to genius.com for providing the platform for this endeavour (I hope you get in touch with me!).

</comment></comment></comment><comment><USER3> > contains "troubling" rules on intellectual property that threaten to make > Canada a "permanent underclass" in the economy of selling ideas

Why?

> He fears it would give American firms an edge and cost Canadian companies > more money because they would have to pay for someone else's ideas instead > their own.

What?

> On top of that, Balsillie believes the structure could prevent Canadian > firms from growing as it would also limit how much money they can make from > their own products and services.

Again why?

I don't think this article ever specifically explains why TPP is bad for Canada.

<comment><USER4> >I don't think this article ever specifically explains why TPP is bad for Canada.

Does any TPP article do more than fearmongering? Its clear there are people who are against low barriers to trade by principle. They believe in strict isolationist protectionism as being economically superior. Historically they've been wrong, but they have an activist voice on the web. Stuff like this should give people pause on how things get popular on the web and who is selling you what message.

From a larger perspective, I feel that TV and print media had guys like Neil Postman and Marshall McLuhan, but the web doesn't really have anyone giving a critical message about how untrustworthy and unreliable communication like this is.

<comment> vezzy-fnord Of course, it's the people _against_ convoluted, multipronged trade agreements who are the neo-mercantilists! The Ludwig von Mises Institute are all a bunch of reds!

<comment><USER5> You do understand what mercantilism is, right? Less free trade is a central part of it.

<comment> vezzy-fnord And by definition omnibus bills like "free trade agreements" are a central instrument in curtailing it. Micromanagement of every detail is the _antithesis_ of freedom. You don't seem to be well versed in what free trade is.

</comment></comment></comment></comment></comment><comment><USER6> Jeffrey Sachs commented yesterday about the U.S. fast-track requirement for a bundled all-or-nothing vote, [http://www.bostonglobe.com/opinion/2015/11/08/jeffrey- sachs-...](http://www.bostonglobe.com/opinion/2015/11/08/jeffrey-sachs-tpp- too-flawed-for-simple-yes-vote/sZd0nlnCr18RurX1n549GI/story.html), _" TPP is too flawed for a simple 'yes' vote" … the 12 signatories should slow down, take the pieces of this complex trade agreement in turn, and work harder for a set of international standards that will truly support global sustainable development … The agreement, with its 30 chapters, is really four complex deals in one.

The first is a free-trade deal among the signatories. That part could be signed today. Tariff rates would come down to zero; quotas would drop; trade would expand; and protectionism would be held at bay. The second is a set of regulatory standards for trade. Most of these are useful, requiring that regulations that limit trade should be based on evidence, not on political whims or hidden protectionism.

The third is a set of regulations governing investor rights, intellectual property, and regulations in key service sectors, including financial services, telecommunications, e-commerce, and pharmaceuticals. These chapters are a mix of the good, the bad, and the ugly. Their common denominator is that they enshrine the power of corporate capital above all other parts of society, including labor and even governments.

The fourth is a set of standards on labor and environment that purport to advance the cause of social fairness and environmental sustainability. But the agreements are thin, unenforceable, and generally unimaginative. For example, climate change is not even mentioned, much less addressed boldly and creatively.

… The up-or-down vote therefore raises two questions. First, are the bad parts indeed bad enough to vote down the package, thereby jeopardizing the undoubted good of other chapters? Second, do we truly face an all-or-nothing proposition, or rather could we agree with our negotiating counterparts on certain chapters while reconsidering others? … Congress should vote "no'' on the current TPP, while simultaneously endorsing its trade provisions as well as continuing the work with our counterparts on the other chapters. Globalization is indeed so important for our common good that it's of overriding significance to get it right."_

<comment><USER7> The reason all these things are glued together into one deal is that they will not pass on their own, because international trade is not symmetrical.

Consider a wealthy post-industrial nation A trading with a poor industrial nation B. Raw materials and simple goods flow from B to A, so tariffs will be the primary concern. Capital, complex goods, services, and IP flow from A to B, so investment, IP, and regulatory issues will be of concern in that direction. A tariffs-only deal will not be balanced and therefore not succeed. Likewise a regulations-only deal.

Trade issues are not even balanced between industries. A tariffs-dropping deal will find support from manufacturers, but opposition from materials companies.

So to succeed, a trade deal must balance the various interests of many stakeholders. That means gluing a bunch of stuff together so that to any given person, some parts will look good and some parts will look bad.

The reason Congress created fast track is that different people will see different parts as good and bad. Fast track ensures a simple vote on the balance as a whole. If enough people see more good than bad--overall--it passes.

A trade deal will never look ideal to anyone. The question is whether it's a net gain for most.

<comment><USER6>
      > The reason Congress created fast track is that different
      > people will see different parts as good and bad.

That's one perspective. Public Citizen has another, [http://www.citizen.org/documents/fast-track- chart.pdf](http://www.citizen.org/documents/fast-track-chart.pdf)

 _" When Richard Nixon was president, he cooked up Fast Track to seize power from Congress. The U.S. Constitution gives Congress exclusive authority to "regulate commerce with foreign nations" (Art. I-8). Fast Track was a mechanism that delegated away to the executive branch Congress' authority to control the contents of U.S. trade pacts, as well as other important powers.

Fast Track empowered executive branch trade negotiators, advised by more than 600 official trade advisors who mostly represent large corporations, to choose trade partners and negotiate and sign trade pacts, all before Congress voted. Once signed, Fast Track put such deals on a legislative luge run: no matter how many domestic non-trade policies were implicated or threatened by the deal, Fast Tracked agreements hurtled through Congress within a set number of days, with normal democratic checks and balances iced over.

Fast Track ensured that Congress' role came too late to influence trade pacts' contents: Congress only got a yes or no vote after a pact was signed and "entered into." That vote also OK'd hundreds of changes to U.S. non-trade law to conform our policies to "trade" deal terms. Federalism was also flattened by Fast Track via a form of international pre-emption: state officials had to conform local laws to expansive non-trade domestic policy restrictions in Fast Tracked "trade" pacts. State officials did not even get Congress' cursory role.

… Fast Track should be relegated to a museum of inappropriate technology. Congress, state officials and the public need a new modern procedure for developing U.S. trade policy, one that takes into account the realities of 21st-century globalization agreements."_

<comment><USER8> The first president to bend the Constitution to reduce Congress's role in making trade deals and treaties was... George Washington, of all people.

Note that the Constitution says "[The president] shall have Power, by and with the Advice and Consent of the Senate, to make Treaties, provided two thirds of the Senators present concur." At the time this was written, the intent was clearly to have the Senate be as intimately involved in the treaty negotiation process as the president. George Washington started his first treaty by basically asking the Senate what the negotiators should be aiming for. Neither the Senate nor Washington was happy with the process, and so Washington (nor any subsequent president) attempted a repeat. (See <[http://www.au.af.mil/au/awc/awcgate/congress/treaties_senate...](http://www.au.af.mil/au/awc/awcgate/congress/treaties_senate_role.pdf>)).

<comment><USER6> These days, revolving doors and web-based access to TPP drafts give corporate lawyers many advantages over the legislative branch, as members of Congress are restricted to reading TPP drafts in a locked room, without taking notes, without their trade/legal staff, without a phone.

The executive branch delegated trade negotiations to former bankers, e.g. the lead TPP negotiator is ex-Citibank, [http://www.commondreams.org/news/2015/05/28/us-trade-rep- wal...](http://www.commondreams.org/news/2015/05/28/us-trade-rep-wall-street- crony-groups-demand-transparency), _" Noting deep ties between the country's top trade negotiator and Wall Street banks, ten groups representing millions of Americans are calling on the White House to make public all communications between U.S. Trade Representative Michael Froman and the massive financial institutions that stand to benefit from proposed trade deals."_

For more on lobbyists, see [http://www.ip-watch.org/2015/06/05/confidential- ustr-emails-...](http://www.ip-watch.org/2015/06/05/confidential-ustr-emails- show-close-industry-involvement-in-tpp-negotiations/), _".. Many of the industry representatives are themselves former USTR officials ... Jim DeLisi of Fanwood Chemical said he had just seen the text on rules of origin, and remarked, 'Someone owes USTR a royalty payment. These are our rules … This is a very pleasant surprise.'"_

The end result is an expansion of ISDS, which benefits corporate lawyers, [https://youtube.com/watch?v=M4-mlGRPmkU](https://youtube.com/watch?v=M4-mlGRPmkU)

</comment></comment></comment></comment></comment><comment><USER9> TPP should be opposed already for the single fact that it's an undemocratic backdoor agreement that attempts to circumvent proper legislative process to shape law.

<comment><USER10> Barbara Weisel, chief negotiator for the US, works in the USTR, which answers to the President, who was democratically elected.

Koji Tsuruoka, chief negotiator for Japan, answers to the Minister for Foreign Affairs, who is appointed by the Prime Minister, who is designated by the Diet, which is democratically elected.

For most parties involved ( _cough_ Vietnam _cough_ Brunei) negotiators ultimately answer to democratically elected officials, and approval follows the respective constitution of the involved party. If I had not wanted a President who supports free trade agreements, I would have voted for someone other than Obama in 2012.

This may be a "backdoor agreement," but it is not an undemocratic backdoor agreement.

<comment><USER9> They are from executive branch. TPP is clearly a legislative effort (of monstrous proportions), so it should be controlled by the legislative branch, including ability to amend and discuss the agreement in advance in _transparent and public fashion_.

It is clearly undemocratic, because executive branch here usurps the power to create law.

<comment><USER11> How do you propose coordinating the amendment processes between a dozen or more legislatures?

It doesn't really make sense to let any legislature amend a treaty under the current system, where the President and his designated functionaries do the negotiating - then you have Congress modifying a _negotiated_ agreement which would make treaties wildly impractical, especially when multiplied by all the member-legislatures.

It doesn't make sense under an imaginary primary-legislature system either. The US Congress has different rules for amendments and debate than say, the Japanese Diet.

If Congress doesn't like the TPP, it is entirely in their power to refuse to ratify the treaty and send it back to the negotiating table. And it was entirely in their power to not grant the President the Trade Promotion Authority.

<comment><USER9> _> It doesn't really make sense to let any legislature amend a treaty under the current system_

Not just amend - they have to be involved in designing it (that would avoid the problem you described). And of course in the public fashion. If they aren't - it's already undemocratic corrupted farce.

<comment><USER11> How could multiple legislatures design a treaty together?

You have the same problem, it can't be done. Each legislature has different rules and completely different cultures. What would happen is each legislature would appoint individual legislators to negotiate for them and you'd have exactly the same system you have now, except with the negotiators being members of the legislative branch instead of the executive branch.

Even on the microscale, the US House and the US Senate have the same problem, for which they invented conference committees, which is where the House and the Senate appoint a couple representatives and senators to negotiate for their interests. [1] The results of the committee are sent to both houses for an up-or-down no-amendments vote.

[https://en.wikipedia.org/wiki/United_States_congressional_co...](https://en.wikipedia.org/wiki/United_States_congressional_conference_committee)

<comment><USER9> _> except with the negotiators being members of the legislative branch instead of the executive branch._

That's already better in a case when agreement involves laws. As long as those negotiations are transparent, and legislative branch can weigh in during the process - things can be fixed in timely manner. When they are completely opaque and results are shown post factum - that's where potential for corruption grows.

To put it shortly - evil things like to lurk in the dark.

<comment><USER11> > That's already better in a case when agreement involves laws.

Why on Earth would it be better to have Jeff Sessions (R-AL) representing US interests during the TPP negotiations rather than a US trade rep? Actually that seems exactly the _opposite_ of a good thing, since any individual Congressman or set of Congressman is going to favor their state(s) over the country as a whole; they are directly accountable to the people in their state who elected them. At least a US trade representative is accountable to an elected official who represents the entire country.

> When they are completely opaque and results are shown post factum - that's > where potential for corruption grows.

That's how Congress already works. Staffers and legislators produce the text of a bill and the results are shown after the deed is already done. All that enters the public record is some of the amendment history and the conference report, if there is one. And often amendments change huge portions of a bill, and you again see only the after-the-fact result. It's not a write-commit- write-commit cycle, it's a write-write-write-write-write-commit.

> To put it shortly - evil things like to lurk in the dark.

A lot of effective governance also works in the dark. The reality of life is that completely transparent, open negotiations are very difficult and close to impossible except for small, very tight-knit communities.

<comment><USER9> _> The reality of life is that completely transparent, open negotiations are very difficult and close_

And closed ones are prone to corruption. I prefer hard to finalize agreements to those which serve various crooks.

It's not like TPP is even needed to begin with. Trade is already pretty much free. TPP is designed to make it less free in practice.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> I am surprised by this line, _Alternatively, the treaty can also take effect if it's ratified by half the countries representing 85 per cent of the zone's economy._ Is this something that the negotiators really had the power to agree and bind their countries to???

The US constitution is very clear that the negotiators lack that power. However the question can't come up because the USA is about 16% of the world economy, so you can't get to the 85% of the economy figure without the USA.

But Canadian law is not entirely dissimilar. Specifically Canada may have signed it, but according to [http://www.parl.gc.ca/content/lop/researchpublications/2008-...](http://www.parl.gc.ca/content/lop/researchpublications/2008-45-e.htm#a5), Canada is not bound by the agreement until it is ratified. And even then it does not have any force in Canadian domestic law until Parliament has passed specific bills to implement it. So Canada shouldn't be bound by this, and the negotiators were in the wrong to promise what they had no authority to promise.

I'm sure that the US and Canada are not the only two countries where the negotiators did not rightly have power to bind their countries to that term. So why is this term considered binding rather than being pointed to as a clear example of overreach??

<comment><USER13> > I am surprised by this line, Alternatively, the treaty can also take effect > if it's ratified by half the countries representing 85 per cent of the > zone's economy. Is this something that the negotiators really had the power > to agree and bind their countries to???

Of course the negotiators don't, only the ratifying authorities have the power to bind, but that's true of all of the rest of the treaty (and _every_ treaty) as well: note that, in that case, in comes into effect _between those who ratified it_. So, only for those for whom those with the power to bind the country did so (including agreeing to that condition for it going into effect.)

NOTE: This type of minimum threshold clause is common in agreements (many multilateral treaties have something like it.) The idea being that the prospective parties don't think that the restrictions are worthwhile unless there is a sufficiently-large group joining the arrangement.

<comment><USER12> That sounds very reasonable.

OK, TPP doesn't. But that term does.

</comment></comment></comment><comment><USER14> A very smart friend of mine on Facebook with lots of ties in the tech industry described Balsillie as "Canada's Donald Trump."

He says "I'm not a partisan actor, but I actually think this is the worst thing that the Harper government has done for Canada." The worst?

He says "It's a treaty that structures everything forever – and we can't get out of it." Forever?

Later in the article we find out,

"The deal must be ratified by all 12 countries, and then it would come into force six months later. It would require a parliamentary vote in Canada. Alternatively, the treaty can also take effect if it's ratified by half the countries representing 85 per cent of the zone's economy. A country can withdraw any time, on six months' notice."

So not only can we get out, but it's not forever if you can get out. So Balsillie is full of $hit, alarmist, and possibly still butthurt over losing out to a patent troll that RIM never took seriously enough.

</comment><comment><USER15> > "It's a treaty that structures everything forever – and we can't get out of > it."

> he noted treaties like this one set rules that must be followed forever

But a few lines further down:

> A country can withdraw any time, on six months' notice.

I'm confused; which is it?

</comment><comment><USER16> I'd love to see the TPP text annotated on Genius (or a similar site). Is that a thing?

<comment><USER17> There's a copy of the TPP on Documentcloud.

[https://www.documentcloud.org/documents/2507281-tpp- complete...](https://www.documentcloud.org/documents/2507281-tpp- complete.html)

</comment></comment><comment><USER18> No shit. This goes for everyone else apart from the US too. That's why it was kept a secret.

If we can prove that these politicians signed these agreements after receiving backhanders, can we declare it null and void?

<comment><USER19> For some interesting insight into why trade agreements are negotiated in secret, listen to this planet money episode: [http://www.npr.org/sections/money/2015/06/26/417851577/episo...](http://www.npr.org/sections/money/2015/06/26/417851577/episode-635-trade- deal-confidential).

Part of the problem of any trade deal is that you'll end up pissing off one group at home to make another one more happy. Trade negotiators argue they need to have the deals be negotiated in secret or special interest groups will cause too much noise and trade deals will never get done.

<comment><USER18> Maybe we should democratically vote for representatives that keep their policies secret until we've voted for them.

<comment><USER20> Yes, sometimes secret negotiations are needed to get things done. Look at the recent budget deal in the US Congress. [1] The media and the public had no idea what was going on behind the scenes when Boehner announced his resignation. If Obama or key Republicans had talked about the negotiations, no deal could have been made.

[1] [http://www.vox.com/2015/10/26/9619214/budget-deal- congress](http://www.vox.com/2015/10/26/9619214/budget-deal-congress)

</comment></comment></comment></comment><comment><USER21> I and a lot of others have been talking about the dispute resolution processes and how they shift power to corporations over and above all sectors of government. In the domain name space they are called Rapid Dispute Resolution Processes (DRRPs) and around, in particular, intellectual property, they are fraught with danger. They allow corporations to overrule national laws around environment, climate, working conditions, you name it.

I hope we can slow this train down enough so that people can understand what is on the table here. At almost 6 thousand pages there are also a lot of devils in the details.

</comment><comment><USER22> Rather light on details.

</comment><comment><USER23> "A country can withdraw any time, on six months' notice."

Why not give notice now? Who exactly has this power? This is incredibly vague.

</comment><comment><USER24> 6,000 page document? It feels anything that long is purposely hiding as much as possible.

<comment><USER25> Kind of the same thing with Obamacare.. Nearly all the politicians who voted for it didn't even read it.. By their own admission. John Conyers of MI comes immediately to mind.

<comment><USER26> Politicans generally won't read most of the laws they sign and why would they? There are many laws on incredible wide range of different topics and you only have so many representatives. You can't possibly expect every lawmaker to be an expert on every of these topics. That's why they have experts and colleagues that they can talk to and why lobbying exists and is not an entirely bad thing.

</comment></comment></comment><comment><USER27> Canada's already lost at innovation. Almost everyone I know who graduated with a STEM degree moved to the US immediately upon graduation.

My favorite example: Apoorva Mehta invented Instacart in Waterloo, Canada because it was too cold to go grocery shopping and too expensive to own a car. Then he immediately went to San Francisco (a city with warm weather and cheap cars?!) to start his unicorn.

Waterloo students still go shopping in the snow. #fail.

<comment><USER28> I don't know how you can dismiss an entire country because of one person's move. Toronto and Montreal both have big tech scenes and plenty of investors (albeit a bit on the bearish side). As much as we lose talent to the states, we also pull a lot up as well.

<comment><USER29> Waterloo itself has a pretty big tech scene. There's a number of incubators and a few big companies have opened local offices (e.g., Google and Shopify).

<comment><USER30> Ottawa has a large tech scene too.

<comment><USER31> As does Vancouver.

</comment></comment></comment></comment></comment><comment><USER32> I suspect Mr. Balsillie still owns a chunk of BBRY stock, which in turn claims ownership of a massive (multi-billion dollar)[1] patent portfolio. Some might argue that these patents represent the majority of the residual value of his former company, hence the alarmist rhetoric. The absence of any concrete info on how this will harm innovation is laughable.

[1]: Patent buy in 2011: "Apple, RIM and their bidding partners control over more than 6,000 patents and applications that cover wireless and Internet technologies" which cost $4.5 Billion. www.bloomberg.com/news/articles/2011-07-01/nortel-sells-patent-portfolio- for-4-5-billion-to-group

<comment><USER33> You took the time to look for something about Blackberry patents, you could have also taken a moment to confirm that he has long since sold off his Blackberry shares.

[http://business.financialpost.com/fp-tech-desk/rim-co- founde...](http://business.financialpost.com/fp-tech-desk/rim-co-founder-jim- balsillie-has-sold-all-his-shares-in-blackberry)</comment></comment>


Developer Preview: Interstellar Module System - <AUTHOR> https://www.stellar.org/blog/developer-preview-interstellar-module-system/

<comment><USER2> I love what the Stellar.org people are doing.

It would be interesting to consider a hardware device that would act as a wallet, with a SIM card that would enable it to communicate transactions through SMS/text messages.

In my view, the biggest issue with Stellar.org, or any other crypto currency trying to solve the "unbanked" problem, is the last mile.

<comment><USER3> Funny you pick that example! We just had an internal hack day on Friday and Bartek (who also worked on Interstellar) was working on a SMS client as his project. I'll ask him to swing by and post some thoughts on it here but he is in Europe so asleep now. (I work for Stellar.org).

And thanks for the kind words - in our view, to handle the last mile problem, we need to build things to be accessible and as modular as possible which will hopefully make things much easier for developers everywhere. By bringing down the barriers of use of the code base, we will hopefully see more developers building things for their local communities and starting to fill in the gaps in the last mile. Goal: let a thousand flowers bloom!

</comment></comment><comment><USER4> I wonder how space start-ups will be called in future now that words like "stellar" and "terraforming" are taken. Refactoring.org for asteroid mining? Recursive.net for solar system cargo transport?</comment>