Of the four present members of The Rolling Stones, three (Mick Jagger, Keith Richards, and Charlie Watts) were with the band since the beginning. You might be confusing them with Stone Temple Pilots, whose original lead vocalist recently died.
But if certificates are a dime a dozen, you've not really protected from MITM phishing as well as impersonation phishing.
Then let me reword my perception of your central thesis one more time: "It is not worth making a certificate that protects against impersonation of a domain owner using the same domain unless it is also worth paying for a certificate that protects against impersonation of a business using a different domain." Do I have it right now?
I think bingoUV's point is that novice users do not know what to look for to tell the difference between DV and EV certificates. The icon is the same either way: a lock for DV or a lock and business name for EV. Novices don't know to look for the business name because they haven't been taught so, as back when TLS proponents were first saying "look for the lock", EV didn't exist.
unless you have a DBMS that includes robust search functionality (which really means having a separate store of the data, an index, that is optimized for search rather than relational integrity).
It's not full text, but SQL offers some automatic indexing functions. For example, it's trivial to index products by SKU, by price, by brand, by date added, by category, etc. In fact, when one object refers to an object in another table, these "foreign keys" are automatically indexed. The tradeoff is that indexes in the database are subject to slowdown to maintain consistency guarantees at all times.
My thoughts would be to setup an association that basically took ownership of all patents produced by engineers and then licensed these back to employers.
Employers would fire or decline to hire anybody who joins such an association.
Of course Apple/Samsung/Google would fight such a setup like crazy, which is sad in itself, but if enough engineers en-mass started doing this, and in particular the top talent in these companies, they would have little ability to fight it.
"A site doesn't need MITM protection unless it also needs phishing protection." Are you claiming or not claiming this?
MITM is too much work for dragnet.
Yet MITM is common on corporate networks.
And I remember emails from my bank a few years ago about looking for the padlock icon
It depends on how long ago was "a few years ago". Was it before the introduction of extended validation? If so, browsers might not yet have introduced UI to distinguish domain- from organization-validated certificates.
So it remains a bad idea - insufficiently validated websites getting that padlock, getting more people to be phished.
For a web site operated by an individual as a hobby, where the operator desires protection from passive and MITM attacks, what measures count as "sufficient validation" to you? When forming your answer, consider that trademark laws do not apply to names of individuals to the same extent that they apply to names of companies. Different people may have the same name. This means a domain name displayed in the address bar might be more distinctive than an individual's name displayed in the address bar. Or ought sites operated by individuals to lack protection from MITM attacks?
Interfaces have become too large for a human being to keep in his short-term memory. So if it's acceptable for an interface to make it too easy for a human being to accidentally produce insecure code, then perhaps you're right that human beings in general "should not be doing this in the first place."
The big pink box at the top of the page marking it as deprecated
Good point
plus the warnings in the error log when running in dev mode
Can "dev mode" and production mode be used on the same server? And/or can logs from dev mode or production mode be sent to different log files for different shared hosting customers? If not, then it isn't suitable for use with shared hosting. In addition, a lot of developers may not be running exactly the same version of PHP, and a developer may conflate "dev mode" behaviors with differences between the version of PHP for Windows running on his dev box and the version of PHP for Linux running on the production server.
Or even better, you don't even have to copy the code, you just need to type the google terms that result in the appropriate SO question as the first hit.
Java web apps would typically split the presentation, logic and storage from each other and the storage would be via Hibernate / OpenJPA.
Do you also advocate separating storage from search? SQL can do both in one command. How does search work in Hibernate / OpenJPA? Does the application have to maintain all indexes itself?
For example the php expression blocks should do html escaping, and when you don't want escaping you would use a more verbose command that would make it clear that you are outputting a trusted value.
Which would make it that much harder to use PHP to output a Content-type other than text/html or types matching application/*+xml.
Kind of makes me wish that standards for different languages would refuse to accept normal strings as arguments to anything that "executes a statement" (SQL, shell commands, etc), and instead require a custom command-string type/class which does not allow straightforward concatenation (making developers explicitly have to convert types if they want to concatenate, maybe with a conversion function name like "useUntrustedString" or somesuch), with the error message if they try to concatenate without explicit conversion pointing out not just that concatenation is banned, but stating why it's banned.
Say you want to write a SELECT statement in SQL, but you want to give the app's user options for what information is included in a report. These options may cause the statement to refer to different columns in the heading, or a JOIN to different tables, or different columns used for summary (GROUP BY). For these kinds of query adaptation, you can't use a prepared statement because the PDO API allows substituting only literal scalar values (such as 3 or 'kitten') into a prepared statement, not table names, not column names, and definitely not entire JOIN clauses. What's the best practice to securely build queries at runtime like this in a language that bans concatenation of SQL strings? Encouraging useUntrustedString for things like this would just encourage users to use all useUntrustedString all the time.
Personally, I wouldn't consider functional bugs to bugs in the language, unless there is no way to accomplish a task without generating exploitable bugs.
The standard library has bugs. For example, one bug in PHP is the existence of mysql_escape_string, whose behavior is unlikely to match the quoting conventions set on the current connection except by coincidence. These bugs are kept for the sake of backward compatibility, even if they're exploitable by using an incorrect quoting convention for SQL injection.
But it is a bug to fail to discourage new code from using deprecated library functionality. Failure to conspicuously mark deprecated functionality as such in the manual, such as by changing the background styling, is a bug. Failure to log use of deprecated functions by default is a bug. Requiring the server operator to silence deprecation warnings server-wide just to run a particular legacy app is a bug. This means the server administrator or shared hosting customer needs the ability to suppress logging of particular deprecated functions used by particular legacy apps while continuing to log other deprecated functions and the same functions used in other apps.
Two of the items on the list, iOS and Android, are not programming languages. Why do they appear on a list of programming languages?
Because it's poorly named and should have been called a list of "platforms" more than languages. The opportunities to introduce defects using Java in the javax.servlet framework are very different from those using Java in the android framework. Likewise, the characteristics of bugs in C# and Visual Basic web apps should be fairly similar because both use the ASP.NET framework.
There is a fourth one - phishing. You might call it a variant of typo-squatting, but actually it is not.
Phishing is similar to typosquatting in that the user is being redirected to the wrong domain. I agree that an organization-validated cert protects against this, especially among novice users who can't be trusted to stick to bookmarks. But a domain-validated cert might be enough if credentials aren't valuable enough to allow rapid irreparable damage before blocking the account, such as a forum or wiki account compared to a bank account.
There is a fifth attack vector - though none of the business of website owners or visitors. But EFF has made it their business to complain about it. It is the dragnet surveillance by TLAs. HTTPS prevents that too. "Let's Encrypt" sounds like an attack on that attack.
This counts as passive sniffing and occasionally MITM.
both - banks' padlock icon and Joe Sixpack's website's padlock icon look the same to me.
On Pin Eight, which uses a domain-validated certificate, Firefox shows me only a green lock. On Chase, which uses an organization-validated certificate with EV extensions, Firefox shows me a green lock plus "JPMorgan Chase & Co." in green.
Thank you for explaining. Consider three different attacks on an HTTP session: passive sniffing, active proxying by a man in the middle, and typosquatting. HTTPS with a self-signed certificate solves the first. HTTPS with a domain-validated certificate solves the first two. HTTPS with an organization-validated certificate solves all three.
Want to send encrypted? Generate a certificate and send away, no problem there either.
This resists passive attacks but not MITM or typosquatting. Traditionally, web browsers that support HTTPS have set the bar at MITM.
Want someone to vouch for you that you are the sender you pretend to be? Ouch, that will be $x - not because it is a prerogative of the rich, but we need to do the following verifications which cost $x.
That depends on whether you define attacks on "the sender you pretend to be" to include typosquatting. The premise of StartSSL, WoSign, and Let's Encrypt is that validation that you are the same person who owns a particular domain costs very little on top of what you are already paying for a domain. Perhaps we disagree on the impact of typosquatting, especially in a hypertext environment when people are more likely to find web sites through hyperlinks in other web documents, such as web search results, news articles, opinion columns, social media, and bookmarks, than through type-in traffic.
Remember banks are relying on the "HTTPS" lock icon and instructing their users to look for it and consider themselves "safe" if it exists.
The two tiers of CA-signed certificate have distinct purposes. Domain validation is suitable for basic validation that the sender is authorized to speak for the owner of a particular domain, whereas organization validation is suitable for further validation that the owner of a domain is also an established business. Domain validation is resistant to MITM attacks, but only organization validation is resistant to typosquatting. A hobbyist operator of a forum or wiki would use the former because he wants his site's login page to be resistant to MITM, but he sees little risk (probability times damage) of typosquatting given that forums rely on bookmarks and wikis rely on search traffic. A bank would use the latter because it sees more type-in traffic and thus more risk of typosquatting.
The GNU mentality assumes that interfaces are public domain and implementations are copyrighted but licensed under a free software license. GNU, for example, is a copylefted implementation of the POSIX interface. The new wrinkle in Oracle is copyright in the interface itself.
Let's Encrypt already validates that the sender is authorized to speak for the domain. But you make it sound like there's no place for encryption in transit without stronger sender identification, ideally one verified against real-world credentials. Further, you make it sound like there ought to be an entry barrier to sender identification. Do I understand you correctly so far? And if so, how much ought the right to send to cost, in your opinion? Should individuals have the right to send, outside the course of a business?
Slashdot Mirror
Of the four present members of The Rolling Stones, three (Mick Jagger, Keith Richards, and Charlie Watts) were with the band since the beginning. You might be confusing them with Stone Temple Pilots, whose original lead vocalist recently died.
But if certificates are a dime a dozen, you've not really protected from MITM phishing as well as impersonation phishing.
Then let me reword my perception of your central thesis one more time: "It is not worth making a certificate that protects against impersonation of a domain owner using the same domain unless it is also worth paying for a certificate that protects against impersonation of a business using a different domain." Do I have it right now?
I think bingoUV's point is that novice users do not know what to look for to tell the difference between DV and EV certificates. The icon is the same either way: a lock for DV or a lock and business name for EV. Novices don't know to look for the business name because they haven't been taught so, as back when TLS proponents were first saying "look for the lock", EV didn't exist.
Then what would you rather enter into your browser when setting up Thunderbird? imap.example.com or 162.150.32.54?
unless you have a DBMS that includes robust search functionality (which really means having a separate store of the data, an index, that is optimized for search rather than relational integrity).
It's not full text, but SQL offers some automatic indexing functions. For example, it's trivial to index products by SKU, by price, by brand, by date added, by category, etc. In fact, when one object refers to an object in another table, these "foreign keys" are automatically indexed. The tradeoff is that indexes in the database are subject to slowdown to maintain consistency guarantees at all times.
My thoughts would be to setup an association that basically took ownership of all patents produced by engineers and then licensed these back to employers.
Employers would fire or decline to hire anybody who joins such an association.
Of course Apple/Samsung/Google would fight such a setup like crazy, which is sad in itself, but if enough engineers en-mass started doing this, and in particular the top talent in these companies, they would have little ability to fight it.
Except in antitrust court.
"A site doesn't need MITM protection unless it also needs phishing protection." Are you claiming or not claiming this?
MITM is too much work for dragnet.
Yet MITM is common on corporate networks.
And I remember emails from my bank a few years ago about looking for the padlock icon
It depends on how long ago was "a few years ago". Was it before the introduction of extended validation? If so, browsers might not yet have introduced UI to distinguish domain- from organization-validated certificates.
So it remains a bad idea - insufficiently validated websites getting that padlock, getting more people to be phished.
For a web site operated by an individual as a hobby, where the operator desires protection from passive and MITM attacks, what measures count as "sufficient validation" to you? When forming your answer, consider that trademark laws do not apply to names of individuals to the same extent that they apply to names of companies. Different people may have the same name. This means a domain name displayed in the address bar might be more distinctive than an individual's name displayed in the address bar. Or ought sites operated by individuals to lack protection from MITM attacks?
Interfaces have become too large for a human being to keep in his short-term memory. So if it's acceptable for an interface to make it too easy for a human being to accidentally produce insecure code, then perhaps you're right that human beings in general "should not be doing this in the first place."
What would be insanely easier is making a command that let you specify it directly rather than having 2 commands
I wonder how hard that would be to implement in terms of PHP output buffering.
The big pink box at the top of the page marking it as deprecated
Good point
plus the warnings in the error log when running in dev mode
Can "dev mode" and production mode be used on the same server? And/or can logs from dev mode or production mode be sent to different log files for different shared hosting customers? If not, then it isn't suitable for use with shared hosting. In addition, a lot of developers may not be running exactly the same version of PHP, and a developer may conflate "dev mode" behaviors with differences between the version of PHP for Windows running on his dev box and the version of PHP for Linux running on the production server.
These bugs are mostly irrelevant. The ones that matter is where the programmer did not understand the code he/she wrote.
Languages make it easier or harder for a programmer to reason about the behavior of the code he/she wrote.
Or even better, you don't even have to copy the code, you just need to type the google terms that result in the appropriate SO question as the first hit.
That'd bring new meaning to "full Stack developer".
Java web apps would typically split the presentation, logic and storage from each other and the storage would be via Hibernate / OpenJPA.
Do you also advocate separating storage from search? SQL can do both in one command. How does search work in Hibernate / OpenJPA? Does the application have to maintain all indexes itself?
For example the php expression blocks should do html escaping, and when you don't want escaping you would use a more verbose command that would make it clear that you are outputting a trusted value.
Which would make it that much harder to use PHP to output a Content-type other than text/html or types matching application/*+xml.
Languages make it easier or harder for programmers to inadvertently make bugs.
Kind of makes me wish that standards for different languages would refuse to accept normal strings as arguments to anything that "executes a statement" (SQL, shell commands, etc), and instead require a custom command-string type/class which does not allow straightforward concatenation (making developers explicitly have to convert types if they want to concatenate, maybe with a conversion function name like "useUntrustedString" or somesuch), with the error message if they try to concatenate without explicit conversion pointing out not just that concatenation is banned, but stating why it's banned.
Say you want to write a SELECT statement in SQL, but you want to give the app's user options for what information is included in a report. These options may cause the statement to refer to different columns in the heading, or a JOIN to different tables, or different columns used for summary (GROUP BY). For these kinds of query adaptation, you can't use a prepared statement because the PDO API allows substituting only literal scalar values (such as 3 or 'kitten') into a prepared statement, not table names, not column names, and definitely not entire JOIN clauses. What's the best practice to securely build queries at runtime like this in a language that bans concatenation of SQL strings? Encouraging useUntrustedString for things like this would just encourage users to use all useUntrustedString all the time.
I don't see how Taylor Swift can solve this problem
Ask the headline writer for El Reg.
Personally, I wouldn't consider functional bugs to bugs in the language, unless there is no way to accomplish a task without generating exploitable bugs.
The standard library has bugs. For example, one bug in PHP is the existence of mysql_escape_string, whose behavior is unlikely to match the quoting conventions set on the current connection except by coincidence. These bugs are kept for the sake of backward compatibility, even if they're exploitable by using an incorrect quoting convention for SQL injection.
But it is a bug to fail to discourage new code from using deprecated library functionality. Failure to conspicuously mark deprecated functionality as such in the manual, such as by changing the background styling, is a bug. Failure to log use of deprecated functions by default is a bug. Requiring the server operator to silence deprecation warnings server-wide just to run a particular legacy app is a bug. This means the server administrator or shared hosting customer needs the ability to suppress logging of particular deprecated functions used by particular legacy apps while continuing to log other deprecated functions and the same functions used in other apps.
Two of the items on the list, iOS and Android, are not programming languages. Why do they appear on a list of programming languages?
Because it's poorly named and should have been called a list of "platforms" more than languages. The opportunities to introduce defects using Java in the javax.servlet framework are very different from those using Java in the android framework. Likewise, the characteristics of bugs in C# and Visual Basic web apps should be fairly similar because both use the ASP.NET framework.
So what languages for apping web apps aren't Luddite? Now that Swift is free software, would it be worth it to tailor Swift for server-side use?
There is a fourth one - phishing. You might call it a variant of typo-squatting, but actually it is not.
Phishing is similar to typosquatting in that the user is being redirected to the wrong domain. I agree that an organization-validated cert protects against this, especially among novice users who can't be trusted to stick to bookmarks. But a domain-validated cert might be enough if credentials aren't valuable enough to allow rapid irreparable damage before blocking the account, such as a forum or wiki account compared to a bank account.
There is a fifth attack vector - though none of the business of website owners or visitors. But EFF has made it their business to complain about it. It is the dragnet surveillance by TLAs. HTTPS prevents that too. "Let's Encrypt" sounds like an attack on that attack.
This counts as passive sniffing and occasionally MITM.
both - banks' padlock icon and Joe Sixpack's website's padlock icon look the same to me.
On Pin Eight, which uses a domain-validated certificate, Firefox shows me only a green lock. On Chase, which uses an organization-validated certificate with EV extensions, Firefox shows me a green lock plus "JPMorgan Chase & Co." in green.
Perhaps because the phone would have to waste time launching each (and killing another to save RAM) as each receives messages.
Thank you for explaining. Consider three different attacks on an HTTP session: passive sniffing, active proxying by a man in the middle, and typosquatting. HTTPS with a self-signed certificate solves the first. HTTPS with a domain-validated certificate solves the first two. HTTPS with an organization-validated certificate solves all three.
Want to send encrypted? Generate a certificate and send away, no problem there either.
This resists passive attacks but not MITM or typosquatting. Traditionally, web browsers that support HTTPS have set the bar at MITM.
Want someone to vouch for you that you are the sender you pretend to be? Ouch, that will be $x - not because it is a prerogative of the rich, but we need to do the following verifications which cost $x.
That depends on whether you define attacks on "the sender you pretend to be" to include typosquatting. The premise of StartSSL, WoSign, and Let's Encrypt is that validation that you are the same person who owns a particular domain costs very little on top of what you are already paying for a domain. Perhaps we disagree on the impact of typosquatting, especially in a hypertext environment when people are more likely to find web sites through hyperlinks in other web documents, such as web search results, news articles, opinion columns, social media, and bookmarks, than through type-in traffic.
Remember banks are relying on the "HTTPS" lock icon and instructing their users to look for it and consider themselves "safe" if it exists.
The two tiers of CA-signed certificate have distinct purposes. Domain validation is suitable for basic validation that the sender is authorized to speak for the owner of a particular domain, whereas organization validation is suitable for further validation that the owner of a domain is also an established business. Domain validation is resistant to MITM attacks, but only organization validation is resistant to typosquatting. A hobbyist operator of a forum or wiki would use the former because he wants his site's login page to be resistant to MITM, but he sees little risk (probability times damage) of typosquatting given that forums rely on bookmarks and wikis rely on search traffic. A bank would use the latter because it sees more type-in traffic and thus more risk of typosquatting.
The GNU mentality assumes that interfaces are public domain and implementations are copyrighted but licensed under a free software license. GNU, for example, is a copylefted implementation of the POSIX interface. The new wrinkle in Oracle is copyright in the interface itself.
Let's Encrypt already validates that the sender is authorized to speak for the domain. But you make it sound like there's no place for encryption in transit without stronger sender identification, ideally one verified against real-world credentials. Further, you make it sound like there ought to be an entry barrier to sender identification. Do I understand you correctly so far? And if so, how much ought the right to send to cost, in your opinion? Should individuals have the right to send, outside the course of a business?