Depends on the wave and the ship, but just turning the ship so it faces directly into the wave can be sufficient to greatly mitigate damage in a lot of cases. Being hit by an unexpected large wave broadside is typically worse than hitting it head-on, especially by reducing the risk of capsizing.
Rogue wave or not, captains want to steer their ship into the wave as it's the only way to get through the water safely. Waves hitting broadside is asking for a capsize. Engine failure during a storm is considered a very serious event because loss of engine power means loss of steering, and loss of steering means your ship can no longer be pointed into the waves and you risk capsize.
There was one drive maker which actually did this. They had two drive platters at opposite ends, each independent of the other, and either could fail, letting the other completely take over. I've wondered why this isn't more commonplace, perhaps a drive form factor with four heads, all active/active and can handle a head array failing (perhaps lighting up SMART.) This wouldn't just allow for four times the I/O, but allow four different threads to write at the same time, which is useful for virtualization, although these days, virtualization should just go to SSD or a large I/O buffer due to all the random reads/writes.
There was a drive that had two actuators that could access the entire platter. That was the design, but I think in the end the complexity of multiple heads accessing the same sector was problematic because of the ordering of the operations (i.e., one head could write data to the sector that the other head was reading - if you didn't catch this, you would corrupt the data).
Plus, double the heads doubles the chance of a head crash.
This just shows exactly how America is really messed up. There is going to be massive regulation framework for the operation of a 2 kilo drone. But the operation of a gun with massive more kinetic energy doesn't require any regulation.
You can blame the founding fathers for that, for you should know the second amendment strongly limits what any government can do regulating firearms.
Especially since the NRA transformed itself from an organization dedicated to elevating the skill level of riflemen from "can't hit the broadside of a barn" to "potential sharpshooter" to a more "guns for all" organization. (Yes, the early days, the NRA was formed because it was one thing to be allowed to own a gun. It was quite another to be able to use it properly, and most people who owned guns were terrible shots. So the NRA held courses and all that other stuff to teach people how to operate guns safely and to actually be able to shoot worth a damn. They were quite successful at the time, too).
So they've created a feature that allows you to remotely run the heater or a/c indefinitely while nobody is occupying the vehicle? Seems to me that one of the first things done when designing this would to implement a timer and/or an occupancy sensor. Preheating/cooling the interior on a cold/hot day is great, and sometimes you just want to run into a store with your dogs in the back without leaving the engine on, but both of these scenarios should be rather brief in duration. Allowing the system to discharge the battery to the point of leaving you stranded is just piss poor design. Security flaw aside, I see no good argument for allowing your car to be used as an unattended fridge or oven for extended periods of time.
Not only that, but simply disallowing pre-heat or pre-cool while not attached to a charger is pretty dumb. I mean, the whole point of pre-heat and pre-cool is to run the HVAC while you're on the charger so you're not consuming valuable miles to do so - you're plugged in, so coming into a pre-heated or pre-cooled car is pretty nice. But if you're away from the charger, that option should be disabled or attached to a very short timer (good for once use - requires cycling the "ignition" switch to reset).
All the while the FCC and the EU are working on preventing users from protecting themselves by modifying the routers firmware:
Only to prevent transmitting outside of the appropriate bands.
That's all the FCC cares about, and they want protections put in place to prevent a user from using say, channel 14 in North America.
Now, until now, most manufacturers simply used location specific firmware to lock down the transmit channels, but the next generation set will probably incorporate protections stored elsewhere - either an EEPROM, or maybe even fuses blown on the radios itself that say what channels are allowed. Which means it doesn't matter what software says - the hardware (or radio firmware, which is unmoddable) locks out the request to change to an invalid channel.
Anyhow, it's really a case more of manufacturers not taking responsibility for their product - no more "sorry, your product is unsupported" come time for a manufacturer-introduced vulnerability.
Used to be the case that the reaction time on non-BT wireless was quicker. It wasn't necessarily cheaping out as the proprietary solution actually provided a benefit. More overhead in the BT protocol meant more lag. Not sure if that's still true with current BT hardware/software stacks.
Not something you'd notice typing in the office, but gamers...
The other problem I had with Bluetooth is stuck keys or sticky keys caused by flaky signals. I used to use an Apple Bluetooth keyboard with my Mac Mini. It worked, but if the distance increased beyond a few feet, it was unreliable and keys would randomly get stuck as the key down report gets received, while the keyboard is trying to send a key up report. End result is you can get a stuck modifier key or a repeating typable key until the keyboard finally reconnects.
Replaced it with a Logitech, never had a problem since - no stuck keys and response time seemed way quicker.
Though I wonder - the Unifying receivers Logitech have require pairing devices together - not as sophisticated as Bluetooth, but you have to go into the app and tell it to pair devices at which point it searches for the first device to be power cycled. Which would mean physical access to the machine is required and thus a way to install malware way quicker and easier.
I think general iOS updates do require one to unlock their phone before proceeding, what is being talked about is the phone recovery mechanism when one connects the phone to a computer. I assume this was left 'open' so that it could be performed when the phone is software "bricked" so that the hardware may be ok, but the software is beyond usable/repairable.
If Apple blocks this for the obvious personal info safety benefits it would mean that the only way to recover a phone may be to wipe it completely clean, which I'm all good with, but expect lots of people complaining about it as well.
I think even on a DFU update, it erases the entire media. The only reason it appears that all your data is safe is because iTunes does a backup immediately before, erases and applies the DFU update, then immediately does a restore, so appearances are that it did an in-place upgrade.
Because DFU is the "emergency restore" method, it makes sense engaging it forces a complete wipe to clear out any crud that may be wedging the software.
>>"The best solution I've seen so far, from right here on Slashdot, is to have future firmware updates require the phone to be unlocked." The flash memory on the iPhone can be flashed from an external computer connected to the flash chip via an interface (http://www.mouser.com/Semiconductors/Memory/Flash-Memory/_/N-488w1), so software solutions probably won't work. Maybe you could try to use a hardware burned cipher in a "security chip" that can't output its key to engineer around that...
iPhones since the 3GS have hardware encryption to flash memory. The key is derived partly from a secret per-SoC key that is generated and Apple does not have. You cannot program the flash outside of the device (you lack the encryption key), nor can you remove the flash and read it out (you lack the decryption key). The data stored on the flash memory is married to the SoC and you need the SoC to decrypt it.
The next iPhones should have the timer between password attempts and the "wipe after 10 tries" options moved from software to the security chips in silicon.
"Sure we can put in a hacked iOS version, but the counters and timers are all in chip and iOS cannot touch those."
iPhone 5S and above already do that - the secure enclave checks PINs, enforces the 10 entry lockout and wipe (if enabled), and enforces the delays. And it's speed means the slow hashes stay slow.
The iPhone 5c is based on the iPhone 5, which lacks the secure enclave.
Err, can't you? Since only Apple has the private key necessary to sign iOS firmware updates, AFAICT that means that Apple could release a nerfed firmware that would run only on an iPhone 5c with Sayed Farouk's phone's hardware ID, and refuse to run on any other device, and nobody would be able to modify it without breaking its signature.
I understand there is also a principle of legal precedent to consider, but from a technical standpoint I don't see how it's impossible.
It's more of a barrier to entry.
Right now, Apple has to develop the firmware. And while it's easy to disable the 10 PIN check, the FBI wants additional development to be able to programmatically guess the PIN.
Once that is done, you have basically a master key. It doesn't matter that the FBI has a nerfed version that only works on one phone. One it's out, the barrier to developing it for other phones Is a lot lower - "We just want what you have given the FBI, just with this hardware ID". And so on.
And then there's a whole case of cyberattackers wanting to look at the firmware and find ways to break it - through jailbreaking if need be. Imagine the havoc caused if this firmware was released as part of a jailbreak tool for iOS.
In fact, the precedent for the All Writs Act is if something is already done, then law enforcement can ask for it to be done as well. Since the telephone company already uses pen registers for their own internal investigations (fraud, etc), then the FBI, local LEOs and others asking the phone company to put on a pen register on a specific line can do so as well. After all, the difference between the phone company and LEOs is who the data goes to in the end.
And the FBI doesn't want static data. They want live data. Let's say they used GMail and other services - they could ask Google for the data, but that requires a warrant. They could ask Apple, then use the GMail app on the phone in question and get the data without a warrant. Sure, it's probably not admissible, but if you really needed to know, you could either subpoena Google later for an "official" copy of the evidence, or just find other evidence.
And one final note - if you're comfortable with LEOs accessing your phone, then why bother putting a PIN on it? Or do you have crap on your phone that you don't want others to see?
Tim Cook knows about privacy - if nothing more than to protect those who have yet to come out of the closet. Which even in these modern times still brings up punishments as severe as the death penalty in many countries. Even in the first world many people are unable to cope with learning their son/daughter is gay.
So yeah, the phone owner's life could literally be on the line.
You have to admit, though, that "24 year-old programmer destroys billion-dollar company with worst video game ever" is a fantastic story. I doubt many of the people supporting the narrative have even seen an Atari 2600. It hardly matters how much of "Atari: Game Over" is truth, hyperbole, or flat out fiction, any more than "Wargames."
Atari only invested five person-weeks of effort into ET: it was not a big production. They lost something like $30M on E.T. (most of it marketing and the $20-25M fee to license E.T.), but most of the stories will mention Atari's $300+M quarterly loss when they talk about ET. And no one's going to suggest that the real reason ET lost so much money was some executive's decision to pay Spielberg $25M. The truth is boring, though, and always has been. Much better to tell an implausible story supported by conflating and exaggerating data.
Except what's true is the programmer behind ET made multi-million dollar hits. He was specifically chosen for the ET game because his career record for games was basically stunning.
So he did the best work he could making a game in 5 weeks (which was done by piss-poor management, who overpaid for an ET license as well). Sure in those days you could write a game in 5 weeks, but that's not a lot of time when you toss in a long test cycle (you had to assemble the code, then burn it onto cartridges, which meant testing a build took easily an hour or more) Plus, you didn't have debuggers or other sort of debug capability which made it all the much harder.
And the hardware itself was really only designed for two games - Pong and Battlezone. Any other game using the hardware was really more of luck than anything - the graphics hardware was designed purely to support Pong and Battlezone.
ET was also a pretty good seller - for the worlds worst videogame, it certainly moved a lot of units.
Finally, ET the game required approval from Spielberg - he actually LIKED the game and felt it did justice to the movie. And his approval was required in order to publish.
I really really hate it when some group does things "for my own good" when I want the exact opposite. For instance I really hate the phone app on the iPhone. Yet I can't remove or improve upon it. I want fine grained control over what my apps have access to and what information they get from my phone....
Basically I want to actually own my phone.
Your problem is you want an Android phone and got an iPhone instead. You want control over every little thing? Android gives you all the tools and APIs and tweaking ability to have your phone do exactly as you wish. Get a Nexus phone and load on your exactly customized version of Android you built from the Android source code.
iPhones don't have that sort of control - Apple retains a lot of control to give a more unified experience and to avoid a few issues like sending texts or making phone calls without your explicit approval (that's why the dialer cannot be replaced - when you want to dial a number, the iPhone brings up the dialer with the number pre-loaded, and you give the dialer (not the app calling the dialer) permission to make the call. That way no app can force you to make a 1-900 call - at best they can bring up the dialer and populate the number, but not force you to make the call.
Of course, with that level of control comes a level of responsibility since a misconfiguration could render your phone unable to make a call or even worse, unable to answer a call because of some strange dependency issue. Another reason why Apple doesn't want to give users that level of control.
Spoken like someone who either doesn't use their phone much, or is too young to remember the benefits of proper removable batteries.
I have some power packs like that. However trying to carry around and use your phone while tethered to one is not much better than being tethered to a wall plug. It's utterly impractical. Do you hold the battery pack, wire AND phone all in one hand while talking? Or do you now walk around like holding a Wii remote+nunchuk? Or maybe you get a 6' USB cord and stuff the battery pack onto your body somewhere? It's just ridiculous.
I can swap the battery in my S5 with a fully-charged one in under 10 seconds then be back on my way using my phone just as before, no wires, no tethers, no hassle.
And I remember when chargers came with spare battery docks so they could charge your spare batteries AND the phone at once.
Carrying extra batteries... how do you charge them? Samsung makes a dock for one phone (the S5, I believe) so you can charge the spare battery without the phone, but otherwise...? Do you charge the phone, then remember to swap the battery afterwards? Or do you just hope you remember to swap the battery and end up with a dead battery you carry along thinking it's full?
That's why we like external packs - because you can always charge them together with the phone. And unless your phone has an external docking station to charge extra batteries, it's a hassle to charge your phone, then remember 4 hours later to swap the batteries to charge the spare.
And I had a phone where I had 2 spare batteries. Usually one was dead because I forgot to swap the batteries.
Is this really more secure? Or is it just more convenient?
Neither. It's for vanity. It's to appeal to the millennials to give them one more selfie opportunity, so they can charge their card AND post about their new purchase on social media at the same time.
If's to encourage sales, which means more revenue for MasterCard in the end. If they had a doubt whether they wanted to buy something, well, the ability to take a selfie of it will hopefully convince them to buy.
The cell provider gave them their info and Apple gave the FBI the last iCloud back-up for the device, so what more could they actually find on the phone that would be of such a great use? I mean, I have a hard time believing that a couple of people that think throwing a hard drive in to a lake destroys the data on it would have the info on their phone not back-up to iCloud or have used something that is only obtainable from the unlocked phone itself. Add to that the story of the phones pass code changing while in FBI possession, which would be easy to track, and that the reports were that they threw their phones in the lake too. So you can find a 18 year old downloading illegal movies, but you can't track who changed the phone's lock code?? Ahhh yeahhhh, all of it together seems like some overwhelming bullshit.
Easy. The FBI has two reasons for compelling Apple to do this.
1) The phone itself. Think of all the credentials stored on the device that you now can access. Saved messages in WhatsApp and other IM style apps, live access to various services (perhaps they used GMail? The Gmail app or web page will show you the account and its data as well), etc. etc. etc.
Effectively, they get access to all sorts of data without requiring a warrant - perhaps they know he had a GMail account, and then they'd need to get a warrant to get information from that account from Google. But if they can access the Gmail app from the iPhone, warranty avoided!
2) The second part is to get Apple to deveop this software, because once it exists, it can be used over and over again.
The case cited for the All Writs Act involves the use of pen registers. The telephone company lost purely because they were already using pen registers in their day to day operations to verify billing and check for fraud. So they can be compelled to connect a pen register up to a desired phone line because they were doing it already.
Apple doesn't have the software, but once they do, it can be compelled into action. That's the result the FBI really wants.
Whatever happens to Apple here will impact everyone else
So assume that if they never jump in, they are already compromised.
But if they're going to jump in, they won't do it now. Let Apple deal with the PR issues (which won't be entirely in their favor, a lot of people are terrified of terrorists and would gladly give their house keys to the government). If Google and MS are going to jump in, and i agree they pretty much have to if they are not already compromised, it will be when this hits the courts.
Or, perhaps Samsung, Microsoft, etc., are simply relishing at the thought? I mean, if the FBI wins, that means they'll benefit in the short term as everyone leaves Apple for competitors. After all, Trump just gave Samsung a boost.
Yes, it's very short term thinking at the expense of the long term - perhaps Samsung will be next, and they can't fight it because Apple lost. Now everyone moves from Samsung to someone else. Rinse, repeat and so on.
Basically, the competitors are making hay while the sun shines.
What happens to Apple will happen to everyone else, but in the meantime, they have a year or two to sell lots more phones for profit.
Why is it so hard to believe that/. has supported Unicode for ages now? (It was courtesy of a patch by Slashdot.jp). However, a bunch of posters realized that the finer points of Unicode could be used to abuse the site (and many sites are still ripe for the abuse) to fake titles and scoring?
It's a pity the Unicode filter is run again on old comments but use Google to search for the odd phrase "erocS" and even "5:erocS" With a bit of Unicode trickery in the subject, you could fake a score 5 post.
After this and a bunch of other posters deciding to play with Unicode to screw up the layout, the powers that be installed a whitelist of allowed Unicode codepoints. Which basically ended up being the printable characters form the ASCII set.
Yep, I've looked at the article and found a couple legitimate bugs, and the rest of it is the authors complete misunderstanding of what he's talking about. He doesn't seem to understand that strcpy and memcpy DO NOT DO THE SAME THING. He assumes that an extra tab means an if was done incorrectly, goes on about bad practices when its just that he doesn't know what the code is doing and taking 3 seconds to understand that a MACRO behaves differently on different architectures and maybe, just maybe, the hardcode 0 makes sense on that specific architecture and not on others... which he could have found had he simply checked the places where the MACRO was defined instead of just the one that was compiled.
Or perhaps the trickiest bugs are caused by the most subtle of errors?
I mean, the concerns raise issues with what's happening in the code.
The tab issue - the code LOOKS like it does one thing, but it does something else completely. Depending on where it is in the code it could be on the scale of the "goto fail" bug (which was the result of the same kind of error) or it just leads to an obscure crash if certain conditions are right.
And when blocks of code in an if-then-else statement start being identical, that usually mean something is messed up. Or when you compare something against itself.
A lot of bugs are subtle ones - they don't fail immediately, but perhaps after a little while things start going wonky because the condition is being tripped. Or perhaps it's a security issue.
Perhaps it's being pedantic, but it looks like it catches what could be issues that would take weeks to debug.
And sometimes stuff is hidden through macros so it looks innocent, but because of the way the macro is written, it comes out completely different. Not parenthesizing macros leads to all sorts of strange bugs since the C preprocessor just works on blocks of and not semantics. So a macro that looks like a function doesn't necessarily behave like one (e.g., any math done in a macro is passed verbatim to the macro and not evaluated.
I'd say the bugs found are not the typical crash bugs or reproducible ones you fine, but more along the lines of those that happen infrequently and result in crashes that no one can really determine the cause because the code paths are executed frequently.
The FCC aren't enforcing it, yes, and I agree that it was not their goal. Still the impact of their decision remains the same.
You can run apps on Android devices. That's the single reason why android devices have separation, even though separation costs more in manufacturing. For routers, separation just isn't an option economically.
If the FCC had cared, it would have required separation, or just left the state as it was, but they didn't do either.
No, the FCC should not enforce separation. They should let the manufacturer deal with it however they want.
Some will lock it down completely. Others will leave it fully open, having locked it down in hardware. Some will do it by separating their radios and routing firmware.
In fact, #3 is how ALL wireless routers currently work - they have a main routing CPU, and attached to that is the WiFI radios through some interface. So they are separated, just they're usually treated as one unit.
To be honest, what's actually going to happen is router chips will be locked to their region - you buy a North American router, and the hardware bits will show which channels it's allowed to transmit on. This is easy to do, and leaves the opportunity open for fully customizable firmware since hardware is enforcing the channel lockouts.
Or how you still afaik can not get a app to scan wifi aps?
Because there's no way to write a wifi-scanner without using private APIs. You can probably write a very basic one that scans for available APs, but gets you little more than what the settings dialog shows you anyways using the available APIs. Getting any more information requires private API usage which is banned.
Of course, no one really talks much about it since Apple has an open-source sideload ability now - open source apps can be loaded on your iOS device provided you have a Mac. (Yes, I say open-source because Apple strongly discourages abusing this mechanism for binary only apps - which is what happened to f.lux - they distributed their app as a binary with an Xcode project wrapper).
Which I find mind-boggling, for Apple has found a way to have a walled garden, support open-source applications (no, you can't download binaries, but you can certainly BUILD the binary yourself and load it on your device), with the advantage that open-source apps can do a lot of things since Apple doesn't approve them. Oh yeah, added Mac sales, yadda yadda yadda.
I think Google is really talking about third-party stores in China, India, etc. I'm not sure if the Google presentation didn't mention those countries by name, though TFA does. Apparently, lots of people use them over there, and subsequently get viruses or malware. It probably causes Android malware vs iOS to be badly skewed. Google is rightly pointing out that you're more likely to get hit with malware from some sketchy Chinese app store than from Google Play. It's not really all that shocking a revelation. Think about CNet's Download.com and all the crap you get on your system if you use that site, and you get the basic idea.
Problem is, Google Play is not available in China. (I have no information on whether or not it is available in India).
So if you're an Android phone user in China, you have no choice BUT to use a third party app store. And there are several Chinese app stores, and various ones run by the carriers. Of course, they are havens for piracy and malware since those stores do not care about user safety or anything.
For this, to increase safety would require developers to release the APKs on their own websites and simply not use those sketchy app stores.
Well my parent's believe Apple are being a bunch of dicks about this and should just comply. I doubt they are the only ones. While you and me may believe privacy is worth fighting for I bet most companies would rather get a good feeling for the general consensus first. From a pure 'business' perspective that's the right thing to do when not specifically on the spot like Apple is.
Apple had no good option to go with, spend lots of time and effort trying to make it possible with no return or make this a public case of privacy for their users and the government is 'bad'. Looking at those of course they go 'User Privacy!' as a rallying cry. You need to remember while peopel may run then, a company is a collective entity that is entirely selfish.
To which you point out to your parents Tim Cook's letter, which is linked off the front page of apple.com. In it he details why he's making the stand, and even more importantly, why he's "being a dick". He even addresses terrorism itself. It's a very insightful and thoughtful message that explains why Apple does not want to roll over and be the FBI's pet. And he even details why encryption is not just optional on a smartphone, but mandatory. And heck, Apple did give up the data they could - the iCloud backups, which were obtained legally by a warrant.
As for the "user privacy" stance - after the Snowden revelations, it's the only stance Apple can take. It's also beneficial, since it's the stance Apple can take to differentiate their products from their competitors.
But think of it this way - if they didn't care, why did they go through all the trouble of the secure enclave? And to make it an extremely paranoid one at that - giving it the ultimate power to wipe the phone if attacked? (Error 53 is such an attack - perhaps a modified fingerprint sensor is trying to find a way to break the secure enclave code and allow it to run arbitrary code, allowing full access to the system without the system knowing. The secure enclave is paranoid as it should be). It's why later phones rely on it to do the 10 authentication attempts and wipe, and why the enclave enforces the delays between attempts.
If anything, this issue should go to the Supreme Court to be decided there, putting to rest all those legislation trying to put backdoors in encryption products and other things.
And yes, there is a chilling effect - it spreads wider than just Apple, but to everyone. Not just iOS, or Android, or Blackberry, but to the very foundations of what the Internet provides. Because it's not just encryption, but efforts like HTTPS Everywhere, Lets Encrypt and other services,
My question is a side one. Apple has described that for every secure enclave in its iPhones (region of the core processing chips), they inscribe a unique ID -- completely unknown and irretrievable by Apple or its suppliers -- that serves as a private key during encryption operations. This way you cannot unlock an iPhone's contents without the correct passphrase/passkey and the phone's unique ID in your possession.
How does a chip manufacturer inscribe a unique code into every chip? As I understand it, chips are produced by successive masks (film) with the circuit pattern layered on each mask.
Is one of the masks getting printed with the unique set of codes? Are the masks printed and changed with every wafer, after the unique codes are changed and discarded? Seems like a very intense way of having to put a unique code on each chip.
Or, if you remember film cameras from like the 80s/90s, where they could burn a date into the corner of the negative, do IC making masks have the ability to dynamically burn a changing code during exposure of the wafer??
Just to reiterate a point - the phone in question is an iPhone 5C which doesn't have a secure enclave. A7 SoCs and above with the secure enclave do all the PIN verification in hardware, enforcing the timeouts and the 10 incorrect guess wipes. But since the iPhone 5C doesn't have this, it's a software check that does it. (However, it doesn't mean Apple can just load on a new firmware update to a locked phone - doing so could wipe the phone as well).
So it is theoretically possible to write code that allows unlimited guesses. Whether or not you can load it on a phone is another question altogether (and I wouldn't be surprised if you couldn't without wiping the phone).
As for the SoC part - no, they don't pattern the masks with the ID. What happens is in practically every SoC in existence, there is a bit of memory that is one-time programmable. Effectively, it's an array of fuses (we call them fuses, but in reality, they're antifuses). You can blow the fuses which often sets various configuration options (e.g., blow one fuse, and the JTAG interface is disabled, blow another fuse, and you disable some block, or half the cache or whatever). You can also blow fuses that have special properties - e.g., a memory area that cannot be read by software, but hardware can access it. This is often done by initial programming software - you program in a serial number and the software blows the right fuses for that serial number. That software can also generate the hardware keys for encryption - by generating a random key using the key generator block (usually a random number generator) of the cryptographic engine, then using that to blow the key fuses. If the software doesn't report the key to the manufacturing hardware, then no one knows the key, not even Apple.
OTP fuses can be blown during the hardware test phase of chip production as well. Special pads on the die that aren't brought out of the package can be used to access and blow the OTP fuses. This is typically done for the unique identifier portion
For small lots, it's often easier to do it in software during production - customers will buy chips with areas of the OTP unblown to which they can use vendor-provided tools to blow them. Larger runs can be blown at the factory.
The OTP array is not strictly a 2D array of fuses - there's metadata like a valid bit (the row of memory is programmed - used by boot firmware to determine if it needs to engage the encryption unit), a lock bit (to prevent bits from being written - stuff like serial numbers and unique IDs will have the lock bit blown to prevent people from blowing fuses in that row and changing the ID), the bits themselves and special wiring that connects each bit with the appropriate piece of hardware.
Density is now up to and surpassing "spinning rust" and durability is arguably as good or better. But price per gig is not quite there yet. However, I suspect it is coming!
Slowly. The nice thing is Moore's Law basically states how fast - transistor density doubling means you can get twice the storage for the same price, or the price of the drive halves.
So price per gig will roughly halve every 18 months or so. Given you can get 2TB drives for under $100 these days, it's roughly 3-4 generations away, or maybe 5-6 years.
Slashdot Mirror
Rogue wave or not, captains want to steer their ship into the wave as it's the only way to get through the water safely. Waves hitting broadside is asking for a capsize. Engine failure during a storm is considered a very serious event because loss of engine power means loss of steering, and loss of steering means your ship can no longer be pointed into the waves and you risk capsize.
There was a drive that had two actuators that could access the entire platter. That was the design, but I think in the end the complexity of multiple heads accessing the same sector was problematic because of the ordering of the operations (i.e., one head could write data to the sector that the other head was reading - if you didn't catch this, you would corrupt the data).
Plus, double the heads doubles the chance of a head crash.
Well, the Internet Archive has copies of it.
The only thing is it has an older version of AnyDVD HD and a couple of other programs, too.
https://web.archive.org/web/20...
You can blame the founding fathers for that, for you should know the second amendment strongly limits what any government can do regulating firearms.
Especially since the NRA transformed itself from an organization dedicated to elevating the skill level of riflemen from "can't hit the broadside of a barn" to "potential sharpshooter" to a more "guns for all" organization. (Yes, the early days, the NRA was formed because it was one thing to be allowed to own a gun. It was quite another to be able to use it properly, and most people who owned guns were terrible shots. So the NRA held courses and all that other stuff to teach people how to operate guns safely and to actually be able to shoot worth a damn. They were quite successful at the time, too).
Not only that, but simply disallowing pre-heat or pre-cool while not attached to a charger is pretty dumb. I mean, the whole point of pre-heat and pre-cool is to run the HVAC while you're on the charger so you're not consuming valuable miles to do so - you're plugged in, so coming into a pre-heated or pre-cooled car is pretty nice. But if you're away from the charger, that option should be disabled or attached to a very short timer (good for once use - requires cycling the "ignition" switch to reset).
Only to prevent transmitting outside of the appropriate bands.
That's all the FCC cares about, and they want protections put in place to prevent a user from using say, channel 14 in North America.
Now, until now, most manufacturers simply used location specific firmware to lock down the transmit channels, but the next generation set will probably incorporate protections stored elsewhere - either an EEPROM, or maybe even fuses blown on the radios itself that say what channels are allowed. Which means it doesn't matter what software says - the hardware (or radio firmware, which is unmoddable) locks out the request to change to an invalid channel.
Anyhow, it's really a case more of manufacturers not taking responsibility for their product - no more "sorry, your product is unsupported" come time for a manufacturer-introduced vulnerability.
The other problem I had with Bluetooth is stuck keys or sticky keys caused by flaky signals. I used to use an Apple Bluetooth keyboard with my Mac Mini. It worked, but if the distance increased beyond a few feet, it was unreliable and keys would randomly get stuck as the key down report gets received, while the keyboard is trying to send a key up report. End result is you can get a stuck modifier key or a repeating typable key until the keyboard finally reconnects.
Replaced it with a Logitech, never had a problem since - no stuck keys and response time seemed way quicker.
Though I wonder - the Unifying receivers Logitech have require pairing devices together - not as sophisticated as Bluetooth, but you have to go into the app and tell it to pair devices at which point it searches for the first device to be power cycled. Which would mean physical access to the machine is required and thus a way to install malware way quicker and easier.
I think even on a DFU update, it erases the entire media. The only reason it appears that all your data is safe is because iTunes does a backup immediately before, erases and applies the DFU update, then immediately does a restore, so appearances are that it did an in-place upgrade.
Because DFU is the "emergency restore" method, it makes sense engaging it forces a complete wipe to clear out any crud that may be wedging the software.
iPhones since the 3GS have hardware encryption to flash memory. The key is derived partly from a secret per-SoC key that is generated and Apple does not have. You cannot program the flash outside of the device (you lack the encryption key), nor can you remove the flash and read it out (you lack the decryption key). The data stored on the flash memory is married to the SoC and you need the SoC to decrypt it.
iPhone 5S and above already do that - the secure enclave checks PINs, enforces the 10 entry lockout and wipe (if enabled), and enforces the delays. And it's speed means the slow hashes stay slow.
The iPhone 5c is based on the iPhone 5, which lacks the secure enclave.
It's more of a barrier to entry.
Right now, Apple has to develop the firmware. And while it's easy to disable the 10 PIN check, the FBI wants additional development to be able to programmatically guess the PIN.
Once that is done, you have basically a master key. It doesn't matter that the FBI has a nerfed version that only works on one phone. One it's out, the barrier to developing it for other phones Is a lot lower - "We just want what you have given the FBI, just with this hardware ID". And so on.
And then there's a whole case of cyberattackers wanting to look at the firmware and find ways to break it - through jailbreaking if need be. Imagine the havoc caused if this firmware was released as part of a jailbreak tool for iOS.
In fact, the precedent for the All Writs Act is if something is already done, then law enforcement can ask for it to be done as well. Since the telephone company already uses pen registers for their own internal investigations (fraud, etc), then the FBI, local LEOs and others asking the phone company to put on a pen register on a specific line can do so as well. After all, the difference between the phone company and LEOs is who the data goes to in the end.
And the FBI doesn't want static data. They want live data. Let's say they used GMail and other services - they could ask Google for the data, but that requires a warrant. They could ask Apple, then use the GMail app on the phone in question and get the data without a warrant. Sure, it's probably not admissible, but if you really needed to know, you could either subpoena Google later for an "official" copy of the evidence, or just find other evidence.
And one final note - if you're comfortable with LEOs accessing your phone, then why bother putting a PIN on it? Or do you have crap on your phone that you don't want others to see?
Tim Cook knows about privacy - if nothing more than to protect those who have yet to come out of the closet. Which even in these modern times still brings up punishments as severe as the death penalty in many countries. Even in the first world many people are unable to cope with learning their son/daughter is gay.
So yeah, the phone owner's life could literally be on the line.
Except what's true is the programmer behind ET made multi-million dollar hits. He was specifically chosen for the ET game because his career record for games was basically stunning.
So he did the best work he could making a game in 5 weeks (which was done by piss-poor management, who overpaid for an ET license as well). Sure in those days you could write a game in 5 weeks, but that's not a lot of time when you toss in a long test cycle (you had to assemble the code, then burn it onto cartridges, which meant testing a build took easily an hour or more) Plus, you didn't have debuggers or other sort of debug capability which made it all the much harder.
And the hardware itself was really only designed for two games - Pong and Battlezone. Any other game using the hardware was really more of luck than anything - the graphics hardware was designed purely to support Pong and Battlezone.
ET was also a pretty good seller - for the worlds worst videogame, it certainly moved a lot of units.
Finally, ET the game required approval from Spielberg - he actually LIKED the game and felt it did justice to the movie. And his approval was required in order to publish.
Your problem is you want an Android phone and got an iPhone instead. You want control over every little thing? Android gives you all the tools and APIs and tweaking ability to have your phone do exactly as you wish. Get a Nexus phone and load on your exactly customized version of Android you built from the Android source code.
iPhones don't have that sort of control - Apple retains a lot of control to give a more unified experience and to avoid a few issues like sending texts or making phone calls without your explicit approval (that's why the dialer cannot be replaced - when you want to dial a number, the iPhone brings up the dialer with the number pre-loaded, and you give the dialer (not the app calling the dialer) permission to make the call. That way no app can force you to make a 1-900 call - at best they can bring up the dialer and populate the number, but not force you to make the call.
Of course, with that level of control comes a level of responsibility since a misconfiguration could render your phone unable to make a call or even worse, unable to answer a call because of some strange dependency issue. Another reason why Apple doesn't want to give users that level of control.
And I remember when chargers came with spare battery docks so they could charge your spare batteries AND the phone at once.
Carrying extra batteries ... how do you charge them? Samsung makes a dock for one phone (the S5, I believe) so you can charge the spare battery without the phone, but otherwise...? Do you charge the phone, then remember to swap the battery afterwards? Or do you just hope you remember to swap the battery and end up with a dead battery you carry along thinking it's full?
That's why we like external packs - because you can always charge them together with the phone. And unless your phone has an external docking station to charge extra batteries, it's a hassle to charge your phone, then remember 4 hours later to swap the batteries to charge the spare.
And I had a phone where I had 2 spare batteries. Usually one was dead because I forgot to swap the batteries.
Neither. It's for vanity. It's to appeal to the millennials to give them one more selfie opportunity, so they can charge their card AND post about their new purchase on social media at the same time.
If's to encourage sales, which means more revenue for MasterCard in the end. If they had a doubt whether they wanted to buy something, well, the ability to take a selfie of it will hopefully convince them to buy.
Easy. The FBI has two reasons for compelling Apple to do this.
1) The phone itself. Think of all the credentials stored on the device that you now can access. Saved messages in WhatsApp and other IM style apps, live access to various services (perhaps they used GMail? The Gmail app or web page will show you the account and its data as well), etc. etc. etc.
Effectively, they get access to all sorts of data without requiring a warrant - perhaps they know he had a GMail account, and then they'd need to get a warrant to get information from that account from Google. But if they can access the Gmail app from the iPhone, warranty avoided!
2) The second part is to get Apple to deveop this software, because once it exists, it can be used over and over again.
The case cited for the All Writs Act involves the use of pen registers. The telephone company lost purely because they were already using pen registers in their day to day operations to verify billing and check for fraud. So they can be compelled to connect a pen register up to a desired phone line because they were doing it already.
Apple doesn't have the software, but once they do, it can be compelled into action. That's the result the FBI really wants.
Or, perhaps Samsung, Microsoft, etc., are simply relishing at the thought? I mean, if the FBI wins, that means they'll benefit in the short term as everyone leaves Apple for competitors. After all, Trump just gave Samsung a boost.
Yes, it's very short term thinking at the expense of the long term - perhaps Samsung will be next, and they can't fight it because Apple lost. Now everyone moves from Samsung to someone else. Rinse, repeat and so on.
Basically, the competitors are making hay while the sun shines.
What happens to Apple will happen to everyone else, but in the meantime, they have a year or two to sell lots more phones for profit.
Why is it so hard to believe that /. has supported Unicode for ages now? (It was courtesy of a patch by Slashdot.jp). However, a bunch of posters realized that the finer points of Unicode could be used to abuse the site (and many sites are still ripe for the abuse) to fake titles and scoring?
It's a pity the Unicode filter is run again on old comments but use Google to search for the odd phrase "erocS" and even "5:erocS" With a bit of Unicode trickery in the subject, you could fake a score 5 post.
After this and a bunch of other posters deciding to play with Unicode to screw up the layout, the powers that be installed a whitelist of allowed Unicode codepoints. Which basically ended up being the printable characters form the ASCII set.
Or perhaps the trickiest bugs are caused by the most subtle of errors?
I mean, the concerns raise issues with what's happening in the code.
The tab issue - the code LOOKS like it does one thing, but it does something else completely. Depending on where it is in the code it could be on the scale of the "goto fail" bug (which was the result of the same kind of error) or it just leads to an obscure crash if certain conditions are right.
And when blocks of code in an if-then-else statement start being identical, that usually mean something is messed up. Or when you compare something against itself.
A lot of bugs are subtle ones - they don't fail immediately, but perhaps after a little while things start going wonky because the condition is being tripped. Or perhaps it's a security issue.
Perhaps it's being pedantic, but it looks like it catches what could be issues that would take weeks to debug.
And sometimes stuff is hidden through macros so it looks innocent, but because of the way the macro is written, it comes out completely different. Not parenthesizing macros leads to all sorts of strange bugs since the C preprocessor just works on blocks of and not semantics. So a macro that looks like a function doesn't necessarily behave like one (e.g., any math done in a macro is passed verbatim to the macro and not evaluated.
I'd say the bugs found are not the typical crash bugs or reproducible ones you fine, but more along the lines of those that happen infrequently and result in crashes that no one can really determine the cause because the code paths are executed frequently.
No, the FCC should not enforce separation. They should let the manufacturer deal with it however they want.
Some will lock it down completely.
Others will leave it fully open, having locked it down in hardware.
Some will do it by separating their radios and routing firmware.
In fact, #3 is how ALL wireless routers currently work - they have a main routing CPU, and attached to that is the WiFI radios through some interface. So they are separated, just they're usually treated as one unit.
To be honest, what's actually going to happen is router chips will be locked to their region - you buy a North American router, and the hardware bits will show which channels it's allowed to transmit on. This is easy to do, and leaves the opportunity open for fully customizable firmware since hardware is enforcing the channel lockouts.
Because there's no way to write a wifi-scanner without using private APIs. You can probably write a very basic one that scans for available APs, but gets you little more than what the settings dialog shows you anyways using the available APIs. Getting any more information requires private API usage which is banned.
Of course, no one really talks much about it since Apple has an open-source sideload ability now - open source apps can be loaded on your iOS device provided you have a Mac. (Yes, I say open-source because Apple strongly discourages abusing this mechanism for binary only apps - which is what happened to f.lux - they distributed their app as a binary with an Xcode project wrapper).
Which I find mind-boggling, for Apple has found a way to have a walled garden, support open-source applications (no, you can't download binaries, but you can certainly BUILD the binary yourself and load it on your device), with the advantage that open-source apps can do a lot of things since Apple doesn't approve them. Oh yeah, added Mac sales, yadda yadda yadda.
Problem is, Google Play is not available in China. (I have no information on whether or not it is available in India).
So if you're an Android phone user in China, you have no choice BUT to use a third party app store. And there are several Chinese app stores, and various ones run by the carriers. Of course, they are havens for piracy and malware since those stores do not care about user safety or anything.
For this, to increase safety would require developers to release the APKs on their own websites and simply not use those sketchy app stores.
To which you point out to your parents Tim Cook's letter, which is linked off the front page of apple.com. In it he details why he's making the stand, and even more importantly, why he's "being a dick". He even addresses terrorism itself. It's a very insightful and thoughtful message that explains why Apple does not want to roll over and be the FBI's pet. And he even details why encryption is not just optional on a smartphone, but mandatory. And heck, Apple did give up the data they could - the iCloud backups, which were obtained legally by a warrant.
As for the "user privacy" stance - after the Snowden revelations, it's the only stance Apple can take. It's also beneficial, since it's the stance Apple can take to differentiate their products from their competitors.
But think of it this way - if they didn't care, why did they go through all the trouble of the secure enclave? And to make it an extremely paranoid one at that - giving it the ultimate power to wipe the phone if attacked? (Error 53 is such an attack - perhaps a modified fingerprint sensor is trying to find a way to break the secure enclave code and allow it to run arbitrary code, allowing full access to the system without the system knowing. The secure enclave is paranoid as it should be). It's why later phones rely on it to do the 10 authentication attempts and wipe, and why the enclave enforces the delays between attempts.
If anything, this issue should go to the Supreme Court to be decided there, putting to rest all those legislation trying to put backdoors in encryption products and other things.
And yes, there is a chilling effect - it spreads wider than just Apple, but to everyone. Not just iOS, or Android, or Blackberry, but to the very foundations of what the Internet provides. Because it's not just encryption, but efforts like HTTPS Everywhere, Lets Encrypt and other services,
Just to reiterate a point - the phone in question is an iPhone 5C which doesn't have a secure enclave. A7 SoCs and above with the secure enclave do all the PIN verification in hardware, enforcing the timeouts and the 10 incorrect guess wipes. But since the iPhone 5C doesn't have this, it's a software check that does it. (However, it doesn't mean Apple can just load on a new firmware update to a locked phone - doing so could wipe the phone as well).
So it is theoretically possible to write code that allows unlimited guesses. Whether or not you can load it on a phone is another question altogether (and I wouldn't be surprised if you couldn't without wiping the phone).
As for the SoC part - no, they don't pattern the masks with the ID. What happens is in practically every SoC in existence, there is a bit of memory that is one-time programmable. Effectively, it's an array of fuses (we call them fuses, but in reality, they're antifuses). You can blow the fuses which often sets various configuration options (e.g., blow one fuse, and the JTAG interface is disabled, blow another fuse, and you disable some block, or half the cache or whatever). You can also blow fuses that have special properties - e.g., a memory area that cannot be read by software, but hardware can access it. This is often done by initial programming software - you program in a serial number and the software blows the right fuses for that serial number. That software can also generate the hardware keys for encryption - by generating a random key using the key generator block (usually a random number generator) of the cryptographic engine, then using that to blow the key fuses. If the software doesn't report the key to the manufacturing hardware, then no one knows the key, not even Apple.
OTP fuses can be blown during the hardware test phase of chip production as well. Special pads on the die that aren't brought out of the package can be used to access and blow the OTP fuses. This is typically done for the unique identifier portion
For small lots, it's often easier to do it in software during production - customers will buy chips with areas of the OTP unblown to which they can use vendor-provided tools to blow them. Larger runs can be blown at the factory.
The OTP array is not strictly a 2D array of fuses - there's metadata like a valid bit (the row of memory is programmed - used by boot firmware to determine if it needs to engage the encryption unit), a lock bit (to prevent bits from being written - stuff like serial numbers and unique IDs will have the lock bit blown to prevent people from blowing fuses in that row and changing the ID), the bits themselves and special wiring that connects each bit with the appropriate piece of hardware.
Slowly. The nice thing is Moore's Law basically states how fast - transistor density doubling means you can get twice the storage for the same price, or the price of the drive halves.
So price per gig will roughly halve every 18 months or so. Given you can get 2TB drives for under $100 these days, it's roughly 3-4 generations away, or maybe 5-6 years.