These points were exactly what I was thinking as I reading the summary. I would mod you up if I had mod points.
Although as a partial counterpoint, if it is noticeably cheaper, it might indirectly allow the balance point between cost, speed, and yield of mass produced parts to be a bit faster...
I replaced the batteries in my 15c for the first time a couple of years ago. And just to be clear, it has three small non-rechargable button batteries, like you would find in a watch.
I'm mildly curious what stories (and/or original headlines) go with some of these generated headlines, but I notice that neither TFA nor the TFS seems to have preserved that information.
In my case, $DAYJOB now uses gmail-hosted "G Suite" email, and has configured it to require either the web interface, or OAUTH2-based POP/IMAP/SMTP authentication. No app passwords or other options are available.
As mentioned by others, it generally seems really low security to trust your data to a server not directly under your control, regardless of whatever access controls it supposedly enforces.
It is debatable if all the extra hoops needed for OAUTH2 actually improve or degrade security, especially if you use a strong password (long randomly generated), protect it carefully (e.g. password manager), and also treat recovery questions the same way as the password (long randomly generated, stored securely).
To actually have usable, email, I wrote up some instructions, patches, and scripts to allow me to use any local email client while relaying through google with OAUTH2. In my case, I prefer mutt, but with this infrastructure, I could use any email client I wanted. Perhaps other people might find my instructions useful.
In the last few years he has posted much less often, and when he posts, it is usually only announcing the latest product his company has made, but most of his older "reading list" articles (from the front page) are still excellent.
Properly implemented, SRP does not store the the secret on the server end. It only stores v=pow(g,x) mod N, where "x" is a secret needed on the client end (derived from the password), and can't be extracted from v without either using a brute-force algorithm (try all weak passwords), or solving the discrete logarithm problem. You may want to read https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol more carefully.
I hadn't looked at SCRAM before, but from at a quick glance it looks like the only thing preventing an attacker from brute forcing weak passwords from nothing but a passively captured login session is an expensive-to-compute hash function (PBKDF2). It isn't as bad if SCRAM is wrapped in an SSL/TLS session with associated certificate, but if you really trust nothing has MITMed (i.e. incorrectly trusted certificate) or otherwise broken TLS (from the perspective of the client authenticating the server), then why not just send the password directly through the tunnel (from client to server), and avoid extra complexity?
Note that capturing a login session is generally a much lower bar than obtaining the password database, and SRP does not allow brute forcing even trivially weak passwords from just a captured login exchange. (As long as there aren't any huge breakthroughs in quantum computing or other discrete logarithm algorithms.)
All that said, you are correct that SRP or other low level single-connection authentication mechanisms do nothing for the cross-party authentication issue discussed in the article.
Possibly useful if you have old Apple ][ disks laying around:
Many years ago I graduated and lost access to Apple ][ machines at school, but still had a bunch of floppy disks for them.
Then just a few years ago I happened to stumble across a tool called disk2fdi http://www.oldskool.org/disk2fdi for MS-DOS, that can read Apple disks using IBM hardware. I was able to use the trial version of that (from MS-DOS on an old IBM compatible) to recover images of my disks.
I transferred the images to a newer Linux machine, and was able to use dos33fsprogs https://github.com/deater/dos33fsprogs to extract individual files and confirm that the recovery was successful. I also tested some of the disk images in an Apple ][ emulator.
I also have a couple of old TRS-80 disks (possibly a version of CPM?) that I have not been able to recover, although I haven't really tried very hard either.
I agree with plain xterm. Others tend to annoy me.
It's true there are a number of oddities about xterm that might put off people who've never used it before. By default no scrollbar, and once you enable it, it is kind of odd in that you don't use "modern" conventions to interact with it. Its menus and other features are hidden by keystroke combinations that are probably hard to discover if you don't already know about them. I don't like some aspects of the default configuration. I've heard the code is a mess internally, although I haven't checked. Etc.
But I still think xterm is the best. Some emulators flicker when scrolling; not xterm. It just seems faster, and I'm spoiled: even a small fraction of a second response time seems excessive to me. Uses very little RAM. Very configurable if you actually take the time to search through the man page. No superfluous decorations around the terminal (even a scrollbar) unless you want them. Doesn't depend on any huge modern GUI toolkits; if you can run X at all, then you can run xterm. It's available everywhere; get used to it once, and you aren't constantly getting used to other terminal idiosyncracies. Etc.
My personal configuration:
xterm*saveLines: 3000 xterm*scrollBar: true xterm*boldFont: 6x10 xterm*foreground: white xterm*background: black xterm*font: 6x10 ! Very useful to quit out of vi or less, and still refer to ! what you were seeing while typing next command: xterm*titeInhibit: true xterm*pointerMode: 0 ! works better with the black background I like above: *VT100*color4: blue *VT100*color12: lightblue *VT100*colorUL: yellow *VT100*colorBD: white
If you can pick or control the overall authentication protocol, it would be even better to only store the s and v parameters from the Secure Remote Password (SRP) protocol. Pick a good underlying hash function H(), such as in the parent post. SRP uses some fancy zero-knowledge proof / public key algorithms (fairly interesting if you study it) to significantly reduce attack cross-sections for a much wider range of attack scenarios than just a hashed password, even when the password is weak.
Unfortunately, the most common situation is a web browser using http or https, and I don't know any way to use SRP properly in that context. Perhaps implement a secure tunnel on top of http in javascript and send all data through that - but that is totally tedious and impractical, probably can't work with images, and doesn't prevent MITM (man-in-the-middle) attacker from replacing the javascript in a way nearly impossible for either end to detect.
Someone ought to define a way to delegate a web apps' password validation to the SSL layer of the https connection, which would then use SRP to do the validation. Find ways to make it hard for attacker to force a downgrade to less secure authentication, for example by making the browser remember what web sites have used SRP in the past, and refusing to use weaker authentication protocols for them ever again. Done well, this would also reduce vulnerability to should-not-have-been-signed fraudulent certificates.
POSIX filesystem semantics, including removing/renaming open files (continue access until closed), transition away from mandatory file locking by default, transition away from carriage returns in text files (fix notepad, start changing tools to default to leaving the carriage returns out), switch to UTF-8 encoding for unicode by default for filenames and contents (instead of 2-bytes-per-character), transition to case-sensitive filenames (when most people use GUIs instead of typing names, why have the insensitive complexity in there...), etc.
Fix it so POSIX api functions are no longer treated as bastard stepchildren - implement them in the core, and emulate others.
Include a good, standard scriptable command line interpreter by default, where it can be counted on to be installed./bin/sh and associated commands would be a vast improvement, and it wouldn't be hard support command line editting ala bash or zsh as well.
I could go on for some time, but maybe you see the pattern. Summary: Keep the fancy end user GUI stuff, but fix the underlying foundation.
http://xkcd.com/681/ has a nice graph of gravitational potential energy differences that need to be overcome when traveling around the solar system (ignoring gravity assists, etc). Mercury is clearly harder to match up with energy-wise than anywhere else besides the sun itself.
This reminds me of The Gambler by Paolo Bacigalupi, a short story where a reporter on the web tries to pursue meaningful stories rather than the fluff that attracts the most hits, and has trouble meeting his quota as a result. A very good read.
Another related text interface benefit is support for essentially unlimited type-ahead (typing in stuff faster then the computer visually responds to it). In GUIs, single windows generally support type-ahead, but it typically does not work if a dialog opens or closes.
Given how confused the rep appears to be, does anyone else suspect that the written note in his acoount says "$0.002" even as they said they wrote 0.002 cents?
This special version of munpack adds a "-m" flag to extract "message/rfc822"'s to a named file. This can be useful if your company has annoying policies (must have exchange account; no POP or IMAP access; etc) designed to force you to use Microsoft Outlook and Exchange.
Instead, you can set up a rule to "forward as attachment", and then use a combination of this tool, some procmail rules, and a shell script (included) to read your mail on any UNIX system with any standard mail reader.
Slashdot Mirror
These points were exactly what I was thinking as I reading the summary. I would mod you up if I had mod points.
Although as a partial counterpoint, if it is noticeably cheaper, it might indirectly allow the balance point between cost, speed, and yield of mass produced parts to be a bit faster...
I replaced the batteries in my 15c for the first time a couple of years ago. And just to be clear, it has three small non-rechargable button batteries, like you would find in a watch.
I'm mildly curious what stories (and/or original headlines) go with some of these generated headlines, but I notice that neither TFA nor the TFS seems to have preserved that information.
In my case, $DAYJOB now uses gmail-hosted "G Suite" email, and has configured it to require either the web interface, or OAUTH2-based POP/IMAP/SMTP authentication. No app passwords or other options are available.
As mentioned by others, it generally seems really low security to trust your data to a server not directly under your control, regardless of whatever access controls it supposedly enforces.
It is debatable if all the extra hoops needed for OAUTH2 actually improve or degrade security, especially if you use a strong password (long randomly generated), protect it carefully (e.g. password manager), and also treat recovery questions the same way as the password (long randomly generated, stored securely).
To actually have usable, email, I wrote up some instructions, patches, and scripts to allow me to use any local email client while relaying through google with OAUTH2. In my case, I prefer mutt, but with this infrastructure, I could use any email client I wanted. Perhaps other people might find my instructions useful.
Old but excellent article about the choice between organic growth vs get big fast, and how to implement the decision: https://www.joelonsoftware.com/2000/05/12/strategy-letter-i-ben-and-jerrys-vs-amazon/
The article's links seem to have better real experimental data backing them up, but I still think I prefer reading http://www.joelonsoftware.com/'s 15 year old article "Human Task Switches Considered Harmful". The second half of "Where do These People Get Their (Unoriginal) Ideas?" is also relevant.
In the last few years he has posted much less often, and when he posts, it is usually only announcing the latest product his company has made, but most of his older "reading list" articles (from the front page) are still excellent.
Properly implemented, SRP does not store the the secret on the server end. It only stores v=pow(g,x) mod N, where "x" is a secret needed on the client end (derived from the password), and can't be extracted from v without either using a brute-force algorithm (try all weak passwords), or solving the discrete logarithm problem. You may want to read https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol more carefully.
I hadn't looked at SCRAM before, but from at a quick glance it looks like the only thing preventing an attacker from brute forcing weak passwords from nothing but a passively captured login session is an expensive-to-compute hash function (PBKDF2). It isn't as bad if SCRAM is wrapped in an SSL/TLS session with associated certificate, but if you really trust nothing has MITMed (i.e. incorrectly trusted certificate) or otherwise broken TLS (from the perspective of the client authenticating the server), then why not just send the password directly through the tunnel (from client to server), and avoid extra complexity?
Note that capturing a login session is generally a much lower bar than obtaining the password database, and SRP does not allow brute forcing even trivially weak passwords from just a captured login exchange. (As long as there aren't any huge breakthroughs in quantum computing or other discrete logarithm algorithms.)
All that said, you are correct that SRP or other low level single-connection authentication mechanisms do nothing for the cross-party authentication issue discussed in the article.
Possibly useful if you have old Apple ][ disks laying around:
Many years ago I graduated and lost access to Apple ][ machines at school, but still had a bunch of floppy disks for them.
Then just a few years ago I happened to stumble across a tool called disk2fdi http://www.oldskool.org/disk2fdi for MS-DOS, that can read Apple disks using IBM hardware. I was able to use the trial version of that (from MS-DOS on an old IBM compatible) to recover images of my disks.
I transferred the images to a newer Linux machine, and was able to use dos33fsprogs https://github.com/deater/dos33fsprogs to extract individual files and confirm that the recovery was successful. I also tested some of the disk images in an Apple ][ emulator.
I also have a couple of old TRS-80 disks (possibly a version of CPM?) that I have not been able to recover, although I haven't really tried very hard either.
I agree with plain xterm. Others tend to annoy me.
It's true there are a number of oddities about xterm that might put off people who've never used it before. By default no scrollbar, and once you enable it, it is kind of odd in that you don't use "modern" conventions to interact with it. Its menus and other features are hidden by keystroke combinations that are probably hard to discover if you don't already know about them. I don't like some aspects of the default configuration. I've heard the code is a mess internally, although I haven't checked. Etc.
But I still think xterm is the best. Some emulators flicker when scrolling; not xterm. It just seems faster, and I'm spoiled: even a small fraction of a second response time seems excessive to me. Uses very little RAM. Very configurable if you actually take the time to search through the man page. No superfluous decorations around the terminal (even a scrollbar) unless you want them. Doesn't depend on any huge modern GUI toolkits; if you can run X at all, then you can run xterm. It's available everywhere; get used to it once, and you aren't constantly getting used to other terminal idiosyncracies. Etc.
My personal configuration:
I hope this is implemented. Then I'll just code mysefl up a minivan: http://dilbert.com/strips/comi...
(Or was it the worst? I forget...)
> 1 UOW = program for yourself
> 3 UOW = give it to someone else
> (you install, you copy, etc)
> 9 UOW = give it to local group
> (howto, platform change)
> 27 UOW = shareware/open source
> (configure/make/make install)
> 81 UOW = product
> (real docs, slick UI, support teams)
> 243 UOW = business
> (lawyers, CEO, sales, marketing)
If you can pick or control the overall authentication protocol, it would be even better to only store the s and v parameters from the Secure Remote Password (SRP) protocol. Pick a good underlying hash function H(), such as in the parent post. SRP uses some fancy zero-knowledge proof / public key algorithms (fairly interesting if you study it) to significantly reduce attack cross-sections for a much wider range of attack scenarios than just a hashed password, even when the password is weak.
Unfortunately, the most common situation is a web browser using http or https, and I don't know any way to use SRP properly in that context. Perhaps implement a secure tunnel on top of http in javascript and send all data through that - but that is totally tedious and impractical, probably can't work with images, and doesn't prevent MITM (man-in-the-middle) attacker from replacing the javascript in a way nearly impossible for either end to detect.
Someone ought to define a way to delegate a web apps' password validation to the SSL layer of the https connection, which would then use SRP to do the validation. Find ways to make it hard for attacker to force a downgrade to less secure authentication, for example by making the browser remember what web sites have used SRP in the past, and refusing to use weaker authentication protocols for them ever again. Done well, this would also reduce vulnerability to should-not-have-been-signed fraudulent certificates.
Some ways Windows core OS could be improved:
POSIX filesystem semantics, including removing/renaming open files (continue access until closed), transition away from mandatory file locking by default, transition away from carriage returns in text files (fix notepad, start changing tools to default to leaving the carriage returns out), switch to UTF-8 encoding for unicode by default for filenames and contents (instead of 2-bytes-per-character), transition to case-sensitive filenames (when most people use GUIs instead of typing names, why have the insensitive complexity in there...), etc.
Fix it so POSIX api functions are no longer treated as bastard stepchildren - implement them in the core, and emulate others.
Include a good, standard scriptable command line interpreter by default, where it can be counted on to be installed. /bin/sh and associated commands would be a vast improvement, and it wouldn't be hard support command line editting ala bash or zsh as well.
I could go on for some time, but maybe you see the pattern. Summary: Keep the fancy end user GUI stuff, but fix the underlying foundation.
http://xkcd.com/681/ has a nice graph of gravitational potential energy differences that need to be overcome when traveling around the solar system (ignoring gravity assists, etc). Mercury is clearly harder to match up with energy-wise than anywhere else besides the sun itself.
This reminds me of The Gambler by Paolo Bacigalupi, a short story where a reporter on the web tries to pursue meaningful stories rather than the fluff that attracts the most hits, and has trouble meeting his quota as a result. A very good read.
Another related text interface benefit is support for essentially unlimited type-ahead (typing in stuff faster then the computer visually responds to it). In GUIs, single windows generally support type-ahead, but it typically does not work if a dialog opens or closes.
Given how confused the rep appears to be, does anyone else suspect that the written note in his acoount says "$0.002" even as they said they wrote 0.002 cents?
Does your company IT bureaucracy disable POP/IMAP access to the exchange server?
Cutsomized munpack
This special version of munpack adds a "-m" flag to extract "message/rfc822"'s to a named file. This can be useful if your company has annoying policies (must have exchange account; no POP or IMAP access; etc) designed to force you to use Microsoft Outlook and Exchange.
Instead, you can set up a rule to "forward as attachment", and then use a combination of this tool, some procmail rules, and a shell script (included) to read your mail on any UNIX system with any standard mail reader.