For some years now, an ISO/IEC working group, WG23, has been compiling lists of programming language vulnerabilities, both for specific languages and generically. The documents list for the WG is a bit of a mess, with the main link to the current draft getting a 404, but you can find links to sections on individual languages there. Some language committees are actively participating in WG23, but the C++ committee, I am told by another member, refuses to do so.
I too use Jolly Roger, and subscribe to the service where my Google Voice number multi-ring forwards to them and a bot picks up if the number appears on a known-telemarketer list. Google Voice itself does a pretty decent job of filtering spam calls, but some get through.
I recently retired (as a senior developer) from a very large technology company that, in recent years, pretty much ONLY hired "junior developers". "Recent College Graduate" was the term used, and even then it was difficult to find promising candidates. The company also "strongly encouraged" hiring of women and "underrepresented minorities" (that is, not from India or China). I was not a hiring manager, but I did interview candidates and reviewed CVs - nearly all of them were from foreign-born applicants.
Yes, the senior people such as myself were expected to train the newcomers, and we did, gladly, because we wanted there to be continuity in the product development. In my conversations with peers at other firms, it was largely the same - junior programmers were much easier to get hired than senior ones.
If I could offer one piece of advice to aspiring software developers, it's to look outside of Silicon Valley. There are lots of great opportunities at companies with offices in the south, midwest and northeast. We were not looking for specific skills, other than being familiar with C or C++. (None of this new-age Python or R crap...) Nothing you learn (other than basic programming) in college is directly applicable to the real world of commercial software development - we'd teach you what we needed - but finding people willing to move outside of the west coast comfort zone was very difficult.
That said, we did find really great junior people who are well on their way to becoming the senior developers of the future.
I'm not doubting you, just stating that my experience was different. MyVoice was not mentioned at all until I brought it up, though the agent did say he had intended to ask if I wanted it.
I am a Fidelity customer. I received a mailing from Fidelity describing the My Voice feature but it said I had to call in and specifically request that it be enabled. Fidelity is NOT enabling it by default for customers, at least based on what I can see.
However, this is not entirely a seamless experience. When you call in, you still have to enter your username or SSN using the phone keypad (for a username, you press the digit the letter is on, case doesn't matter, and * for special characters. Without My Voice, you also enter your password this way! Since I have a strong, unique password I ended up creating a note in LastPass with the keys to press.) Then you have to speak to have it detect your voice. I was told I could unenroll at any time.
I'm not exactly thrilled with voice being the authentication mechanism, but it's better than what they had before. Fidelity, at least, doesn't use 2FA for typical operations; their web site says they may ask for it (a code sent by SMS, I'd guess) for certain transactions, but they've never asked me for this in the past.
I wrote release notes for operating systems and compilers for nearly 40 years, and it was never an easy task. New features aren't the issue - they're usually straightforward to describe. It's bug fixes that sometimes had me tearing my hair out. For each one, based on the developers' notes and (sometimes) the original problem description, I had to figure out what I could tell a reader that would help them recognize the exact problem that was fixed. In many cases, the problem was exposed only under specific combinations of uses (especially for compiler bugs), and there was no clear-cut way of describing these.
Worse, from support and development's view, were customers who had not reported a problem themselves, but saw a description that vaguely matched what they were seeing and they'd complain that "the bug wasn't fixed". Of course, THEIR version of the bug was different from what was behind the release note.
The primary purposes of release notes, in my view, are to highlight changes in behavior or requirements that users need to know about. Lists of bug fixes are a high-effort task for low user benefit, and indeed my former employer stopped providing bug fix lists in recent years.
The little snippet release notes for apps are very vague summaries of changes, and I don't at all blame developers from writing "Bug fixes and performance improvements" over and over. Yeah, the entertaining notes are, um, entertaining, but I agree that they're more a promotional thing than an attempt to educate users.
AT&T has had their Call Protect feature for a few months now, including telemarketer identification and network-level fraudulent call blocking. I use it and it works very well.
That's a problem across the whole web and, at least the deletion part, happens more often than you'd think. When I've updated links on Wikipedia, I note that it not only asks for a CAPTCHA but alerts editors to the change, in case the change was malicious.
I think the motivation is good, but the implementation (as I understand it) could be better. Perhaps what is needed is to add a Wayback link alongside the original one. Does Wikipedia have a process for human review of broken links? In the cases I've found, replacement links can be found quickly for content that just moved.
I have found many cases on Wikipedia where the links are broken but the correct content exists at a different URL. This auto-archive system would bypass that and perhaps prevent ever recognizing that the link target still exists. This is especially an issue for links to corporate and government pages where someone periodically gets the bright idea to reshuffle the web site's organization and doesn't put in permanent redirects.
I write such reviews - both for Amazon Vine and for vendors who offer me free or discounted products. I take my reviewer role seriously and don't treat a review any differently if I paid for the item or not. I recognize that that there is a serious abuse problem - my fellow reviewers use the term "coupon queens", though these can be both male and female - and I applaud Amazon taking this position even though it means I will receive fewer items to review.
I would urge you, though, not to automatically downvote incentivized reviews. If you believe the review is genuinely not helpful, ("I haven't received it yet but I'm sure my grandson will like it, unless I sell it on eBay first..), downvote away. But there are good reviewers out there trying to help purchasers as if they had bought the item themselves. Indeed, those who paid for an item are often biased in favor of it so as to not appear foolish for having spent the money.
You misunderstand the threat. It is not that an attacker uses MITM to relay the data, though that has been demonstrated. The threat is due to the cardholder data (name, account number and expiration date) being readable in plaintext from hundreds of meters away using readily available and inexpensive equipment. This data can then be used to perform offline transactions or other identity fraud ("what are the last four digits of your credit card number..." sort of "verification" questions.)
Even just knowing the name of a cardholder passing by could be a security risk (ask in nearby hotel for the room of Jane Doe, etc.)
But consider what happened to me last year on the first day of a two-week international vacation. I got a notice from my primary card bank (Chase) that my card had been compromised and that they would cancel it and send a new one. The problem was that I was depending on this card (which has no foreign transaction fees) and I would be moving around every two days meaning that it would be difficult to get a new card to me quickly. They did offer a compromise - disable any card-not-present transactions and had me list which countries I would be in, until I could return home. I had several online purchases outstanding so I had to scramble to fix those, and even then I missed one of the countries I would be in and had my card declined twice before I figured out the problem.
I am sure this case was a leak from a merchant that stored card data insecurely, or maybe a skimmer somewhere. That card did not have RFID. We really do need to move quicker to a tokenized system. Even so, it was more than a minor annoyance to me.
The chip creates a digital signature for the transaction, but the data is cleartext. EMV makes card cloning much more difficult, but it doesn't protect the data against interception.
Pretty much every week I place online orders with merchants that don't ask for CVV2. While it is true that the RFID data doesn't include CVV2 (it has a digital signature code created by the EMV chip), what is sent is MORE than enough to commit wide-scale fraud.
Do you really think that the banks would have added a feature that makes fraud as easy as pointing an antenna at people walking past? Where are the crime waves of people draining accounts with concealed card readers?
Why yes, I do. It has been demonstrated numerous times, and is easy to reproduce on your own with inexpensive equipment. The specs are public (have you read them? I have.) Even EMV chips send your card information in plaintext - any encryption needs to be added by the terminal. You may not have read much about it as RFID cards are still uncommon in the US, but that is changing. The specs for this and EMV are more than a decade old and were designed for the banks' convenience, not your protection.
US banks have shown a singular unwillingness to invest in technology that helps their customers. In the US they fall back on "zero liability" terms that mostly shield customers from direct financial losses but then pass on the cost of billions of dollars of fraud to all consumers and merchants.
PayWave is awesome. You just tap the card on the terminal (or near it) to pay, no pin, no signature.
That it is - I have used it once so far, at a Walgreens, and it was very speedy. Not too surprising as it's effectively the same as swiping - there's no challenge-response sequence as there is with a chip-based transaction. Indeed, Visa's specs for PayWave require a response in half a second.
That said, I very much prefer tokenization systems such as Apple Pay and I find that is almost as fast as PayWave. (PayWave is Visa's brand name for RFID transactions - other card issuers use different names, but the underlying technology is the same.)
Slashdot Mirror
For some years now, an ISO/IEC working group, WG23, has been compiling lists of programming language vulnerabilities, both for specific languages and generically. The documents list for the WG is a bit of a mess, with the main link to the current draft getting a 404, but you can find links to sections on individual languages there. Some language committees are actively participating in WG23, but the C++ committee, I am told by another member, refuses to do so.
I too use Jolly Roger, and subscribe to the service where my Google Voice number multi-ring forwards to them and a bot picks up if the number appears on a known-telemarketer list. Google Voice itself does a pretty decent job of filtering spam calls, but some get through.
Absolutely correct. It would have been a LOT worse if nothing had been done.
I recently retired (as a senior developer) from a very large technology company that, in recent years, pretty much ONLY hired "junior developers". "Recent College Graduate" was the term used, and even then it was difficult to find promising candidates. The company also "strongly encouraged" hiring of women and "underrepresented minorities" (that is, not from India or China). I was not a hiring manager, but I did interview candidates and reviewed CVs - nearly all of them were from foreign-born applicants.
Yes, the senior people such as myself were expected to train the newcomers, and we did, gladly, because we wanted there to be continuity in the product development. In my conversations with peers at other firms, it was largely the same - junior programmers were much easier to get hired than senior ones.
If I could offer one piece of advice to aspiring software developers, it's to look outside of Silicon Valley. There are lots of great opportunities at companies with offices in the south, midwest and northeast. We were not looking for specific skills, other than being familiar with C or C++. (None of this new-age Python or R crap...) Nothing you learn (other than basic programming) in college is directly applicable to the real world of commercial software development - we'd teach you what we needed - but finding people willing to move outside of the west coast comfort zone was very difficult.
That said, we did find really great junior people who are well on their way to becoming the senior developers of the future.
I'm not doubting you, just stating that my experience was different. MyVoice was not mentioned at all until I brought it up, though the agent did say he had intended to ask if I wanted it.
Ah, reading too fast. The story seems ok, but my experience doesn't match that of user maiden_taiwan.
I am a Fidelity customer. I received a mailing from Fidelity describing the My Voice feature but it said I had to call in and specifically request that it be enabled. Fidelity is NOT enabling it by default for customers, at least based on what I can see.
However, this is not entirely a seamless experience. When you call in, you still have to enter your username or SSN using the phone keypad (for a username, you press the digit the letter is on, case doesn't matter, and * for special characters. Without My Voice, you also enter your password this way! Since I have a strong, unique password I ended up creating a note in LastPass with the keys to press.) Then you have to speak to have it detect your voice. I was told I could unenroll at any time.
I'm not exactly thrilled with voice being the authentication mechanism, but it's better than what they had before. Fidelity, at least, doesn't use 2FA for typical operations; their web site says they may ask for it (a code sent by SMS, I'd guess) for certain transactions, but they've never asked me for this in the past.
I wrote release notes for operating systems and compilers for nearly 40 years, and it was never an easy task. New features aren't the issue - they're usually straightforward to describe. It's bug fixes that sometimes had me tearing my hair out. For each one, based on the developers' notes and (sometimes) the original problem description, I had to figure out what I could tell a reader that would help them recognize the exact problem that was fixed. In many cases, the problem was exposed only under specific combinations of uses (especially for compiler bugs), and there was no clear-cut way of describing these.
Worse, from support and development's view, were customers who had not reported a problem themselves, but saw a description that vaguely matched what they were seeing and they'd complain that "the bug wasn't fixed". Of course, THEIR version of the bug was different from what was behind the release note.
The primary purposes of release notes, in my view, are to highlight changes in behavior or requirements that users need to know about. Lists of bug fixes are a high-effort task for low user benefit, and indeed my former employer stopped providing bug fix lists in recent years.
The little snippet release notes for apps are very vague summaries of changes, and I don't at all blame developers from writing "Bug fixes and performance improvements" over and over. Yeah, the entertaining notes are, um, entertaining, but I agree that they're more a promotional thing than an attempt to educate users.
AT&T has had their Call Protect feature for a few months now, including telemarketer identification and network-level fraudulent call blocking. I use it and it works very well.
http://mashable.com/2017/01/25...
AT&T's Call Protect is "powered by HiYa".
Amazon does now limit reviews of non-verified purchases to 5/week. (Books, videos, CDs and Vine excepted.)
They ought to provide a way to filter reviews so that one can choose to see only reviews/ratings from verified purchasers.
They do - if you click See All Reviews, you can choose to filter by Verified Purchase Only.
That's a problem across the whole web and, at least the deletion part, happens more often than you'd think. When I've updated links on Wikipedia, I note that it not only asks for a CAPTCHA but alerts editors to the change, in case the change was malicious.
I think the motivation is good, but the implementation (as I understand it) could be better. Perhaps what is needed is to add a Wayback link alongside the original one. Does Wikipedia have a process for human review of broken links? In the cases I've found, replacement links can be found quickly for content that just moved.
I have found many cases on Wikipedia where the links are broken but the correct content exists at a different URL. This auto-archive system would bypass that and perhaps prevent ever recognizing that the link target still exists. This is especially an issue for links to corporate and government pages where someone periodically gets the bright idea to reshuffle the web site's organization and doesn't put in permanent redirects.
I write such reviews - both for Amazon Vine and for vendors who offer me free or discounted products. I take my reviewer role seriously and don't treat a review any differently if I paid for the item or not. I recognize that that there is a serious abuse problem - my fellow reviewers use the term "coupon queens", though these can be both male and female - and I applaud Amazon taking this position even though it means I will receive fewer items to review.
I would urge you, though, not to automatically downvote incentivized reviews. If you believe the review is genuinely not helpful, ("I haven't received it yet but I'm sure my grandson will like it, unless I sell it on eBay first..), downvote away. But there are good reviewers out there trying to help purchasers as if they had bought the item themselves. Indeed, those who paid for an item are often biased in favor of it so as to not appear foolish for having spent the money.
From what I read, it's the heartbeat-sensing LED on the watch's underside that overheats.
Many banks, including mine, do this as well. But that doesn't help with card-not-present transactions.
You misunderstand the threat. It is not that an attacker uses MITM to relay the data, though that has been demonstrated. The threat is due to the cardholder data (name, account number and expiration date) being readable in plaintext from hundreds of meters away using readily available and inexpensive equipment. This data can then be used to perform offline transactions or other identity fraud ("what are the last four digits of your credit card number..." sort of "verification" questions.)
Even just knowing the name of a cardholder passing by could be a security risk (ask in nearby hotel for the room of Jane Doe, etc.)
But consider what happened to me last year on the first day of a two-week international vacation. I got a notice from my primary card bank (Chase) that my card had been compromised and that they would cancel it and send a new one. The problem was that I was depending on this card (which has no foreign transaction fees) and I would be moving around every two days meaning that it would be difficult to get a new card to me quickly. They did offer a compromise - disable any card-not-present transactions and had me list which countries I would be in, until I could return home. I had several online purchases outstanding so I had to scramble to fix those, and even then I missed one of the countries I would be in and had my card declined twice before I figured out the problem.
I am sure this case was a leak from a merchant that stored card data insecurely, or maybe a skimmer somewhere. That card did not have RFID. We really do need to move quicker to a tokenized system. Even so, it was more than a minor annoyance to me.
The EMV chip contacts have nothing to do with RFID capability.
The chip creates a digital signature for the transaction, but the data is cleartext. EMV makes card cloning much more difficult, but it doesn't protect the data against interception.
Pretty much every week I place online orders with merchants that don't ask for CVV2. While it is true that the RFID data doesn't include CVV2 (it has a digital signature code created by the EMV chip), what is sent is MORE than enough to commit wide-scale fraud.
Do you really think that the banks would have added a feature that makes fraud as easy as pointing an antenna at people walking past? Where are the crime waves of people draining accounts with concealed card readers?
Why yes, I do. It has been demonstrated numerous times, and is easy to reproduce on your own with inexpensive equipment. The specs are public (have you read them? I have.) Even EMV chips send your card information in plaintext - any encryption needs to be added by the terminal. You may not have read much about it as RFID cards are still uncommon in the US, but that is changing. The specs for this and EMV are more than a decade old and were designed for the banks' convenience, not your protection.
US banks have shown a singular unwillingness to invest in technology that helps their customers. In the US they fall back on "zero liability" terms that mostly shield customers from direct financial losses but then pass on the cost of billions of dollars of fraud to all consumers and merchants.
PayWave is awesome. You just tap the card on the terminal (or near it) to pay, no pin, no signature.
That it is - I have used it once so far, at a Walgreens, and it was very speedy. Not too surprising as it's effectively the same as swiping - there's no challenge-response sequence as there is with a chip-based transaction. Indeed, Visa's specs for PayWave require a response in half a second.
That said, I very much prefer tokenization systems such as Apple Pay and I find that is almost as fast as PayWave. (PayWave is Visa's brand name for RFID transactions - other card issuers use different names, but the underlying technology is the same.)