Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×

Comment Sure, why not? (Score 1) 351

At present, I probably wouldn't eat cultured tissue just because it's wildly expensive and only available in teeny little bits because the cardiovascular system is there for a reason in mammals; but if the tech were worked out what possible objection would there be to it?

Cruelty-free, so long as you don't grow the brain; and quite probably a lot cleaner than the authentically-butchered-in-its-own-entrails-and-hopefully-not-too-feces-smeared natural stuff. Less chance to pick up cool parasites and stuff in the field as well.

Comment Umm... (Score 1) 89

I'm confused by the issue here:

Yes, it is definitely true that digital forensics requires care to not munge the evidence and preserve its integrity; and that gets a lot harder if you are actively attacking a remote host that multiple other people have access to and can potentially also be altering, rather than just shoving an HDD into a write blocker and reading it back; but I'm unclear on why that relates to encryption.

Basically nothing you 'find' on a computer is actually meaningful without a layer of software interpretation(or, for simple formats, one skilled in the art running the algorithm in their head). Why is applying a decryption algorithm to an encrypted file different than, say, trusting an NTFS implementation to accurately take a partition full of meaningless garbage and present you with a filesystem; or a JPEG implementation to tell you whether a given sequence of bits is kiddie porn or not?

It is true that if encryption happens to be what turns a 'seize the server, grab images of the drives' investigation into a 'hack the server in an unknown location, malware the data out on the fly' investigation then, in a weak sense, I suppose that 'encryption' has complicated the investigation; but aside from that it doesn't seem any different than the usual problems with attribution of files, interpretation of formats, and so on.

Comment Re:C'mon, one google search to solve all your prob (Score 2) 726

Plus, you don't need to build your l33t rig just because you intend to do some gaming. If you don't want to build it yourself there are plenty of companies who will shove a tested combination of off the shelf components into a box for you, for a pretty modest premium over doing it yourself; and even a random Dell or the like probably just needs a better graphics card to be more than adequate for most games, since CPUs are mostly absurdly powerful.

Sure, the agony of trying to figure out why $1500 worth of parts won't POST after accidentally slicing your hand open on case sheet metal and without sufficient test equipment or spare components sucks; but that's largely irrelevant because it's totally optional.

Comment Re:Other motivations (Score 1) 164

Even among people who can afford hardware, there is a lot of effective consolidation because of 'pools'. These aren't irrational behavior: if you have a small amount of hashing capacity going it alone might pay off handsomely but will probably pay nothing, while pooling more or less guarantees a return proportional to your hashing capacity; but also leaves you largely at the mercy of the infrastructure.

Comment Re:Break TLS? Isn't it already broken? (Score 1) 65

I'm not anything approaching a cryptoanalyst; but my understanding is that TLS has been 'broken' at various times because of either implementation flaws or legacy-compatibility stuff not being dropped fast enough(and there's the minor problem of CAs being a total clusterfuck); but that these breaks were of the somewhat less scary kind that can be fixed by deprecating a specific cipher, or increasing a key length, or patching/replacing a specific flawed implementation.

A development of the 'hahaha, prime factorization is now trivial!' flavor would be the sort of ugly break where fundamental underlying assumptions are no longer correct and there no amount of incremental fixing will work.

Comment Re:fox guarding the chicken coop (Score 1) 65

It's really worth keeping a precise distinction in mind when talking about Google and privacy:

Google is clearly hell-bent on being as much of an Orwellian data overlord as possible; so trusting them to design products in such a way that they don't tend to leak data to Google during the course of routine use is foolish.

However, Google's approach to gathering alarming amounts of data is usually to make themselves attractive enough that they get invited in to the system(eg. gmail, google voice, 'free' google analytics for website operators, 'benevolently' hosting common javascript libraries so that you can save yourself bandwidth at the minor cost of inserting Google into every page load, that sort of thing.) They get the target to 'agree'(certainly they'll exploit ignorance and product tie-ins to do this, they are hardly committed to some idealistic vision of contracts between fully informed equals); rather than compromising the target's security and malwareing the data out. Presumably this is both because that would probably open them to legal exposure; and because an "insecurity and hacks" data collection mechanism would open the field to Google competitors who would do none of the work but get the same data just by compromising the system.

Because of this; Google actually tends to be pretty respectable in terms of design and implementation; sometimes even notably superior, in terms of quality of implementation and resistance to unauthorized 3rd parties. Chrome routinely scores very well in browser security comparisons, ChromeOS is also quite solid; Android usually doesn't turn into a dumpster fire until 3rd parties get involved, Gmail is better than an alarming number of sites about support for 2 factor authentication, and so on. It's just that all their products and services are designed to put them 'in the loop' by default and if you want everything to work smoothly, so that they have no need to compromise the system; because they are a trusted part of it.

