Hacker Newsnew | past | comments | ask | show | jobs | submit | more daemonize's commentslogin

I think showing the actual disassembly would help people understand. it might lose some so maybe as a side bar.


Showing some C-like pseudo-code would probably do the trick nicely.


p->m() ~= m(p) - e.g. the object is pushed as the first argument to the method.

The actual "m" is found by looking at the "p" class if it's non-virtual, and at the "v-table" in p if it's "virtual".

If "m" is static, no class lookup, or object v-table lookup is done, and the call is p->m() ~= m()


I was disappointed that there was no mention of side channel attacks and countermeasures.

http://web.mit.edu/press/2012/thwarting-eavesdropping-data.h...

Edit: added link


interesting how something so trivial as sockets (but in the context of a http browser) can stir so much talk of decentralization. maybe if people pull their heads out of their asses about web and embrace native apps again...


Agreed. A P2P program with a browser? Come on! We /already have/ wonderful P2P programs. I sense browsers becoming awfully bloated. And for who's benefit? Google's.


I would imaginr that the flat panel could be hooked to a servo and a control loop be used to optimize poiting attitude in real time to compensate for the sun's natural cycle.


This is already extremely common, with significant efficiency gains. As ever, the downside is added complexity and cost.

See https://secure.wikimedia.org/wikipedia/en/wiki/Solar_tracker



Japan has no defense investment. 'nuff said.


Japan spends 3% of its annual budget on defense.


Yet they still have a debt-to-GDP ratio of 225%


What about China bailing. How bad does it need to get before they decide to pull out?


Old joke: If you owe the bank a thousand dollars and you can't pay it back, then you have a problem. If you owe the bank a billion dollars and you can't pay it back, then the bank has a problem.


I think the original joke was a million dollars not a billion dollars, but I guess with inflation...


It'd have to get very bad for China to pull out. If China pulls out and damages our economy, our imports will dry up, their exports will dry up and their economy will dry up. I understand that China and the US might not be the best of friends right now, but their interests are generally aligned on US debt.


They would do that without hesitation. The problem (at the moment) is they have nowhere else to put that much money.


Its really not. If what you say was true they wouldn't still be actively buying U.S. Debt.

Their hesitation is they wouldn't get all their money back. If China pulled even 25% of its investments out of the U.S. the dollar would free fall. They wouldn't be able to cash out before most of the dollars value was inflated away.

China continues to buy our debt because they don't want the value of their current investment to collapse


that's not the only reason, they also need to keep buying it for as long as we're a sizable portion of their export market. We still are, for now..


China could either put it back in their coffers or invest in Brazil. Consider that they have Sino-Brazilian trade and technology agreement.


That and Congress keeps banning all collaboration with them in space and energy technologies.


This says a lot about the ISP's ethics if they are shown to be consenting to this. One thing I didn't see in the EFF article is something a user could do about it: use SSL! This may eventually force these companies into more nefarulious and active techniques of hijacking, but it should alleviate the basic technique they are employing now, if i am not mistaken.


From the EFF article:

"And the best protection against the privacy and security risks created by this type of hijacking is to visit sites using HTTPS rather than HTTP, which can easily be achieved using EFF's HTTPS Everywhere Firefox extension"


You're right, sry. Was on my mobile and must have glossed over that. Next time I will RTFA fully.


My understanding is HTTPS only encrypts the content of the page, not the actual URL request.

(And it's worth noting that proxies can unwrap HTTPS).


Your understanding is incorrect. This is the reason SSL is incompatible with virtual hosts (see http://en.wikipedia.org/wiki/Server_Name_Indication)


It's not! Just use the latest Apache. It works great. I have 30 domains on a single IP, all under SSL.


Then it's using SNI, which I linked to. The request is still encrypted, but the host name is passed unencrypted using SNI.


Which is great unless you have to deal with IE6 users :(.


Does MS even support IE6 anymore? Or are people using it without the benefit of security patches? Where I work, IE7 is considered obsolete.


IE6 has extended support until 2014 or market share is under 1%

http://en.wikipedia.org/wiki/Internet_Explorer_6


> proxies can unwrap HTTPS

They cannot get at the plaintext without a certificate warning (or installing a certificate in the user's browser beforehand).


They cannot get at the plaintext without a certificate warning (or installing a certificate in the user's browser beforehand).

Which will get clicked through anyway, so, uh, the security is kinda moot. =)


I don't know why you were downvoted for this, it's a very cogent point— most users would probably click through a big red screen that says "DO NOT VISIT THIS WEB SITE!" We need to be thinking of them when we design our security model.


This is something I keep circling around. The host doesn't seem like a thing you could encrypt, because the intermediaries need to know where to send your packets. It seems like https encrypts the headers: http://stackoverflow.com/questions/187655/are-https-headers-... but does this include the Location header?


The HTTP request itself is encrypted, but the IP packet (including the source and destination IP addresses) is not. SSL/TLS is application level encryption, and if you wanted to encrypt the actual packet, you need to switch to something like IPsec, but even then you need some sort of routing method (which I can't remember).


IPSec can work in many different ways. One of those is to encapsulate the entire packet as the encrypted payload of a new packet, with the new packet having headers in plain text leading to the other end of the IPSec tunnel. That other end will then decrypt and forward as appropriate (this is called a 'tunnel').


Yes. SSL / TLS happens below HTTP at the socket layer. This is why you couldn't have vhosts's using SSL on a single IP for a very long time (the webserver wouldn't know which certificate to use).


uhm. this "revelation" was already written about the first time jailbreakme did this, at least a year or two ago... Why is this news?


It was proven on the last jailbreak-via-web - it was amazing to see it work the first time and you really understood the severity of a simple bug. I think it's news now for many people (perhaps not a large bunch of HNers) because the first time was "huh - pretty crazy! But I'm sure it won't happen again" and now it's "holy shit, there IS no security!"



Does the TCP over TCP problem occur with socat tunnels?


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: