evilDagmar

This sounds like he'd spent time low-balling on salaries until he'd collected a cadre of people only barely interested in their work. It doesn't take much to make those people completely disinterested in doing more than marking time.

If you're hiring people who are engaged and genuinely interested in what they're doing and giving them a reasonable workload(!), they're likely to just treat that day as a day they can work from home with the option to not do work if life suddenly has plans for them.

XKCD-style admins, for instance, are likely to just spend that day spitballing ways to reduce downtime (which make the other 32 hours less annoying) and hardening infrastructure without having to worry about producing results. Planning is everything for that sort of work. My occasional work-from-home days were frequently days when I'd get a positively lurid number of things done just because of fewer interruptions.

Their ethical obligation would also be to err towards full disclosure, not away from it.

Google's original view of the situation was that installers like this make devices measurably less secure (to which Epic's response was pretty meh), and the installer being exploitable to install pretty much anything only proved that point and then some.

...and frankly, it would not matter who wrote the installer if it got used for a mass infection and attack. Google would still get the bad press and a generous helping of blame because of the trashy way so many "tech reporters" behave to get those mouse clicks.

One only has to work in IT security for a relatively short span to see ample evidence that humans are not generally concious.

Perhaps they would do well to realize that if someone uses a "joke licence" they are implicitly stating that the code in question, according to their personal standards, probably isn't suitable for production environments. In some offices however, this same code might be viewed as worth trying to build a blockchain currency system with. Coughcough*

Programmers write things all the time that they wouldn't inflict on anyone else. They're written to get a one-time thing done and no more than that, however, they do sometimes realize that someone else might be facing that very same one-time problem, so there's no harm in at least letting other people play with said abomination.

In this case the point of the licence is that the original author knows they have done something terrible and/or inadvisable (probably out of desperation), but still... The code worked once and it might be useful to someone else in a bind, but the author absolutely does not want anything to do with whatever new problem it was leveraged against, or the fallout if this time it doesn't work.

A licence is not provided with free software in order to convince you that you should use that person's code. It's provided because some people are just shirty enough to steal other people's work, claim it for themselves, and then eventually sue the original author for copyright infringement.

This is up there with buffer overflow bugs (is counting really that hard?) for things we bitch about all the time, yet somehow developers manage to ignore it.

This type of screwup goes all the way back to DOS days and beyond with similar stunts being attempted with unix tar.

While we're at it, let's repackage people using terrible passwords as a newly discovered widespread problem.

This situation has never shown signs of improvement.

Reminder: That didn't stop them from converting HoTMail over to NT/Exchange.

No, it does not need to "print and burn", but if you'd like to begin buying some from me for $1.10 each, I'll happily accommodate you in large quantities if you can comply with KYC.

No, they don't need to print more tether to protect the price. The price of tether is locked to $1.

The other allegation (which is pretty viable) was with large reserves to play with, they could cause crashes or spikes in order to gobble up their users risky shorts. Shorts they would know the exact number and values of.

What makes it easier is having fixed goals in mind, because I am seeing a lot of people in this thread arguing because they're all solving different problems which is obviously going to mean different solutions.

If your only concern is passive tracking, then a randomized MAC being used for SSID probes (because whitelist-only hidden SSIDs are rare enough that those people can manually connect) will be sufficient.

If you're looking to keep an open Wifi provider from tracking you over the course of days, then using a different MAC for each connect is going to be sufficient.

If you're looking to avoid tracking by people doing traffic analysis to correlate by behaviour no amount of MAC trickery will help you.

If one is looking to avoid having to pay for overstaying their visit at a coffee house or similar capture portal, maybe what needs to be changed is one's sense of ethics, and changing a MAC won't help with that.

So, you can say "it should be a default" all you like, but everyone's going to have a different idea of what the default is for and they're going to throw a fit about it not being "the right default". Better to be conservative like Android and avoid inciting the newbs.

Hopefully just the process of watching all connections break and seeing the internet go away as the client reassociates with the AP each time they foolishly tumble their MAC on an _active_ connection will be enough to keep this scenario from ever playing out.

This requires that Windows knows about the exact size of the display, but Windows cuts a few corners there so it's unlikely to be as precise as an 8.5x11 piece of paper.

Compounding the problem is that the operating system relies on the monitor reporting its physical size correctly via EDID and for a lot of vendors (most notoriously Dell) this isn't guaranteed either.

Not to be "that nerd" but it wasn't an accident. The writers actually performed a fairly elegant retconning to explain the difference in appearance between the Klingons as they appeared in multiple series.

Actually, on many if not most devices you can just 'cast' the entire display to a Chromecast, which is inexpensive enough that it's unlikely anyone's going to bother developing a replacement mechanism. The nearest thing to that is MHL, which is apparently encumbered by licencing issues and requires use of the USB port (which means that an OTG adapter for attaching mouse/keyboard is now out of the question).

I think the phrase you're looking for is stalking horse.