If given the choice between a design where there is no need for anything to talk to the mothership and a design that relies on a Google account and being logged into Chrome and so on; they'll choose the latter every time; but when they set out to keep unauthorized parties out; they usually mean it, though they work to ensure that they are not 'unauthorized parties' in as many real world use cases as they can.

Comment Re:The irony.. (Score 1) 221

There's also the matter of which vendors have enough market power to push designs that enhance their bottom line; vs. vendors who pretty much have to throw in anything the customer might want because they are nearly interchangeable.

Omitting microSD is very attractive to handset vendors because the premium they charge for moving between storage 'tiers' tends to be exceedingly profitable. With Apple's current lineup, 16GB to 64GB or 64GB to 128GB are $100 bumps. I don't doubt that Apple is using nicer NAND than the people slapping together atrocious unbranded fleabay tablets or impulse-buy USB sticks; but that cost/GB($1.56/GB or $2.08/GB) is roughly what you'd see in an 'enterprise' PCIe NVME SSD(something like an Intel P3700) ; with consumer/enthusiast cost/GB more in the $.50/GB range from respectable brands. And that includes the price of the controller and packaging. If you have market power(as Apple does, since if you want an iDevice they are the only option; and as some Android vendors do to lesser degrees, thanks to having the must-have flagship of the moment, or strong brand awareness, or a telco deal or the like); margins like that make cutting the microSD slot very, very tempting; not because it's expensive to implement; but because offering it will eat into sales of your higher margin models.

If you are basically interchangeable with your multiple competitors, it's a much more sensible thing to include: microSD connectors are under a dollar in quantity one; substantially cheaper in volume, basically all common ARM SoCs have at least one SD or SDIO controller available; and the pin count and frequency aren't that heroic so it's not a terribly ugly thing to route from the SoC to the connector.

Comment Re:The irony.. (Score 1) 221

And, for backup(as well as ease of access across multiple devices) it is a fairly compelling offering; particularly for people who lack the skill, resources, or interest to handle administering a file server and supporting infrastructure themselves.

That, though, doesn't replace having a bunch of local storage for caching and offline use; it complements it. Even if cost is no object network latency makes grabbing something from a remote host slightly slower than pulling it from a local cache(unless your storage system is truly atrocious); locally cached data also allow you to make any intermittent connectivity losses(fairly common on wireless networks) invisible to the user; and allow you to do things(like video recording or taking a bunch of photos in quick succession) that produce markedly more data than you can safely assume your network connection can handle for a short period of time.

The 'cloud' certainly needs some improvements in terms of security and privacy; but being able to back up the contents of a client device that may be lost, stolen, broken, etc. and make them available to you on other devices is a pretty compelling set of features. It's just a quite different set of features from what a nice chunk of local storage offers: local storage isn't a backup, isn't conveniently accessible from other devices; but costs nothing to read/write to no matter where you are, is usually capable of higher speeds than your network interface is(unless it is egregiously lousy or you have a really, really, classy network; but cellphones aren't usually connected by 10GbE iSCSI HBAs or anything).

The point isn't that "I want an SD card because I'm a luddite who hates all networked filesystems or network file transfer mechanisms"; but "cache crops up in all sorts of areas of computer design where a bit of storage allows you to compensate for the deficiencies, in bandwidth, latency, reliability, or all of the above, of a bus; and given how little an adequate-but-not-thrilling SD card costs; having a generous chunk of cache to improve the apparent performance of a device that relies largely on wireless connections is an obvious win.

Comment Re:Recipe for disaster (Score 1) 73

The trouble is that one of the things malware can do is clean up after itself: exfiltration is much harder to hide from network logs(if the target actually has any); but unless you are hoping to remain undiscovered indefinitely, why wouldn't your exfiltration agent delete itself after its job is done?

Comment Re:Hooray (Score 1) 122

There was a brief burst of enthusiasm back in 2003 because the original 'support' for ipods on PCs was 'Musicmatch Jukebox'; a program so terrible that it made iTunes look like a blessing.

I can't really think of any situations since then when iTunes has looked like the better option; but there was that one.

Comment Re:Arr (Score 1) 147

From the looks of the PR renderings, they seem to be getting dangerously impractical in the pursuit of everything-will-be-white-and-curved-in-the-future aesthetics as it is. Yeah, futuristic and stuff; but ports are not going to be amused by anything that makes loading and unloading containers slower or more expensive.

Comment Re:I can see how this might be useful... (Score 1) 147

I doubt that the customers would want poison gas seeping into their products during shipping, even if Loyd's was up for the idea; but it wouldn't be a complete surprise to hear of an unmanned bulk carrier of some sort being flushed with dry nitrogen as a preservative; and some idiots encountering inert gas asphyxiation.

Slashdot Top Deals

"It says he made us all to be just like him. So if we're dumb, then god is dumb, and maybe even a little ugly on the side." -- Frank Zappa