NASA's big argument is that the former (rocket goes boom while fuel-loading) is much more likely than the later (a rocket that has proven to go boom during/immediately after fueling suddenly goes boom at a later point in time, while the astronauts are on their way, but not already installed into something that can serve as an emergency escape) - ie: fueling in particular is making them extremely nervous compared to any other step.
SpaceX' argument is that the escape mecanism is good enough to make the actual impact of a boom-during-fuelling negligible - ie they have quite some crazy trust into their capsule's escaping performance.
I fail to see any difference between "load it up with propellant at super-cold temperatures to shrink its size" and "load it up with liquid hydrogen and liquid oxygen", where, as far as I know, manned rockets have been loaded that way since the Apollo missions.
Think liquid mercury changing density (and thus size occupied in the thermometer's tube) depending on the temperature.
Since the Apollo missions, liquid hydrogen and liquid oxygen are made liquid by cooling them just barely enough to make them liquid, just below their freezing point. The big advantage is that, even if it's cooling, it's not cooling *that* much. The rocket can then basically stay waiting for some time (well a tiny bit is going to boil of, but you can top that tiny bit at the last moment, by adding more liquid).
The SpaceX way is to cool the liquid *much further*. You're not just cooling them "a bit" to make them liquid, you cool them as much as physically possible in your system. Because you cool them to much colder temperature, they are much dense. You can fit much more such super-cooled fuel in the same tank than if it were merely "chilled enough to be liquid" fuel. The draw back is that once loaded, you have to take off as fast as possible. Otherwise you'll eventually loose any advantage of your super-cooled/super-dense fuel as the temperature will eventually rise (less dense fuel : suddenly occupies at lot more space. It will either flow out, boil out, or you'll bust the tank if there's no way to get of the sudden extra volume). You could top up any boiled-off fuel at the last moment, but you cannot regain any of the higher-density unless you magically re-cool the whole tank's worth of fuel.
In NASA's experience, the most dangerous moment is the moment you're loading the fuel in.
- With the Appollo style, the point is to do the dangerous fueling first, when there's nobody in the dangerzone around the rocket. Only then, once the dangerous phase is over and the whole thing is a bit more secure now, you take the necessary time to load your payload (passengers here). Then top-up the boiled-off and go.
- With SpaceX, the payload need to be loaded first (the astronauts needs to be already in the capsule), because you can't afford much wait time between the fuel loading and the take off (remember, the more time pass, the more the temperature rises, the less super-cooled/denser you fuel is). So during the most dangerous phase, during the fueling there are already people (the astronauts) in place. SpaceX's mitigation is that by that time, they are already well installed in the capsule, so the capsule should be able to evacuate them to safety if anything goes wrong. NASA's opinion is that this is unnecessary risk taking just to shave off a few more fuel by having it at a lower-than-apollo temperature.
That's why a few law needs to be passed, e.g.: limiting the price of such re-sell to the exact price at which the ticket was bought. (France has such laws).
Other wise you can bet that the "TicketMaster-approved second-hand market" will reimburse the original owner the price of *original* ticket (minus a fee) and will bill the new user the *current price* of the ticket (plus another fee), and the second hand marker owners (and their shareholders... Ticket master) will pocket the price difference and twice the fee. It's not going to be as such high profit as ticket scalpers who try to resell desirable rare tickets for 10x the price, but it will be a guaranteed revenue stream (tons of people can have a last minute change of plans).
The way I've seen it implemented, ID is used as a fallback.
When the QR-code / Barcode is rejected at the gate, two scenarios :
- some con artist used that code to generate a false ticket and managed to enter first into the premise, and the ticket S/N is marked as "already used". Too late to find out who's the cheater, but at least you can use the ID and verify the legitimate customer and let them in.
- the legitimate customer already went in with this barcode/QR-code first. The person refused at the gate has a counterfeit ticket that re-uses the code from the legitimate user. The person will also fail the ID check (the ID in the database is tied to the legitimate user's ticket S/N). You can safely refuse access to the user.
So in term of your exemple, you aren't adding 270 hours total of checks spread among the ~60-80 people manning the gates. You'r only adding 10s x the number of time the system reports "Ticket S/N already used to enter the event", so only for the ticket cloning counterfeit attempts-
It's not as robust as checking every single person entering the event, but at least :
- the legitimate owner can always enter the event, no matter what
- at most 1 single counterfeit clone-ticket holder can manage to get in with a given serial number befire the system notices and require ID checks for the same ticket.
---
This is usually coupled with another details (I've mostly seen in France) : Event organizers and/or ticket provider, makes it mandatory to use a specific web platform to sell tickets second hand.
- This platform forbids to sell second hand ticket at a higher price than the official ticket price. (It avoid scalpers)
- This platform can track change of ownership for the organizers/ticket providers. Whenever a ticket is resold, the database can be updated to match the new legitimate owner (the S/N of the ticket can even be changed so that the older barcode isn't valid anymore), and the new owner is issued a new PDF that they can print that contains an update QR-code/barcode.
---
That requires a tiny bit of infrastructure (basically servers holding the database mapping who is the valid owner of a ticket, and what is the latest S/N on said ticket). And blockchain is typically the kind of technology that can do decentralized ownership tracking - so no infrastructure but a distributed ledger.
But it's probably overkill. I haven't seen a barcode server failing on the day of an event yet, all the e-ticket have always been working as expected.
(But you can count on France that one day one critical person in this system is going to be on strike, and the system will be non-functional)
This law requires the ban of selling such hybrids by 2040. There are lots of different models of cars currently sold in 2018 that already have better batteries than that (I'm not only speaking of Tesla, I'm speaking about the Renault, Nissan, VW, Citroen, etc.)
Non plug-in hybrids where an interesting stop-gag measure back at a time when everybody was heavily relying on an existing infastructue/logistics for gaz, when battery were still small, and there was virtually no chargers infrastructure. But plugin to charge your car's battery while it's not in use is definitely the long term target to go to.
By 2040, probably all car will be able to do well more than 100km at least, with maybe some still featuring gaz-powered range-extenders for the few occasions when people need to drive for prolonged distance without ever seeing a charger. (e.g.: using their cars to drive in remote/backwards area where ubiquitous public chargers aren't yet a thing, the gaz station are still the most common energy delivery, and the user isn't interesting in fork whatever the cost of a 200-200hWh battery will be by then).
The Society of Motor Manufacturer are only panicking because some of their members are realizing that they are left with lots of soon-to-be-dead assets (stock, manufacturing capacity, etc.).
Most sane car manufacturers have started thinking about this for quite some time, and will probably be more-than-ready by 2040.
If you can load the dishwasher, you can also press a button to start it.
But, the next logical question is "what if you don't want to start it now, but in the morning" (because you don't want to noise to wake anyone up in you tiny apartment, nor your neighbors across the thin walls). So most company put a "delay before start" setting (which by itself isn't a stupid idea).
But that the exact point where things start to roll down hill, because the "delay" implementation might not be that good.
- It's not intuitive user/friendly (requires weird button completion)
- It requires the time being set (cue in "Blinking 12:00" for anyone who isn't the typical/.er) etc. Which usually end ups with a company having a "brilliant !" (ahem...) idea : Let's make an App for it (because for 99% of normal population outthere, smartphone is something that they are used with and which is intuitive for them). Which immediately jumps to the last horrible point : Let's make the app web-enabled/cloud-hosted/whatever, so the user can start the dish washer from outside home if they forgot to put the delay timer for the morning. Cue in all Asian no-name cheap companies seeing a new selling point on the feature bullet list and deciding to clone this feature. Poorly. (But extremely cheaply).
And that's how you end up with internet enabled dishwashers and fridges with pointless cloud-feature that barely anyone actually needs, but which are a giant security nightmare.
Meltdown can be totally protected against in software however with a significant performance impact.
It is patched, by completely changing the way kernel works and not relying on memory protection anymore. Thank you very much, Intel ! Instead you need to context switch and make important kernel parts inaccessible on each system call.
(PCID is something that helps a bit the context switching : you don't actually flush the whole context, you use different process tags so the differently tagged process cannot be seen anymore).
Spectre can be divided into two kinds of attacks: . One kind that bypass protection checks (range checks etc.) used to create software based virtual machines. These can be protected against in software.
Specifically, relying on by-passing any check (such as a boundary check on an array). It's ABSOLUTELY NOT virtual-machine specific. The thing is, it's still the same process, still reading data that it has access to, to begin with (unlike Meltdown which basically fucks up any notions of memory protection). So its usability is limited to processes that both can run 3rd party provided code and contain critical data (i.e.: a badly designed webbrowser that runs web-provided javascript and its password manager both in the same context) (or another example: the Linux kernel's new-gen PacketFilter can be optionally configured to JIT compile the user-provided filtering scripts. USer-provided code in a kernel context, what could possibly go wrong ? Hint: There's a reason why it's not "on" by default).
But basically, most of the cases can be handled by keeping sane design pattern in software.
One kind that use shared branch prediction state between an attacker and a victim to influence speculative execution when running the victim code, this can be used to extract data that can be exfiltrated through a shared cache.
Which means that an attacker could be a userland software running on the cloud, and target could be the hypervisor itself. Which is several levels of scarry. But this thing also requires very detailled knowledge of the internal of the CPU. It has been successfully exploited on Intel Xeon by Google Project Zero. The jury ist still out if it is possible to make a meaningul exploit on AMD CPUs (they also to indirect branching speculation, but in a completely different way, that currently seems unlikely to be actually exploitable.
This is in general not possible to patch in software.
It is actually pretty much patchable, the technology is called a retpoline. It's basically the compiler instructed to make special construct that cause mis-predicted branches to jump to an innocuous piece of code. But it's compiler-dependant, meaning that you need to have a source code to recompile. For the open-source world (like most of Linux distros), it's piece of cake, it's just recompiling the packages with different flags. For closed source Linux drivers (hello, nvidia), for binary linux systems (the thing that your smartphone manufacturer put on your device and refuses to upgrade since basically the day after it started shipping), and for any windows computer : that's a nightmare.
Good program design have nothing to do with this.
Good program design try to keep sensitive data and 3rd party provided scripts separated. That handles a lot of the Spectre v1 attacks.
It's not solving ALL the speculative execution problems tough. (it's doing nothing against Spectre v2 and Meltdown. But those are mostly due to lack of good *hardwware* design. Thanks again Intel !)
Because ALL news is fake With the near-zero journalistic integrity of all basically all MSM in America, the obvious problem for Facebook is whatever objective criteria you set for labelling "Fake News", you would include basically all MSM, and also including a lot of (if not all) advertising.
Seriously, the first step should always be to start by considering ANY NEWS as fake
Then you should be doing your due diligence :
- What is the source ?
- Is the source even actually stated or is a completely unsourced post ?
- If you follow the source trail, do can you go back to a primary source ? Or are you stuck in an endless loop of clickbait/internet meme/etc. cheap websites citing each other ?
Further, regarding sources :
- is the image actually relevant to the article, or is some old or unrelated photo that the article attempts to use to excite an emotion and google image search reveals that it has nothing to do with the subject (e.g.: illustration use to make you thing that people are "behaving like animals and opportunistic thieves" during a natural disaster, actually doesn't date back from the disaster and wasn't even taken in the area).
- Is the primary source actually contactable (e.g.: the initial article sites some officials. Are they named, can you reach them out for a comment)
Also you could consider some heuristics :
- Is the title giving out some information "Study find that 10% of population does bla" ? or is it the usual 100% emotion and 0% data click bait "10 things that will save your life, you won't believe when your see number 7 !" (Warning it's a heurisitc, but a very good one to eliminate ton of crap from your feed)
- Is the information coming from a reputable newspaper (Again, it's just a heuristic. Even big newspaper make mistakes, and even serious people can be wrong. So don't trust them blindly, it's only a heuristic when you're in a hurry - But at least the more serious newspaper will usually put some effort to publish retractions, corrections, etc.)
- Prefer offline media (newspapers) which have time to do some more in-depth analysis, or written on-line media that doesn't rely on ads for survival (They don't have such a high incentive to attract clicks to survive). Be really wary of TV (their business model is trying to attract your attention to have more eyeballs to sell to the advertising network. Being fast and catchy is more important to them than being right. Avoid heavily ad-sponsored websites at all costs. (It's just a heuristic, but some people have no strong incentive in telling you the truth)
- And last but no least : If you heard about it in the news, don't panic. It's just something new, they are called "news" for a reason after all. It's probably more a freak accident that gets overblown than an actual menace.
And the intent I was having with my common : "We know for an extremely long time that fast displays and high precision tracking are absolutely key points so people don't suffer from nausea. 10 years ago we were already been achieving better on that front that this cheap VR headset"
Yes, my old equipment did cost a lot a decade ago. Because they tried to achieve this spec with tech that was available to them in 2005.
But a decade later, if we absolutely try to stick to at least this level of nausea-prevention, we could possibly come down to something that cost a tiny bit better (say 300$) but is vastly better.
(Also, Occulus GO needs to be configured using a smartphone connected to it (so add it to the price) and works over wifi (so add the price of the router too, while you're at it), just pointing out~~;-) )
I don't really see why people are so against to hashes that they need to shout.
My main reason was for commically over-exagerated "hysteria".
The actual reason why people are against hashes, is a combination of three factors :
Brute forcing:
The computational power has vastly increased recently. Noticed the "Tera hash" that bitcoin ASIC miner have been advertising ? That's trillion of SHA256 hashes computed by second. GPU and FPGA are widely available and are good at brute forcing millions, perhaps billions of hashs per second.
We humans suck at picking passwords. You don't need to actually scan the whole vast 256bits space (would be difficult to achieve before end-of-life of our solar system), you can scan a few million of the most popular password and variation there of and/or scan password patterns(*)
So guessing passwords out of (fast) hashes is completely doable for anyone with a little bit of ressource (paying a tiny sum to rent GPUs on the Cloud).
Big data bases leaks: Just have a look at http://haveibeenpwned.com/ . Very often (though not always), attacker manage to get the password hashes. If you've been using a fast hashing function like SHA, guessing a significant proportion of the passwords is largely possible (like the point 1. above) at the cost of some GPU cloud-renting.
Password reuse: we human are stupid and tend to reuse passwords. Once you managed to successfully guess a password from point 2, you can try to see if it unlocks the e-mail account associated with the account in the database, or any other account you can find online associate with the same email and/or username and/or real identity (depending on what the leaked db provides to you).
That last one gives you tons of social engineering and identity theft/impersonation possibility to "profit!!!" from. So you can guess it is something that could happen in the wild.
--- (*) -- (when asked to follow password rules, humans will generally put the capital letter at the beginning, use 5-to-6 letters, then put 2-to-4 numbers, and the special at the end, most of the time it will be "!". The number of combination that follow this rules is vastly smaller than what "[A-Za-z0-9_!#@-]{8,16}" would imply)
Yes, bcrypt and similar are better and should be used. But I'd consider a hash, if properly used, still reasonably secure.
The vast difference is that bcrypt, scrypt and argon2 are on purpose designed to slow down bruteforcing and make FPGA and ASICs difficult (by using lots of iterations, and by requiring lots of memory)
The point 1. from the list above doesn't hold true anymore, so if the KDF's hash get laked in point 2. you can't gain much from them.
By properly used I mean hash(hash(password + salt) + salt), where + stands for concatenation. Even better if it has some concatenated pepper, too.
You don't even need to remember that formula if you remember the letters "hmac"...
For a typical/. geek who :
- generated purely random string from/dev/random+base64 (good luck using patterns or common password lists on that !)
- and uses 1 different password for each typical site (no password reuse) ( - and uses a secure password manager to keep them organised)
- and has activated 2-factors-auth (like Google Auth) on each website that supports it (so even if a password is somehow guessed correctly by shear luck, it's not useful on its own).
Yup, salted hashes are good enough.
For the rest of normal the humans, the 3 points I've listed above a re a real danger.
I'm just pointing out that the thing they cut back on (refresh rate/transition speed of LCD, lower quality tracking) are the exact cause of motion sickness and headache in VR.
To take the matephore of Ars Technica : Yes, like the author mentions, it's like back at the beginning of MP3 player (back when they were expensive due to the HD drive inside), there were a few Asian no-name who thought about slapping a cheap MP3-decoding chip on a cheap portable CD-player. Result: a device that can play MP3s, but is cheap and you can store a ~10h long playlist by burning a cheap CD.
But there's metaphorically a risk that users confuse the short coming of the MP3CD player (CD skpis, a scratch killing a whole MP3 song, etc) and think that MP3 in general sucks as a technology.
Here, there's a risk that simple consumer pick-up the Go, get motion sickness and decide that Virtual Reality isn't for them or isn't even a promising technology.
With the design of the Go, Occulus/Rift wants to reach a much wider audience than with their flagship Rift. But the wide public is very often put off by the headache/motion sickness (see most frequent / most vocal complain anytime stereo 3D is brought up as a technology). And the Go, by cutting the specific corner it cut to reach a 200USD price point will exacerbate these problem.
PBKDF2 uses SHA-variants in it iteration. Despite "Shattered", it's not "broken" yet.
There are just better more modern KDFs (like the Bcrypt used by Github, like the Scrypt designed for use in tarsnap, or like Argon2 which is the latest competition winner) that don't have PBKDF's short comings (e.g.: collision of long input pass phrases and their SHA-1).
Regarding : "Shattered" you have to understand its context. SHA-1 has known to be not as secure as it could be (a 128bit SHA-1 has not 128bits of security) for quite some time. (The main reason why SHA-2 was developed and is now widely used in cryptography, and a partial reason why SHA-3 got recently developed-though-competition (the other reasons being that SHA-3 / Keccak also introduce some novel interesting concepts) ).
Because of this it was widely speculated that collision could be found. A team of security research spent massive resource (lots of computation time) to search for collision (not brute forcing the whole 128bits space of sha-1 - which would be hard in any reasonable time -, but cleverly exploiting the above known limitation and vulnerability of sha-1). After spending a considerable amount of time they managed to create two different blocs of (complete non-sense random) data that happen to hash to the exact same value. It's not that they can generate collision at a whim, they can generate collision at a tremendous computational cost (but still an achievable cost - unlike the whole 128bits search space), and thus far managed to generate exactly 1 such collision.
Also due to the block-iterative way SHA (And most other pre-SHA-3 hashes) operate, it means you can stick this block in a file in a specific way, and get the same hash as if you stuck the collision in the other wise same file.
That limits severly the possible uses of this collision. You need a situation where you can store arbitrary noisy binary data, and have a program that can react to the presence of one or the other piece of data.
Currently, the only successful demo of Shattered is in a PDF file, because PDF can store arbitrary blobs (e.g.: used to storing bitmap data for illustrations, fonts, etc.) and the PostScript language used in PDF is Turing-Complete (some people are even writing ray-tracers written in post-script). So you can craft a special PDF that hashes to the same SHA-1 sum, but whose PostScript will generated two different document, depending on which of the two collision block is stored in the blobs.
It's pretty limited in practical use.
In PBKDF, it means that you can have two long passphrases, that will generate the same SHA-1 on the first round of PBKFD2 (so you have a tripple collision : both long passphrase containing the 2 blocks of Shattered, and their SHA-1 sum)
But the exploitability of such a solution is quite limited (complex scenarios like an oracle giving passwords, and Eve secretely colluding with the oracle, so the oracles gives two provably different password to Alice and Eve (e.g.: if they compare the SHA256 or SHA3 of the passwords, they are different), but Eve can use her password to unlock Alice's stuff. And vice versa).
So : TL;DR: Shattered isn't affecting PBKDF2 directly that much, but people have moved to more modern KDFs anyway, because they are better.
So how is this "random salt" recovered when you need to check the password's validity?
It's stored along in the data base. Most stored password have a form like :
${type of algorithm used}${parameters used}${data}
where: - "type of the algorithm used" tell you what was used to generate this (e.g: using Bcrypt, like GitHub as mentioned in the summary). - "data" is the actual salted-output that you need to replicate to successfully log-in - "parameters" is any extra-data that the algorithm needs to generate password checks. Like the salt. Or like the number of iterations. Because nobody sane actually use a hash function such as SHA512 anymore. Instead you use a Key Derivation Function (KDF) such as Bcrypt (or Scrypt or Argon2) and those are *slow* on purpose, to make brute-forcing much less likely (e.g.: they slow down by repeating a hash for large number of iterations).
The exact implementation vary (the above is typically used by the "crypt" function used, e.g., on Linux log-ins), but basically are the same : the salt (and iterations) are stored together with the "hash" that you need to test.
And most of the KDF function can work as "hash_to_compare = KDF(password_login_attempt, old_hash_from_database)", ie.: they can automatically extract the parameters if you give them the string that is in the database, and generate the hash the exact same way. They'll invent a new salt (and guess the optimal number of iterations) only if you omit the old hash and give the new password as the single parameter.
you feed the string and the salt into an encryption algorythm like sha512 which produces a HASH this is what gets stored
Argh! No! NO!!! NO-NO-NO-NO!!!! DO NOT USE HASHES ! (like Sha512).
These are designed to be *fast* (1), meaning that it could be not impossible for an attacker to guess the password out of the hash simply by brute forcing all the most common password and variations thereof into the same salt and see if they match.
(1 - And remember that the "tera hash" that ASIC bitcoinminer are reporting are exactly that : trillion of SHA256-like computation per second.)
USE KEY-DERIVATION FUNCTIONS (KDF) INSTEAD !
Like the Bcrypt use by github as mentionned in the summary. Or Scrypt (same used by tarsnap). Or Argon2. etc. These also produce a value out of a password and a salt, but they are on purpose extremely slow (E.g.: by repeating a hash function over and over for a high number of iteration). If each computation takes some time, it doesn't impact login that much (After all, you only need to log in once at the beginning of your session), but it hinders anyone wanting to brute force your password out of a stolen hash.
It makes data breaches that managed to steal your user database a lot less dangerous (because once you have successfully guessed the password from the hash, the next step is to see all the other places where the user has re-used the same password).
But headaches and motion sickness are everything, at least if you want a product with wide mass appeal among the general public.
You want the headset to display something that is as close as possible as the motion sensed by the user while moving the head around.
That means the best head tracking you can get. This has been studied for as long as VR headsets exist. The expensive headsets use IR+camera tracking to be extremely fast and reactive and precise as possible.
That also means a very fast display: as high FPS rate as possible, and individual frames that blink for the shortest time possible (think CRT phosphor blink vs. LCD's crystals slowly changing configuration). Occulus has done a lot of research themselves about that. The expensive headsets use OLED because of that. It can have very high framrates, and each frame can "blink" for a very short delay.
This devices cuts back on the motion tracking, and uses cheaper LCD with slower frame rate and longer frame remanescence. That will worsen the exact kind of problems that VR has that prevents wide public adoption and that normal users are complaining about (headache and motion sickness).
Regular users aren't aware of all the small details going behind a good VR implementation. They'll see the cheap headset, pick it up, try it, get headache/motion sickness and think that "yeah, VR definitely doesn't work" and VR will again lose general interest and marketability because of that.
Cheap headsets as this (and cardboard solutions, depending on the screen of the smartphone you drop in and the software running on it) are best used only for 3D stereo cinema movie (where there is no tracking involved).
(DISCLAIMER: I happen to be lucky and *not* affected by motion sickness that much. So it's not a personal attack against VR. But if you want to reach a wide audience, you need to address the problems that most users are complaining about, and this product is a step backward compared to other facebook/occulus product).
Really? You have one with a > 538ppi screen that's almost a decade old?
By some random chance it happens that, yeah, about three time this resolution. But it's not relevant actually.
PPI (points-per-inches) are (nearly) irrelevant in headset for the resolution. What's relevant and of key important:
- the field of view (the total angle that the screen cover in front of view).
- the angular resolution (number of pixels per degree of angle). Yes, on modern headsets, the display is achieved usually by using a smartphone screen, so you can take a short cut and compare the screen resolution and basically have a comparison. That wasn't the necessarily the case a decade ago.
So my headset happens to use display that completely beat the crap out of anything on the market now, with somewhere around 1600DPI. But that's that because they are tiny screens to begin with : each eye has a micro OLED display that's about a square milimeter, and offers a 852x600 resolution which the optics make cover ~40 degree of FOV. That was very impressive 10 years ago, but probably pales in comparison in what smartphone-screen-based headsets are doing now (or what the same company is doing now with 2k x 2k micro-OLED displays).
But resolution isn't what I was talking about.
What headset is that?...and how much did it cost?
eMagine z800 3D Visor, I managed to grab one during the short launch promotion where it sold for 600-700$ (normal price was twice that).
I suspect you're not talking about an even remotely comparable device here.
The device is based around a much older and much more expensive approach to headsets (using expensive custom made micro OLED. But they were mainly making devices for military use so it was worth for them. The z800 was just them making their port-folio diverse by adding some civilian products. They also use high quality complex optics to make the screen appear flat) than what is used today (use cheap off-the-shelves display like those mass-produced for smartphone, use a simple lens and compensate the distorsion in (GPU shader) software).
But it's comparable for 2 specific points.
- display refresh rate and persistence
- tracking
- my old gear used on purpose OLEDs, because they can go up to 85Hz (that was incredibly impressive back then) and can keep display for very short time (as soon as you cut the power, the pixel goes immediately dark). - most modern headsets (Occulus Right, HTC Vive, etc.) use OLEDs. They can go even higher max display rate, and again can "blink" their display for very short time. - this thing uses LCD. It's max refresh rate is a pale 72Hz which is *very* low for a VR headset. and LCD are slow to transition between one state and another (compared to OLED or even old tech like CRT. Of course if you compare them to even older pre-TFT LCD, they are a lot less blurry nowadays).
- my old gear used the best accelerometers they could get access to a decade ago- - most modern headests have even better tracking than that, mostly relying on IR+camera-based tracking. - this thing has dialed back the tracking a lot.
To roll back to the main subject of my comment: kinetosis (sea sickness, VR-induced nausea, etc.) are caused by discrepencies between the motion you see with your eyes and the motion you feel with your inner ear (balance). You want your headset to display a picture as close as possible at what the user would be seeing given the current head position as possible, to minimize the risk of getting headache and motion sickness.
That's why you want OLEDs: - you want a frame rate as fast as possible to update as best as possible what the eyes should be seeing. This requires a high frame rate. This cheap
The printer ports or the ISA bus on your old computer that is gathering dust in a corner of your basement are true parallel connection: Each bit of a 8bit byte is traveling in parallel in a neighboring conductor.
(But this would be a technical nightmare on modern speed used in modern system, as you'd need to make sure that all the bits arrive at the exact same time in perfect unison at the destination. lenght of conductor and speed of light/speed of electricity in a medium start to matter a lot. See the complicated squiggly traces between DIMMs and memory controllers to make sure that the path takes the exact same amount of time. That's why it's being abandoned in modern buses)
DVI, SATA-Express, PCI-Express, USB 3, etc. have all multiple conductor, but they are all in essence still serial. Each bit of a word is travelling one after the other in the same conductor. And the above standard just happen to have multiple serial-links that can be used concurrently : the system can send multiple data packet more or less at the same time, each sent serially along a different line. (And in the cases of standards such as PCIe, the various serial links might not be even talking to the same device).
Unlike the parallel situation, you do not need to make sure that the bits travel in unison down different conductors : each serial link is sending different data packets, they can arrive with slightly different timing.
(Basically, is like plugging 2 network cables in 2 ports of the same server using link aggregation. You didn't suddenly turn ethernet into a parallel bus, you just have more interfaces to spread the load of sending your packet over).
So no. Latest iteration USB are still serial. They can just have more independent serial-links used concurrently, but the bits still travel one after the other on the same link, the other link is used to send a different data packet concurrently)
At best you could invent a new term like "multi-serial" or "concurrent serial".
You seem to think that producers/engineers will create two cuts of a recording - one with heavy compression for digital, and one unrestricted for vinyl. How quaint!
Doe *all* engineers ? It's very likely:*NO*.
Do *some* studio make an new mix for vinyl ? Some will. And that contributes to the myth that vinyl sounds better.
(The sound *currently stored on this vinyl* does indeed sound better than the sound *currently stored on that CD*. By conscious choice of the engineer doing the corresponding mix.)
Or it might be attempt to transfer the kind of considerations that already happen between domain-squatters and trademarks.
But adapted to Geographic Indication instead of brand-names (which is really *serious business* in France. They were the first country to have official law in place for GI with their AOC - "Appellation d'origin protégée")
In other way, just as some random schmuck shouldn't be allowed to register "coca-cola.com" (it's a protected trademark) even if it's a fan page and forum that serves as a gathering place for the brand's fans, some random schmuck couldn't use specific Geographic Indications in their webdomain (exactly as they couldn't use that GI in their business name) if they don't follow the requirement for said GI (usually : growing and processing your product in the region named in the GI).
Or it might actually be a case of "Geographic Indication" ?
The European continent has a complex system of laws defining which names of places can be used by commercial entities. France is about the oldest country with such law systems (the AOC - Appellation d'origine controlée). You can't arbitrarily call you wine "Champagne" if it's not actually produced in the Fench region of Champagne. (Which by it self gave rise to tons of other problems as, e.g.: there's a region of Switzerland which also happens to be called Champagne and happens to produce (completely different, non-sparkling) wines as well). See it as a sort of "trademark" law, but for geographic names, instead of brand names.
I haven't bothered to check the french court ruling, but I wouldn't be surprise if it was done in that sense (that there are precise "GI" criteria defining whether a comp can use "France" in their name).
Of course, then the simplest course of actions for Frydman would be to re-register a "France" domain at a registrar in some country that doesn't follow any treaty regarding GI. (China ?)
I'm glad to be rid of hiss, pops, scratches, wow, flutter, 5% total harmonic distortion, stretching, rumble.
You can gladly exchange them for saturated over-loud mix, where your equalizer's "frequeccy analyser display" has all the display bars permanently stuck to the top, with frequent pops and clicks due to range-clipping.
(More seriously, there is a key difference :
- Vinyl's defect come from limitation (and fagility) of the medium.
- CD's biggest problem come from the idiot at the mixing table who tries hard to get more attention by attempting at being louder than the others
But these defect might be also a reason to why people might try to avoid digital media : not because inherent flaws, but because they are fed up with the type of mixing that ends up being done on those media.)
A regular 44khz audio CD can't capture the full resolution of a digital master done at e.g 96khz.
The thing is, human ears can't capture it either. Physics/physiology has a nasty habit of popping in the way.
More seriously, there's a point in the digital domain (basically when it has reached and overtaken the limitation of the human ears you're targetting) beyond which you can consider the sound perfect and all the problem coming from the medium. And as you point out:
But imperfections in the medium are more likely to cause differences you can actually hear.
(Perfect: it's not actually. But unless you have a few bats and dolphins that managed to hide among your public, you can ignore safely the difference).
(Also, hoping that the digital to analog conversion isn't horribly distorted).
Mikrotiks, on the other hand, as easy to re-install with a good opensource firmware (like OpenWRT/LEDE, etc.). Same with tons of cheap chinese routers (though not all have enough flash/ram to support all features including filesharing over IPv6, at least they can have good basic router functionality).
The same cannot be said for Apple's hardware.
- 3rd party firmware has always been difficult.
- apple discontinuing them means no way to get a 1st party secure firmware either.
On some brands of router, the default password isn't something simple (like "admin"), but each device has a random string generated as a default password and wifi, just as each device has its own serial number (it might be that one is generated from the other on-device), with those printed out on same sticker as the serial number on the box it self (there is no default password in the manual, as there is no series-wide password) so in an emergency you can reset to these long random default.
Slashdot Mirror
NASA's big argument is that the former (rocket goes boom while fuel-loading) is much more likely than the later (a rocket that has proven to go boom during/immediately after fueling suddenly goes boom at a later point in time, while the astronauts are on their way, but not already installed into something that can serve as an emergency escape) - ie: fueling in particular is making them extremely nervous compared to any other step.
SpaceX' argument is that the escape mecanism is good enough to make the actual impact of a boom-during-fuelling negligible - ie they have quite some crazy trust into their capsule's escaping performance.
I fail to see any difference between "load it up with propellant at super-cold temperatures to shrink its size" and "load it up with liquid hydrogen and liquid oxygen", where, as far as I know, manned rockets have been loaded that way since the Apollo missions.
Think liquid mercury changing density (and thus size occupied in the thermometer's tube) depending on the temperature.
Since the Apollo missions, liquid hydrogen and liquid oxygen are made liquid by cooling them just barely enough to make them liquid, just below their freezing point.
The big advantage is that, even if it's cooling, it's not cooling *that* much. The rocket can then basically stay waiting for some time (well a tiny bit is going to boil of, but you can top that tiny bit at the last moment, by adding more liquid).
The SpaceX way is to cool the liquid *much further*. You're not just cooling them "a bit" to make them liquid, you cool them as much as physically possible in your system.
Because you cool them to much colder temperature, they are much dense. You can fit much more such super-cooled fuel in the same tank than if it were merely "chilled enough to be liquid" fuel.
The draw back is that once loaded, you have to take off as fast as possible. Otherwise you'll eventually loose any advantage of your super-cooled/super-dense fuel as the temperature will eventually rise (less dense fuel : suddenly occupies at lot more space. It will either flow out, boil out, or you'll bust the tank if there's no way to get of the sudden extra volume).
You could top up any boiled-off fuel at the last moment, but you cannot regain any of the higher-density unless you magically re-cool the whole tank's worth of fuel.
In NASA's experience, the most dangerous moment is the moment you're loading the fuel in.
- With the Appollo style, the point is to do the dangerous fueling first, when there's nobody in the dangerzone around the rocket.
Only then, once the dangerous phase is over and the whole thing is a bit more secure now, you take the necessary time to load your payload (passengers here).
Then top-up the boiled-off and go.
- With SpaceX, the payload need to be loaded first (the astronauts needs to be already in the capsule), because you can't afford much wait time between the fuel loading and the take off (remember, the more time pass, the more the temperature rises, the less super-cooled/denser you fuel is).
So during the most dangerous phase, during the fueling there are already people (the astronauts) in place.
SpaceX's mitigation is that by that time, they are already well installed in the capsule, so the capsule should be able to evacuate them to safety if anything goes wrong.
NASA's opinion is that this is unnecessary risk taking just to shave off a few more fuel by having it at a lower-than-apollo temperature.
That's why a few law needs to be passed, e.g.: limiting the price of such re-sell to the exact price at which the ticket was bought.
(France has such laws).
Other wise you can bet that the "TicketMaster-approved second-hand market" will reimburse the original owner the price of *original* ticket (minus a fee) and will bill the new user the *current price* of the ticket (plus another fee), and the second hand marker owners (and their shareholders... Ticket master) will pocket the price difference and twice the fee. It's not going to be as such high profit as ticket scalpers who try to resell desirable rare tickets for 10x the price, but it will be a guaranteed revenue stream (tons of people can have a last minute change of plans).
The way I've seen it implemented, ID is used as a fallback.
When the QR-code / Barcode is rejected at the gate, two scenarios :
- some con artist used that code to generate a false ticket and managed to enter first into the premise, and the ticket S/N is marked as "already used". Too late to find out who's the cheater, but at least you can use the ID and verify the legitimate customer and let them in.
- the legitimate customer already went in with this barcode/QR-code first. The person refused at the gate has a counterfeit ticket that re-uses the code from the legitimate user. The person will also fail the ID check (the ID in the database is tied to the legitimate user's ticket S/N). You can safely refuse access to the user.
So in term of your exemple, you aren't adding 270 hours total of checks spread among the ~60-80 people manning the gates.
You'r only adding 10s x the number of time the system reports "Ticket S/N already used to enter the event", so only for the ticket cloning counterfeit attempts-
It's not as robust as checking every single person entering the event, but at least :
- the legitimate owner can always enter the event, no matter what
- at most 1 single counterfeit clone-ticket holder can manage to get in with a given serial number befire the system notices and require ID checks for the same ticket.
---
This is usually coupled with another details (I've mostly seen in France) :
Event organizers and/or ticket provider, makes it mandatory to use a specific web platform to sell tickets second hand.
- This platform forbids to sell second hand ticket at a higher price than the official ticket price. (It avoid scalpers)
- This platform can track change of ownership for the organizers/ticket providers. Whenever a ticket is resold, the database can be updated to match the new legitimate owner (the S/N of the ticket can even be changed so that the older barcode isn't valid anymore), and the new owner is issued a new PDF that they can print that contains an update QR-code/barcode.
---
That requires a tiny bit of infrastructure (basically servers holding the database mapping who is the valid owner of a ticket, and what is the latest S/N on said ticket).
And blockchain is typically the kind of technology that can do decentralized ownership tracking - so no infrastructure but a distributed ledger.
But it's probably overkill. I haven't seen a barcode server failing on the day of an event yet, all the e-ticket have always been working as expected.
(But you can count on France that one day one critical person in this system is going to be on strike, and the system will be non-functional)
This law requires the ban of selling such hybrids by 2040.
There are lots of different models of cars currently sold in 2018 that already have better batteries than that (I'm not only speaking of Tesla, I'm speaking about the Renault, Nissan, VW, Citroen, etc.)
Non plug-in hybrids where an interesting stop-gag measure back at a time when everybody was heavily relying on an existing infastructue/logistics for gaz, when battery were still small, and there was virtually no chargers infrastructure.
But plugin to charge your car's battery while it's not in use is definitely the long term target to go to.
By 2040, probably all car will be able to do well more than 100km at least, with maybe some still featuring gaz-powered range-extenders for the few occasions when people need to drive for prolonged distance without ever seeing a charger. (e.g.: using their cars to drive in remote/backwards area where ubiquitous public chargers aren't yet a thing, the gaz station are still the most common energy delivery, and the user isn't interesting in fork whatever the cost of a 200-200hWh battery will be by then).
The Society of Motor Manufacturer are only panicking because some of their members are realizing that they are left with lots of soon-to-be-dead assets (stock, manufacturing capacity, etc.).
Most sane car manufacturers have started thinking about this for quite some time, and will probably be more-than-ready by 2040.
If you can load the dishwasher, you can also press a button to start it.
But, the next logical question is "what if you don't want to start it now, but in the morning" (because you don't want to noise to wake anyone up in you tiny apartment, nor your neighbors across the thin walls).
So most company put a "delay before start" setting (which by itself isn't a stupid idea).
But that the exact point where things start to roll down hill, because the "delay" implementation might not be that good. /.er)
- It's not intuitive user/friendly (requires weird button completion)
- It requires the time being set (cue in "Blinking 12:00" for anyone who isn't the typical
etc.
Which usually end ups with a company having a "brilliant !" (ahem...) idea :
Let's make an App for it (because for 99% of normal population outthere, smartphone is something that they are used with and which is intuitive for them).
Which immediately jumps to the last horrible point :
Let's make the app web-enabled/cloud-hosted/whatever, so the user can start the dish washer from outside home if they forgot to put the delay timer for the morning.
Cue in all Asian no-name cheap companies seeing a new selling point on the feature bullet list and deciding to clone this feature. Poorly. (But extremely cheaply).
And that's how you end up with internet enabled dishwashers and fridges with pointless cloud-feature that barely anyone actually needs, but which are a giant security nightmare.
Meltdown can be totally protected against in software however with a significant performance impact.
It is patched, by completely changing the way kernel works and not relying on memory protection anymore. Thank you very much, Intel !
Instead you need to context switch and make important kernel parts inaccessible on each system call.
(PCID is something that helps a bit the context switching : you don't actually flush the whole context, you use different process tags so the differently tagged process cannot be seen anymore).
Spectre can be divided into two kinds of attacks:
. One kind that bypass protection checks (range checks etc.) used to create software based virtual machines. These can be protected against in software.
Specifically, relying on by-passing any check (such as a boundary check on an array). It's ABSOLUTELY NOT virtual-machine specific.
The thing is, it's still the same process, still reading data that it has access to, to begin with (unlike Meltdown which basically fucks up any notions of memory protection). So its usability is limited to processes that both can run 3rd party provided code and contain critical data (i.e.: a badly designed webbrowser that runs web-provided javascript and its password manager both in the same context) (or another example: the Linux kernel's new-gen PacketFilter can be optionally configured to JIT compile the user-provided filtering scripts. USer-provided code in a kernel context, what could possibly go wrong ? Hint: There's a reason why it's not "on" by default).
But basically, most of the cases can be handled by keeping sane design pattern in software.
One kind that use shared branch prediction state between an attacker and a victim to influence speculative execution when running the victim code, this can be used to extract data that can be exfiltrated through a shared cache.
Which means that an attacker could be a userland software running on the cloud, and target could be the hypervisor itself. Which is several levels of scarry.
But this thing also requires very detailled knowledge of the internal of the CPU.
It has been successfully exploited on Intel Xeon by Google Project Zero.
The jury ist still out if it is possible to make a meaningul exploit on AMD CPUs (they also to indirect branching speculation, but in a completely different way, that currently seems unlikely to be actually exploitable.
This is in general not possible to patch in software.
It is actually pretty much patchable, the technology is called a retpoline. It's basically the compiler instructed to make special construct that cause mis-predicted branches to jump to an innocuous piece of code.
But it's compiler-dependant, meaning that you need to have a source code to recompile.
For the open-source world (like most of Linux distros), it's piece of cake, it's just recompiling the packages with different flags.
For closed source Linux drivers (hello, nvidia), for binary linux systems (the thing that your smartphone manufacturer put on your device and refuses to upgrade since basically the day after it started shipping), and for any windows computer : that's a nightmare.
Good program design have nothing to do with this.
Good program design try to keep sensitive data and 3rd party provided scripts separated.
That handles a lot of the Spectre v1 attacks.
It's not solving ALL the speculative execution problems tough. (it's doing nothing against Spectre v2 and Meltdown. But those are mostly due to lack of good *hardwware* design. Thanks again Intel !)
Because ALL news is fake
With the near-zero journalistic integrity of all basically all MSM in America, the obvious problem for Facebook is whatever objective criteria you set for labelling "Fake News", you would include basically all MSM, and also including a lot of (if not all) advertising.
Seriously, the first step should always be to start by considering ANY NEWS as fake
Then you should be doing your due diligence :
- What is the source ?
- Is the source even actually stated or is a completely unsourced post ?
- If you follow the source trail, do can you go back to a primary source ? Or are you stuck in an endless loop of clickbait/internet meme/etc. cheap websites citing each other ?
Further, regarding sources :
- is the image actually relevant to the article, or is some old or unrelated photo that the article attempts to use to excite an emotion and google image search reveals that it has nothing to do with the subject (e.g.: illustration use to make you thing that people are "behaving like animals and opportunistic thieves" during a natural disaster, actually doesn't date back from the disaster and wasn't even taken in the area).
- Is the primary source actually contactable (e.g.: the initial article sites some officials. Are they named, can you reach them out for a comment)
Also you could consider some heuristics :
- Is the title giving out some information "Study find that 10% of population does bla" ? or is it the usual 100% emotion and 0% data click bait "10 things that will save your life, you won't believe when your see number 7 !"
(Warning it's a heurisitc, but a very good one to eliminate ton of crap from your feed)
- Is the information coming from a reputable newspaper
(Again, it's just a heuristic. Even big newspaper make mistakes, and even serious people can be wrong. So don't trust them blindly, it's only a heuristic when you're in a hurry - But at least the more serious newspaper will usually put some effort to publish retractions, corrections, etc.)
- Prefer offline media (newspapers) which have time to do some more in-depth analysis, or written on-line media that doesn't rely on ads for survival (They don't have such a high incentive to attract clicks to survive). Be really wary of TV (their business model is trying to attract your attention to have more eyeballs to sell to the advertising network. Being fast and catchy is more important to them than being right. Avoid heavily ad-sponsored websites at all costs.
(It's just a heuristic, but some people have no strong incentive in telling you the truth)
- And last but no least : If you heard about it in the news, don't panic. It's just something new, they are called "news" for a reason after all. It's probably more a freak accident that gets overblown than an actual menace.
And the intent I was having with my common :
"We know for an extremely long time that fast displays and high precision tracking are absolutely key points so people don't suffer from nausea.
10 years ago we were already been achieving better on that front that this cheap VR headset"
Yes, my old equipment did cost a lot a decade ago. Because they tried to achieve this spec with tech that was available to them in 2005.
But a decade later, if we absolutely try to stick to at least this level of nausea-prevention, we could possibly come down to something that cost a tiny bit better (say 300$) but is vastly better.
(Also, Occulus GO needs to be configured using a smartphone connected to it (so add it to the price) and works over wifi (so add the price of the router too, while you're at it), just pointing out~~ ;-) )
I don't really see why people are so against to hashes that they need to shout.
My main reason was for commically over-exagerated "hysteria".
The actual reason why people are against hashes, is a combination of three factors :
So guessing passwords out of (fast) hashes is completely doable for anyone with a little bit of ressource (paying a tiny sum to rent GPUs on the Cloud).
Just have a look at http://haveibeenpwned.com/ . Very often (though not always), attacker manage to get the password hashes. If you've been using a fast hashing function like SHA, guessing a significant proportion of the passwords is largely possible (like the point 1. above) at the cost of some GPU cloud-renting.
we human are stupid and tend to reuse passwords. Once you managed to successfully guess a password from point 2, you can try to see if it unlocks the e-mail account associated with the account in the database, or any other account you can find online associate with the same email and/or username and/or real identity (depending on what the leaked db provides to you).
That last one gives you tons of social engineering and identity theft/impersonation possibility to "profit!!!" from. So you can guess it is something that could happen in the wild.
---
(*) -- (when asked to follow password rules, humans will generally put the capital letter at the beginning, use 5-to-6 letters, then put 2-to-4 numbers, and the special at the end, most of the time it will be "!". The number of combination that follow this rules is vastly smaller than what "[A-Za-z0-9_!#@-]{8,16}" would imply)
Yes, bcrypt and similar are better and should be used. But I'd consider a hash, if properly used, still reasonably secure.
The vast difference is that bcrypt, scrypt and argon2 are on purpose designed to slow down bruteforcing and make FPGA and ASICs difficult (by using lots of iterations, and by requiring lots of memory)
The point 1. from the list above doesn't hold true anymore, so if the KDF's hash get laked in point 2. you can't gain much from them.
By properly used I mean hash(hash(password + salt) + salt), where + stands for concatenation. Even better if it has some concatenated pepper, too.
You don't even need to remember that formula if you remember the letters "hmac"...
For a typical /. geek who : /dev/random+base64 (good luck using patterns or common password lists on that !)
- generated purely random string from
- and uses 1 different password for each typical site (no password reuse)
( - and uses a secure password manager to keep them organised)
- and has activated 2-factors-auth (like Google Auth) on each website that supports it (so even if a password is somehow guessed correctly by shear luck, it's not useful on its own).
Yup, salted hashes are good enough.
For the rest of normal the humans, the 3 points I've listed above a re a real danger.
I'm not criticizing the picture quality.
I'm just pointing out that the thing they cut back on (refresh rate/transition speed of LCD, lower quality tracking) are the exact cause of motion sickness and headache in VR.
To take the matephore of Ars Technica : Yes, like the author mentions, it's like back at the beginning of MP3 player (back when they were expensive due to the HD drive inside), there were a few Asian no-name who thought about slapping a cheap MP3-decoding chip on a cheap portable CD-player.
Result: a device that can play MP3s, but is cheap and you can store a ~10h long playlist by burning a cheap CD.
But there's metaphorically a risk that users confuse the short coming of the MP3CD player (CD skpis, a scratch killing a whole MP3 song, etc) and think that MP3 in general sucks as a technology.
Here, there's a risk that simple consumer pick-up the Go, get motion sickness and decide that Virtual Reality isn't for them or isn't even a promising technology.
With the design of the Go, Occulus/Rift wants to reach a much wider audience than with their flagship Rift.
But the wide public is very often put off by the headache/motion sickness (see most frequent / most vocal complain anytime stereo 3D is brought up as a technology).
And the Go, by cutting the specific corner it cut to reach a 200USD price point will exacerbate these problem.
PBKDF2 uses SHA-variants in it iteration.
Despite "Shattered", it's not "broken" yet.
There are just better more modern KDFs (like the Bcrypt used by Github, like the Scrypt designed for use in tarsnap, or like Argon2 which is the latest competition winner) that don't have PBKDF's short comings (e.g.: collision of long input pass phrases and their SHA-1).
Regarding : "Shattered" you have to understand its context.
SHA-1 has known to be not as secure as it could be (a 128bit SHA-1 has not 128bits of security) for quite some time.
(The main reason why SHA-2 was developed and is now widely used in cryptography, and a partial reason why SHA-3 got recently developed-though-competition (the other reasons being that SHA-3 / Keccak also introduce some novel interesting concepts) ).
Because of this it was widely speculated that collision could be found.
A team of security research spent massive resource (lots of computation time) to search for collision (not brute forcing the whole 128bits space of sha-1 - which would be hard in any reasonable time -, but cleverly exploiting the above known limitation and vulnerability of sha-1).
After spending a considerable amount of time they managed to create two different blocs of (complete non-sense random) data that happen to hash to the exact same value.
It's not that they can generate collision at a whim, they can generate collision at a tremendous computational cost (but still an achievable cost - unlike the whole 128bits search space), and thus far managed to generate exactly 1 such collision.
Also due to the block-iterative way SHA (And most other pre-SHA-3 hashes) operate, it means you can stick this block in a file in a specific way, and get the same hash as if you stuck the collision in the other wise same file.
That limits severly the possible uses of this collision. You need a situation where you can store arbitrary noisy binary data, and have a program that can react to the presence of one or the other piece of data.
Currently, the only successful demo of Shattered is in a PDF file, because PDF can store arbitrary blobs (e.g.: used to storing bitmap data for illustrations, fonts, etc.) and the PostScript language used in PDF is Turing-Complete (some people are even writing ray-tracers written in post-script).
So you can craft a special PDF that hashes to the same SHA-1 sum, but whose PostScript will generated two different document, depending on which of the two collision block is stored in the blobs.
It's pretty limited in practical use.
In PBKDF, it means that you can have two long passphrases, that will generate the same SHA-1 on the first round of PBKFD2 (so you have a tripple collision : both long passphrase containing the 2 blocks of Shattered, and their SHA-1 sum)
But the exploitability of such a solution is quite limited (complex scenarios like an oracle giving passwords, and Eve secretely colluding with the oracle, so the oracles gives two provably different password to Alice and Eve (e.g.: if they compare the SHA256 or SHA3 of the passwords, they are different), but Eve can use her password to unlock Alice's stuff. And vice versa).
So :
TL;DR: Shattered isn't affecting PBKDF2 directly that much, but people have moved to more modern KDFs anyway, because they are better.
So how is this "random salt" recovered when you need to check the password's validity?
It's stored along in the data base.
Most stored password have a form like :
${type of algorithm used}${parameters used}${data}
where:
- "type of the algorithm used" tell you what was used to generate this (e.g: using Bcrypt, like GitHub as mentioned in the summary).
- "data" is the actual salted-output that you need to replicate to successfully log-in
- "parameters" is any extra-data that the algorithm needs to generate password checks.
Like the salt.
Or like the number of iterations. Because nobody sane actually use a hash function such as SHA512 anymore. Instead you use a Key Derivation Function (KDF) such as Bcrypt (or Scrypt or Argon2) and those are *slow* on purpose, to make brute-forcing much less likely (e.g.: they slow down by repeating a hash for large number of iterations).
The exact implementation vary (the above is typically used by the "crypt" function used, e.g., on Linux log-ins),
but basically are the same : the salt (and iterations) are stored together with the "hash" that you need to test.
And most of the KDF function can work as "hash_to_compare = KDF(password_login_attempt, old_hash_from_database)", ie.: they can automatically extract the parameters if you give them the string that is in the database, and generate the hash the exact same way.
They'll invent a new salt (and guess the optimal number of iterations) only if you omit the old hash and give the new password as the single parameter.
you feed the string and the salt into an encryption algorythm like sha512 which produces a HASH this is what gets stored
Argh!
No!
NO!!!
NO-NO-NO-NO!!!!
DO NOT USE HASHES ! (like Sha512).
These are designed to be *fast* (1), meaning that it could be not impossible for an attacker to guess the password out of the hash simply by brute forcing all the most common password and variations thereof into the same salt and see if they match.
(1 - And remember that the "tera hash" that ASIC bitcoinminer are reporting are exactly that : trillion of SHA256-like computation per second.)
USE KEY-DERIVATION FUNCTIONS (KDF) INSTEAD !
Like the Bcrypt use by github as mentionned in the summary. Or Scrypt (same used by tarsnap). Or Argon2. etc.
These also produce a value out of a password and a salt, but they are on purpose extremely slow (E.g.: by repeating a hash function over and over for a high number of iteration).
If each computation takes some time, it doesn't impact login that much (After all, you only need to log in once at the beginning of your session), but it hinders anyone wanting to brute force your password out of a stolen hash.
It makes data breaches that managed to steal your user database a lot less dangerous (because once you have successfully guessed the password from the hash, the next step is to see all the other places where the user has re-used the same password).
Realism isn't everything.
But headaches and motion sickness are everything, at least if you want a product with wide mass appeal among the general public.
You want the headset to display something that is as close as possible as the motion sensed by the user while moving the head around.
That means the best head tracking you can get. This has been studied for as long as VR headsets exist.
The expensive headsets use IR+camera tracking to be extremely fast and reactive and precise as possible.
That also means a very fast display: as high FPS rate as possible, and individual frames that blink for the shortest time possible (think CRT phosphor blink vs. LCD's crystals slowly changing configuration).
Occulus has done a lot of research themselves about that.
The expensive headsets use OLED because of that. It can have very high framrates, and each frame can "blink" for a very short delay.
This devices cuts back on the motion tracking, and uses cheaper LCD with slower frame rate and longer frame remanescence.
That will worsen the exact kind of problems that VR has that prevents wide public adoption and that normal users are complaining about (headache and motion sickness).
Regular users aren't aware of all the small details going behind a good VR implementation. They'll see the cheap headset, pick it up, try it, get headache/motion sickness and think that "yeah, VR definitely doesn't work" and VR will again lose general interest and marketability because of that.
Cheap headsets as this (and cardboard solutions, depending on the screen of the smartphone you drop in and the software running on it) are best used only for 3D stereo cinema movie (where there is no tracking involved).
(DISCLAIMER: I happen to be lucky and *not* affected by motion sickness that much. So it's not a personal attack against VR. But if you want to reach a wide audience, you need to address the problems that most users are complaining about, and this product is a step backward compared to other facebook/occulus product).
Really? You have one with a > 538ppi screen that's almost a decade old?
By some random chance it happens that, yeah, about three time this resolution. But it's not relevant actually.
PPI (points-per-inches) are (nearly) irrelevant in headset for the resolution. :
What's relevant and of key important
- the field of view (the total angle that the screen cover in front of view).
- the angular resolution (number of pixels per degree of angle).
Yes, on modern headsets, the display is achieved usually by using a smartphone screen, so you can take a short cut and compare the screen resolution and basically have a comparison.
That wasn't the necessarily the case a decade ago.
So my headset happens to use display that completely beat the crap out of anything on the market now, with somewhere around 1600DPI.
But that's that because they are tiny screens to begin with : each eye has a micro OLED display that's about a square milimeter, and offers a 852x600 resolution which the optics make cover ~40 degree of FOV. That was very impressive 10 years ago, but probably pales in comparison in what smartphone-screen-based headsets are doing now (or what the same company is doing now with 2k x 2k micro-OLED displays).
But resolution isn't what I was talking about.
What headset is that?...and how much did it cost?
eMagine z800 3D Visor, I managed to grab one during the short launch promotion where it sold for 600-700$ (normal price was twice that).
I suspect you're not talking about an even remotely comparable device here.
The device is based around a much older and much more expensive approach to headsets (using expensive custom made micro OLED. But they were mainly making devices for military use so it was worth for them. The z800 was just them making their port-folio diverse by adding some civilian products. They also use high quality complex optics to make the screen appear flat) than what is used today (use cheap off-the-shelves display like those mass-produced for smartphone, use a simple lens and compensate the distorsion in (GPU shader) software).
But it's comparable for 2 specific points.
- display refresh rate and persistence
- tracking
- my old gear used on purpose OLEDs, because they can go up to 85Hz (that was incredibly impressive back then) and can keep display for very short time (as soon as you cut the power, the pixel goes immediately dark).
- most modern headsets (Occulus Right, HTC Vive, etc.) use OLEDs. They can go even higher max display rate, and again can "blink" their display for very short time.
- this thing uses LCD. It's max refresh rate is a pale 72Hz which is *very* low for a VR headset. and LCD are slow to transition between one state and another (compared to OLED or even old tech like CRT. Of course if you compare them to even older pre-TFT LCD, they are a lot less blurry nowadays).
- my old gear used the best accelerometers they could get access to a decade ago-
- most modern headests have even better tracking than that, mostly relying on IR+camera-based tracking.
- this thing has dialed back the tracking a lot.
To roll back to the main subject of my comment :
kinetosis (sea sickness, VR-induced nausea, etc.) are caused by discrepencies between the motion you see with your eyes and the motion you feel with your inner ear (balance).
You want your headset to display a picture as close as possible at what the user would be seeing given the current head position as possible, to minimize the risk of getting headache and motion sickness.
That's why you want OLEDs :
- you want a frame rate as fast as possible to update as best as possible what the eyes should be seeing. This requires a high frame rate. This cheap
given the specs of that gadget, 2018 will mostly be the year of the cheap headache.
I have an almost-decade-old VR headset with specs better than that.
(the slow LCD causing motion blur combined with the limited motion tracking are going to be kill*ing* features).
The printer ports or the ISA bus on your old computer that is gathering dust in a corner of your basement are true parallel connection:
Each bit of a 8bit byte is traveling in parallel in a neighboring conductor.
(But this would be a technical nightmare on modern speed used in modern system, as you'd need to make sure that all the bits arrive at the exact same time in perfect unison at the destination. lenght of conductor and speed of light/speed of electricity in a medium start to matter a lot.
See the complicated squiggly traces between DIMMs and memory controllers to make sure that the path takes the exact same amount of time.
That's why it's being abandoned in modern buses)
DVI, SATA-Express, PCI-Express, USB 3, etc. have all multiple conductor, but they are all in essence still serial.
Each bit of a word is travelling one after the other in the same conductor.
And the above standard just happen to have multiple serial-links that can be used concurrently : the system can send multiple data packet more or less at the same time, each sent serially along a different line.
(And in the cases of standards such as PCIe, the various serial links might not be even talking to the same device).
Unlike the parallel situation, you do not need to make sure that the bits travel in unison down different conductors : each serial link is sending different data packets, they can arrive with slightly different timing.
(Basically, is like plugging 2 network cables in 2 ports of the same server using link aggregation. You didn't suddenly turn ethernet into a parallel bus, you just have more interfaces to spread the load of sending your packet over).
So no. Latest iteration USB are still serial. They can just have more independent serial-links used concurrently, but the bits still travel one after the other on the same link, the other link is used to send a different data packet concurrently)
At best you could invent a new term like "multi-serial" or "concurrent serial".
You seem to think that producers/engineers will create two cuts of a recording - one with heavy compression for digital, and one unrestricted for vinyl. How quaint!
Doe *all* engineers ? It's very likely :*NO*.
Do *some* studio make an new mix for vinyl ?
Some will. And that contributes to the myth that vinyl sounds better.
(The sound *currently stored on this vinyl* does indeed sound better than the sound *currently stored on that CD*.
By conscious choice of the engineer doing the corresponding mix.)
Or it might be attempt to transfer the kind of considerations that already happen between domain-squatters and trademarks.
But adapted to Geographic Indication instead of brand-names (which is really *serious business* in France. They were the first country to have official law in place for GI with their AOC - "Appellation d'origin protégée")
In other way, just as some random schmuck shouldn't be allowed to register "coca-cola.com" (it's a protected trademark) even if it's a fan page and forum that serves as a gathering place for the brand's fans, some random schmuck couldn't use specific Geographic Indications in their webdomain (exactly as they couldn't use that GI in their business name) if they don't follow the requirement for said GI (usually : growing and processing your product in the region named in the GI).
Or it might actually be a case of "Geographic Indication" ?
The European continent has a complex system of laws defining which names of places can be used by commercial entities.
France is about the oldest country with such law systems (the AOC - Appellation d'origine controlée).
You can't arbitrarily call you wine "Champagne" if it's not actually produced in the Fench region of Champagne.
(Which by it self gave rise to tons of other problems as, e.g.: there's a region of Switzerland which also happens to be called Champagne and happens to produce (completely different, non-sparkling) wines as well).
See it as a sort of "trademark" law, but for geographic names, instead of brand names.
I haven't bothered to check the french court ruling, but I wouldn't be surprise if it was done in that sense (that there are precise "GI" criteria defining whether a comp can use "France" in their name).
Of course, then the simplest course of actions for Frydman would be to re-register a "France" domain at a registrar in some country that doesn't follow any treaty regarding GI. (China ?)
I'm glad to be rid of hiss, pops, scratches, wow, flutter, 5% total harmonic distortion, stretching, rumble.
You can gladly exchange them for saturated over-loud mix, where your equalizer's "frequeccy analyser display" has all the display bars permanently stuck to the top, with frequent pops and clicks due to range-clipping.
(More seriously, there is a key difference :
- Vinyl's defect come from limitation (and fagility) of the medium.
- CD's biggest problem come from the idiot at the mixing table who tries hard to get more attention by attempting at being louder than the others
But these defect might be also a reason to why people might try to avoid digital media : not because inherent flaws, but because they are fed up with the type of mixing that ends up being done on those media.)
A regular 44khz audio CD can't capture the full resolution of a digital master done at e.g 96khz.
The thing is, human ears can't capture it either.
Physics/physiology has a nasty habit of popping in the way.
More seriously, there's a point in the digital domain (basically when it has reached and overtaken the limitation of the human ears you're targetting) beyond which you can consider the sound perfect and all the problem coming from the medium. And as you point out :
But imperfections in the medium are more likely to cause differences you can actually hear.
(Perfect: it's not actually. But unless you have a few bats and dolphins that managed to hide among your public, you can ignore safely the difference).
(Also, hoping that the digital to analog conversion isn't horribly distorted).
Mikrotiks, on the other hand, as easy to re-install with a good opensource firmware (like OpenWRT/LEDE, etc.).
Same with tons of cheap chinese routers (though not all have enough flash/ram to support all features including filesharing over IPv6, at least they can have good basic router functionality).
The same cannot be said for Apple's hardware.
- 3rd party firmware has always been difficult.
- apple discontinuing them means no way to get a 1st party secure firmware either.
There are better solution than that.
On some brands of router, the default password isn't something simple (like "admin"), but each device has a random string generated as a default password and wifi, just as each device has its own serial number (it might be that one is generated from the other on-device), with those printed out on same sticker as the serial number on the box it self (there is no default password in the manual, as there is no series-wide password) so in an emergency you can reset to these long random default.