HN user
25db6c1376d93247b27c430492fd49@gmail.com
It is a security measure, as it involves authentication through the series of knocks. It's a weak security measure on its own, so you obviously wouldn't want to rely on port knocking by itself, but it does have utility in preventing an attacker from discovering the service through a simple port scan.
I don't quite understand why you're saying it adds nothing at all.
Looks rather nice, reminiscent of drawing using Teletext (e.g. http://teletextart.co.uk/, http://www.bbcbasic.co.uk/bbcwin/manual/bbcwinh.html).
If the port knocking was obscuring an unauthenticated root shell then you would have a good point, but this is a defence in depth measure that adds to the security. It helps because it's one more hurdle for an attacker to bypass.
Hopefully a lot better than the Linux kernel: http://www.cvedetails.com/product/47/Linux-Linux-Kernel.html...
You can uninstall it with an administrative Powershell using this command:
Get-AppxPackage Microsoft.WindowsStore | Remove-AppxPackage
Unfortunately the QR code might be an improvement over Windows 8 and 8.1 if the QR code contains more detailed information.
The QR code shown in the example screenshot is just a link to http://windows.com/stopcode - hopefully they'll improve it to at least include the bug check code.
(QR code decoder output: https://zxing.org/w/decode?u=http%3A%2F%2Fcdn.arstechnica.ne...)
The USA has a lot of catching up to do with the rest of the world then.
Six weeks paid leave is paltry compared to the vast majority of countries.
Most of the commentary here so far is really quite tangential to the actual research done. Everyone commenting on this article should make sure they've read the study first, with particular attention to the 'Limitations' section on page 11: http://m.jmq.sagepub.com/content/early/2016/02/25/1077699016...
One other feature of the study that limits its wider applicability is that it is entirely US-centric. It would be interesting to read follow-up work on samples taken from other cultures and countries.
It does appear to be some encoding issue relating to the Unicode "→" (U+2192). Encoded with UTF-8, this is represented by the three bytes 0xE2 0x86 0x92. In the TeX EC encoding, these correspond to "âĘŠ".
(See https://www.tug.org/TUGboat/Articles/tb11-4/tb30ferguson.pdf, also section 2.3 of http://mirrors.ctan.org/macros/latex/doc/encguide.pdf)
After the initial period of adaptation, I found it actually increased productivity. Perhaps it was just preventing already-established bad habits that arise from having the internet constantly available.
On the topic of work environment: in one job I worked at, we had the Internet machines completely separated from the work machines. If you needed to check something you had to physically walk over to the Internet desk. Great for focussing on the task at hand without distraction, and considering carefully what information you need.
Unsurprising that they've ceased to accept Bitcoin. The only significant use cases thus far have been ransomware and buying recreational drugs. And early adopters cashing out of the pyramid scheme.
Only in the amount of effort one is willing to expend in doing so, and learning any necessary skills. It's only a happy accident that so many (relatively inexpensive) routers are easily flashable with custom firmware, not an entitlement.
If you're buying a device to replace the stock firmware with something customised to your liking, then you're already in the hacker mindset, so having to tinker that little bit harder surely shouldn't be much of a burden.
Is this really that much of a problem? Circumventing the block sounds like it could be a rather interesting technical challenge.
In what ways is the BSD networking stack superior?
There's no known API to read the UID out (there is one to use it, or the GID, or any other AES key: http://iphonedevwiki.net/index.php/IOCryptoAcceleratorFamily...), no published side-channel attacks, and the destructive/invasive techniques that would involve decapping the chip and using an electron microscope are not solid enough to use for this, such that there would a huge risk of destroying evidence.
You can't parallelise it like that, because the passcode check relies on an unreadable AES key (the UID) that is unique to that particular iPhone.
Interesting technique, but it doesn't remove the long interval between permitted passcode attempts - an equally important problem for brute-forcing.
So the FBI would most likely still require Apple's assistance in this.
That's quite a delight for the ears. Reminds me of Stéphane Picq's work on the Dune computer game soundtrack, back in the early 90s. It had some similar sounds.
The way it is currently implemented, by which Apple can - if in physical possession of the device - unilaterally force new firmware onto it without the consent of the user, yes.
Nonetheless, if Apple had designed the update mechanism to require both a signed firmware image, and authentication by the user, then the FBI's request would not be possible. Such a design would also help to mitigate the end-user effects of an insider attack at Apple, where a rogue employee signs malicious firmware, or leaks the signing key to some adversary.
Being able to load arbitrary firmware onto the device without requiring user authentication, so long as it's signed by Apple.
The backdoor is already present, through Apple's design. The FBI are just requesting to use it.
Good point, thanks for the correction.
I'd be very surprised to meet a computer scientist who doesn't know what a stack is. It really is a fundamental part of computer science.
Jailbreaks address a different type of vulnerability - that of incorrectly written code or poorly designed systems, that can lead to a privilege escalation.
The vulnerability that the FBI are using is the ability of Apple to update the iPhone with arbitrary code, provided it has been signed with their secret key. It's an important feature, of course, but still a security vulnerability - albeit an irrelevant one for the vast majority of iPhone users.
I agree - this is the type of vulnerability that, assuming Apple is extremely careful about protecting their signing key, is only exploitable by court order or similar state request. This crypto implementation on iPhones and the like isn't really designed to protect against that, it's really more to prevent the common criminal from accessing your personal data. Apple already comply with law enforcement requests to access iCloud backups and other such data, so assisting with this passcode crack isn't really much of a stretch.
The purpose of the non-disclosure sections of this law is to prevent the suspect being wiretapped (or similar) knowing that they're being wiretapped.
It's not exactly very useful if someone under active investigation finds out that they're being watched, and changes their communications behaviour as a result.
In this case, it wouldn't need to be applied as the suspect is dead.