Appropriate choice of words
"People's privacy and security is incredibly important..."
Right. I don't believe it.
655 posts • joined 19 Dec 2012
"People's privacy and security is incredibly important..."
Right. I don't believe it.
The hanging sentence in the article itself contains the word "frequency". I am guessing the original context was exactly what the OP meant.
While one may argue that adding a small chip to a motherboard is feasible, that it will only need to inject some extra/modified code into the loaded kernel at boot, will need only a small amount of power at that point, will be passive/dormant the rest of the time, and the actual spying will be done by the injected code in main memory, etc., what I could not understand from the start is how the gathered information (that may be very damaging indeed) will be sent stealthily to the mothership. Even less so, how it will be done from a data centre server that isn't even supposed to ever make outbound connections to the rest of the world.
Outbound traffic is routinely monitored, and a server trying to reach a machine outside of the organization will be detected fairly quickly by a serious player such as AMZN or AAPL. AAPL say as much in their letter to Congress.
I didn't see any statements anywhere that said, e.g., that any of the affected servers were involved in serving external requests. Even if they did, it would, IMHO, take too many miracles to arrange for useful and undetectable "steganography" in the responses. Besides, a machine service external requests is not likely to have the information that would justify such a complex hack.
Supply chain malware is nothing new and has been seen in the wild and it is usually its activity - either lateral movement or "phoning home" or both - that gives the game away.
IMHO, this is the most glaring hole in the Bloomberg story.
@AC: "How on earth are they making that sort of money of the sh*t platform that linkedin has become?"
I can only assume that those "premium accounts" that HR droids use are fairly expensive, and that there are enough HR/marketing/sales/whatever users who pay for them.
Disclaimer: no LinkedIn account here, premium or regular, so I woudn't know how sh*t they are.
The product may still be the best in category, and the huge security hole(s) may still be "minor" compared to the competition, for all I know.
@JohnFen: These days neither developers nor QA have much say in the release process - it is all decided by Product Management / Sales / Other Management. Who often think in terms of "Will it install without major headaches in a PoC environment by our qualified personnel who know where not to trod? Yes? Good enough..." Subsequent headaches bypass Product/Sales, VP R&D has his anatomy covered in front of CEO/board because Product signed off on the release, and the engineers are left to deal with the fallout...
We seem to be of a reasonably similar age...
I was almost ready to be as outraged as the next commentard, but then I recalled that when I worked for a Big Blue multinational ~15 years ago there was already a company policy in place regarding this. I travelled with a company laptop with lots of sensitive material on an encrypted disk. The policy said, "If you are asked to unlock the computer on any border in the world comply without arguing or questioning - even in countries that are more than likely to be interested in our commercial secrets. Any conceivable commercial damage is preferable to the hassle of extricating an employee from a dispute with foreign authorities."
So, it looks like NZ is merely catching up, at worst, and in a mild manner, comparatively speaking. Out of curiousity, how do such laws work in jurisdictions where there is a right to withhold potentially self-incriminating information when questioned by authorities (not sure about NZ, hell, not sure about UK, either - IANAL)? Are such rights suspended on the borders?
Oracle and Microsoft have been prohibiting benchmarks of their database software for many years...
So did VMware, as I recall - for quite a few years while the overhead of full virtualization led to inferior performance compared to native HW or paravirtualized machines. That was before Intel and AMD added HW support for virtualization (i.e. before, say, 2006). Today (with HW support) the overhead is not significant, and I believe the "no benchmark publishing" clause is no longer there (but I have not checked recently).
The industry is rather used to this. I am not very surprised that the likes of Red Hat and SuSE behave pragmatically and thus don't have a problem, or that Debian have.
@aks: I am missing something. How exactly will a pay-as-you-go SIM receive an SMS sent to a number assigned to the SIM you lost? What's the point of sending a verification code to a different number?
@DougS: you should be able to respond immediately while you in the store / on the phone with them.
Not if you've lost the SIM, which I suspect is the most common legitimate cause of a transfer request.
@Justthefacts: "Google cars have currently driven 120million miles..."
Citation needed. I got interested and checked (took me a few minutes). Waymo (Alphabet's autonomous vehicle arm that grew out of the X Lab project) reported 5M miles driven on public roads by February 2018. This is since October 2015, which on average means 2.5M miles/yr (if we assume that in the first few months there was a ramp-up from zero then we'll just count Feb 2016 through Feb 2018, OK for order of magnitude estimates?).
As a baseline for comparison, there are more than 250M registered car in the US (mostly passenger cars) driving on average 15K miles/yr. This is 1.5 MILLION times more miles per year than the whole of "Google's fleet". There are 6.3M road-accident related claims per year involving something like 12M vehicles (the numbers are from 2015-2016 and seem to be broadly consistent with each other). So, let's take 6.3M as a proxy for the number of accidents per year, including everything from fatalities to fender-benders, regardless of whose fault it is. To claim better safety, Google/Waymo must show less than 4.2 accidents/yr.
I found out that useful stats on Waymo accidents is not easy to unearth. E.g., Waymo's own "safety report" does not have the numbers, just the details on how hard they work on it. However, it is waaay higher than 4.2/yr. The graph here (some aspects look problematic, but it was easy to found) indicates something like 600-700 crashes per 100M miles (~30 over the 5M miles actually driven - seems correct as there certainly have been a few dozen reports) rather than ~168 (per 100M miles) that would put Waymo on a par with humans on average. The graph illustrates that the only two categories of drivers who are worse than Waymo are youngsters and very elderly (something that you point out, too, but then letting youngsters drive is the only way to make them safe drivers).
This, by the way, does not take into account at all how many accidents have been avoided by mandatory humans taking control.
So, for my money any claims that Waymo (in this case - and they seem to be the best in class, far ahead of competition) are already safer than humans are not confirmed at any level beyond handwaving. Statements like "94% of accidents are due to human error" are, by the way, pure handwaving: there is no one else in today's normal car who makes complex decisions, so the number is meaningless, apart from "car components don't break down and cause accidents often".
A <$100 device with a half-decent screen, phone, contacts, calendar, and maps, and maybe even a light-weight browser and an email client, and without all the storage-hogging stupid apps, from FB to Drive to Office to whatever, that I never use but can't remove without rooting / voiding warrantly / etc.?
Hell, I'll pay cash! A camera is nice to have, but not mandatory.
So have GitHub shared any stats regarding how many times the repo with Snapchat's code had been cloned before it was taken down via DMCA?
Worse than that. I can easily see a future when it will be (next to[*]) impossible to get any customer service except via Messenger, which will require a FB account, which, even if FB really do not get or store or use any of one's financial data (yeah, right...) will by itself be good for FB's "monthly active users" stats, hence share price, etc., etc.
Even if only a fraction of customer-rep interaction is delegated to chatbots banks are hoping to make a saving by reducing headcount, too.
Result: Zuck and other FB shareholders becomes richer, banks cut costs, service becomes worse...
And all that comes before storing, analyzing, and using the financial data for ads, or at least bragging about your unproven ability to increase efficacy of targeted ads with all that additional info, and before the info is sold to 3rd parties for all sorts of purposes.
Oh, and what about "shadow profiles"? How certain are we that banks will not provide FB access to our financial details and transactions without even checking if we have FB accounts in the first place? Frankly, I am scared.
[*] The "next to" qualification is included only because there may be a regulatory regime that mandates multiple customer service channels. I do not expect such a regime to specify availability, maximal response times, or any QoS/SLA whatsoever.
NoScript to the rescue
Take it half a step further: the login page may not work without JS, but it is probably irrelevant for non-customers.
it would disable the machine doing the port scanning...
...which is your machine, and behind iptables, innit?
Have they tested massively parallel workloads, such as partial differential equations solving? This is a typical HPC problem, and it seems different from the "computationally intensive code" they analysed. Pure number-crunching does not use much I/O or system calls indeed. For parallelized derivative computation you will need to exchange information between the nodes working in parallel though - this is why low latency networks are so important in HPC systems. And that means I/O.
That does not necessarily mean system calls, especially if the information exchange is facilitated by RDMA-capable HW - the kernel may be bypassed.
Enquiring minds want to know, etc., etc. ...
...but we can't do it faster than the speed of light, despite all out "innovation".
[Sounds better to me than the "can't put a man on the Sun" retort: we can, in principle, send the FBI Director to the Sun. He won't survive for long, but that's a different matter.]
1. A $BIG_CORP is concerned about potential questionable uses of its face recognition tech. Fine.
2. The $BIG_CORP urges the legislators of its home country to regulate things like whether or not the $BIG_CORP should ask their users for permission to use the tech on the user's devices. Huh? If that's what makes your peace and quite, why don't you just start asking your users before/without any regulation? And as for 3rd party, e.g., government use of your tech they license or buy, first, things that you are concerned about are already illegal, and secondly, feel free to put restrictions into contracts/licenses. Oh, you are concerned that your competitors will not be as scrupulous or conscientious? How much is your conscience worth to you then?
3. Whether or not regulation is passed, the same $BIG_CORP will undoubtedly hide the users' automatic consent somewhere on page 739 of legalese of the T&C that users will be deemed to have agreed to by
reading the text clicking on the link or checking a box, and the opt-out process will be phenomenally convoluted and impractical.
Dear MSFT, by now you are a grown-up, you don't need your
parents' government's help to do stuff.
This only highlights the fact that the whole sham of "signing" has nothing to do with security, but only with an "Ah, don't worry, this rascal of a program comes from a good family (that we don't know at all, they have actually just moved into town)" certificate. Those AV tools look for the cert and that's their only decision point.
Some time ago we got a Windows executable signed to avoid exactly this kind of problem. The only check that was ever done was running the executable with a specific configuration file that we provided, if that. Certainly no one checked whether a different set of configuration parameters launches ICBMs or whatever. Basically, no one except us, the vendor, is any wiser about what it does after signing (it's benign, I assure you, it's actually a part of a security product, and our customers trust us, anyway). But it's signed, so there.
Getting that headcount down is sure to shrink the gap, right? Right?
Eh... no. Not the way you phrase it, at least. Not if you just push headcount down at random. If you do it may go either way. The sample gets smaller, and the probability of getting an outlier result, in this case a pay gap much higher or much lower than the average, gets higher. So while after a drastic RIF the chances to get a pay gap very different from the average become better, the outcome will not necessarily be in the desired direction.
If you orchestrate the layoffs with a gap reduction in mind or, for instance, if you tend to fire quite a few senior (overpaid, or experienced, or valuable, or expensive for any other reason) males that contribute significantly to the pre-layoff pay gap then your RIF may well result in a lower gender pay gap.
Specifically, one of the common arguments about the gender pay gap is that women tend to be, on average, less experienced, less senior, less promoted than men because of they time they take off for maternity / child care. If senior / experienced people are laid off with a higher probability - because they are more expensive and firing them will result in bigger savings - then that would tend to reduce pay gap as a side effect.
[Disclaimer: this is quite independent of any discussion of whether not correcting for this natural disadvantage is fair or unfair. That is a different question altogether.]
AI for spacecraft? Made by IBM? HAL, is that you?
I visit Italy often and I speak the language, but I do not live there. Nor have I got an Italian credit card. As for Italian petrol stations, I can confirm that normally you fill up, go into the store, and pay at the till. Unless...
One very late night some years ago I was driving along a strada statale with an Italian friend of mine as a passenger, and I was low on petrol. The next distributore ("petrol station" in inglese) down the road was dark and deserted, but I figured I would manage to swipe my card and fill up. The machine asked for a PIN which I dutifully punched in only to see that there was a 5th position and a cursor blinking. Pressing "OK" (or "Continue" or whatever the green button said) didn't work, and I could not find any way to make the machine accept my woefully inadequate 4-digit PIN. Exasperated, I turned to my friend and asked, "Do you really have 5-digit PIN codes for you credit cards?" With a confused look on her face, the widely traveled university professor responded, "I wouldn't know. I haven't got a credit card."
The solution was to feed the machine some cash, of course. Trying to prepend the PIN with a zero never occurred to me.
Thank you for the useful tip for my future trips. I won't Forget It.
@Ian Emery: I found that out years and years ago; multiple online translation programs converted English "bread and water" in to Russian "bad food".
Actually, that is likely to be an artefact of an idiom rather than an adversarial typo: for a Russian "to sit/live on bread and water" means to be constantly hungry, either due to extreme poverty or due to some illness or another reason that does not permit one to eat normal food. The translation apparently preferred the idiom (and bungled it a bit) to the literal meaning.
So why not outlaw keeping the data (and metadata) that provide "near perfect surveillance" capabilities for any length of time beyond providing the requested service? Or even collecting such data except in cases where the service (to the end user!) where the service cannot be provided without it? Motivation: no one in a free, democratic society should have "near perfect surveillance" capabilities, neither corporations nor the police. The potential for abuse outweighs any possible usefulness by orders of magnitude.
Then the question whether such data can be retrieved from a third party without a warrant will not even arise...
Yes, I realize this suggestion is for the legislative branch to consider, not for the courts.
No, I will not regard any "think of the terrorists" arguments as valid. Such arguments are not fundamentally distinct from the case in question where a string of violent crimes (robberies) was committed. A bit of help proving the criminals', even terrorists' (who are not even a very big problem, statistically speaking), whereabouts after they have been caught is not a justification for keeping everyone under "near perfect surveillance". Real time surveillance (while the service is being provided), needed for the "ticking bomb" situation, is covered.
Flipping several settings / Bluetooth on, open maps, turn off Wi-Fi, turn on GPS, turn on selective call blocking every time I get in the car is a pain.
Nokia's old "dumb" phones of 15+ years ago did not have all the goodies that a modern Samsung has, but they had this amazing thing called (IIRC) "profiles". You could change multiple settings on your phone by switching between custom "profiles", which was one operation. I used to have a "meeting" profile (the phone was silent/on vibration, among other things), "car" profile ( screen lock off, voice operation, etc.), and so on. Seems to be a lost art now, just like the integrated calendar and contact list that I miss so much (set a meeting with someone in your contact list by actually accessing the contact list from the calendar, when the reminder beeps and you are still stuck in traffic there is a friendly green button that dials the right number so you can apologize for being late without fiddling with the contact list while driving - worked amazingly well in the previous millennium...)
I would love to see profiles. It would make my phone so much "smarter". The next best thing would be to react to being connected to my car's Bluetooth (as opposed to any other Bluetooth) to reconfigure just about everyhting.
What's with the reference to Denmark (here and in the main article)? Vasa is/was a Swedish shp.
Stroustroup is Danish.
(This is not intended as support for stings against Danes, in either articles or comments.)
>> To the wild west.2.0
> East, technically.
Well, technically also West of the (previous) California Gold Rush...
You appear to know something about technology and that would hinder some attorney's ability to submit garbage into evidence and have it accepted unquestioned.
And my naive idealism clings, against all hope, to the completely unrealistic notion that one should be judged "by a jury of one's peers", which in this case would imply, IMHO, inclusion of at least a couple of qualified security researchers who could judge from experience where the aforementioned "fence" stands.
But we won't.
somebody has died needlessly
And let's not forget the people in the other cars that were directly hit by the Tesla - the Audi and the Mazda. It is not clear to me if they were hurt, but they could have been. Even if they didn't suffer as much as a scratch there is a lot of damage to their property. And in this and in other similar situations quite a few other drivers may have to swerve, brake hard, and in general take extreme evasive action, putting themselves, their passengers/families, and yet other people at risk through no fault of their own.
Of all the people involved, only one bought the new shiny Tesla, engaged the Autopilot, trusted it to a degree, mistakenly or not, ... In a situation like this they all are innocent victims, whether or not the Tesla driver was partially responsible. It seems clear from the description that Tesla are at least partially responsible, and all those other people on the road should be a factor in their requirements, design, implementation, testing, marketing, etc., as much or more than the driver probably, because he driver is supposed to have more information and act accordingly. Other drivers may not even realize the car in the next lane is a Tesla (just that it is blue), may be on Autopilot, its driver may be out of control for many seconds, etc.
It's about hardware and software. Obviously.
You would be surprised what 30K tons moving at 10 knots can do to anything if they hit it.
<pedantic>Actually, just half of what you think it can. </pedantic>
And maybe no really important information to protect? So no real reason to invest in security? Easy to remember creds on a shared system, and who cares if they are weak?
Maybe these guys are not completely daft, after all. The article seems to suggest the white hats didn't manage to do much even with everything they discovered...
Not sure why the bad guys had any history. That may cause some information leakage (though it seems to have leaked their competitors' IP addresses only in this case, eh?). That actually does sound like development infrastructure left in "production" code by negligence...
The only use case for the "screenpad" that I can think of is, maybe, when one makes presentations: the main screen will be projected onto the big screen/TV/whatever and show the presentation, while the small screen will contain notes and other stuff the audience should not see. The presenter will face both screens simultaneously and will not do much on the keyboard during the talk.
But that's a stretch as far as selling power goes.
I smell blockchain...
"Public on the Internet" vs. "private"... Hmmm... What might that mean?
To quote the problem description, ...the misconfiguration happens when Groups Visibility is configured to “Public on the Internet”.
I am sorry, but I don't find this confusing at all. Nor is it “complex terminology”, IMHO. All it is is PEBCAK.
I am not arguing against GDPR, for ICANN, or in favor of US laws superseding European or German ones. Not at all. Having said that, Tucows' argument that for "the vast majority" of registered domains owner, admin, and tech contacts are the same and thus there is no need to collect all three seems strange. Even if those are different only in a small fraction of cases, it seems to me there may well be reasons for them to be different, and thus they need to be collected for legitimate operational purposes.
E.g., imagine an organization that wants to register a .de domain. Someone else here has already pointed out that one needs to be in Germany and have a German address to do that. That's the "owner", right? However, for administrative purposes, e.g., billing, someone else, maybe the company's finance department in another country, should be contacted (surely you've provided a separate "billing address" many times). That's a separate "admin" contact then. And technical/operational issues are handled by a third party - hell, the organization may not even have IT staff but still needs internet presence. That's a "technical contact", separate again. It does not seem to be far-fetched at all...
The registration procedure may have checkboxes saying "use the above address as your admin/tech contact" to avoid duplication (IIRC, this is similar to what AMZN do when you buy something from them - there is a checkbox to indicate that the billing address is the same as the delivery address), but in principle it makes perfect sense to me that the three contacts are logically independent and all are needed to complete the registration.
1. Mandate some metadata marking of job ads as such. Also mandate further job ad metadata to specify location, industry, category, title, etc.
2. Forbid restricting job ads by age/race/religion/whatever (this is probably in line with the existing laws in most enlightened countries, but IANAL).
3. Devise a way to tell ad blockers to filter out everything but job ads, based on the ad metadata. Utilize the metadata from item 1 above to further narrow things down. Filter out everything that does not follow the standards of item 1 above.
4. Sue the pants off anyone who does not follow the rules. Channel the fines collected to development of ad blockers (one can hope, can't one?).
Potential employers/advertizers have an incentive to follow the rules because they should be interested in having a wide audience (beyond complying to laws). The filtering will be done by people looking for employment. Ad flingers and ad brokers will avoid legal troubles as long as they enforce the simple rules of item 1...
There may or may not be a law specifying that customers must be reimbursed by money paid up front for goods or services that were not delivered as promised. Nevertheless, isn't it customary to contractually specify the penalty for defaulting on one's obligation? People really write checks for $5K without asking "what happens if"? Oh, I forgot: new and shiny...
...who must have realized that the technology may be used to waste annoying callers' time and money.
...for Turing tests?
I thought anti-doping agencies grabbed athletes for mandatory urine samples after competition and maybe also periodically (presumably to make sure someone who uses forbidden performance-enhancing substances gets a place on the national team and hurts the country's reputation if caught). I also thought athletes could not refuse those tests if they wanted to compete. I also thought this was not law enforcement, and that performance-enhancing substances in general are not illegal unless one competes in official events.
Where does hacking phones fit in? And how can it possibly be justified? Even Down Under...
@Lee D - I am not entirely sure what exactly you input into the various fields of that online calculator.
I just rely on my own understanding of kinematics for order of magnitude estimates. With constant deceleration the braking distance (i.e., without taking into account the driver's reaction time that can easily be 0.7s for an alert driver, adding ~18m at 96.6km/h to the stopping distance) is
x = vt - at^2/2
where v=96.6km/h is the initial velocity and a is the deceleration that we want to compute. The deceleration time is t=v/a, which yields
a = v^2/(2x) = (96600m/3600s)^2/(2*46.3m) = 7.3 m/s^2 ~ 0.75g
for the Tesla. It is not clear to me what exactly "far worse" means in the context, but presumably other cars get closer to 1g and the corresponding 35m (115ft) that other posters assert as the best in class.
...that he actually forgot to put the SD in?
Or could it be that the SD was in, but cosmic rays, the freezing cold of the vacuum, the temperature gradients across the GoPro, or something else affected the contacts or the general operation of the camera resulting in the "No SD" message?
2FA is supposed to help with the problem that your privates will be swiped if anyone steals or guesses your password. However, it brings on bigger problems, IMHO, such as lock-outs, without any breach at all, in case something happens to your second factor/token. That problem is independent of using something insecure such as SMS.
For something work-related 2FA is probably fine in most cases. If my phone/token gets lost or borked or whatever while I am traveling, but I can call a sysadmin/security admin who knows me and recognizes my voice and resets/reconfigures the 2nd factor so that I can access what I need with a different phone (or without 2FA until I get back from the trip), the problem can be mitigated. I am not sure many organizations have protocols/procedures for that, but it is possible.
I would not use 2FA with something like GMail, however. If something happens to my phone I do not, for the life of me, understand what the process to convince Google, in a reasonable amount of time at least, that it is really me and not some impostor who wants to reset the 2nd factor might be.
2FA by SMS is stupid not only because SMS is insecure, but because it simply does not work. I travel with a different SMS/phone number and messages sent to my normal number simply won't reach me (calls will). Not a problem, unless/until I need those messages to access essential services...
I still haven't figured out how I would deal with online credit card payments - those "Verified by Visa" and similar mechanisms - while on the road. Somehow I managed to avoid that until now. I suppose I can bring the "domestic" SIM with me and swap it in temporarily and pay for the incoming SMS, so it may be doable, albeit quite inconvenient/costly.
Ironically, I assume that in a pinch I can convince the credit card company to reset the second factor on the basis of KBA over the phone. This means that the 2FA is only as secure as KBA, anyway.
How much noise does a typical mining rig - one that would be powerful enough to contribute significantly to keeping a room warm - generate?
Biting the hand that feeds IT © 1998–2018