Kind of. NTFS provided a way of storing data in different streams, but did not include data stored in alternate streams in file size accounting and did not provide an interface for enumerating them. We used this to great effect when I was in school, storing a copy of Quake in an alternate stream of a 100-byte text file. There was no mechanism for the system administrators to find it and they just saw that disk space was lower than expected.
No, the GP was (almost) correct. 3840x2160 is four times the number of pixels per frame of 1920x1080 and 60fps is double the frame rate of a standard 30fps 1080p stream. Four times as many pixels and double the frame rate gives 8 times as much raw data. That said, it also includes a lot more redundant data (changes between frames will be smaller if they're closer together, lots of areas in the larger image can be interpolated from the smaller one) and so the encoded size should be a lot less than 8 times the size of the same stream at 1080p, 30fps.
I quite like Thunderbird, but my big issue with it is that it renders HTML email using the Gecko engine in the same process that contains all of my mail server login credentials and full access to my email history. I don't know if Windows Mail does this, but Apple Mail uses the same sandboxing as Safari, so if there's a WebKit bug it will crash the renderer process but without a separate privilege escalation vulnerability it can't compromise my mail client. Handling untrusted data using a massively complex renderer in process just seems like a recipe for disaster.
WinCE was terrible, but it's worth remembering what the competition looked like. Prior to EKA2, Symbian didn't do protected memory. EKA2 was a nice kernel design, but it was crippled by userspace APIs designed when 2MB of RAM was a high-end phone so made developers think aggressively about memory management and cleanup. WinCE only looks bad in comparison to more modern systems that run a full desktop OS on a mobile device (which is a couple of orders of magnitude more powerful than the original desktops that said OS ran on). In comparison to the other options at the time, it was just mediocre.
I have and Android phone and an iPad, but my partner had a Windows Phone and it was the only mobile UI I've used that hasn't annoyed me. I don't 'miss' it, in the same way that I don't 'miss' BeOS, because I never used either enough to get accustomed to their features and be annoyed by their lack elsewhere. I didn't get one, because she was always frustrated by the lack of third-party support: the built-in functionality was mostly good (though, like Android, the lack of out-of-the-box CalDAV / CardDAV support was annoying) but if you ever wanted to do something that it couldn't do out of the box then it probably couldn't do it at all. If I could buy a Windows phone that could set up virtual Android environments with each completely isolated from the others then I'd buy one today.
The first four were easy; this one is going to hurt. Cook, it's time to start open sourcing some of Apple's code
This one is easy because they've already done it. Go to http://opensource.apple.com/ and take a look. A lot of the recent vulnerabilities were found in code that has been open sourced but none of the ones that I'm aware of were found by source analysis. Apple incorporates static analysis into their workflow on a pretty aggressive basis so bugs that are easy to find by static analysis of the source code don't usually make it into their code. A lot of their recent vulnerabilities have been found by Google Project Zero and were found by fuzzing and then binary analysis. Having access to the source code might make it easier for third parties to fix it, but wouldn't make it noticeably easier for anyone to find holes.
I often write code on a whiteboard, but when I do it's rarely valid code in any given language, it's pseudocode that omits any details that aren't relevant to the particular explanation that I'm giving at the time. That's a useful skill, but it's not usually the one that's tested in exams, where you're penalised for syntactic errors.
His idea is that you start with the new password, unhashed. Then you permute it in various ways and hash it. If any of these permutations gives the old hash, then you reject it. If not, then you hash it, store it, and scrub memory very carefully to erase all copies of the permuted unhashed password.
In case you missed the last dozen or so stories about Windows on ARM, it includes an x86 emulator (currently 32-bit only) and can run x86 Windows apps.
Depends on how much I'm buying, but generally if it's more than a few items then no - I'll do a rough estimate, but I can't be bothered to count all the pennies.
Amusingly, one of the arguments given for voting leave (and the reason that a lot of Indian and Pakistani immigrants voted) was the preferential treatment of Europeans over Asians by the UK immigration system. It's amusing how even the racism in the leave campaign wasn't self consistent, let alone their economic arguments.
It's one of two things. Either the transaction itself correlated with fraudulent transactions, or the transaction didn't correlate with your own spending habits. Banks build fairly complex statistical models of spending and flag any outliers as potential fraud. The most amusing one of these for me was the registration fee for a DARPA PI meeting. Apparently my bank believes that paying money to the US government correlates strongly with fraud. Somewhat less helpfully, they insisted on calling me during UK business hours (i.e. in the middle of the night where I was) to confirm. After a very grumpy 4am conversation (the third time they'd woken me up that night, but the first time I'd managed to get to my phone before it stopped ringing) they gave me a 24-hour number that I could call from anywhere in the world.
All UK banks that I'm familiar with mail you out the initial PIN (on a weird sticker thing that's meant to make it impossible to read by shining a bright light through the envelope) and then suggest that you change it at an ATM.
You'd have to want battery life and the ability to run Windows apps, though the fact that MS Office runs on Android and iOS makes that a bit more of a stretch.
For some value of exploited. Spectre lets the JavaScript snoop on the contents of RAM within the same process. Given that most web browsers perform tab-granularity sandboxing, that basically means that the JavaScript can snoop on all of the data that's associated with the tab that provided the JavaScript. It may mean that malicious JavaScript in an ad can snoop credentials from the enclosing page if it's in an iframe, but that's about it. The bigger danger is that this can be combined with other vulnerabilities to provide the disclosure step in a code reuse attack.
For most server workloads, unless you're allowing arbitrary untrusted code to run then it shouldn't matter.
Before you even hear any stories about how awful they are, the first thing you encounter with any of them, is that they don't interoperate with anything else. That is, if you want to talk to someone who uses that app, you have to use the same app
This is a failing of education. Most people don't understand that a service, a protocol, and a client are all separable components. They typically don't even differentiate between the service and the client: Skype is the Skype app, ICQ was the ICQ app, and so on. This has been made worse by webmail, where people don't realise that they can use Hotmail, GMail, or whatever with any IMAP and SMTP client - even on mobile devices, you'll often see people using the Microsoft app for their Hotmail account and the Google app for their GMail account, not realising that they could be using the same app for both.
My bank and credit card companies let me download my full transaction log, including amounts, times, and locations, so that I can see exactly where I have spent money. They let me download in the same format as my bank, so I can also see recurring payments in the same format. That makes budgeting a lot easier.
I thought the chip was securely communicating with the bank. Like, it was drawing power from the terminal and encrypting data on the card itself. (And signing the cost.) Therefore, unlike a magstripe, no reason to be wary about inserting it in the card into a terminal. And I like it because I have to insert it into the terminal to make it communicate, not just have it unprotected in near someone who wants to scan it.
Two issues. The first is that there are some flaws in the EMV protocol. The most glaring is that, whereas the card authenticates itself to the bank, the bank does not authenticate itself to the card. That makes it possible for the terminal to launch MITM attacks. The card reader is not intended to be a trusted part of the system, but that means that you're entering the PIN into an untrusted device. That means that a thief can use a modified card reader to record your PIN, then steal the card. There are also some vulnerabilities in specific EMV implementations, for example some terminals use a simple incrementing counter for the 'unpredictable number.' This means that if you run one transaction you can predict the secret used in the next one and perform a replay attack.
I'm not sure if Google protects my fingerprint from themselves, but neither answer would surprise me (okay, the protection does.)
Google's problem is that they don't control the hardware. A few Android devices have something roughly similar to Apple's Secure Element (typically using TrustZone rather than a separate core), but most don't, and because the code that runs on it is provided by the vendor it doesn't integrate well with the OS.
I hate self-checkout. I'm doing a job that someone else could be doing, badly because they (rightly) don't trust their customers as much as their cashiers so make it more malice proof.
That depends on the shop. For example, Waitrose in the UK doesn't perform any of the weight checking that many of them use. This means that it's very quick. You might have more competent cashiers than I'm used to, but here they often don't pack things in a sensible order and they're not good at packing things into backpacks or pannier bags.
No more insecure than cash. If someone steals my wallet, they can use the card for small purchases or the cash. The difference is that the with the cash it's gone, with contactless it's the bank's liability and they will refund any transactions. It's also limited to a relatively small number of transactions per day and to £30 per transaction. The bank system may also decline contactless and require a PIN if they detect unusual purchase patterns.
To be clear, I know the reason "to stimulate economy", just I am not familiar with any historical evidence to support it.
Take a look at what happened when economies abandoned gold or silver standards. In several cases it was because their economies started to grow faster than their money supply, which led to recessions.
Isn't it that there were economically stable times when currency had an intrinsic value, and quite to contrary - most big financial collapses happened under "modern" economy rules
The Great Depression happened when most countries were on the gold standard.
lastly isn't it the right of a human being to be rewarded for their work with something of intrinsic value and keep it under their bed if they chose so?
That's an interesting philosophical question. Part of the problem is defining what such a thing should be. Let's say that we use gold. Now if I do some work but there's no gold available, what happens?
The cheap display will most likely support HDMI and DisplayPort. You can drive it via the in-built GPU on your graphics card. With the latest macOS, you can also use eGPU, which means an external GPU connected via PCIe over Thunderbolt, so you get a more powerful GPU in an enclosure that's easier to cool. Or you can get a DisplayLink piece of crap, which uses USB and a weird hodgepodge of software or render-to-texture in the GPU then pulls the data out, compresses it and sends it over a proprietary protocol encapsulated in USB.
The only valid reason for buying DisplayLink stuff is that you want more monitors than your computer can drive and it isn't possible to add a GPU. Given that all MacBooks Pro released in the last 4-5 years support at least two external monitors (I think), there's little reason to buy one to go with a Mac.
A really crappy monitor that can't even be driven by something that uses a GPU. I have a 4-year-old MacBook Pro and a few of my colleagues have newer ones. They'll all quite happily drive a pair of external 4K monitors (we've been buying 4K as standard for 2-3 years, because they're not much more expensive than 1080 ones). I've no idea why you'd want to buy a display that didn't have a standard DisplayPort or HDMI interface.
Slashdot Mirror
Kind of. NTFS provided a way of storing data in different streams, but did not include data stored in alternate streams in file size accounting and did not provide an interface for enumerating them. We used this to great effect when I was in school, storing a copy of Quake in an alternate stream of a 100-byte text file. There was no mechanism for the system administrators to find it and they just saw that disk space was lower than expected.
No, the GP was (almost) correct. 3840x2160 is four times the number of pixels per frame of 1920x1080 and 60fps is double the frame rate of a standard 30fps 1080p stream. Four times as many pixels and double the frame rate gives 8 times as much raw data. That said, it also includes a lot more redundant data (changes between frames will be smaller if they're closer together, lots of areas in the larger image can be interpolated from the smaller one) and so the encoded size should be a lot less than 8 times the size of the same stream at 1080p, 30fps.
I quite like Thunderbird, but my big issue with it is that it renders HTML email using the Gecko engine in the same process that contains all of my mail server login credentials and full access to my email history. I don't know if Windows Mail does this, but Apple Mail uses the same sandboxing as Safari, so if there's a WebKit bug it will crash the renderer process but without a separate privilege escalation vulnerability it can't compromise my mail client. Handling untrusted data using a massively complex renderer in process just seems like a recipe for disaster.
WinCE was terrible, but it's worth remembering what the competition looked like. Prior to EKA2, Symbian didn't do protected memory. EKA2 was a nice kernel design, but it was crippled by userspace APIs designed when 2MB of RAM was a high-end phone so made developers think aggressively about memory management and cleanup. WinCE only looks bad in comparison to more modern systems that run a full desktop OS on a mobile device (which is a couple of orders of magnitude more powerful than the original desktops that said OS ran on). In comparison to the other options at the time, it was just mediocre.
I have and Android phone and an iPad, but my partner had a Windows Phone and it was the only mobile UI I've used that hasn't annoyed me. I don't 'miss' it, in the same way that I don't 'miss' BeOS, because I never used either enough to get accustomed to their features and be annoyed by their lack elsewhere. I didn't get one, because she was always frustrated by the lack of third-party support: the built-in functionality was mostly good (though, like Android, the lack of out-of-the-box CalDAV / CardDAV support was annoying) but if you ever wanted to do something that it couldn't do out of the box then it probably couldn't do it at all. If I could buy a Windows phone that could set up virtual Android environments with each completely isolated from the others then I'd buy one today.
The first four were easy; this one is going to hurt. Cook, it's time to start open sourcing some of Apple's code
This one is easy because they've already done it. Go to http://opensource.apple.com/ and take a look. A lot of the recent vulnerabilities were found in code that has been open sourced but none of the ones that I'm aware of were found by source analysis. Apple incorporates static analysis into their workflow on a pretty aggressive basis so bugs that are easy to find by static analysis of the source code don't usually make it into their code. A lot of their recent vulnerabilities have been found by Google Project Zero and were found by fuzzing and then binary analysis. Having access to the source code might make it easier for third parties to fix it, but wouldn't make it noticeably easier for anyone to find holes.
I often write code on a whiteboard, but when I do it's rarely valid code in any given language, it's pseudocode that omits any details that aren't relevant to the particular explanation that I'm giving at the time. That's a useful skill, but it's not usually the one that's tested in exams, where you're penalised for syntactic errors.
His idea is that you start with the new password, unhashed. Then you permute it in various ways and hash it. If any of these permutations gives the old hash, then you reject it. If not, then you hash it, store it, and scrub memory very carefully to erase all copies of the permuted unhashed password.
In case you missed the last dozen or so stories about Windows on ARM, it includes an x86 emulator (currently 32-bit only) and can run x86 Windows apps.
Depends on how much I'm buying, but generally if it's more than a few items then no - I'll do a rough estimate, but I can't be bothered to count all the pennies.
Amusingly, one of the arguments given for voting leave (and the reason that a lot of Indian and Pakistani immigrants voted) was the preferential treatment of Europeans over Asians by the UK immigration system. It's amusing how even the racism in the leave campaign wasn't self consistent, let alone their economic arguments.
It's one of two things. Either the transaction itself correlated with fraudulent transactions, or the transaction didn't correlate with your own spending habits. Banks build fairly complex statistical models of spending and flag any outliers as potential fraud. The most amusing one of these for me was the registration fee for a DARPA PI meeting. Apparently my bank believes that paying money to the US government correlates strongly with fraud. Somewhat less helpfully, they insisted on calling me during UK business hours (i.e. in the middle of the night where I was) to confirm. After a very grumpy 4am conversation (the third time they'd woken me up that night, but the first time I'd managed to get to my phone before it stopped ringing) they gave me a 24-hour number that I could call from anywhere in the world.
All UK banks that I'm familiar with mail you out the initial PIN (on a weird sticker thing that's meant to make it impossible to read by shining a bright light through the envelope) and then suggest that you change it at an ATM.
You'd have to want battery life and the ability to run Windows apps, though the fact that MS Office runs on Android and iOS makes that a bit more of a stretch.
For some value of exploited. Spectre lets the JavaScript snoop on the contents of RAM within the same process. Given that most web browsers perform tab-granularity sandboxing, that basically means that the JavaScript can snoop on all of the data that's associated with the tab that provided the JavaScript. It may mean that malicious JavaScript in an ad can snoop credentials from the enclosing page if it's in an iframe, but that's about it. The bigger danger is that this can be combined with other vulnerabilities to provide the disclosure step in a code reuse attack.
For most server workloads, unless you're allowing arbitrary untrusted code to run then it shouldn't matter.
Before you even hear any stories about how awful they are, the first thing you encounter with any of them, is that they don't interoperate with anything else. That is, if you want to talk to someone who uses that app, you have to use the same app
This is a failing of education. Most people don't understand that a service, a protocol, and a client are all separable components. They typically don't even differentiate between the service and the client: Skype is the Skype app, ICQ was the ICQ app, and so on. This has been made worse by webmail, where people don't realise that they can use Hotmail, GMail, or whatever with any IMAP and SMTP client - even on mobile devices, you'll often see people using the Microsoft app for their Hotmail account and the Google app for their GMail account, not realising that they could be using the same app for both.
The brain is not a computational device.
Citation or proof needed. There is no evidence that the brain can run any algorithm that a classical computer cannot run.
My bank and credit card companies let me download my full transaction log, including amounts, times, and locations, so that I can see exactly where I have spent money. They let me download in the same format as my bank, so I can also see recurring payments in the same format. That makes budgeting a lot easier.
I thought the chip was securely communicating with the bank. Like, it was drawing power from the terminal and encrypting data on the card itself. (And signing the cost.) Therefore, unlike a magstripe, no reason to be wary about inserting it in the card into a terminal. And I like it because I have to insert it into the terminal to make it communicate, not just have it unprotected in near someone who wants to scan it.
Two issues. The first is that there are some flaws in the EMV protocol. The most glaring is that, whereas the card authenticates itself to the bank, the bank does not authenticate itself to the card. That makes it possible for the terminal to launch MITM attacks. The card reader is not intended to be a trusted part of the system, but that means that you're entering the PIN into an untrusted device. That means that a thief can use a modified card reader to record your PIN, then steal the card. There are also some vulnerabilities in specific EMV implementations, for example some terminals use a simple incrementing counter for the 'unpredictable number.' This means that if you run one transaction you can predict the secret used in the next one and perform a replay attack.
I'm not sure if Google protects my fingerprint from themselves, but neither answer would surprise me (okay, the protection does.)
Google's problem is that they don't control the hardware. A few Android devices have something roughly similar to Apple's Secure Element (typically using TrustZone rather than a separate core), but most don't, and because the code that runs on it is provided by the vendor it doesn't integrate well with the OS.
I hate self-checkout. I'm doing a job that someone else could be doing, badly because they (rightly) don't trust their customers as much as their cashiers so make it more malice proof.
That depends on the shop. For example, Waitrose in the UK doesn't perform any of the weight checking that many of them use. This means that it's very quick. You might have more competent cashiers than I'm used to, but here they often don't pack things in a sensible order and they're not good at packing things into backpacks or pannier bags.
No more insecure than cash. If someone steals my wallet, they can use the card for small purchases or the cash. The difference is that the with the cash it's gone, with contactless it's the bank's liability and they will refund any transactions. It's also limited to a relatively small number of transactions per day and to £30 per transaction. The bank system may also decline contactless and require a PIN if they detect unusual purchase patterns.
Hmm, isn't the point of the newer cellulose / plastic 'paper' money to combine the two uses into a simple tool?
To be clear, I know the reason "to stimulate economy", just I am not familiar with any historical evidence to support it.
Take a look at what happened when economies abandoned gold or silver standards. In several cases it was because their economies started to grow faster than their money supply, which led to recessions.
Isn't it that there were economically stable times when currency had an intrinsic value, and quite to contrary - most big financial collapses happened under "modern" economy rules
The Great Depression happened when most countries were on the gold standard.
lastly isn't it the right of a human being to be rewarded for their work with something of intrinsic value and keep it under their bed if they chose so?
That's an interesting philosophical question. Part of the problem is defining what such a thing should be. Let's say that we use gold. Now if I do some work but there's no gold available, what happens?
I don't disagree that there are reasons to prefer cash, but convenience is not one of them.
The cheap display will most likely support HDMI and DisplayPort. You can drive it via the in-built GPU on your graphics card. With the latest macOS, you can also use eGPU, which means an external GPU connected via PCIe over Thunderbolt, so you get a more powerful GPU in an enclosure that's easier to cool. Or you can get a DisplayLink piece of crap, which uses USB and a weird hodgepodge of software or render-to-texture in the GPU then pulls the data out, compresses it and sends it over a proprietary protocol encapsulated in USB.
The only valid reason for buying DisplayLink stuff is that you want more monitors than your computer can drive and it isn't possible to add a GPU. Given that all MacBooks Pro released in the last 4-5 years support at least two external monitors (I think), there's little reason to buy one to go with a Mac.
A really crappy monitor that can't even be driven by something that uses a GPU. I have a 4-year-old MacBook Pro and a few of my colleagues have newer ones. They'll all quite happily drive a pair of external 4K monitors (we've been buying 4K as standard for 2-3 years, because they're not much more expensive than 1080 ones). I've no idea why you'd want to buy a display that didn't have a standard DisplayPort or HDMI interface.