HP2000 timesharing computer system with remote access via teletype at 110bps and an accoustic model. I can still remember the smell of teletype ribbons and paper in the high school computer room.

Why? To be able to get the computer to compute stuff for me. Initial programs were to print trig/log tables so i wouldn't have to buy them. I was already a science geek, computing orbital parameters for fun, and adding logs was easier than multiplication.

I was 13 years old. It was 1974.

The next year the high school got a 300 bps DecWriter. OMG! That was "fast". We got a card reader and optical scan 40 column cards, so we could "program" outside of the computer room. At some point we got a 1200 bps portable thermal paper TI terminal.

By 1975 or 76, I was hacking on an Altair at a local business, writing accounting software for them in Basic.

My first computer that I actually owned was a 6809-based system running Flex around 1984. A PC clone came shortly after that. By this time I was well on my way toward an Honours Computer Science degree.

As a former H1-B holder, and current lawful permanent resident ("Green Card"), here long enough to become a citizen (> five years), H1-B DO NOT work cheaper.

At least, it is ILLEGAL to pay them less than 95% of the prevailing wage in the local area (as determined by the State Dept. of Labor). Furthermore, the employer has to bear the brunt of non-immigrant related legal paperwork and the cost of sending them home at the end of their visa. H1-Bs actually cost employers MORE than citizen workers.

While it is true that contracting firms and employers themselves will often lie regarding wages, this is criminal, and strongly opposed by legal H1-B workers as much as it is opposed by citizens.

Quoting another post to get past the damn filter.

Then once you figured that out you could learn about variables, figure out how to write to the screen RAM, and eventually figure out sprites. And then once you figured out that interpreted BASIC at 1 MHz wasn't fast enough to do a decent arcade game, you'd move on to assembly. I'd wager a majority of the people programming today learned in an environment like this. Edsger Dijkstra and other academic computer scientists hated BASIC, which they thought taught bad habits and caused brain damage, but they were wrong. It was this kind of hacker culture that created the flourishing IT industry we have today, not the dead-end bureaucracy represented by Thatcherite Britain.

How to make the lineprinter rip the paper:

              PROGRAM FOO(INPUT, OUTPUT)
10 PRINT 20
20 FORMAT(133H+---- .... ----)
              GOTO 10
              STOP
              END

Stupid formatting doesn't work, but you get the idea.

1979-1980. Punched cards. CDC 7600. If one was lucky one could get time on one of the Decwriters and work interactively. Getting paper before someone stole your seat was another story. Pair programming became popular for that reason.

Subway's Sriracha is adulterated with mayo. Not exactly great for the diet. Idiots: they have mayo. If people wanted both, they could ASK for both. But, no.....

Actually, we'd push the CA on the enterprise desktops to make the "experience" identical to it not being there. because the product was advertised as "transparent" to traffic, for some marketting-speak definition of "transparent".

The bottom line is "do that which makes customers complain the least".

If enough employees complained that this interception and certificate resigning was unacceptable, or not disclosed clearly enough, things might change. They don't.

For my part, I was satisfied that the decrypted traffic would not leave the appliance. Of course, someone could later change things so this was possible, but one can't object to useful, legitimate functions, because another might expend non-trivial effort to twist them to nefarious ends.

Hmm. I have BOTH Comcast residential and business class service. I wonder if the reponses are different.

Really? Adding untrusted sites always struck me as trivial.

We supported PKI integration simply to avoid the manpower lost in constantly trusting such sites, or having to manually import certs.

Furthermore, the mechanism is in the product to NOT decrypt and reencrypt selected sensitive whitelisted sites. The purchaser of the appliance has complete control.

It also does not work for some web applications which HAVE to be whitelisted because they do not permit import of new trust credentials.

Pfft.

Your whole privacy argument fails in the legal context because the unencrypted data does not leave the appliance.

Trust me, my employer and their lawyers went over these issues with great care, and I raised many of the concerns you pointed out. The issue hinges on two points:
1) enencrypted data does not leave the box (except whent the box actually does SSL termination), and 2) non-modified browsers (such as BYOD equipment) would pop up a Certificate validation error.

At that point it becomes an HR education issue.

Perhaps, but anything not belonging to third parties DOES belong to the deceased and should be bequethed as directed.

Now, getting a court order in a case like this should be trivial: the order is quite specific, the motion to the court to make the order simple, and the evidence clear.

No, people do not lose their individuality at work, but they should have a resonable understanding of their use of corporate resources, and most HR departments issue employee handbooks that spell this out, including any monitoring of computing or network resources that may take place.

As for being "tricked", only a fool would consider equipment not their own to respect their privacy wishes without engaging in some due diligence: either establishing a VPN to trusted equipment, or carefully examining the trust anchors the equipment they use has installed.

A better complaint might be to question the use of such equipment in public access networks, with forged CA certs. Proper practice would have a captive portal explaining policy, and using a clearly non-standard resigning CA that had to be explicitly accepted. But still, it is ultimately the user's responsibility to establish due diligence with regard to network security.

There is nothing inherently nefarious about resigning SSL traffic. In fact, in the public access scenario it helps thwart drive-by virus attacks and other malware through secure web sessions, at the expense of end user privacy. Do what us "in the know" do: set up a VPN to trusted servers.

In any case, the problem only arises when using equipment administered by others wirh prior installation of the trusted resigning CA cert: your own equipment, lacking the cert would CLEARLY indicate signing by an untrusted source. That strikes me as an appropriate balance: you have no expectation of privacy using someone else's computer!

Wrong: behind our corporate router, it's our network. The users are in our employ. That's the reasoning.

And the notice is in the trusted certs installed on the client PCs.

End to end security was in place AS FAR AS THE CORPORATE ORGANIZATION IS CONCERNED. Security from the standpoint of the employee is a different issue that the employee has to take up with the employer.

Do you really think your corporate network traffic is secure from your employer? It's easy enough for you to check, you know.

HTTP Proxy, SMTP Proxy "encrypted traffic" features. (There was also an HTTPS proxy, but all it did was drop connections to destinations on a blacklist by domain name as specified by the certificate the remote server provided: it did not decrypt, reencrypt, and resign).

It properly IS a proxy since it proxies the traffic for you. Whether you consider that a MITM attack on encrypted traffic depends on whether you trust the proxy or not.

SSL does not prevent MITM attacks: it just makes MITM mangling of encrypted traffic discoverable. IF the "man" is "your man" (or your employer's man) then it presumably is not an attack.

Realize the target audience of vendors of procducts like these: IT managers who want to "protect" against malicious traffic, whether encrypted or not. Of course we can only do that as a MITM. But they way they see it, all network connections "inside" are "theirs", so our box is "their" man in the middle. Often they are clueless and just ask salesmen "Does it work with HTTPS and SMTP/STARTTLS and SMTP/SSL?" without knowing what that means, only that encrypted traffic is "difficult" to scan.