Unless he's really just an idiot; or (probably correctly) assuming that this proposal sounds just plausible enough to be held out as a 'twitter, actually has a plan it's totally working on to not be a bit farm forever' fluff proposal to mollify people for a while; I suspect that something like what you propose is what he would really like(though biometrics would be of limited relevance of platform vendors were to give it to him: something that ties login/account creation attempts to relatively expensive hardware would also ruin the economics of bots).
Qhe big question would be if platform vendors(basically read 'Apple', since knocking your app off iOS over the issue probably isn't happening) will want to play ball.
They certainly could, architecturally. In the Apple case I think Apple-blessed client authentication certs are already a big part of APN(if memory serves that's one of the obstacles that has scuttled any serious effort to get iMessage and FaceTime working in non-blessed areas(I think they haven't fully closed it off on hackintoshes, though it already requires plenty of fiddling and wouldn't be a huge surprise to see getting the axe properly, against any attack short of dumping keys out of the T2 chip from an actual Apple device once Apple phased out the models that don't have one of those). The PC and Android sides are more chaotic; but anything with a TPM(implementing a piece of software that behaves according to the TPM spec is quite doable and basically all the recent hypervisors support doing so; but obtaining a supply of private endorsement keys signed by one of the vendors 3rd parties will trust? Not so simple, which is what makes remote attestation toothy and could be used to prevent client activity not tied to actual hardware the bot herder would have to purchase or compromise) could add a hard to clone device-unique element tothe authentication process; as could many common 'trustzone'-implemented things, though there's less uniformity there.
Not as obvious that they would want to. Unless handled rather carefully doing so would be handing every random app-slinger a persistent hardware GUID with robust cryptographic backing(which, if the clampdown on IMEI scraping is anything to go by, they aren't entirely happy with); and it would also mean making available to 3rd parties an advantage that they currently enjoy themselves: if you want to sell your own account system as a de-facto standard for 3rd party services(and reap the ecosystem lock in and sweet, sweet data) that would be a powerful selling point: why let Twitter and such enjoy that for free when you could, instead, tell them that they can roll their own authentication and accounts, and fight bots and such; or bow to Apple IDs and enjoy assurances that logins are being made under controlled circumstances(untampered hardware whose platform key hasn't been burned as cloned or stolen, from a user who has recently performed a biometric authentication, etc.)
That's something valuable enough that he won't necessarily see vendors tripping over themselves to offer it as an agnostic API of some sort just to make solving his not problem easier. Platform vendor exploitation of the ability to do that would also get pretty dystopian pretty quickly; but that's not really a reason to think it won't happen.
Given how much of old-world mac Toolbox behavior was in ROM; and how this project's plan to not require ROM dumps to run(as the current classic macOS options do); it sounds a bit more DOSbox than Wine.
The project does have to include WINE-style implementations of OS behavior; but much more like DOSbox the relative lack of clean abstraction between the OS and and the lower level platform bits means a need to emulate that aspect as well. There may be bits of WINE that have to lie about a BIOS(I suspect some win32 software freaks out if WMI inquiries related to win32_computersystembios and friends don't produce coherent answers); but the OS and the platform details were much less entangled at that point.
Does Dorsey not understand how 'biometrics' are used in this context? You don't send a picture of your fingerprints/retina/whatever to the remote host(indeed, doing the processing on-module so that the main OS never gets a crack at the data is a feature you typically brag about on your spec sheet if you've avoided cheaping out enough to support that).
The biometric widget is just used by the local device as a mechanism for controlling whether or not to unlock the actual authentication material(whether it's just a tepid shared secret in the case of a password manager or one of the fancier FIDO/etc. cryptographic things).
Now, the part of this plan that might work would be coupling it with a platform that (in a feature technically unrelated to biometrics but probably implemented in the same securi-SoC) doesn't use something generic like a password; but includes an element that's hard to spoof without access to a slightly expensive device. Like, not terribly hypothetically, a private key or device certificate signed by the platform vendor. This has nothing to do with biometrics whatsoever; but it could make it much harder to just spam new accounts without also finding a source for extremely cheap TPMs or iphone secure enclaves or the like to pop up as a new device.
I imagine that the main area of interest(aside from people doing cryptoanalysis for its own sake or professionally) is in getting output that hasn't been decompressed, potentially resized or munged a bit by the decoding device's particular color profile; and finally grabbed off the HDMI output and recompressed.
If the stream provided to L3 clients is lousy enough you may still come out ahead by qualifying for L1-super-premium-secure and then HDCP stripping; but the clean copy will be worse than what was originally provided.
There's also the matter of convenience: HDMI framegrabbers are much cheaper than they used to be; but setting up a capture arrangement based on one is still way more of a hassle than just being able to clean up a media file with just a little bit of software manipulation. Unless the provider caps the download bitrate to 'just fast enough for real-time, maybe 30-90 seconds of buffer to cover for glitches' the software attack is likely to be faster as well: analog hole or HDCP strip attacks are usually real-time at best(sometimes slower if re encoding is computationally expensive) unless the target can be coaxed to play back at greater than 1x speed and your capture device can cope with it
Probably not going to set the world on fire in the Bluray rip scene; but could be very popular indeed for services that forbid or tightly restrict offline use in favor of streaming only and people who want access to that media when out and about without burning tons of cell data. Small screen makes resolution less of a concern and the fact that most phones don't exactly support simultaneous HDMI output and HDMI capture and encoding makes a pure software attack attractive.
This story of spammers trying to drum up support for the incumbent puerile attention whore of youtube almost makes me think that the Iranian social media crackdown will do them some good.
I think that all reasonable friends of free enterprise can agree that this was merely some 911 prioritization; which is both a celebration of the first amendment rights of CenturyLink and will assuredly encourage further investment.
It isn't clear that "We have employers call us all the time (saying), 'I'm looking for low-wage, entry-level workers,'" means "skilled tradesmen wanted"; rather than "local housing prices mean that everyone as cheap as I want my labor to be has either moved away or is already working 3.5 jobs to make rent".
This isn't to say that a BA in something that's not terribly marketable is a better idea than relevant trade experience and qualification(it often isn't); but "looking for low-wage, entry-level workers" likely rules out skilled trades as much as it does BAs looking for the bottom rung of the white collar ladder; that's somebody looking for cheap landscaping and big-box service sector peons at lowest possible cost.
There was a somewhat uncomfortable period for anyone who wanted to sneakernet files to other people; floppies were cheap enough to give to someone who might not bring them back, flash drives not even close; but for personal storage the price difference wasn't so bad(helped by the fact that floppies had tepid reliability and were individually quite small, so the fact that you could buy a 100 pack and have 140mb of space for way less than a 128mb flash drive was less helpful in practice). CD-Rs also helped soften the blow: much more capacious and acceptably cheap for situations where you were not expecting them to return.
It's not as glamorous a reason; but the copyright situation is also a pretty strong argument in favor of a conservative approach; unless you are notable enough to have a shot at exceptions(in the US case that pretty much means Library of Congress and maybe a few fairly prestigious university libraries with law faculty interested in providing them some cover at below market rates).
Media that either has no DRM or uses a DRM system that is fully offline(books, CDs, DVDs) and which is/was sold in some lendable form is relatively easy to deal with because the right of libraries(and people generally, where First Sale or equivalent is law) to lend out copies of copyrighted media is well established.
Stuff with a DRM system that phones home in one way or another is more difficult because, while the library can lend copies, they can't make those copies actually useful without either the vendor's cooperation or legally and technically tricky DRM breaking. That makes it a troublesome part of a library collection. Software platform requirements make archive grade longevity tricky enough; the fact that much software is essentially designed to defeat resale or lending really, really, doesn't help.
Things that were never sold as lendable copies are also tricky; since, while the right of libraries to lend copies they purchase is well established, the right of libraries to make copies to lend is much weaker and more uncertain. This is a bit problem for archiving most of the internet. Some of it is explicitly and liberally licensed, which makes archiving a technical problem(and, compared to software, not too bad); but most of it either has no explicit license(in which case it's still copyrighted anywhere in Berne Convention territory; though the rightsholder is less likely to come after you, though also harder to find if you do want to do rights clearance) or is quite explicitly marked as copyrighted with an owner that is more or less energetic about enforcement. This is why the Internet Archive, despite its mission being all about preservation of parts of the web that would otherwise link-rot, has to cave so readily to takedown requests: most of what they do has relatively little support in law, so they have no choice but to cave if anyone objects and confine their efforts to the stuff whose owners are either apathetic or supportive.
That's the great thing about doing 'security'. You get to claim that going into pesky detail about what you did would aid the enemy and imperil the effectiveness of the defenses; which can keep scrutiny at bay well beyond the duration of your career.
In this case we can make some unflattering inferences, given that they apparently didn't have a remotely adequate system last week(or they would have used it rather than fail visibly for three days); and given that one tends not to put together a system of this sort of complexity in this amount of time(suggesting that, at best, a good plan was developed but then ignored; and more likely that the plan that supposedly exists now is ill tested and probably overstated); but barring a leak we won't see the specifics for at least a decade, probably several.
Is the complaint that the service being paid for isn't as advertised somehow more or less valid because of the overall affluence of the situation?
If the complaint were that degradations in prime service were a human rights violation or something the fact that the situation is vastly better than most of history would be relevant. In this case it's merely that Amazon either can't hack their attempts at further scaling out or is in the 'switch' phase of 'bait and switch', which a complaint purely relative to what prime service used to be; not some grand historical arc.
Nuclear, even from an optimist's perspective, seems to be an abjectly terrible idea for the more small scale/dispersed requirements. It's a pity; because some of its features are very attractive(radiothermal generators pretty much give you something that puts out the power of a decent size battery; except for several decades; all sorts of things that currently use a beefy diesel engine or generator are large enough to make use of a nuclear reactor without heroic minaturization efforts); but the more widely you distribute something the more often the owner is negligent or incompetent and doesn't really do things like 'maintenance' or 'disposal' properly.
The soviet use of radiothermal generators gave us a bunch of (not well sealed) Strontium 90 sources floating around, not necessarily even documented in the worse cases; use in commercial shipping would likely end up with a bunch of reactors ending up in one of the hellholes where shipbreaking is cheap because regulations are thin and workers largely expendable.
It's much easier to get adequate standards for operational competence when you have fewer specialist operators; but that rules out a lot of distributed applications. As it is, isotope sealed sources with assorted medical, industrial, and scientific applications already go missing all the time; increasing the number(and power) of those things being used out and about seems likely to go poorly.
The tricky bit will be dealing with the 'garbage in/garbage out' problem. As a technical matter any vaguely competent VCS, ideally with cryptographic signatures(whether integral to the design or bolted on; conveniently CACs and PIVs already support signing, so a lot of fed-level IDs do signing in addition to authentication) can keep track of who changed what when; but there is no technical fix for people dumping big ugly blobs that probably represent dozens or hundreds of internal changes into the publicly visible system as a single commit.
Even that beats the 'somebody changed something at some time, we think, because it's definitely changed now and we just passed it by voice vote' system we currently have; but I'd expect to see a lot of cases where a chunk of law, carefully prewritten, gets committed by someone's deniable junior staffer with all the care for mainline compatibility exhibited by a shoddy router vendor engaging in minimum-necessary GPL 'compliance' by vomiting forth their hideous BSP lump.
Can't beat the system once you do commit; and you can enforce at least one interaction with the system by mandating that the authoritative text of the law is the one that comes out of the VCS; but if someone is feeling uncooperative they can deny the system a lot of information by sticking to 11th hour giant blob commits.
It doesn't say which of their ships is being converted, so it's hard to say how much energy is required; but I think the important point is that the biogas is being produced, liquified, then used as fuel.
It's not an onboard fish-guts-to-power arrangement; it's a ship converted to run on liquefied natural gas which is provided ready for use at the dock; at least some of which is supposed to be sourced from organic waste decomposition.
That's vastly easier and more plausible. LNG is somewhat less dense than diesel; and requires more care in storage; but it's a perfectly viable fuel; and production of methane from organic waste is going to be easier and cheaper when you don't need something you can fit into a ship while leaving room for cargo and passengers. Landfills do it automatically when left to their own devices(though it's often not captured in these cases), there may be some arrangement that is preferred when methane, rather than waste disposal, is the goal.
None of this is to say that they'll actually end up carefully accounting for how much LNG they burn and ensuring it is all sourced from organic fish heads rather than ordinary natural gas; but even if they cheat on that it'll be much nicer than bunker fuel.
How useful the information is would likely depend on how clever the jamming was. Spewing enough noise to drown out some satellites broadcasting over a fairly wide area from 20,000km away(and not that loudly, I think the power budget for the block III satellites is ~4kw, for everything they do, not just broadcast power) isn't necessarily of much interest; though it might be slightly alarming how many people need a reminder that it isn't exactly difficult.
Exploiting the details of the implementation to allow jamming at power levels and/or duty cycles well below those of naive noisemaking is more interesting. Subtle injection of skew into the time or position results without being caught by any sanity checks is more interesting still.
I doubt it's the case; but I can only hope that he's departing to devote himself full time to penitence. He'd have to be a telemarketer to have done more in the service of injecting petty irritation into the lives of so many.
It's good that we understand how humans acquire natural language well enough that 'just make the computer do it that way' is a plan. Otherwise this might not actually work terribly well.
Luckily AI is used to this class of failure by now, so they'll probably be OK.
There's also the issue(likely very significant in this case) that Tor does not (and doesn't claim to; and probably couldn't in principle, at least without significant redesign) protect you from endpoints inferring things about your traffic if it is interesting/identifiable in itself.
The onion routing and encryption of your traffic as it gets passed between the intermediate nodes breaks trivial identification of the origin of the traffic and keeps the intermediate nodes in the dark; but the exit node [i]must[/i] have access to your traffic(potentially not plaintext if you are communicating with a site that uses TLS) in exactly the form that the server you are communicating with expects.
If your traffic isn't intrinsically identifying; this is something to be aware of; but an improvement over the situation where the origin of your traffic is trivially available to everyone involved in getting it from source ot destination and back. If it is, though, Tor's protections get markedly less useful.
Contemporary systems can be chatty enough on the PC side(one of the reasons why specialty distros are commonly recommended for Tor use); is anyone crazy enough to expect a smartphone, exemplar of post-privacy computing, to not shed identifying information right and left?
Some devices already do that(unless they've changed it recently, Nvidia-SoC ones had fairly granular control over power vs. performance through a custom settings widget); and basically all of them do in the limited sense that they have 'battery saver' as an option that prunes power consumption in some areas.
I suspect that the cheaters aren't primarily motivated by confusion about how to implement this feature, though; but by the desire to get impossibly good numbers: if there is a slider the reviewer knows about they'll presumably run the battery and thermal benchmarks with it on the same setting they use for performance benchmarks; which will make it abundantly clear that there's a tradeoff, quite possibly a really harsh one. If you successfully sneak the settings past them you can potentially get performance benchmark numbers that would generate horrific battery life; and battery life numbers based on the handset mostly avoiding its most power hungry modes.
This is more of a laser vs. inkjet thing than a cheap consumer trash vs. 'workgroup' thing; but the very low duty cycles of common home uses are really an unfortunate match for inkjets.
This isn't to say that expensive print-shop inkjets are bulletproof or anything; but the cheap inkjet that gets used maybe a couple of times a month seems to be magnificently good at being clogged or dried out(maybe it'll come back after a 'cleaning' that consumes a substantial percentage of the cartridge, maybe not; but hey, the print head is probably part of the cartridge anyway..); while cheap and awful laser printers work pretty well for infrequent use because you won't wear them out that way, the per-page cost matters less; and toner doesn't tend to dry out or degrade under home conditions.
Inkjets just don't scale down to really cheap or infrequently used as well. It took a while for the cost of entry to laser to fall; but it has now; and scaled-down lasers are worse than nice ones; but don't tend to have the same really awful character defects as scaled-down inkjets; which are just terrible.
"The only potential difference in the market is the subscription model, where ink is included, and you pay for a certain number of prints per month. That offers an opportunity to be truly competitive."
You may not have had the...pleasure...of a copier lease. That's often the model used, so the hardware does tend to emphasize durability and actually sane consumables design(toner cartridges that aren't tightly coupled to transfer rollers, that sort of thing); but the vendors are utter dicks about basically everything else. Everything is gated behind a license key, including basic things like 'speak postscript'; 'value added' software like the various print management/document release/OCR integration stuff tends to be pretty janky; and the vendors have a relationship with their dealer networks and VARs unpleasantly reminiscent of the automobile industry.
Low end printers are utter trash by comparison; and companies that sell you toner cartridges, rather than 'managed print solutions', have an incentive to jerk you around on consumables that they often succumb to; but you don't get nonsense like having to pay your dealer to send a tech just to apply a firmware update; or having most of the actually useful configuration options locked behind a password that you don't receive.
I suspect the terms have the convenient feature of being a bit of both. It's not false that 'just use a never-updated internal copy of webkit as a minimum-effort cross platform porting tool" is vastly worse for security than using the actually-maintained platform tools for rendering potentially untrustworthy material. However, the rules as written also mean that no other browsers are allowed in the app store: you can slap your logo and few UI tweaks on Edge; but that's the extent of it. Basically the same arrangement as iOS; which isn't a good sign from the perspective of people who purchase Windows because it runs the programs they want rather than to enjoy Microsoft's Rich Consumer App Experiences.
It is a first world problem; but if you live in the first world that doesn't help you much.
In the educational context(which appears to be where this research was being done), things aren't going to go so well for you if you've got a household with contention over the computer and a bunch of homework that assumes you have one.
Slashdot Mirror
Unless he's really just an idiot; or (probably correctly) assuming that this proposal sounds just plausible enough to be held out as a 'twitter, actually has a plan it's totally working on to not be a bit farm forever' fluff proposal to mollify people for a while; I suspect that something like what you propose is what he would really like(though biometrics would be of limited relevance of platform vendors were to give it to him: something that ties login/account creation attempts to relatively expensive hardware would also ruin the economics of bots).
Qhe big question would be if platform vendors(basically read 'Apple', since knocking your app off iOS over the issue probably isn't happening) will want to play ball.
They certainly could, architecturally. In the Apple case I think Apple-blessed client authentication certs are already a big part of APN(if memory serves that's one of the obstacles that has scuttled any serious effort to get iMessage and FaceTime working in non-blessed areas(I think they haven't fully closed it off on hackintoshes, though it already requires plenty of fiddling and wouldn't be a huge surprise to see getting the axe properly, against any attack short of dumping keys out of the T2 chip from an actual Apple device once Apple phased out the models that don't have one of those). The PC and Android sides are more chaotic; but anything with a TPM(implementing a piece of software that behaves according to the TPM spec is quite doable and basically all the recent hypervisors support doing so; but obtaining a supply of private endorsement keys signed by one of the vendors 3rd parties will trust? Not so simple, which is what makes remote attestation toothy and could be used to prevent client activity not tied to actual hardware the bot herder would have to purchase or compromise) could add a hard to clone device-unique element tothe authentication process; as could many common 'trustzone'-implemented things, though there's less uniformity there.
Not as obvious that they would want to. Unless handled rather carefully doing so would be handing every random app-slinger a persistent hardware GUID with robust cryptographic backing(which, if the clampdown on IMEI scraping is anything to go by, they aren't entirely happy with); and it would also mean making available to 3rd parties an advantage that they currently enjoy themselves: if you want to sell your own account system as a de-facto standard for 3rd party services(and reap the ecosystem lock in and sweet, sweet data) that would be a powerful selling point: why let Twitter and such enjoy that for free when you could, instead, tell them that they can roll their own authentication and accounts, and fight bots and such; or bow to Apple IDs and enjoy assurances that logins are being made under controlled circumstances(untampered hardware whose platform key hasn't been burned as cloned or stolen, from a user who has recently performed a biometric authentication, etc.)
That's something valuable enough that he won't necessarily see vendors tripping over themselves to offer it as an agnostic API of some sort just to make solving his not problem easier. Platform vendor exploitation of the ability to do that would also get pretty dystopian pretty quickly; but that's not really a reason to think it won't happen.
Given how much of old-world mac Toolbox behavior was in ROM; and how this project's plan to not require ROM dumps to run(as the current classic macOS options do); it sounds a bit more DOSbox than Wine.
The project does have to include WINE-style implementations of OS behavior; but much more like DOSbox the relative lack of clean abstraction between the OS and and the lower level platform bits means a need to emulate that aspect as well. There may be bits of WINE that have to lie about a BIOS(I suspect some win32 software freaks out if WMI inquiries related to win32_computersystembios and friends don't produce coherent answers); but the OS and the platform details were much less entangled at that point.
Does Dorsey not understand how 'biometrics' are used in this context? You don't send a picture of your fingerprints/retina/whatever to the remote host(indeed, doing the processing on-module so that the main OS never gets a crack at the data is a feature you typically brag about on your spec sheet if you've avoided cheaping out enough to support that).
The biometric widget is just used by the local device as a mechanism for controlling whether or not to unlock the actual authentication material(whether it's just a tepid shared secret in the case of a password manager or one of the fancier FIDO/etc. cryptographic things).
Now, the part of this plan that might work would be coupling it with a platform that (in a feature technically unrelated to biometrics but probably implemented in the same securi-SoC) doesn't use something generic like a password; but includes an element that's hard to spoof without access to a slightly expensive device. Like, not terribly hypothetically, a private key or device certificate signed by the platform vendor. This has nothing to do with biometrics whatsoever; but it could make it much harder to just spam new accounts without also finding a source for extremely cheap TPMs or iphone secure enclaves or the like to pop up as a new device.
I imagine that the main area of interest(aside from people doing cryptoanalysis for its own sake or professionally) is in getting output that hasn't been decompressed, potentially resized or munged a bit by the decoding device's particular color profile; and finally grabbed off the HDMI output and recompressed.
If the stream provided to L3 clients is lousy enough you may still come out ahead by qualifying for L1-super-premium-secure and then HDCP stripping; but the clean copy will be worse than what was originally provided.
There's also the matter of convenience: HDMI framegrabbers are much cheaper than they used to be; but setting up a capture arrangement based on one is still way more of a hassle than just being able to clean up a media file with just a little bit of software manipulation. Unless the provider caps the download bitrate to 'just fast enough for real-time, maybe 30-90 seconds of buffer to cover for glitches' the software attack is likely to be faster as well: analog hole or HDCP strip attacks are usually real-time at best(sometimes slower if re encoding is computationally expensive) unless the target can be coaxed to play back at greater than 1x speed and your capture device can cope with it
Probably not going to set the world on fire in the Bluray rip scene; but could be very popular indeed for services that forbid or tightly restrict offline use in favor of streaming only and people who want access to that media when out and about without burning tons of cell data. Small screen makes resolution less of a concern and the fact that most phones don't exactly support simultaneous HDMI output and HDMI capture and encoding makes a pure software attack attractive.
This story of spammers trying to drum up support for the incumbent puerile attention whore of youtube almost makes me think that the Iranian social media crackdown will do them some good.
And that takes some doing. Good work guys.
I think that all reasonable friends of free enterprise can agree that this was merely some 911 prioritization; which is both a celebration of the first amendment rights of CenturyLink and will assuredly encourage further investment.
It isn't clear that "We have employers call us all the time (saying), 'I'm looking for low-wage, entry-level workers,'" means "skilled tradesmen wanted"; rather than "local housing prices mean that everyone as cheap as I want my labor to be has either moved away or is already working 3.5 jobs to make rent".
This isn't to say that a BA in something that's not terribly marketable is a better idea than relevant trade experience and qualification(it often isn't); but "looking for low-wage, entry-level workers" likely rules out skilled trades as much as it does BAs looking for the bottom rung of the white collar ladder; that's somebody looking for cheap landscaping and big-box service sector peons at lowest possible cost.
There was a somewhat uncomfortable period for anyone who wanted to sneakernet files to other people; floppies were cheap enough to give to someone who might not bring them back, flash drives not even close; but for personal storage the price difference wasn't so bad(helped by the fact that floppies had tepid reliability and were individually quite small, so the fact that you could buy a 100 pack and have 140mb of space for way less than a 128mb flash drive was less helpful in practice). CD-Rs also helped soften the blow: much more capacious and acceptably cheap for situations where you were not expecting them to return.
It's not as glamorous a reason; but the copyright situation is also a pretty strong argument in favor of a conservative approach; unless you are notable enough to have a shot at exceptions(in the US case that pretty much means Library of Congress and maybe a few fairly prestigious university libraries with law faculty interested in providing them some cover at below market rates).
Media that either has no DRM or uses a DRM system that is fully offline(books, CDs, DVDs) and which is/was sold in some lendable form is relatively easy to deal with because the right of libraries(and people generally, where First Sale or equivalent is law) to lend out copies of copyrighted media is well established.
Stuff with a DRM system that phones home in one way or another is more difficult because, while the library can lend copies, they can't make those copies actually useful without either the vendor's cooperation or legally and technically tricky DRM breaking. That makes it a troublesome part of a library collection. Software platform requirements make archive grade longevity tricky enough; the fact that much software is essentially designed to defeat resale or lending really, really, doesn't help.
Things that were never sold as lendable copies are also tricky; since, while the right of libraries to lend copies they purchase is well established, the right of libraries to make copies to lend is much weaker and more uncertain. This is a bit problem for archiving most of the internet. Some of it is explicitly and liberally licensed, which makes archiving a technical problem(and, compared to software, not too bad); but most of it either has no explicit license(in which case it's still copyrighted anywhere in Berne Convention territory; though the rightsholder is less likely to come after you, though also harder to find if you do want to do rights clearance) or is quite explicitly marked as copyrighted with an owner that is more or less energetic about enforcement. This is why the Internet Archive, despite its mission being all about preservation of parts of the web that would otherwise link-rot, has to cave so readily to takedown requests: most of what they do has relatively little support in law, so they have no choice but to cave if anyone objects and confine their efforts to the stuff whose owners are either apathetic or supportive.
That's the great thing about doing 'security'. You get to claim that going into pesky detail about what you did would aid the enemy and imperil the effectiveness of the defenses; which can keep scrutiny at bay well beyond the duration of your career.
In this case we can make some unflattering inferences, given that they apparently didn't have a remotely adequate system last week(or they would have used it rather than fail visibly for three days); and given that one tends not to put together a system of this sort of complexity in this amount of time(suggesting that, at best, a good plan was developed but then ignored; and more likely that the plan that supposedly exists now is ill tested and probably overstated); but barring a leak we won't see the specifics for at least a decade, probably several.
Is the complaint that the service being paid for isn't as advertised somehow more or less valid because of the overall affluence of the situation?
If the complaint were that degradations in prime service were a human rights violation or something the fact that the situation is vastly better than most of history would be relevant. In this case it's merely that Amazon either can't hack their attempts at further scaling out or is in the 'switch' phase of 'bait and switch', which a complaint purely relative to what prime service used to be; not some grand historical arc.
We surely can't expect Google to tailor Youtube's behavior to some Edge case; can we?
Nuclear, even from an optimist's perspective, seems to be an abjectly terrible idea for the more small scale/dispersed requirements. It's a pity; because some of its features are very attractive(radiothermal generators pretty much give you something that puts out the power of a decent size battery; except for several decades; all sorts of things that currently use a beefy diesel engine or generator are large enough to make use of a nuclear reactor without heroic minaturization efforts); but the more widely you distribute something the more often the owner is negligent or incompetent and doesn't really do things like 'maintenance' or 'disposal' properly.
The soviet use of radiothermal generators gave us a bunch of (not well sealed) Strontium 90 sources floating around, not necessarily even documented in the worse cases; use in commercial shipping would likely end up with a bunch of reactors ending up in one of the hellholes where shipbreaking is cheap because regulations are thin and workers largely expendable.
It's much easier to get adequate standards for operational competence when you have fewer specialist operators; but that rules out a lot of distributed applications. As it is, isotope sealed sources with assorted medical, industrial, and scientific applications already go missing all the time; increasing the number(and power) of those things being used out and about seems likely to go poorly.
The tricky bit will be dealing with the 'garbage in/garbage out' problem. As a technical matter any vaguely competent VCS, ideally with cryptographic signatures(whether integral to the design or bolted on; conveniently CACs and PIVs already support signing, so a lot of fed-level IDs do signing in addition to authentication) can keep track of who changed what when; but there is no technical fix for people dumping big ugly blobs that probably represent dozens or hundreds of internal changes into the publicly visible system as a single commit.
Even that beats the 'somebody changed something at some time, we think, because it's definitely changed now and we just passed it by voice vote' system we currently have; but I'd expect to see a lot of cases where a chunk of law, carefully prewritten, gets committed by someone's deniable junior staffer with all the care for mainline compatibility exhibited by a shoddy router vendor engaging in minimum-necessary GPL 'compliance' by vomiting forth their hideous BSP lump.
Can't beat the system once you do commit; and you can enforce at least one interaction with the system by mandating that the authoritative text of the law is the one that comes out of the VCS; but if someone is feeling uncooperative they can deny the system a lot of information by sticking to 11th hour giant blob commits.
It doesn't say which of their ships is being converted, so it's hard to say how much energy is required; but I think the important point is that the biogas is being produced, liquified, then used as fuel.
It's not an onboard fish-guts-to-power arrangement; it's a ship converted to run on liquefied natural gas which is provided ready for use at the dock; at least some of which is supposed to be sourced from organic waste decomposition.
That's vastly easier and more plausible. LNG is somewhat less dense than diesel; and requires more care in storage; but it's a perfectly viable fuel; and production of methane from organic waste is going to be easier and cheaper when you don't need something you can fit into a ship while leaving room for cargo and passengers. Landfills do it automatically when left to their own devices(though it's often not captured in these cases), there may be some arrangement that is preferred when methane, rather than waste disposal, is the goal.
None of this is to say that they'll actually end up carefully accounting for how much LNG they burn and ensuring it is all sourced from organic fish heads rather than ordinary natural gas; but even if they cheat on that it'll be much nicer than bunker fuel.
How useful the information is would likely depend on how clever the jamming was. Spewing enough noise to drown out some satellites broadcasting over a fairly wide area from 20,000km away(and not that loudly, I think the power budget for the block III satellites is ~4kw, for everything they do, not just broadcast power) isn't necessarily of much interest; though it might be slightly alarming how many people need a reminder that it isn't exactly difficult.
Exploiting the details of the implementation to allow jamming at power levels and/or duty cycles well below those of naive noisemaking is more interesting. Subtle injection of skew into the time or position results without being caught by any sanity checks is more interesting still.
I doubt it's the case; but I can only hope that he's departing to devote himself full time to penitence. He'd have to be a telemarketer to have done more in the service of injecting petty irritation into the lives of so many.
It's good that we understand how humans acquire natural language well enough that 'just make the computer do it that way' is a plan. Otherwise this might not actually work terribly well.
Luckily AI is used to this class of failure by now, so they'll probably be OK.
When we say "understand the world" we pretty much just want a 'terrorist'/'non-terrorist' breakdown; missiles aren't cheap.
There's also the issue(likely very significant in this case) that Tor does not (and doesn't claim to; and probably couldn't in principle, at least without significant redesign) protect you from endpoints inferring things about your traffic if it is interesting/identifiable in itself.
The onion routing and encryption of your traffic as it gets passed between the intermediate nodes breaks trivial identification of the origin of the traffic and keeps the intermediate nodes in the dark; but the exit node [i]must[/i] have access to your traffic(potentially not plaintext if you are communicating with a site that uses TLS) in exactly the form that the server you are communicating with expects.
If your traffic isn't intrinsically identifying; this is something to be aware of; but an improvement over the situation where the origin of your traffic is trivially available to everyone involved in getting it from source ot destination and back. If it is, though, Tor's protections get markedly less useful.
Contemporary systems can be chatty enough on the PC side(one of the reasons why specialty distros are commonly recommended for Tor use); is anyone crazy enough to expect a smartphone, exemplar of post-privacy computing, to not shed identifying information right and left?
Some devices already do that(unless they've changed it recently, Nvidia-SoC ones had fairly granular control over power vs. performance through a custom settings widget); and basically all of them do in the limited sense that they have 'battery saver' as an option that prunes power consumption in some areas.
I suspect that the cheaters aren't primarily motivated by confusion about how to implement this feature, though; but by the desire to get impossibly good numbers: if there is a slider the reviewer knows about they'll presumably run the battery and thermal benchmarks with it on the same setting they use for performance benchmarks; which will make it abundantly clear that there's a tradeoff, quite possibly a really harsh one. If you successfully sneak the settings past them you can potentially get performance benchmark numbers that would generate horrific battery life; and battery life numbers based on the handset mostly avoiding its most power hungry modes.
This is more of a laser vs. inkjet thing than a cheap consumer trash vs. 'workgroup' thing; but the very low duty cycles of common home uses are really an unfortunate match for inkjets.
This isn't to say that expensive print-shop inkjets are bulletproof or anything; but the cheap inkjet that gets used maybe a couple of times a month seems to be magnificently good at being clogged or dried out(maybe it'll come back after a 'cleaning' that consumes a substantial percentage of the cartridge, maybe not; but hey, the print head is probably part of the cartridge anyway..); while cheap and awful laser printers work pretty well for infrequent use because you won't wear them out that way, the per-page cost matters less; and toner doesn't tend to dry out or degrade under home conditions.
Inkjets just don't scale down to really cheap or infrequently used as well. It took a while for the cost of entry to laser to fall; but it has now; and scaled-down lasers are worse than nice ones; but don't tend to have the same really awful character defects as scaled-down inkjets; which are just terrible.
"The only potential difference in the market is the subscription model, where ink is included, and you pay for a certain number of prints per month. That offers an opportunity to be truly competitive."
You may not have had the...pleasure...of a copier lease. That's often the model used, so the hardware does tend to emphasize durability and actually sane consumables design(toner cartridges that aren't tightly coupled to transfer rollers, that sort of thing); but the vendors are utter dicks about basically everything else. Everything is gated behind a license key, including basic things like 'speak postscript'; 'value added' software like the various print management/document release/OCR integration stuff tends to be pretty janky; and the vendors have a relationship with their dealer networks and VARs unpleasantly reminiscent of the automobile industry.
Low end printers are utter trash by comparison; and companies that sell you toner cartridges, rather than 'managed print solutions', have an incentive to jerk you around on consumables that they often succumb to; but you don't get nonsense like having to pay your dealer to send a tech just to apply a firmware update; or having most of the actually useful configuration options locked behind a password that you don't receive.
I suspect the terms have the convenient feature of being a bit of both. It's not false that 'just use a never-updated internal copy of webkit as a minimum-effort cross platform porting tool" is vastly worse for security than using the actually-maintained platform tools for rendering potentially untrustworthy material. However, the rules as written also mean that no other browsers are allowed in the app store: you can slap your logo and few UI tweaks on Edge; but that's the extent of it. Basically the same arrangement as iOS; which isn't a good sign from the perspective of people who purchase Windows because it runs the programs they want rather than to enjoy Microsoft's Rich Consumer App Experiences.
It is a first world problem; but if you live in the first world that doesn't help you much.
In the educational context(which appears to be where this research was being done), things aren't going to go so well for you if you've got a household with contention over the computer and a bunch of homework that assumes you have one.