No. It only cares about unlocked bootloaders on devices that shipped with Android 7 because a requirement of shipping with that was hardware support facilitating dm_verity, which is essentially a check that the bootloader wasn't tampered with. Without the necessary hardware there's simply no way to perform this check in anything resembling a reliable fashion.

Also, neither root not an unlocked bootloader is required to make "proper backups". Some data actually can't be backed up, and for some data there is no point in making a backup. If the goal is to be able to restore the system to a specific, known state, a bit-for-bit image backup of the entire filesystem is just one way to accomplish the task.

No, they'll still be at fault because if you have a massive pile of highly sensitive data online, and all it takes is one vulnerability to get at it all, then your security model was awful.

Was this database typically accessed with broad-sweeping queries that could snarf large amounts of it at once, or was it the sort of thing where a few specific keys were used to identify a single client record? My thinking is that it was probably the latter, and if that's the case then another layer of security should have been in place there. Stored procedures can be used to require very specific queries to access very specific records--this falls under the "prevention" category. Next, monitors should be deployed so that someone gets notified right away if some session makes a large number of successive queries to get around the restriction--this goes under the heading of "detection". These two things would have been able to prevent attackers getting the goods with just one exploit.

...yet companies regularly fail to take these kinds of simple and rational steps seriously, and then act like it was all just too hard for anyone to possibly defend against.

A guy who has his own garage would have some assets... which would be a step up for most ICOs.

That has no bearing here because it's not the user mis-clicking on the link, but the app in question deliberately following a link on behalf of the user with the stated goal of causing harm.

That's not really likely to help. The main issue appears to be that since fontconfig (a lib used by GIMP) is only "native" to Linux, for it to know about the TTF files, it has to scan them all and build it's cache at startup. For people with hundreds of fonts installed it can be a real PITA.

I avoid it by being careful to not exit GIMP entirely (simply closing all the editing windows) until I am sure I won't need it again for awhile.

I'm sure a lot of people will take "the free money" but it would also mean Coinbase has to write a lot of code to handle those transactions separately, and do so in a very short span of time, oh and that code would need to be safe to put millions of dollars through.

Sounds like time to call the local Nope dealer and tell him he's got some stuff competition.

Thank you. Finally someone said it. This was not the least bit counterintuitive to anyone familiar with randomness.

We're they trying to imply that people should assume the distribution would remain uniform?. That strikes me as more "insane" than intuitive.

It's simply a function of how the tokens are being exchanged that would almost require some actors get the short straw, and since this is happening 100 times per round, that randomness ensure some actors get progressively shorter straws over time, because randomness is neither fair, not even. It's randomness.

I'd like to take a moment to point out that the actual Copyright Act which BMG et al. are so freely waving about has a section that explicitly states that after a certain amount of time, these products are supposed to go into the public domain.

I'm not sure I can really respect their claims when it's clear from their behaviour (DRM, perpetually lobbying to extend the time periods, etc) that they themselves have no intention of heeding the Copyright Act.

...because something can't go to the public domain if no one has useable copies of anything .

This particular tool is somewhat unimpressive.

From what's shown in the article it's likely only usable on RedHat-derivatives (because of the binary-only kernel module). There are already "amateur" rootkits out there, with what's almost certainly a better feature set.

I am particularly unimpressed with the documentation's suggestion to rm the module afterwards, as the systems in question are extremely likely to have the shred command installed (which first overwrites the file contents in-place) which would make it impossible for a quick examiner to simply undelete the module for analysis.

I think this was some agent's idea of a PoC more than something they expected to use.

Yeah, excepting that a label exec would immediately scoop them up to be produced as remix singles, to be released in stages over the next six months on iTunes, Amazon, and Google Play for $1.29 apiece, whether you liked them or not.

Uhh... It mounts after downloading? Aside from that I doubt (or don't want to believe) that's what's happening... Doesn't that sound inherently dangerous to you? We've seen files that could infect Windows machines just from having the file browser look directly at them.

If they did they personally lost quite a bit of money in the process. Just the initial sell resulted in a very large number of their coins selling for below the market average (because there's more exchanges than just Coinbase/GDAX). Those ten cent buys won't make up that difference.

This looked like one sizeable market sell that wiped out a large portion of the buy orders on the book, leaving the remaining buy orders starting the way down at ~$210. This (somewhat predictably) triggered a bunch of people's stops, causing their ETH to be sold at market and pushing the price down even further, triggering more stops, and so on and so on. People should really have paid attention to that not-so-fine print when GDAX added stops because it clearly said that they'd cause a market trade, meaning that if you set a stop to trigger at $250, you would not be guaranteed to get $250, but instead get whatever the highest remaining orders on the book would be.

(Disclaimer: I am not a market specialist, I just read carefully before I go clicking on things.)

Oh yes, it was right there in the log. Whoever that was is probably still trying to wrap their head around that it actually happened (and checking with an accountant because the IRS will be wanting a little chat).