Optimistic; but not quite true. Eve is Eve. Bob is Eve's computer.
It is impossible to build fully effective DRM. With enough skill, money, and equipment, Eve could go in and rework at the IC level, or even do a complete teardown and build a replica-but-without-the-DRM equivalent. If there aren't serious implementation mistakes to work with, though, "enough skill, money, and equipment" is an enormous amount... In practice, it is really only the legacy of the pre-cheap-cryptography general purpose computer, and its massive install base, that keeps us thinking of Bob and Eve as the same person...
For DRM to work(to the degree that it ever does) it has to be implemented in something that the user cannot successfully modify to be less user hostile.
Hardware, because it is comparatively difficult and expensive to modify, generally poses the greatest obstacles to the user.
Closed source software, if sufficiently crafty, can be comparatively difficult(but much cheaper, so it usually falls faster).
OSS, by design, is modifiable, so it would last mere minutes. Is it nice that Mozilla won't do DRM? Sure. Would Mozilla committing to DRM stop Iceweasel from being released in a 100% compatible except when it comes to shafting the user build about 20 minutes later? No.
That is what I don't understand about this "question". Obviously, it would be architecturally trivial to add a 'dontcopythatfloppy' option to the HTML5 Video tag. However, nothing short of the wholesale annihilation of the general-purpose computer and its replacement by a dystopian mass of tivoized appliances and TPM-backed "secure remote attestation" mechanisms would make it remotely relevant. Barring such an outcome, "DRM" would essentially be a polite request to the browser that it please hide the "download" button.
I imagine that you would have two somewhat vexing problems: One, as you note, temperatures high enough to melt rocks are pretty hard on most machinery. Two, while extremely hot, magma has a distinctly finite amount of energy available. Once you get serious about extracting heat, it will cool and solidify. Once solidified, it will be a mediocre conductor of heat. Thus, unless you want to get only toy amounts of energy out of the system, you will need a fairly large surface area exposed to the magma.
Given the assorted delightful cognitive deficiencies associated with malnutrition in infancy and childhood, there is a strong argument to be made that such a policy is simply pragmatic(even if one has no ethical qualms with letting children suffer for their parents' positions).
Nutritional adequacy is cheap, a cognitively dysfunctional underclass is not...
For all but the simplest messages(ie. time-based triggers for instructions previously communicated by some other channel, or very rough information transfer) TV seems like a pretty awful medium. Most of the really fun stegonography can't be performed by humans, and may or may not survive ADC(or one of the not-always-predictable transfer and/or compression steps that can occur as your source video goes through the TV process on its way to the viewer). That seriously limits your bandwidth. So too does the need to do something newsworthy every time you need to send a message.
Now, spam email on the other hand... vast volume, chunks of nonsensical anti-filtering text are a genre convention, plenty of people willing to send it, no questions asked, etc...
Given the lousiness of conventional treatment for serious burns, and the relative ease of detecting many skin cancers, I suspect that a risk of cancer well above 0 would be acceptable(especially since ordinary human skin has that anyway). You would certainly want results markedly better than the "naive and desperate getting stem-cell shots in seedy offshore clinics" level, but even having to pick off a melanoma every few years would almost certainly be both better quality of life, and cheaper, than enduring a patchwork of scar tissue and endless rounds of grafting surgery.... No chance of replacing band-aids until it is essentially 100% safe; but that doesn't sound like the target market.
I suspect that almost any basic research in the "stimulate tissue growth without provoking immune rejection or cancer" genre will eventually have applications to regrowing organs; but there will be additional complications.
Skin(in addition to being an attractive target because it gets damaged a lot and ugly scarring tends to be psychologically problematic) has the advantage of (comparatively) simple geometry. It is a fairly thin membrane with(again comparatively) limited and homogeneous vascular structure. Organs that have a complex 3D structure, and whose function absolutely depends on that structure, will present additional challenges.
On the plus side, if you can solve the cell tractability problem, 3D printing isn't exactly an unknown technology...
I strongly suspect that the delivery mechanism is by far the most boring part of either of these systems.
Spraying fluids and/or particle/fluid aerosols with greater or lesser precision is a basically solved problem. Yours for $50 at Best Buy or your local hobby shop. Yawn.
Stimulating high-speed tissue regrowth, without it turning into a horrible mass of scar tissue and/or cancer, on the other hand, is the cutting edge bit. Mammalian tissue regeneration is rather more conservative than we would like, leading to permanent loss of tissue and limbs, and ugly scarring; but naive stimulation of cell growth, or introduction of pluripotent cells, has an ugly habit of reminding you why that level of conservatism turned out to be evolutionarily adaptive...
Once you solve the hard problem of producing a safe and effective cell/drug/nutrient/whatever slurry that does what you want it to do, it likely barely matters if you use an inkjet, an airbrush, a paintbrush, or just finger-paint it on. The "ink" is the interesting bit.
I was asking if that were practical, since I don't know much about the guts of this stuff. TFA's mention of optimizing code that runs frequently, and not optimizing rarely used code, gave me the impression that there is some sort of technique, presumably a species of JIT compilation, that is quite computationally expensive; but makes the code subjected to it run faster thereafter. NoSig's comment about load times suggested a similar tradeoff.
This struck me(on naive first inspection) as being something that would nicely complement the browser cache: if you have the javascript, and idle cycles, and the user isn't sitting and waiting for the page to display, you might as well apply the most aggressive optimization(some nuances would, of course, have to be adopted for battery-powered or thermally constrained devices, where idle cycles are a comparatively costly resource...)
I don't know enough about the subject to know if there is some reason why this idea is stupid; but if my inference from TFA, that you can trade a one-time, computationally expensive, operation for a speedup on every subsequent run of the code, is correct, it seems as though having a background cache-optimizer would be a comparatively simple extension of the work being done anyway, and would improve user experience for repeatedly loaded sites and/or libraries...
Assuming such a thing is practical, it would also be interesting to see how it would work built into a caching proxy. I imagine that such an arrangement would open an exciting new scope for bugs and subtle evil; but it would also allow resource-constrained clients to have some of their work done for them by much more capable devices.
Given that browsers tend to cache website elements, for better speed when loading objects that haven't changed since last load, and given that, while people want their page now, their computer usually has a fair amount of idle time available, would you expect to see browsers implementing some sort of background optimization mechanism that chews over cached javascript during idle periods in order to reduce the amount of computationally expensive work that needs to be done should the page be reloaded? Or is Javascript not amenable to that level of preemptive processing?
Historically, slashdot(and elsewhere) has seen the battle over performance between the C/C++ classicists, and those who insist that Java or one of its architecturally similar cousins has, with enough work on the JVM, achieved nearly equivalent execution speed.
Does anybody know where we are with Javascript now? Traditionally, its performance has been pathetic, since it wasn't all that heavily used; but of late competition to have a better javascript implementation has been pretty intense. Is there anything fundamentally wrong with the language, that will doom it to eternal slowness, or is it on the trajectory to near-native speeds eventually?
The idea that government jobs are incapable of producing anything of value is nonsense, albeit oft repeated. Nothing magically makes a person paid in tax dollars incapable of producing something that their private sector counterpart could...
Now, as an empirical matter, there are a number of specific instances where(because of some combination of deadweight losses from taxation, poor incentive structures, lack of competition, etc.) you can make the case that state employees are quite inefficient, or that the projects they are working on are white elephants; but you actually have to look at the details to do that.
While there are certainly exceptions, the economics of IT spending make it fairly likely that at least a substantial minority of the available geek talent will be eating right out of the state's hand.
Jobs requiring security clearances(whether directly on the federal payroll, or as one of the legions of subcontracted spooks) are some of the few that are resistant to the ideological free-trade enthusiasts, H1Bs, and assorted other economic and political forces that have been chipping away at the real income of ~the bottom 90% of Americans for a few decades now.
As long as the DoD budget holds out(and it will probably be among the last to go), there will be a fairly powerful incentive among those with the requisite computer skills to keep their mouths shut and keep plugging away at the electronic surveillance state...
Unfortunately, your contemporary wackjob zealot obtains his morals from a questionable understanding of iron age writings about a sociopathic tribal deity; but often shows an otherwise modern understanding of things like computers and small arms...
Even Usenet is really pretty wedded to comparatively low latency communications...
Anything adapted for seriously high latency will probably look a lot more like today's broadcast media: If your ping times are measured in years, waiting for an ack from the remote host, or asking for a corrupt packet to be re-sent are going to be somewhere between painful and useless. As with broadcast, the sender will just have to generate a signal that the receiver can reconstruct without further communication, and pack in whatever they expect to be of interest, with only occasional input from the receiver about what they want. Each side will be both sender and receiver; but each will hear from the other years after the fact, so the communication will only be "bidirectional" in the most limited of senses...
Has Apple ever been about anything other than elegantly polished control(with the possible exceptions of the early Woz years, and the Scully period where they were too busy sucking to be about anything...)?
The only real change is that they now have the power, and the crypto, to bring to fruition the exact same principles that have motivated them for years.
Family is in the car. Keep your breathing steady. Don't think about the red light district. Don't think about the red light district. For fuck's sake don't think about the red light district. Or that apartment on the other side of town. Don't think about it. Don't think about it. The mall, man, get a grip on yourself. Think about the mall. Just focus on the mall. *bead of sweat*...
(There is also another layer to consider: When Intel's CEO comes out with a public statement, odds are that it is neither a candid exposure of his innermost feelings nor altruistic friendly advice. In the PC and server market(particularly in the past few years, as AMD's lead from the A64 vs. Netburst days has faded), there are a number of companies generating enough profit to stay in the business; but the fight over the real margins is basically between Intel and Microsoft. AMD has some aggressively priced value offerings; but Intel has the high end and laptop-friendly thermals largely buttoned up. RAM, shitty onboard sound, mediocre ethernet, etc. are largely commodified. Thus, the big contest going on behind a shipped machine's BOM is how MS and Intel are going to split the juicy slice of the profit... In this case, it seems logical to assume that Intel would really prefer that Android take over, since that is the most plausible path to a situation where handset OSes can command very little of the handset's overall margin, which leaves more for the hardware guys. More broadly, if MS's attempt at the mobile market ends up being more money pissed down the rat hole, that weakens their overall grip a bit, which presumably means that more x86s, especially in servers, will ship with linux or heavily-discounted Windows, which will allow the margins to flow to Intel... FUDing Nokia a bit costs Intel very little, and might hit Nokia in the stock price, and/or require MS to dump more cash into them.)
I suspect that intel(speaking as a hardware manufacturer, and to a hardware manufacturer, not as an end-user) is speaking of "open" in the sense of "the software is freely(or RAND-ly, Intel isn't averse to paying for things if it suits them) for use and modification by multiple vendors" rather than "open" as in "not Tivoized"(which is really only the user's problem)...
A few public executions would very likely reduce the number of fools that use smartphones while driving
I strongly doubt it. Even for the person causing them, car accidents are risky and expensive. Even hitting a pedestrian will probably involve getting a face full of airbag, a bumper replacement, and whatever re-fit is necessary to get the airbag system re-armed. Collision with a more solid object can easily result in serious injury or death, as well as a totalled vehicle.
Even without legal intervention, spikes in insurance rates, and the like, causing a car accident is, a nontrivial percentage of the time, something that carries an automatic punishment with it. Once you add insurance companies, healthcare hassles, and vehicular manslaughter charges, the odds get worse.
If all that doesn't dissuade the dumbasses from keeping their eyes on their toys rather than the road, I'm not thinking that remote odds of execution would...
Establishing that to a reasonable standard of certainty is obviously a matter for discovery; but my guess would be "Yes".
Most cellphones, unless explicitly instructed otherwise, correct their RTCs against the cell network pretty regularly. The cell guys keep a pretty good timebase.
Facebook, or any reasonably sized internet entity, is almost certainly correcting their RTCs with NTP or better, if only because things like logging and authentication are really, really hairy if you can't trust your timestamps.
One would also suspect that 911 call-centers keep accurate timestamps, given that the contents and timing of 911 calls end up being introduced as evidence with some frequency, and a lousy timebase would just be asking to have that evidence challenged every time it popped up...
Speculation is no substitute for knowledge, of course, but all of the timekeeping devices in this scenario are sophisticated, network linked devices, with assorted incentives for keeping accurate time, and comparatively cheap means of doing so. Nobody's imperfect memory of what their $2 timex or expensive-but-pitifully-mechanical "chronometer" was displaying is involved.
Attacking the assumption that the timestamps are synchronized sufficiently well is basically the defendant's only chance of escaping civil and/or criminal penalties, so I suspect the issue will be carefully examined; but I'd be fairly surprised if it turned out to exonerate her...
You are a bit too self-aware about it to not be joking; but it is a matter of continual puzzlement to me that so many people accord higher regard to an assertion made with certainty than to one made with explicit provision for updates in the face of new evidence.
In an institutional setting(where a good slice of any individual's coworkers can probably obtain physical access for 10 minutes without drawing suspicion, and whatever contract cleaning service was cheapest gets absolutely insane levels of physical access, granted to the high-turnover pool of whatever poor bastards they can find to do night-shift cleaning for $not much/hour, written passwords are, indeed, just asking for it.
In a physically secure environment, though, if you are concerned primarily with internet threats(as with, say, home banking) an excellent written password can be a perfectly decent strategy(particularly if you do something like remember an ok password, then append the written-down 20-character-line-noise one... Even a breakin won't get somebody what they need...).
Ultimately, though, if it is really that important, you should probably suck it up and go with some flavor of cryptographic token + password. They aren't terribly inexpensive, and everybody hates them; but they are better.
(especially since after i was there for 2 years, there were hardly any network issues)
Surely that can only mean you were doing your job well.
Unfortunately, this is not the way of user psychology...
By default, all complex network setups work perfectly(It said "enterprise" right on the box, dinn'it?). If yours does not work perfectly, that is because your IT department is incompetent. If yours does work perfectly, this implies that your IT department is slacking off and playing video games, and should probably be fired and replaced by something cheaper.
Slashdot Mirror
Optimistic; but not quite true. Eve is Eve. Bob is Eve's computer.
It is impossible to build fully effective DRM. With enough skill, money, and equipment, Eve could go in and rework at the IC level, or even do a complete teardown and build a replica-but-without-the-DRM equivalent. If there aren't serious implementation mistakes to work with, though, "enough skill, money, and equipment" is an enormous amount... In practice, it is really only the legacy of the pre-cheap-cryptography general purpose computer, and its massive install base, that keeps us thinking of Bob and Eve as the same person...
For DRM to work(to the degree that it ever does) it has to be implemented in something that the user cannot successfully modify to be less user hostile.
Hardware, because it is comparatively difficult and expensive to modify, generally poses the greatest obstacles to the user.
Closed source software, if sufficiently crafty, can be comparatively difficult(but much cheaper, so it usually falls faster).
OSS, by design, is modifiable, so it would last mere minutes. Is it nice that Mozilla won't do DRM? Sure. Would Mozilla committing to DRM stop Iceweasel from being released in a 100% compatible except when it comes to shafting the user build about 20 minutes later? No.
That is what I don't understand about this "question". Obviously, it would be architecturally trivial to add a 'dontcopythatfloppy' option to the HTML5 Video tag. However, nothing short of the wholesale annihilation of the general-purpose computer and its replacement by a dystopian mass of tivoized appliances and TPM-backed "secure remote attestation" mechanisms would make it remotely relevant. Barring such an outcome, "DRM" would essentially be a polite request to the browser that it please hide the "download" button.
I imagine that you would have two somewhat vexing problems: One, as you note, temperatures high enough to melt rocks are pretty hard on most machinery. Two, while extremely hot, magma has a distinctly finite amount of energy available. Once you get serious about extracting heat, it will cool and solidify. Once solidified, it will be a mediocre conductor of heat. Thus, unless you want to get only toy amounts of energy out of the system, you will need a fairly large surface area exposed to the magma.
Given the assorted delightful cognitive deficiencies associated with malnutrition in infancy and childhood, there is a strong argument to be made that such a policy is simply pragmatic(even if one has no ethical qualms with letting children suffer for their parents' positions).
Nutritional adequacy is cheap, a cognitively dysfunctional underclass is not...
For all but the simplest messages(ie. time-based triggers for instructions previously communicated by some other channel, or very rough information transfer) TV seems like a pretty awful medium. Most of the really fun stegonography can't be performed by humans, and may or may not survive ADC(or one of the not-always-predictable transfer and/or compression steps that can occur as your source video goes through the TV process on its way to the viewer). That seriously limits your bandwidth. So too does the need to do something newsworthy every time you need to send a message.
Now, spam email on the other hand... vast volume, chunks of nonsensical anti-filtering text are a genre convention, plenty of people willing to send it, no questions asked, etc...
Given the lousiness of conventional treatment for serious burns, and the relative ease of detecting many skin cancers, I suspect that a risk of cancer well above 0 would be acceptable(especially since ordinary human skin has that anyway). You would certainly want results markedly better than the "naive and desperate getting stem-cell shots in seedy offshore clinics" level, but even having to pick off a melanoma every few years would almost certainly be both better quality of life, and cheaper, than enduring a patchwork of scar tissue and endless rounds of grafting surgery.... No chance of replacing band-aids until it is essentially 100% safe; but that doesn't sound like the target market.
I suspect that almost any basic research in the "stimulate tissue growth without provoking immune rejection or cancer" genre will eventually have applications to regrowing organs; but there will be additional complications.
Skin(in addition to being an attractive target because it gets damaged a lot and ugly scarring tends to be psychologically problematic) has the advantage of (comparatively) simple geometry. It is a fairly thin membrane with(again comparatively) limited and homogeneous vascular structure. Organs that have a complex 3D structure, and whose function absolutely depends on that structure, will present additional challenges.
On the plus side, if you can solve the cell tractability problem, 3D printing isn't exactly an unknown technology...
I strongly suspect that the delivery mechanism is by far the most boring part of either of these systems.
Spraying fluids and/or particle/fluid aerosols with greater or lesser precision is a basically solved problem. Yours for $50 at Best Buy or your local hobby shop. Yawn.
Stimulating high-speed tissue regrowth, without it turning into a horrible mass of scar tissue and/or cancer, on the other hand, is the cutting edge bit. Mammalian tissue regeneration is rather more conservative than we would like, leading to permanent loss of tissue and limbs, and ugly scarring; but naive stimulation of cell growth, or introduction of pluripotent cells, has an ugly habit of reminding you why that level of conservatism turned out to be evolutionarily adaptive...
Once you solve the hard problem of producing a safe and effective cell/drug/nutrient/whatever slurry that does what you want it to do, it likely barely matters if you use an inkjet, an airbrush, a paintbrush, or just finger-paint it on. The "ink" is the interesting bit.
"PC Load Human Flesh" WTF does that mean?
I was asking if that were practical, since I don't know much about the guts of this stuff. TFA's mention of optimizing code that runs frequently, and not optimizing rarely used code, gave me the impression that there is some sort of technique, presumably a species of JIT compilation, that is quite computationally expensive; but makes the code subjected to it run faster thereafter. NoSig's comment about load times suggested a similar tradeoff.
This struck me(on naive first inspection) as being something that would nicely complement the browser cache: if you have the javascript, and idle cycles, and the user isn't sitting and waiting for the page to display, you might as well apply the most aggressive optimization(some nuances would, of course, have to be adopted for battery-powered or thermally constrained devices, where idle cycles are a comparatively costly resource...)
I don't know enough about the subject to know if there is some reason why this idea is stupid; but if my inference from TFA, that you can trade a one-time, computationally expensive, operation for a speedup on every subsequent run of the code, is correct, it seems as though having a background cache-optimizer would be a comparatively simple extension of the work being done anyway, and would improve user experience for repeatedly loaded sites and/or libraries...
Assuming such a thing is practical, it would also be interesting to see how it would work built into a caching proxy. I imagine that such an arrangement would open an exciting new scope for bugs and subtle evil; but it would also allow resource-constrained clients to have some of their work done for them by much more capable devices.
Given that browsers tend to cache website elements, for better speed when loading objects that haven't changed since last load, and given that, while people want their page now, their computer usually has a fair amount of idle time available, would you expect to see browsers implementing some sort of background optimization mechanism that chews over cached javascript during idle periods in order to reduce the amount of computationally expensive work that needs to be done should the page be reloaded? Or is Javascript not amenable to that level of preemptive processing?
Historically, slashdot(and elsewhere) has seen the battle over performance between the C/C++ classicists, and those who insist that Java or one of its architecturally similar cousins has, with enough work on the JVM, achieved nearly equivalent execution speed.
Does anybody know where we are with Javascript now? Traditionally, its performance has been pathetic, since it wasn't all that heavily used; but of late competition to have a better javascript implementation has been pretty intense. Is there anything fundamentally wrong with the language, that will doom it to eternal slowness, or is it on the trajectory to near-native speeds eventually?
The idea that government jobs are incapable of producing anything of value is nonsense, albeit oft repeated. Nothing magically makes a person paid in tax dollars incapable of producing something that their private sector counterpart could...
Now, as an empirical matter, there are a number of specific instances where(because of some combination of deadweight losses from taxation, poor incentive structures, lack of competition, etc.) you can make the case that state employees are quite inefficient, or that the projects they are working on are white elephants; but you actually have to look at the details to do that.
While there are certainly exceptions, the economics of IT spending make it fairly likely that at least a substantial minority of the available geek talent will be eating right out of the state's hand.
Jobs requiring security clearances(whether directly on the federal payroll, or as one of the legions of subcontracted spooks) are some of the few that are resistant to the ideological free-trade enthusiasts, H1Bs, and assorted other economic and political forces that have been chipping away at the real income of ~the bottom 90% of Americans for a few decades now.
As long as the DoD budget holds out(and it will probably be among the last to go), there will be a fairly powerful incentive among those with the requisite computer skills to keep their mouths shut and keep plugging away at the electronic surveillance state...
Unfortunately, your contemporary wackjob zealot obtains his morals from a questionable understanding of iron age writings about a sociopathic tribal deity; but often shows an otherwise modern understanding of things like computers and small arms...
Even Usenet is really pretty wedded to comparatively low latency communications...
Anything adapted for seriously high latency will probably look a lot more like today's broadcast media: If your ping times are measured in years, waiting for an ack from the remote host, or asking for a corrupt packet to be re-sent are going to be somewhere between painful and useless. As with broadcast, the sender will just have to generate a signal that the receiver can reconstruct without further communication, and pack in whatever they expect to be of interest, with only occasional input from the receiver about what they want. Each side will be both sender and receiver; but each will hear from the other years after the fact, so the communication will only be "bidirectional" in the most limited of senses...
Has Apple ever been about anything other than elegantly polished control(with the possible exceptions of the early Woz years, and the Scully period where they were too busy sucking to be about anything...)?
The only real change is that they now have the power, and the crypto, to bring to fruition the exact same principles that have motivated them for years.
Family is in the car. Keep your breathing steady. Don't think about the red light district. Don't think about the red light district. For fuck's sake don't think about the red light district. Or that apartment on the other side of town. Don't think about it. Don't think about it. The mall, man, get a grip on yourself. Think about the mall. Just focus on the mall. *bead of sweat*...
(There is also another layer to consider: When Intel's CEO comes out with a public statement, odds are that it is neither a candid exposure of his innermost feelings nor altruistic friendly advice. In the PC and server market(particularly in the past few years, as AMD's lead from the A64 vs. Netburst days has faded), there are a number of companies generating enough profit to stay in the business; but the fight over the real margins is basically between Intel and Microsoft. AMD has some aggressively priced value offerings; but Intel has the high end and laptop-friendly thermals largely buttoned up. RAM, shitty onboard sound, mediocre ethernet, etc. are largely commodified. Thus, the big contest going on behind a shipped machine's BOM is how MS and Intel are going to split the juicy slice of the profit... In this case, it seems logical to assume that Intel would really prefer that Android take over, since that is the most plausible path to a situation where handset OSes can command very little of the handset's overall margin, which leaves more for the hardware guys. More broadly, if MS's attempt at the mobile market ends up being more money pissed down the rat hole, that weakens their overall grip a bit, which presumably means that more x86s, especially in servers, will ship with linux or heavily-discounted Windows, which will allow the margins to flow to Intel... FUDing Nokia a bit costs Intel very little, and might hit Nokia in the stock price, and/or require MS to dump more cash into them.)
I suspect that intel(speaking as a hardware manufacturer, and to a hardware manufacturer, not as an end-user) is speaking of "open" in the sense of "the software is freely(or RAND-ly, Intel isn't averse to paying for things if it suits them) for use and modification by multiple vendors" rather than "open" as in "not Tivoized"(which is really only the user's problem)...
A few public executions would very likely reduce the number of fools that use smartphones while driving
I strongly doubt it. Even for the person causing them, car accidents are risky and expensive. Even hitting a pedestrian will probably involve getting a face full of airbag, a bumper replacement, and whatever re-fit is necessary to get the airbag system re-armed. Collision with a more solid object can easily result in serious injury or death, as well as a totalled vehicle.
Even without legal intervention, spikes in insurance rates, and the like, causing a car accident is, a nontrivial percentage of the time, something that carries an automatic punishment with it. Once you add insurance companies, healthcare hassles, and vehicular manslaughter charges, the odds get worse.
If all that doesn't dissuade the dumbasses from keeping their eyes on their toys rather than the road, I'm not thinking that remote odds of execution would...
Establishing that to a reasonable standard of certainty is obviously a matter for discovery; but my guess would be "Yes".
Most cellphones, unless explicitly instructed otherwise, correct their RTCs against the cell network pretty regularly. The cell guys keep a pretty good timebase.
Facebook, or any reasonably sized internet entity, is almost certainly correcting their RTCs with NTP or better, if only because things like logging and authentication are really, really hairy if you can't trust your timestamps.
One would also suspect that 911 call-centers keep accurate timestamps, given that the contents and timing of 911 calls end up being introduced as evidence with some frequency, and a lousy timebase would just be asking to have that evidence challenged every time it popped up...
Speculation is no substitute for knowledge, of course, but all of the timekeeping devices in this scenario are sophisticated, network linked devices, with assorted incentives for keeping accurate time, and comparatively cheap means of doing so. Nobody's imperfect memory of what their $2 timex or expensive-but-pitifully-mechanical "chronometer" was displaying is involved.
Attacking the assumption that the timestamps are synchronized sufficiently well is basically the defendant's only chance of escaping civil and/or criminal penalties, so I suspect the issue will be carefully examined; but I'd be fairly surprised if it turned out to exonerate her...
You are a bit too self-aware about it to not be joking; but it is a matter of continual puzzlement to me that so many people accord higher regard to an assertion made with certainty than to one made with explicit provision for updates in the face of new evidence.
It's just a really weird defect.
In an institutional setting(where a good slice of any individual's coworkers can probably obtain physical access for 10 minutes without drawing suspicion, and whatever contract cleaning service was cheapest gets absolutely insane levels of physical access, granted to the high-turnover pool of whatever poor bastards they can find to do night-shift cleaning for $not much/hour, written passwords are, indeed, just asking for it.
In a physically secure environment, though, if you are concerned primarily with internet threats(as with, say, home banking) an excellent written password can be a perfectly decent strategy(particularly if you do something like remember an ok password, then append the written-down 20-character-line-noise one... Even a breakin won't get somebody what they need...).
Ultimately, though, if it is really that important, you should probably suck it up and go with some flavor of cryptographic token + password. They aren't terribly inexpensive, and everybody hates them; but they are better.
(especially since after i was there for 2 years, there were hardly any network issues)
Surely that can only mean you were doing your job well.
Unfortunately, this is not the way of user psychology...
By default, all complex network setups work perfectly(It said "enterprise" right on the box, dinn'it?). If yours does not work perfectly, that is because your IT department is incompetent. If yours does work perfectly, this implies that your IT department is slacking off and playing video games, and should probably be fired and replaced by something cheaper.