mjhall

I don't think the transfer occurs explicitly via LAN as other commenters point out, seems more likely Apple acts as a tunnel between the device requesting the keychain and the device authorising (sending) it.

A bot doesn't necessarily only scan port 22 in a range - nothing stops the bot herder making it scan 1-1024 instead.

The current vulnerability affects environments where untrusted code already executes. Since applets can be used to upload arbitrary code, it makes sense to block it.

This isn't a political move I don't think, just a common sense mitigatory move to protect people. Web apps running Java are safe from this vulnerability, unless they're accepting user-supplied code and running it.

The only means I know of for one to reliably detect the image on the screen would be TEMPEST style attacks [1]. I doubt that Capita can afford to buy the necessary equipment, or even views it as economically viable given the volume of letters they sent out - 56 million letters were sent in 2009, for example [2].

I'm not sure if modern TVs will even emit anything obvious since the connection from the decoder to the panel is covered in EMI shielding.

[1] : http://en.wikipedia.org/wiki/Tempest_(codename) [2] : http://www.tvlicensing.co.uk/about/foi-administering-the-tv-...

It still seems to contain an unpatched code execution vulnerability from 2010, fixed in CS5 and up [1], I'd say that's "bad enough" to warrant not using it.

[1] : http://www.adobe.com/support/security/bulletins/apsb10-30.ht...

At a guess: eventually, yes. I don't think this actually writes over the heap at all - it writes to the .bss section instead. In theory, if left to execute (without the INT3s) it'd probably segfault as soon as it hit the end of the page containing .bss.

malloc could be used to expand the heap, which conveniently appears after .bss. The pointer returned would probably still need to be followed, since heap allocations might not be contiguous (and mprotect needs to be used to mark the pages executable).

Re: the second question, the problem with NX is that it only protects you from overflows where the attacker jumps into the buffer.

Overflows are still exploitable with NX. The attacker instead jumps to a series of fragments of library code[1]. Since libraries will always be executable, there's no problem (aside from the difficulty of finding the right chain of "gadgets").

ASLR goes some way into preventing return oriented programming (ROP) attacks, but it isn't bulletproof.

[1] : http://en.wikipedia.org/wiki/Return-oriented_programming

To add to grecy's comment:

Your login Keychain is usually unlocked - it's encrypted with a key derived from your password that's held in memory from when you log in.

You can lock your login Keychain (or any other) from Keychain Acccess (/Applications/Utilities) or from the security menu bar item (if you have it added) and you'll be asked for the password rather than asked to "allow" it.

These two 28C3 talks[0,1] discuss the precursor to such an apocalypse.

[0]: http://events.ccc.de/congress/2011/Fahrplan/events/4871.en.h...

[1]: http://events.ccc.de/congress/2011/Fahrplan/events/4780.en.h...

I don't think the article's intention is to convince people it's a con or crush the enthusiasm. Their points aren't illegitimate and their arguments are fair - isn't it prudent to criticise them and see how they respond rather than let them continue unchallenged, especially considering the collective financial contribution involved?

Considering that they already have prototypes together, they've already apparently got something to show. As the article points out there are flaws with what they're offering and questions that need answering.

I'm sure most of the questions and queries can be answered satisfactorily, but the crux is the lack of confirmed titles, which they can't fix themselves.

The argument isn't totally correct. The Police can't just make allegations and force you to surrender keys - they have to convince a judge that the allegations are true, and that getting the keys to your random noise will produce evidence.

RIPA is objectively flawed legislation, but it definitely doesn't "outlaw encryption" by anything less than a very long stretch of the imagination (as appears in this article).

It's using sha256, which is far too fast. Key stretching is essential, especially when something as fast as a digest function like the SHA family is used. PBKDF2, as the article points out, can be used to increase the cost of brute forcing, but bcrypt should be considered before opting for PBKDF + SHA.

An article [1] that appeared on HN last month (comments:[2]) also explains why just using hashing with a quick digest function is a bad idea, although this original article does a decent job of it (despite the author ignoring his/her own advice).

This article also uses built in equality tests for comparing the supplied hash to the stored hash. This is bad practice, as it is vulnerable to timing attacks. [1] covers this in the Extra section.

[1] : http://throwingfire.com/storing-passwords-securely/?utm_sour...

[2] : http://news.ycombinator.com/item?id=4075873

I don't think the majority of the feature exclusivity is hardware, it's about differentiating the devices. iOS hardware seems to have hit a convergence point. Although the specs are different, the perceived difference due to the hardware is slight (if there even is one). That means Apple needs to do something else to encourage people to buy a more expensive device, software is now the discriminator instead of hardware.

The iPad 1 corroborates this. It's got the CPU power of the iPhone 4 and the RAM of the 3GS, both of these devices get iOS 6, the iPad 1 does not. There's no apparent technical limitation, they're doing it to differentiate product lines.

I hope it will raise awareness, but my cynical expectation is that the "Accept" button will become one people press habitually to get rid of an annoying banner. Sites abusing the Facebook Like button as a gateway to content are a proof of concept that this might happen.

Considering web browsers already have cookie controls built in it seems a bit silly incur such an enormous cost in implementing a completely redundant feature.

I think the effort would be better spent on publishing transparent descriptions of what data collected and what it is used for than for designers to each create their own non-standard dialog boxes. The cookie issue could be "fixed" (to the extent possible with pointless legislation) with a link to an EU-published HOWTO on configuring a web browser.

It'll be interesting to see if it achieves that goal. In my experience of watching my parents interact with a computer too many buttons translates to "complicated and scary". I think a more reserved approach might have been a bit better than the nuclear option of bombarding the UI with as many buttons as there are options in the current menu.

Take a look at his comment history (turn showdead on first)[1]. He's a somewhat eccentric character.

   [1]:http://news.ycombinator.com/threads?id=losethos

They were, but my most recent experience has been that Windows will offer to make one for you on the first boot of a new machine.

I think the major downside is the world is immutable. For the search algorithm to run in short enough times to render in real time the point cloud needs to be organised very carefully.

Part of the point cloud needs to move for animation, which involves re-indexing at least part of the world. Doing this once per frame is probably far too expensive (at least currently), which is why animation doesn't feature in their videos.

That doesn't mean this technology should be dismissed; most world data in 3D scene graphs is static, so it does have applications. I don't see it overtaking rasterised graphics entirely, but I think there is value in it.

I'm not an expert either, so take my comment with a healthy bucket of salt.

The most significant part (I think, probably wrong) is on page 5[0] where he details the invalid instructions that do more than a NOP and why they're useful.

[0] : http://www.laughtonelectronics.com/arcana/BrideOfSonPg5.html

The writing style does seem different, sentences in this release aren't terminated in some cases, whereas those from officially corroborated releases always are.