Any smartphone sold in Europe should integrate AML, or be banned outright.
So are you intending to take personal responsibility for all the deaths your recommendation will cause?
I know I would be pretty pissed off at you if you are the sole reason my phone costs more, and does literally nothing that it didn't do before simply because I don't live in the UK part of Europe.
Anyone in any European country that isn't the UK specifically has no infrastructure or support for AML, so it will do nothing when calling emergency services.
But now Apple must pay to add additional hardware, and pay all the Google licensing fees for their AML technology, all to ultimately be not supported in nearly all of the EU.
YOU claimed it would save lives, when it clearly will not and can not. That puts those lives on your head.
That's exactly why I said a temp worker shouldn't consider this an option, even if the current company was paying for the implant.
As for removal, and this applies to anyone thinking about getting one of these, one should keep in mind installation is much simpler all around than removal is.
Installation is fast (~15 minutes), being injected under the skin by a tool looking like a novelty sized needle, done under local anesthetic at a doctors office.
Removal would require cutting the skin open, and then stitches or an equivalent, along with the proper after care to prevent infections. I guess it could be done under local anesthetic. That's how guys get their tubes tied after all, which IMHO is far more horrible to think about...
Basically it would be FAR better to think of this as a one-way trip for the chip: in, not to come out again.
If you aren't squeamish, you can do a google image search on "rfid chip implanting" *shiver*
I was speaking of badge cards being issued, not implants.
Generally companies in the US don't tend to define temps or contractors as employees, but I can't say if that's the case here. Neither the article nor the article in the article is too clear, but it does say "offering ALL employees"...
Seeing as it only costs about $50 or less to have the same chip implanted in your cat or dog, even with the insane US healthcare prices it's not like the process is a huge investment of money.
Either way though, the solution is no different than for employees not wanting an implant. Just issue them a NFC badge like before.
That assumes they use the same tags, which is not a safe assumption.
Perhaps not a safe assumption between different companies, but at least purely going by the description given in this example I think it is a good assumption.
Obviously one can use any non-standard protocol over NFC they wish, but there are ISO standards for this sort of thing that are inter-compatible.
That is also the assumption smartphone makers use which mostly works out OK. NFC equipped phones can speak ISO standards, and any proprietary standards for payment/credit type processing (think apple pay)
In this case they talk about using the same NFC tag over a wide range of readers and systems. If any one of those systems was proprietary, it wouldn't at all work with the other ones. It almost needs to be using an ISO standard just for the entire campus to work together, so it is very likely these implantable NFC chips are using an ISO standard.
One of the other benefits to using ISO over NFC is that you can "offer" to employees the ability to use their smartphone as a badge, instead of actually issuing them a badge. From the user point of view, since a phone can be loaded up with a bunch of NFC IDs at once this can be easier than carrying a ton of badge cards. From an employer point of view, that's one less badge to issue and pay for.
But over all you are correct. The next company you work for may be a smaller one that only has a single badge system, say just to open the doors for you. With only one system that doesn't have anything else to "play well together" with, there's nothing preventing them from going with a crappy brand or provider that uses a proprietary badge. It may not even be NFC but older RFID, which would be completely incompatible.
I'm fairly sure our temp agency has contracts with their workers to return company property. But I work in IT, not in HR, so I'm not really sure how that all is handled.
From my end of things, over a decade of working here I've only had two individuals come to me asking for replacement badges. In one case the badge was snapped in half nearly all the way through, although this was after 12+ years of use. In the other case the person lost their badge, and this was after a couple years of employment as well.
In both cases I just issued new badges and deactivated the old ones. We didn't charge the employees anything. Seems a bit petty for an honest mistake over what is in essence a $2 badge we order 100 at a time of.
If someone made a frequent habit of losing their card we might invoke the replacement fee clause, but it's never been an issue yet.
RFID cards tend to heavily rely on having a site ID pre-programmed at the factory, but at least when it comes to the NFC ISO standard there is no site ID anymore, just a very long unique ID.
This is the take that smartphones equipped with NFC hardware utilize, mainly for compatibility sake. I would very much hope the implantable NFC chips are also using this same standard.
Obviously one can use any protocol over NFC including proprietary ones, and it seems some banking type cards do exactly that, but it seems in most of those cases you wouldn't even get compatibility with all of your own readers let alone anyone else.
Since these people mention using it for more than a single task over their campus, I'd tend to believe them regarding using an NFC standard like ISO. It would be difficult if not close to impossible to accomplish otherwise.
That's not how either of those items work however.
Then you get another RFID tag for your next employer, and the reader has to try to read them both and check them both every time you want a pack of gum. Then you go to a fourth and a fifth employer, and your doctor is getting concerned about the amount of foreign material in the limited space in your hand.
No you just have the one single implant. The previous company removes your NFC ID from their systems, and the new company adds that NFC ID to theirs.
My company uses a badge for doors and the snack machine uses that and a PIN. The same thing can be done with the card number, and it doesn't stay with me for life.
Actually the badge ID system is used on the assumption that your badge WILL stay with you, or at least accounts for that possibility.
Yes they ask that the badge be returned, simply because it cost up to $2 and can be reused. But the system doesn't assume it will be returned, and that's why the ID linked to the badge is disabled in their system when you leave, returned or not.
It's always a possibility an employee simply stops showing up for work never to be seen again. The requirement to lock them out of the premises upon termination needs to be handled without physically requiring anything from the now ex-employee.
Most employee handbooks that require signing contain some form of clause of what happens when a badge card, or any other company property for that matter, is not returned. Some don't care, some make you agree to pay a fine for the badge.
There is also the situation of losing a badge ID, ranging from "I dunno where I left it" to "I got mugged last night" Those badges need disabled just the same since you have no idea who if anyone has possession of it now, and some companies stick their logo and name right on the thing making it brain dead simple to know where to attempt to use it.
Our system even has separate flags on the badge ID for "Lost, Claimed" and "Lost, Destroyed" The second one is only to be set when HR or IT physically destroys a card themselves (Say it cracked or popped open, in this case you run it through the heavy duty shredder and flag it as destroyed) The "Lost, Claimed" option is when the employee claims it is lost but this is unconfirmed. It allows the card to be "unlost" and reissued in the future, while the destroyed option removes it from the list of available IDs.
There is no reason an NFC system would need to work any different from an RFID system, other than accounting for the much longer unique ID field.
The slashdot summary originally said "200S" instead of "about 200 microseconds" It was silently changed without an update message saying so.
I too was very confused when I first read it, both that a capitol S and no space isn't any standard notation I know of, and that the only interpretation was 200 seconds which made no sense at all.
You are absolutely correct, you were not one of the people using the term "forced" nor redefining it. I apologize for my mistake.
But you still keep referring to the GPL removing freedoms. You are aware that it is copyright law that removes your freedom to, as you say, to be able to do what one wants.
The GPL, like most licenses, actually *counters* the removal of rights that copyright law forces on you.
As you say, it may not grant you all the rights you wish to have, but not giving you something is quite different from taking something you do have away. Copyright law takes nearly everything away, and the license gives it back to you.
I don't think I understand what you are meaning to say.
Yes, those are valid concerns when writing your own code and hiring someone to write code for you...
But compared to the other options listed (using code under another license, and using GPL code while agreeing to the GPL), plus the option the parent poster said was preferable, namely using GPL code while violating copyright laws in doing so, I'm fairly certain all of those have the same patent risk just the same.
Even purchasing a license to commercial closed code isn't free of those risks. Although if the commercial entity you purchase the code from is also the patent holder for the process it works by, your risk is greatly reduced at least so far as being sued for a patent violation.
As for the problem of "being accused of a crime you didn't commit", at least in the US, this is a risk everyone is exposed to no matter what they do in life. Unfortunately that can happen if you stay in bed sleeping for 23 hours a day, if you happen to piss off the wrong person in you one waking hour.
As a warning to people, fair enough. I just don't see what any of those have to do with the "need" to violate copyright laws like the parent was saying is the best option regarding copyright licenses.
It however do allow people to keep the metaphorical slaves as long as they swear to uphold the holy GPL.
No one is forcing the GPL on anyone. Absolutely no one is forced to take GPL code and do anything with it. Not a single person.
Slaves do not by definition have the choice to not be a slave.
If you don't want to "uphold the holy GPL" as you call it, you are perfectly free to get code in any one of many other ways. You can find code licensed in some other way. You can learn to code and write your own. You can pay someone to write it for you and give you copyright ownership, after which you can license it in anyway you please, including not licencing it at all.
You are the one redefining "freedom", "slaves", and "forced" here.
If the GPL was really about freedom then it would contain exactly one sentence. "You are free to do whatever you want with this software. "
Wow, why do you hate freedom so much?
How am I "free" if I, as you claim, am forced to grant permission to others that allows them to assume ownership of everything I make, and at the same time deny me usage and possession of everything I make?
Also, unlike self-signed certs it demonstrates that the person requesting the cert has control over the hostname(s), which is pretty much all I ever had to do when I paid for a non-EV certificate.
How does it demonstrate that?
Because one must create a file under a name specified by LE, with contents specified by LE. Only one with control over the webhost has access to create files on the webhost.
Can you explain specifically what makes this better than self-signed certs?
Anyone can create and sign a self-signed certificate with any domain(s) in it they wish. You can not easily verify the website owner is the creator of the private key, and in fact the only one way to do so is to compare the certificate signature/hash you see with the website owner, which requires another form of secure out-of-band communications.
With LetsEncrypt, you personally for example can not issue a certificate for my domain. I personally can not issue a certificate for your domain.
Additionally with self signed certificates, you would need to have end-users install your self signed public key in their browsers manually, and to actually be secure it would have to actually be the one you generated. As an attacker I can provide my own public key to your users to trust, with your domain in it, and there is little chance they wouldn't know it was my key instead of yours.
Certificate Authorities have their public keys in the browser already.
What is the basis of trust used to establish ownership?
Access to a web servers files or DNS zone for the domain in question is required. This is the exact same identical process any other CA in the world uses for class-1 certificates. In other words, if you know how any CA handles class-1 certs, you know how LE handles them. It is identical.
What prevents an attacker with access to a victims wires from using LE to obtain fraudulent certificates?
What prevents a person with control over the domain from requesting a certificate for that domain? The exact same thing that prevents an attacker from getting a certificate from any CA issued for that domain - nothing.
If I was an attacker in that position to have control over a victims web host or DNS, I could get a certificate issued from Lets Encrypt, or GoDaddy, or ICANN, or any of the many hundreds of certificate authorities out there.
I'm comfortable with apt-get but that's just upgrading all the softwares other than the operating system. How do I actually upgrade my OS?
My usage pattern tends to be, do a clean install of linux, install all the packages I need, edit the configuration files as I need them. Then use it till I buy a new computer only upgrading the installed packages. Then I start over. I never have actually pathced my Linux or installed an "upgrade". I'm terrified it would break all my packages.
Actually "apt-get upgrade" will also get the latest kernel as well. The only real difference is that you need to reboot into the new kernel, a step never needed for just upgrading software packages.
That's all you need to do to patch your system against this specific vulnerability.
But if by "OS" you mean "distribution version" instead of "kernel" (IE going from Debian 7 to Debian 8), you first do an "apt-get upgrade" like normal, and afterwards do an "apt-get dist-upgrade"
However you are correct that a dist-upgrade may break software packages, or specifically your custom configuration files. The reason they call it the "stable" distribution is because any and all upgrades to software will guarantee config file compatibility.
But between two stable major versions, this is not guaranteed. The new stable version may come with a significantly newer version of some program, not just the same version as shipped with all security fixes back-ported into it. Because of that, if you've made any significant changes to a programs/etc configs, your copy of the "old versions" config will be kept, and may be missing required new lines or have deprecated old lines that will throw an error, thus the program won't run.
The dist-upgrade process WILL give you an opportunity to deal with it on a manual basis, but it sucks to have to do.
Your options are basically "Keep the old possibly missing things config", or "wipe away my config and install the new versions defaults", or "show me the difference and give me an editor"
As it sounds, none of those are "fun"
BUT there is good news! If you installed Debian 7, and Debian 8 comes out, you don't need to dist-upgrade at all. Security fixes and updates will continue to be released for 7 for some time, and you can just keep your working system as is. So your process of waiting until you get new hardware and doing a new install from scratch is perfectly workable for quite some time after new distro versions come out.
$120,000,000 for 100M calls? That's $1.20 per call.
Unless the scammer made $120M in profits, this goes a little beyond punitive.
That's cheap as hell, considering calling a number listed on the do not call registry can be up to $40,000 per violation.
Yes, that's $40k times potentially 100 million calls, or $4 trillion in fines assuming he only called each person just once, which isn't actually the case.
I have over 50 such calls in my phones call history over the past 5-6 months. While it is unlikely to all be from this one single person, this is still two million dollars in violation fees from just on my one phone alone.
He was very aware of the fines for the actions he knew were criminal. Beyond punitive? This is barely a slap on the wrist.
You're right, but you're not factoring in GTA VI into that.
That's not quite accurate. I've factored GTA 6 into things, and will not be purchasing it.
Going by the responses on steam, twitter, youtube, etc., there seems to be a couple million others who have factored in GTA 6 similarly as well...
The vast majority of us that use single player mods were already going to buy, if not pre-purchase, GTA 6 as a simple matter of course. Why would passionate fans of the series, demonstrated by our continued use of the game long after the mainstream got bored with it, not have purchased the next game in the series? Of course we would. And once the mainstream got bored with it, we would have kept it alive with mods long past that point too, likely well into the time GTA 7 is announced two hardware generations from now.
But now that our passion for the game is being treated like some criminal act, why bother spending our time, energy, and creativity in making the game better if in the end all we are going to get for it is the hatred of their publisher and possibly a lawsuit?
It seems to me if anyone hasn't factored GTA 6 into account, it was take two. I hope the lower revenue stream is worth it for them *sarcasm*
But in the end it's OK, fallout and the elder scrolls won't sue us for our love. Sounds like a good of a time as any to start that "never leave sanctuary challenge" I've been meaning to try with the latest batch of settlement expansion mods available.
That is very likely not true, unless you count being best friends with one of the admins at uni who gave you a shell account for free on a server.
"Cloud" is a term from the 1970s. "Hosting", as performed by a company specifically offering such a thing, came about in the 1990's after the commercialization of the Internet.
Well, they do clearly state this malware is not intended to catch criminals in any way, it's primarily for enterprise networks to be targeted.
And downloading via SMB is one of many parts of an Active Directory based Windows network used in everything from small business up to full enterprises.
When a client PC joined to a domain is booted and windows starts, windows will download all of the Group Policy files from your domain controller(s) before applying the "computer" based settings. Upon login by a user it will also check for modifications to the group policy files on the domain controller(s) share and possibly downloading those files again before applying the "user" based settings.
In both of those cases, one typically will have a group policy that specifies a batch file that is also on an SMB or DFS share. That batch file can be as simple as just an "exit" command, or full of a listing of other programs to run which will also be hosted on SMB/DFS shares.
Any executable run via that method is downloaded from the file server(s) to the local PC before being executed.
SMB is a distributed file system like NFS isn't it.
Technically no, but only due to how the different components work together. SMB is purely how to share files and socket pipes over the network. DFS (distributed file share) is the protocols that make SMB be distributed.
Domain controllers on a windows network will always use DFS for the domain related shares. Additional namespaces can be created on top of your SMB share if you wish, but is completely optional. Though it is a very wise idea to do so even if not to use in a distributed fashion, mainly how windows machines stupidly handle hostnames.
DFS lets you create namespaces under the domain share, which you can then point to SMB shares on one or more file servers. Obviously if you have 2 or more SMB shares specified, it becomes distributed. But even with only 1 SMB share specified, this lets you add a second SMB share in the future, migrate files from one server to another, then remove the original SMB share. Windows gets really really unhappy if you ever reuse a hostname on your servers, so this method lets you migrate from an old/small file server to a newer/larger server, without having to modify SMB paths everywhere around your network.
transferring files on an intranet is not what we conventionally mean by "download". The latter usually implies the importation of file from the internet not a local net. It's misleading to conflate these as one usually has quite different procedures in the security onion for treating these two cases.
It's only misleading when you don't understand what "download" and "upload" actually mean.
Transferring a file from a machine that isn't your local one, onto your local machine, is a download. Transferring a file from your local machine to another one that isn't your local machine is an upload.
There is no requirement for the Internet to be involved, and in fact those terms predate both the Internet and the Arpanet by a decade or more.
Even a traditional "network" isn't required to be involved, as two machines connected by a serial cable can upload and download between each other, although typically they will still use networking protocols on top of that serial connection to do so.
There are less and less things using plain FTP, mainly anonymous public file repositories. But they support full FTP authentication none the less.
Since the vast majority of the transfer protocols it supports are encrypted specifically to not send your password in plain-text, it is fairly important to store them encrypted locally too if you will be storing them at all.
Makes little since not to store FTP passwords right along with the others in the same place and would be silly not to.
Personally the last time I used FTP sending a password was to upgrade the firmware on a network switch I had connected via cross over to a laptop, and it was the default user/pass from the manual. In that case the firmware upgrade required blowing away the config and starting over, so it made little sense to change the password ahead of time when I'd need to do it again after. Since this was before deploying the hardware, and in the fully configured state FTP was disabled completely, I don't feel it is fair to consider such a usage as insecure.
While I can't speak of the OS/2 "internals" as I've never developed for the platform, as someone who still administrates OS/2 systems to this day, my end-user experiences are far from what you describe.
At the manufacturing plant I work for, we have numerous pick-and-place machines and through-hole insertion machines that are driven by OS/2 embedded systems. The front end software was also made for OS/2 on a desktop, which in our case lives in VirtualBox instances on the engineers workstations.
While these systems are not on our standard client computer vlan, and in effect can only see each other in what is basically the OS/2 vlan, the systems themselves run flawlessly and with pretty insane uptimes.
The machine controllers have never actually been "rebooted", and in the last decade only powered off and on twice (Once due to a 12+ hour power-loss, and once for relocating the machines themselves) That last power cycle was back in 2011, and they have been running for 6 years non-stop without problems.
The front-end systems have also never once needed rebooted to fix any stability issues or problems, although these systems don't run continuously. That however is mostly due to the fact the virtualbox virtualization hosts are Windows desktops that do have to reboot for updates and stability issues. Thus the VMs are only ran as needed.
None of the bare metal involved are IBM PS/2 based systems, or IBM systems in anyway beyond being x86 backwards compatible Pentium era embedded machines.
As an OS/2 developer, you are likely in a very small minority that is already within a very small minority. I'm not saying you are incorrect or anything, but within the small group of existing "end users" I gather you won't find many people at all that share your view of OS/2.
The point of periodic password changes is to protect against an *UNKNOWN* breach, where the password has been compromised and the user doesn't know. Is there some other method of mitigation for this attack?
As an attacker, I only need your password for about 60 seconds to get in and plant a persistent backdoor, after which I can gain access to everything that password granted but I no longer need your password.
Do you enforce password changing for users every 59 seconds? If not, you are already not mitigating the effects of an unknown breach, so why have your users change passwords when it will not have the effect you are claiming no matter what they do?
All you are doing is making users choose a very short predictable password scheme, typically two characters (one letter/number and one symbol), where the other 6 of 8 characters are the year and month.
So in the end, you have failed to mitigate unknown breaches completely, and lowered your password lengths from 8 to 2 characters as the remainder are predictable.
Archive.org should archive everything, including the robot.txt contents, at each scan.
The content being displayed from the archive.org website itself however could then still honor robots.txt at the time of the scan, purely for "display" purposes.
This way changing robots.txt to block search engines would not delete or hide any previous information. Also the new information would still be in the archive, even if not displayed due to the current robots.txt directives.
Although it would require more work to do so properly, this would potentially allow for website owners to retroactively "unhide" content in the archive in the past as well. Proper in this case would require some way to verify the domain owner, but this could likely be as simple as creating another specifically named text file in the websites root path, with content provided by the archive. That can be as simple as the old school "cookie" data like so many other services use such as Google, or as complex as a standard that allows date ranges specified along with directives.
But in any case, this would preserve copies of the website for future use, such as for when copyright protection expires. Despite everyone having a differing opinion on just how long "limited time" should be in "securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries", no one who wants to be taken seriously can argue that this time of expiration must happen at some point. Since the vast majority of authors make no considerations to protect our property, that task clearly needs to fall on us to secure.
Slashdot Mirror
Any smartphone sold in Europe should integrate AML, or be banned outright.
So are you intending to take personal responsibility for all the deaths your recommendation will cause?
I know I would be pretty pissed off at you if you are the sole reason my phone costs more, and does literally nothing that it didn't do before simply because I don't live in the UK part of Europe.
Anyone in any European country that isn't the UK specifically has no infrastructure or support for AML, so it will do nothing when calling emergency services.
But now Apple must pay to add additional hardware, and pay all the Google licensing fees for their AML technology, all to ultimately be not supported in nearly all of the EU.
YOU claimed it would save lives, when it clearly will not and can not. That puts those lives on your head.
and if you need, Amazon sells swords also!
Hello, "amazon seller not wanting returns #4227"!
Item "death by the sword brand sword" is frequently bought together with the following items:
https://www.amazon.com/Miniature-Violin-Small-4-inches/dp/B00075PSBY/
Include 1-year accident protection for $1.99!
Get this item by tomorrow with Amazon Prime!
That's exactly why I said a temp worker shouldn't consider this an option, even if the current company was paying for the implant.
As for removal, and this applies to anyone thinking about getting one of these, one should keep in mind installation is much simpler all around than removal is.
Installation is fast (~15 minutes), being injected under the skin by a tool looking like a novelty sized needle, done under local anesthetic at a doctors office.
Removal would require cutting the skin open, and then stitches or an equivalent, along with the proper after care to prevent infections.
I guess it could be done under local anesthetic. That's how guys get their tubes tied after all, which IMHO is far more horrible to think about...
Basically it would be FAR better to think of this as a one-way trip for the chip: in, not to come out again.
If you aren't squeamish, you can do a google image search on "rfid chip implanting"
*shiver*
I was speaking of badge cards being issued, not implants.
Generally companies in the US don't tend to define temps or contractors as employees, but I can't say if that's the case here.
Neither the article nor the article in the article is too clear, but it does say "offering ALL employees"...
Seeing as it only costs about $50 or less to have the same chip implanted in your cat or dog, even with the insane US healthcare prices it's not like the process is a huge investment of money.
Either way though, the solution is no different than for employees not wanting an implant.
Just issue them a NFC badge like before.
That assumes they use the same tags, which is not a safe assumption.
Perhaps not a safe assumption between different companies, but at least purely going by the description given in this example I think it is a good assumption.
Obviously one can use any non-standard protocol over NFC they wish, but there are ISO standards for this sort of thing that are inter-compatible.
That is also the assumption smartphone makers use which mostly works out OK.
NFC equipped phones can speak ISO standards, and any proprietary standards for payment/credit type processing (think apple pay)
In this case they talk about using the same NFC tag over a wide range of readers and systems.
If any one of those systems was proprietary, it wouldn't at all work with the other ones.
It almost needs to be using an ISO standard just for the entire campus to work together, so it is very likely these implantable NFC chips are using an ISO standard.
One of the other benefits to using ISO over NFC is that you can "offer" to employees the ability to use their smartphone as a badge, instead of actually issuing them a badge.
From the user point of view, since a phone can be loaded up with a bunch of NFC IDs at once this can be easier than carrying a ton of badge cards.
From an employer point of view, that's one less badge to issue and pay for.
But over all you are correct. The next company you work for may be a smaller one that only has a single badge system, say just to open the doors for you.
With only one system that doesn't have anything else to "play well together" with, there's nothing preventing them from going with a crappy brand or provider that uses a proprietary badge.
It may not even be NFC but older RFID, which would be completely incompatible.
I'm fairly sure our temp agency has contracts with their workers to return company property.
But I work in IT, not in HR, so I'm not really sure how that all is handled.
From my end of things, over a decade of working here I've only had two individuals come to me asking for replacement badges.
In one case the badge was snapped in half nearly all the way through, although this was after 12+ years of use.
In the other case the person lost their badge, and this was after a couple years of employment as well.
In both cases I just issued new badges and deactivated the old ones.
We didn't charge the employees anything. Seems a bit petty for an honest mistake over what is in essence a $2 badge we order 100 at a time of.
If someone made a frequent habit of losing their card we might invoke the replacement fee clause, but it's never been an issue yet.
RFID cards tend to heavily rely on having a site ID pre-programmed at the factory, but at least when it comes to the NFC ISO standard there is no site ID anymore, just a very long unique ID.
This is the take that smartphones equipped with NFC hardware utilize, mainly for compatibility sake.
I would very much hope the implantable NFC chips are also using this same standard.
Obviously one can use any protocol over NFC including proprietary ones, and it seems some banking type cards do exactly that, but it seems in most of those cases you wouldn't even get compatibility with all of your own readers let alone anyone else.
Since these people mention using it for more than a single task over their campus, I'd tend to believe them regarding using an NFC standard like ISO.
It would be difficult if not close to impossible to accomplish otherwise.
That's not how either of those items work however.
Then you get another RFID tag for your next employer, and the reader has to try to read them both and check them both every time you want a pack of gum. Then you go to a fourth and a fifth employer, and your doctor is getting concerned about the amount of foreign material in the limited space in your hand.
No you just have the one single implant.
The previous company removes your NFC ID from their systems, and the new company adds that NFC ID to theirs.
My company uses a badge for doors and the snack machine uses that and a PIN. The same thing can be done with the card number, and it doesn't stay with me for life.
Actually the badge ID system is used on the assumption that your badge WILL stay with you, or at least accounts for that possibility.
Yes they ask that the badge be returned, simply because it cost up to $2 and can be reused.
But the system doesn't assume it will be returned, and that's why the ID linked to the badge is disabled in their system when you leave, returned or not.
It's always a possibility an employee simply stops showing up for work never to be seen again.
The requirement to lock them out of the premises upon termination needs to be handled without physically requiring anything from the now ex-employee.
Most employee handbooks that require signing contain some form of clause of what happens when a badge card, or any other company property for that matter, is not returned.
Some don't care, some make you agree to pay a fine for the badge.
There is also the situation of losing a badge ID, ranging from "I dunno where I left it" to "I got mugged last night"
Those badges need disabled just the same since you have no idea who if anyone has possession of it now, and some companies stick their logo and name right on the thing making it brain dead simple to know where to attempt to use it.
Our system even has separate flags on the badge ID for "Lost, Claimed" and "Lost, Destroyed"
The second one is only to be set when HR or IT physically destroys a card themselves (Say it cracked or popped open, in this case you run it through the heavy duty shredder and flag it as destroyed)
The "Lost, Claimed" option is when the employee claims it is lost but this is unconfirmed. It allows the card to be "unlost" and reissued in the future, while the destroyed option removes it from the list of available IDs.
There is no reason an NFC system would need to work any different from an RFID system, other than accounting for the much longer unique ID field.
The slashdot summary originally said "200S" instead of "about 200 microseconds"
It was silently changed without an update message saying so.
I too was very confused when I first read it, both that a capitol S and no space isn't any standard notation I know of, and that the only interpretation was 200 seconds which made no sense at all.
You are absolutely correct, you were not one of the people using the term "forced" nor redefining it.
I apologize for my mistake.
But you still keep referring to the GPL removing freedoms.
You are aware that it is copyright law that removes your freedom to, as you say, to be able to do what one wants.
The GPL, like most licenses, actually *counters* the removal of rights that copyright law forces on you.
As you say, it may not grant you all the rights you wish to have, but not giving you something is quite different from taking something you do have away.
Copyright law takes nearly everything away, and the license gives it back to you.
I don't think I understand what you are meaning to say.
Yes, those are valid concerns when writing your own code and hiring someone to write code for you...
But compared to the other options listed (using code under another license, and using GPL code while agreeing to the GPL), plus the option the parent poster said was preferable, namely using GPL code while violating copyright laws in doing so, I'm fairly certain all of those have the same patent risk just the same.
Even purchasing a license to commercial closed code isn't free of those risks.
Although if the commercial entity you purchase the code from is also the patent holder for the process it works by, your risk is greatly reduced at least so far as being sued for a patent violation.
As for the problem of "being accused of a crime you didn't commit", at least in the US, this is a risk everyone is exposed to no matter what they do in life.
Unfortunately that can happen if you stay in bed sleeping for 23 hours a day, if you happen to piss off the wrong person in you one waking hour.
As a warning to people, fair enough.
I just don't see what any of those have to do with the "need" to violate copyright laws like the parent was saying is the best option regarding copyright licenses.
It however do allow people to keep the metaphorical slaves as long as they swear to uphold the holy GPL.
No one is forcing the GPL on anyone.
Absolutely no one is forced to take GPL code and do anything with it. Not a single person.
Slaves do not by definition have the choice to not be a slave.
If you don't want to "uphold the holy GPL" as you call it, you are perfectly free to get code in any one of many other ways.
You can find code licensed in some other way.
You can learn to code and write your own.
You can pay someone to write it for you and give you copyright ownership, after which you can license it in anyway you please, including not licencing it at all.
You are the one redefining "freedom", "slaves", and "forced" here.
If the GPL was really about freedom then it would contain exactly one sentence.
"You are free to do whatever you want with this software. "
Wow, why do you hate freedom so much?
How am I "free" if I, as you claim, am forced to grant permission to others that allows them to assume ownership of everything I make, and at the same time deny me usage and possession of everything I make?
Sounds like forced slavery to me...
Also, unlike self-signed certs it demonstrates that the person requesting the cert has control over the hostname(s), which is pretty much all I ever had to do when I paid for a non-EV certificate.
How does it demonstrate that?
Because one must create a file under a name specified by LE, with contents specified by LE.
Only one with control over the webhost has access to create files on the webhost.
Can you explain specifically what makes this better than self-signed certs?
Anyone can create and sign a self-signed certificate with any domain(s) in it they wish.
You can not easily verify the website owner is the creator of the private key, and in fact the only one way to do so is to compare the certificate signature/hash you see with the website owner, which requires another form of secure out-of-band communications.
With LetsEncrypt, you personally for example can not issue a certificate for my domain.
I personally can not issue a certificate for your domain.
Additionally with self signed certificates, you would need to have end-users install your self signed public key in their browsers manually, and to actually be secure it would have to actually be the one you generated.
As an attacker I can provide my own public key to your users to trust, with your domain in it, and there is little chance they wouldn't know it was my key instead of yours.
Certificate Authorities have their public keys in the browser already.
What is the basis of trust used to establish ownership?
Access to a web servers files or DNS zone for the domain in question is required.
This is the exact same identical process any other CA in the world uses for class-1 certificates.
In other words, if you know how any CA handles class-1 certs, you know how LE handles them. It is identical.
What prevents an attacker with access to a victims wires from using LE to obtain fraudulent certificates?
What prevents a person with control over the domain from requesting a certificate for that domain?
The exact same thing that prevents an attacker from getting a certificate from any CA issued for that domain - nothing.
If I was an attacker in that position to have control over a victims web host or DNS, I could get a certificate issued from Lets Encrypt, or GoDaddy, or ICANN, or any of the many hundreds of certificate authorities out there.
I'm comfortable with apt-get but that's just upgrading all the softwares other than the operating system. How do I actually upgrade my OS?
My usage pattern tends to be, do a clean install of linux, install all the packages I need, edit the configuration files as I need them. Then use it till I buy a new computer only upgrading the installed packages. Then I start over. I never have actually pathced my Linux or installed an "upgrade". I'm terrified it would break all my packages.
Actually "apt-get upgrade" will also get the latest kernel as well.
The only real difference is that you need to reboot into the new kernel, a step never needed for just upgrading software packages.
That's all you need to do to patch your system against this specific vulnerability.
But if by "OS" you mean "distribution version" instead of "kernel" (IE going from Debian 7 to Debian 8), you first do an "apt-get upgrade" like normal, and afterwards do an "apt-get dist-upgrade"
However you are correct that a dist-upgrade may break software packages, or specifically your custom configuration files.
The reason they call it the "stable" distribution is because any and all upgrades to software will guarantee config file compatibility.
But between two stable major versions, this is not guaranteed. /etc configs, your copy of the "old versions" config will be kept, and may be missing required new lines or have deprecated old lines that will throw an error, thus the program won't run.
The new stable version may come with a significantly newer version of some program, not just the same version as shipped with all security fixes back-ported into it.
Because of that, if you've made any significant changes to a programs
The dist-upgrade process WILL give you an opportunity to deal with it on a manual basis, but it sucks to have to do.
Your options are basically "Keep the old possibly missing things config", or "wipe away my config and install the new versions defaults", or "show me the difference and give me an editor"
As it sounds, none of those are "fun"
BUT there is good news!
If you installed Debian 7, and Debian 8 comes out, you don't need to dist-upgrade at all.
Security fixes and updates will continue to be released for 7 for some time, and you can just keep your working system as is.
So your process of waiting until you get new hardware and doing a new install from scratch is perfectly workable for quite some time after new distro versions come out.
$120,000,000 for 100M calls? That's $1.20 per call.
Unless the scammer made $120M in profits, this goes a little beyond punitive.
That's cheap as hell, considering calling a number listed on the do not call registry can be up to $40,000 per violation.
Yes, that's $40k times potentially 100 million calls, or $4 trillion in fines assuming he only called each person just once, which isn't actually the case.
I have over 50 such calls in my phones call history over the past 5-6 months.
While it is unlikely to all be from this one single person, this is still two million dollars in violation fees from just on my one phone alone.
He was very aware of the fines for the actions he knew were criminal.
Beyond punitive? This is barely a slap on the wrist.
You're right, but you're not factoring in GTA VI into that.
That's not quite accurate. I've factored GTA 6 into things, and will not be purchasing it.
Going by the responses on steam, twitter, youtube, etc., there seems to be a couple million others who have factored in GTA 6 similarly as well...
The vast majority of us that use single player mods were already going to buy, if not pre-purchase, GTA 6 as a simple matter of course.
Why would passionate fans of the series, demonstrated by our continued use of the game long after the mainstream got bored with it, not have purchased the next game in the series?
Of course we would. And once the mainstream got bored with it, we would have kept it alive with mods long past that point too, likely well into the time GTA 7 is announced two hardware generations from now.
But now that our passion for the game is being treated like some criminal act, why bother spending our time, energy, and creativity in making the game better if in the end all we are going to get for it is the hatred of their publisher and possibly a lawsuit?
It seems to me if anyone hasn't factored GTA 6 into account, it was take two.
I hope the lower revenue stream is worth it for them *sarcasm*
But in the end it's OK, fallout and the elder scrolls won't sue us for our love.
Sounds like a good of a time as any to start that "never leave sanctuary challenge" I've been meaning to try with the latest batch of settlement expansion mods available.
Hosting was around long before cloud
That is very likely not true, unless you count being best friends with one of the admins at uni who gave you a shell account for free on a server.
"Cloud" is a term from the 1970s.
"Hosting", as performed by a company specifically offering such a thing, came about in the 1990's after the commercialization of the Internet.
The 90's did not come before the 70's
Who "downloads" with SMB.
Well, they do clearly state this malware is not intended to catch criminals in any way, it's primarily for enterprise networks to be targeted.
And downloading via SMB is one of many parts of an Active Directory based Windows network used in everything from small business up to full enterprises.
When a client PC joined to a domain is booted and windows starts, windows will download all of the Group Policy files from your domain controller(s) before applying the "computer" based settings.
Upon login by a user it will also check for modifications to the group policy files on the domain controller(s) share and possibly downloading those files again before applying the "user" based settings.
In both of those cases, one typically will have a group policy that specifies a batch file that is also on an SMB or DFS share.
That batch file can be as simple as just an "exit" command, or full of a listing of other programs to run which will also be hosted on SMB/DFS shares.
Any executable run via that method is downloaded from the file server(s) to the local PC before being executed.
SMB is a distributed file system like NFS isn't it.
Technically no, but only due to how the different components work together.
SMB is purely how to share files and socket pipes over the network.
DFS (distributed file share) is the protocols that make SMB be distributed.
Domain controllers on a windows network will always use DFS for the domain related shares.
Additional namespaces can be created on top of your SMB share if you wish, but is completely optional. Though it is a very wise idea to do so even if not to use in a distributed fashion, mainly how windows machines stupidly handle hostnames.
DFS lets you create namespaces under the domain share, which you can then point to SMB shares on one or more file servers.
Obviously if you have 2 or more SMB shares specified, it becomes distributed.
But even with only 1 SMB share specified, this lets you add a second SMB share in the future, migrate files from one server to another, then remove the original SMB share.
Windows gets really really unhappy if you ever reuse a hostname on your servers, so this method lets you migrate from an old/small file server to a newer/larger server, without having to modify SMB paths everywhere around your network.
transferring files on an intranet is not what we conventionally mean by "download". The latter usually implies the importation of file from the internet not a local net. It's misleading to conflate these as one usually has quite different procedures in the security onion for treating these two cases.
It's only misleading when you don't understand what "download" and "upload" actually mean.
Transferring a file from a machine that isn't your local one, onto your local machine, is a download.
Transferring a file from your local machine to another one that isn't your local machine is an upload.
There is no requirement for the Internet to be involved, and in fact those terms predate both the Internet and the Arpanet by a decade or more.
Even a traditional "network" isn't required to be involved, as two machines connected by a serial cable can upload and download between each other, although typically they will still use networking protocols on top of that serial connection to do so.
If I told my boss that the system I designed to stop us from going belly-up has ~50% success rate, I'm pretty sure he would fire me,
Then you should have built 4 or more of those systems before telling him about it :P
who uses FTP? isn't SCP the thing?
Filezilla does SCP as well as SFTP, and FTPS.
There are less and less things using plain FTP, mainly anonymous public file repositories.
But they support full FTP authentication none the less.
Since the vast majority of the transfer protocols it supports are encrypted specifically to not send your password in plain-text, it is fairly important to store them encrypted locally too if you will be storing them at all.
Makes little since not to store FTP passwords right along with the others in the same place and would be silly not to.
Personally the last time I used FTP sending a password was to upgrade the firmware on a network switch I had connected via cross over to a laptop, and it was the default user/pass from the manual. In that case the firmware upgrade required blowing away the config and starting over, so it made little sense to change the password ahead of time when I'd need to do it again after.
Since this was before deploying the hardware, and in the fully configured state FTP was disabled completely, I don't feel it is fair to consider such a usage as insecure.
While I can't speak of the OS/2 "internals" as I've never developed for the platform, as someone who still administrates OS/2 systems to this day, my end-user experiences are far from what you describe.
At the manufacturing plant I work for, we have numerous pick-and-place machines and through-hole insertion machines that are driven by OS/2 embedded systems.
The front end software was also made for OS/2 on a desktop, which in our case lives in VirtualBox instances on the engineers workstations.
While these systems are not on our standard client computer vlan, and in effect can only see each other in what is basically the OS/2 vlan, the systems themselves run flawlessly and with pretty insane uptimes.
The machine controllers have never actually been "rebooted", and in the last decade only powered off and on twice (Once due to a 12+ hour power-loss, and once for relocating the machines themselves)
That last power cycle was back in 2011, and they have been running for 6 years non-stop without problems.
The front-end systems have also never once needed rebooted to fix any stability issues or problems, although these systems don't run continuously.
That however is mostly due to the fact the virtualbox virtualization hosts are Windows desktops that do have to reboot for updates and stability issues. Thus the VMs are only ran as needed.
None of the bare metal involved are IBM PS/2 based systems, or IBM systems in anyway beyond being x86 backwards compatible Pentium era embedded machines.
As an OS/2 developer, you are likely in a very small minority that is already within a very small minority.
I'm not saying you are incorrect or anything, but within the small group of existing "end users" I gather you won't find many people at all that share your view of OS/2.
The point of periodic password changes is to protect against an *UNKNOWN* breach, where the password has been compromised and the user doesn't know. Is there some other method of mitigation for this attack?
As an attacker, I only need your password for about 60 seconds to get in and plant a persistent backdoor, after which I can gain access to everything that password granted but I no longer need your password.
Do you enforce password changing for users every 59 seconds?
If not, you are already not mitigating the effects of an unknown breach, so why have your users change passwords when it will not have the effect you are claiming no matter what they do?
All you are doing is making users choose a very short predictable password scheme, typically two characters (one letter/number and one symbol), where the other 6 of 8 characters are the year and month.
So in the end, you have failed to mitigate unknown breaches completely, and lowered your password lengths from 8 to 2 characters as the remainder are predictable.
It should be even easier than that.
Archive.org should archive everything, including the robot.txt contents, at each scan.
The content being displayed from the archive.org website itself however could then still honor robots.txt at the time of the scan, purely for "display" purposes.
This way changing robots.txt to block search engines would not delete or hide any previous information.
Also the new information would still be in the archive, even if not displayed due to the current robots.txt directives.
Although it would require more work to do so properly, this would potentially allow for website owners to retroactively "unhide" content in the archive in the past as well.
Proper in this case would require some way to verify the domain owner, but this could likely be as simple as creating another specifically named text file in the websites root path, with content provided by the archive.
That can be as simple as the old school "cookie" data like so many other services use such as Google, or as complex as a standard that allows date ranges specified along with directives.
But in any case, this would preserve copies of the website for future use, such as for when copyright protection expires.
Despite everyone having a differing opinion on just how long "limited time" should be in "securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries", no one who wants to be taken seriously can argue that this time of expiration must happen at some point.
Since the vast majority of authors make no considerations to protect our property, that task clearly needs to fall on us to secure.
On the plus side, there was plenty of ASCII porn.
Or with a few dollar donation one can gain access to the high-res 160x120 GIF porn section.
The interlacing along with 2400 baud only added to the mystique :}~