Why Google prepend while(1); to their JSON responses | Hacker News Reader

Why Google prepend while(1); to their JSON responses

stackoverflow.com

76 pointstymscar14 comments

because the web is broken in every way imaginable for no reason and should have been discontinued about 14 years ago. but this is really old, now my favorite is dns rebinding [1]. this has to be one of the most beautiful examples of how core web devs do not understand ANYTHING. every single thing they have ever done is a misconception. not a single web dev related disclosure for the last 20 years has given me insight on how to design secure systems; it's always just a thing that would not exist in any alternate design.

1. https://github.com/mpgn/ByP-SOP

When you wrote this comment, did you expect to get downvoted and just not care?

Like, you have good information, but you crammed it in between so much hyperbole, exaggeration.

Very interesting, thanks for sharing!

Aren't DNS rebinding attacks blocked by using https?

Sending credentials and cookies to third party sites is the original sin. It should have never happened. We keep it because it is useful for advertizers [1]. Same-origin is just a huge and complicated band-aid to close the gap. Without same-origin and credential passing, you could have really cool mashup apps - one page could scrape another (uncooperating) one and display the results in a new way. Heck, you could write a browser in a browser if you wanted.

[1] How would you implement third-party login and similar useful things without it? Your page's script could pass the neccessary cookies explicitly to the third party script, or you could go around the backend and have server A tell server B who a session belongs to.

Interesting that the issue was solved in 2011 but presumably, the risk that someone is still using a 12+ year old browser is greater than the benefit of removing this trick. I wonder if they would ever deem it safe to remove.

Removing it also implies work. I wouldn't expect it to get removed until the whole software subsystem gets a rewrite at some point.

So the protection was trapping the sinister script context running in my browser in an infinite loop. Clever!

…Does that grind my browser to a halt?

Why not just throw an error or something?

If you’re visiting a webpage with such a script, it may be for your own good to freeze it.

It'll grind the context it's running in to a halt. The point is that nobody wants their site to be broken, so they won't request that with a <script> tag.

Oh I see. That makes sense.

> The point is that nobody wants their site to be broken

Nobody wants it but unless it's completely broken most don't care enough to do something about it. Which is why this JSON trick is done in the first place.

Given this is about Google: YouTube has the same bug in its comment text fields for at least 5 years, in rare cases submitting a comment only results in the error "n is undefined", it can't handle the browser's back button, sometimes links don't work until I scroll the site a bit, the new "preview video on hover" feature doesn't reliably react to mouse events and its animation swallows mouse clicks, and that's just the few things I remember off the top of my head.

I imagine for fear that Evil Script would trap the error. An infinite loop precludes any transfer of control. Theoretically.

Yes, I think you could catch the error with window.onerror or script.onerror and in this handler, get the content with script.textContent or script.innerHTML.

(where script is the javascript variable that corresponds to the javascript script tag, possibly initialized with script = document.createElement('script'))

Reply on news.ycombinator.com