USB's been the connector of choice for most of my peripherals. It replaced the floppy drive connector for portable media. It replaced dedicated connectors for keyboards, mice, tablets and the like. My headsets are almost always USB, whether they're wired or wireless. Webcams. The only things I don't use it for are primary networking (hardwired Ethernet there), non-portable mass storage (hard drives and optical drives), and video. Sometimes I still use the PS/2 keyboard connector for non-Windows UEFI systems where a USB keyboard won't get initialized during POST. It's fast enough, there's typically more than enough connectors (especially with a hub for non-latency-sensitive devices), and it's almost universally present and usable.
The EMV chips have been compromised for years. Typically it only takes a couple of weeks to break the latest version. The reason chip-and-PIN sounds so good is the European rules changes that accompanied it: if the transaction was done using chip-and-PIN then it's presumed valid and it's up to the cardholder to prove otherwise which is extremely difficult short of having absolute undeniable proof that you were physically at a different location at the time of the transaction (eg. timestamped video showing you at that other location at that time). So if the EMV chip in your card is compromised and cloned, the fraudulent transactions run up on the fake card are presumed not fraudulent and attempts to dispute them as fraudulent will be denied absent you having extraordinary proof. That skews the fraud statistics considerably.
The reason European cardholders don't raise a fuss about this is that 95+% of card fraud these days is done online using card-not-present transactions where chip-and-PIN isn't a factor. That won't change whether the US adopts chipped cards or not.
This isn't exactly an amazing product. The way Amex generates replacement card numbers is utterly trivial, the hardest part of it's calculating the new check digit. There's really no excuse for that kind of triviality, a replacement card should have a complete new number unrelated to the old one.
Having been on the permanent-staff team dealing with contract workers, I can't see permanent staff ever being replaced by "gig" developers. A lot of things depend on having not just skill in programming but familiarity with the business and prior decisions about the system's design and architecture. You can hire short-term people for specific tasks, but you need people who've been there long-term to work out how to fit new requirements into the system as it exists. Then there's maintenance. Bugs that make it into production tend to be obscure and hard to trace, and someone new who isn't intimately familiar with how things fit together's going to be completely lost trying to troubleshoot a bug that's not in any component but in the interaction between 3 different components (or worse, a bug caused by all 3 components being absolutely correct and bug-free but that particular account's so old it has a combination of settings on it that isn't currently legal and that the documentation doesn't mention).
The permanent staff won't be the cheapest in absolute terms, but they'll be the cheapest in terms of dollars spent for results produced. This isn't a guess, it's a prediction based on the outcome of the vast majority of attempts to replace permanent development teams with contract workers and consulting firms.
G+ has always had little of the Facebook-style indiscriminate "let the world see everything" of most social media, users have focused more on specific groups or communities with the conversations going on within that group and not in public view. The changes seem to make sense in focusing in on that rather than trying to be another Facebook or Twitter or SnapChat. It makes the pundits feel left out because they're outside those groups and not seeing the interactions, but that's easy enough to solve if they want to. If they don't... Not My Problem, Man.
Why would any sane terrorist use any sort of service run by someone else? That just makes them vulnerable. Any sort of PC, install Linux and set up their own private XMPP server, instant fully-encrypted communications without leaving any logs or other traces on anyone else's systems where the authorities could get access to them. And with the authorities' current focus on social media it adds the additional layer of security of not being where anyone's looking for them to be. Geesh, I think government officials have been reading too many best-seller spy novels and listening to too few tech geeks.
IMO it's: s/US Government//
I haven't seen an outsourcing project yet that's been well-managed. Usually it's because management sees the development teams as interchangeable, so they go about managing the outsourced project like they would've their in-house devs. Problem is that your in-house devs you can call into the office and threaten with loss of bonuses and/or job if they aren't getting things done right. You can't do that with the contractors though since they don't work for you and likely aren't even on the same continent and the contract with the outsourcing firm's usually written without any provision for penalties for failure to deliver a product that works correctly and to spec, leaving you with no leverage.
The problem is that management's been taught to look at efficiency over effectiveness. The two aren't the same thing.
Yes, but if you're dealing with a situation where they'll hold and interrogate you for an extended period even if they find absolutely no evidence at all then you have bigger problems than how to keep them from finding anything. In that situation the only way to avoid this is to not go there in the first place and if you have to go there the question's more along the lines of how do you get in and out without them finding out you're you along the way. And that frankly is seriously out-of-scope for this kind of forum.
Best bet is simply not to have anything for them to find. Store your data on a thumb drive (that you'll carry or ship separately) or upload it to your own server or a service like Google Drive or Dropbox, encrypting it or not first, all depending on how sensitive the information is. Delete it or secure-wipe it or wipe the whole drive and do a complete factory restore on your laptop depending on how invasive you think the search might be. Then let the cops search all they want, they won't find what isn't there.
NB: Linux makes a better platform for this than Windows. On Windows bits of your files can end up in the oddest places to be found during a scan of the drive. On Linux it's easy to set up a separate partition where all your data will go and be certain it didn't leave traces anywhere else, and that partition can be secure-wiped and reformatted without messing up the OS installation in the process. Plus the cops are less likely to be familiar with Linux, and you can play the dumb-non-techie card of "I dunno, it's whatever the guys in IT put on it. I just follow the instructions to run my programs and everything works.".
Yep, and I agree with.local,.test and bare names and stuff like localhost not being allowed for commercial CAs. If I used them locally it'd be with my own internal CA for certificates (I have one set up, but that hodge-podge of shell scripts would make you cry).
@sigh Dammit, "The Marching Morons" was supposed to be a satire, not a bloody policy document.
As someone who's written that code, the problem doesn't lie in the timezone code. It lies in the Posix definition of the time() function, requiring it to return GMT/UTC which has leap seconds in it. Programmers too often treat that as if it were TAI which does not include leap seconds, and bugs pop up when leap seconds make UTC jump relative to TAI. If time() returned TAI directly and the timezone code handled leap seconds everything would be a lot better. I find it amusing that that change wouldn't break much Unix code and would in fact probably fix a lot of subtle bugs by bringing time()'s results into alignment with the assumptions of the code using it. And NTP wouldn't be a problem, conversion from NTP's time back to TAI isn't that difficult. But no, we still have to deal with UTC.
True, but at the time that RFC didn't exist. And a lot of software had a hard-coded rule about TLDs: ccTLDs were 2 characters, the generic TLDs were 3 characters and only a few were valid. Trying to use a TLD with more than 3 characters would make some software reject it as invalid, but it was easy to pick a 3-character TLD that was guaranteed not to exist in the global DNS.
Thankfully we've moved past that stage. Though I would like to see a special-use domain "local" defined for names that aren't for testing but are restricted to the organization's network.
I'd wonder why they needed test certificates at all? For any testing of their systems and software they could use fake domains and organizations located under a domain they own and use just for that purpose (I used the.ttk TLD for that sort of thing for years, back before the gTLD flood). If they were testing issuing of certificates to specific organizations, there wouldn't be any need for them to ever get to servers. I can think of no good reason Symantec would need to have certificates issued to Google, and several bad reasons why an antivirus product would want a certificate that'd be accepted as a genuine certificate for a Web site.
No. It means every CA has to have a log of every EV certificate it's issued, and Chrome is checking any purported-EV certificate it sees against the issuing CA's list. If the certificate really is a valid EV certificate, it'll be in the list. I presume that if the certificate isn't a valid EV certificate (ie. it's not found in the list) and you've got the "Automatically report details of possible security incidents to Google" setting turned on (the default) it sends the error report back to Google for analysis. All of that's perfectly reasonable, and Google only sees information about certificates that're lying about their EV status.
I hope they've taken SIM cloning into account. Myself, I prefer TOTP authentication using software like Google Authenticator or a hardware dongle (downside: finding hardware that supports multiple accounts on multiple services).
It won't stop uploading. Tools like wput and Curl don't read the contents of files before uploading, and wouldn't be modified to support one closed-source feature for one specific file format.
It won't affect Web sites. Web servers don't read the contents of files before serving them, files are just blobs of bytes to the server. The sites of interest to the DRM people are running open-source Web server software too, and I seriously doubt Apache or nginx are going to add closed-source code for one specific file format. IIS would, but it's at best the third-place player in the large-volume-site space.
And finally, it'll be cracked. My bet is that before it becomes widely implemented someone'll crack the system and there'll be browser extensions easily available that simply strip the DRM off the JPEG before uploading, displaying or saving it. Those extensions'll be widely used too, it won't be long before anyone having problems viewing images on Pinterest/Tumblr/Twitter/etc. will just get told to install the extension and it'll fix the problem. Users won't know or care how it fixed it, just that it fixes it.
I'd go with Subversion. It's older and has a centralized repository rather than Git's distributed-repositories approach, but that won't be a problem for your team since they aren't spread out across multiple locations. It's got better support for running on Windows (CollabNet sells a supported commercial Windows-based server plus the whole TeamForge line), has Windows clients (both integrated into Explorer and stand-alone) and has supported integration with Visual Studio. Older means that almost every development tool out there for Windows understands how to interact with it. It's also easier for people who aren't familiar with version control to grasp SVN's model and how you interact with it (a commit is a commit, they don't have to understand the differences between their local copy of the repository and the origin copy on the Git server). Finally, SVN offers a degree of centralized control that makes management happy (eg. mandating commit comments in a certain form, controlling individual access to different parts of the directory tree).
The kind of document Gartner's talking about isn't the kind that's written, it's the kind that's transcribed from facts with some formatting applied. As the article says, it's sports scores and budget reports and such. It's the kind of stuff I call "boilerplate" and write scripts to handle, eg. to take a small input file with the information defining a C++ class ("This is the class name, these are the data members and their types.") and spit out a properly-formatted C++ class definition complete with all the constructors, assignment operator and standard methods needed (which is oftentimes 2 orders of magnitude bigger than the input file). Actual creative writing, the kind that requires coming up with the information to put into the document, is in no danger of being replaced any time soon.
At that point I'd actively avoid a pat on the back from him, I couldn't be sure if it were holding a knife or not. As for the pay raise, yes it did. The only problem he had was that the offer from his company to try and convince me to change my mind about my resignation letter was only about half the raise I'd been offered elsewhere. Not that it mattered at that point, there isn't a raise big enough to keep me at a company where that kind of behavior's acceptable in a senior executive.
It was also amusing on my last day watching HR's reactions as I forced them to go through the process of deactivating and securing all of my accounts and access so that I provably wouldn't have access to anything of theirs after that point. They didn't think that was necessary. I... disagreed.:)
If a manager gives me a verbal instruction and won't put it in writing/email, I simply follow up with an email to him saying "Here's what I understood you to be verbally instructing me to do at such-and-such a date and time. Please confirm whether my understanding is correct, and please clarify any points where it's incorrect. Thank you.". The boss trying to avoid a paper trail is a big red flag to me saying that I'm going to need that paper trail at some point.
Had the CTO claim he ordered one thing when he actually ordered exactly the opposite. He was counting on the "document retention" system to have long since deleted any emails documenting his original order. Pity that, as a properly paranoid software engineer, I had archive folders with retention settings of "retain forever" with copies of all relevant emails for any project I worked on (so I wouldn't lose the context of technical decisions or relevant requirement/spec changes) and could produce copies of his own emails with his actual instructions in them.
I hope the VW engineers had the foresight to do something similar, because this smells to me of management looking to find a scapegoat so they don't have to face the consequences of their decisions.
No, in point #2 I'm not talking about placeholders. I'm talking about eg. using an image for a header so you can put the site's name in it's brand-specific font as opposed to simple setting the background color and using text for the name. Or using images to create a separator between headline and content so you can have one that looks exactly like what you use on your TV shows or in print.
As for the third point, it only breaks things if you set the size to something other than the image size (which your server ought to know since it's the one sending the image). And if you're doing dynamic resizing to fit screens, you're probably one of the people I hate when I start scrolling to see the text on your website and suddenly everything jumps around as your page finishes loading and your JS starts resizing images causing reflows and rerendering of the page. It's not so obvious on a desktop system because things tend to load fast, but on mobile devices it makes people tear their hair out. Which is why I said to test your site on a machine with a deliberately-choked-off network connection: to see how it'll render as it loads through a relatively slow, heavily congested link. I suspect a lot of designers test mobile sites on either emulators or using devices connected through fast WiFi links to fast local servers and never test what happens when it takes 30+ seconds to get all the content through the pipe.
This'll be great for individuals, but companies won't accept it. The first problem is that ad networks won't accept the limitation, so any site that shows advertising will have to eschew AMP. The second problem is that companies use Javascript frameworks so heavily in their Web design that they won't be able to just drop it and go back to static HTML/CSS for their sites. If they were willing to, after all, Google wouldn't've seen such a need AMP in the first place.
I think the same results can be achieved by three things:>
1. Strip advertising down. Ads are the biggest things I find slowing mobile Web pages down as the ads do so many things to keep content from being accessed until the ad's been seen and dealt with and fetch so much stuff from so many remote servers. Minimize the number of ads and make them as simple as possible.
2. Stop using images for layout and convert to using CSS instead. Yes you lose the ability to do fancy brand-specific artwork on headers and separators and such, but you know what? Most users don't care about those things.
3. Stop using dynamic layouts that load the entire page and then make changes to it that alter it to it's final layout. Just lay things straight out so the browser can render stuff as it's loaded. Specify sizes for images, drop the "Tap to read the rest" buttons that hide the bulk of the content (but still require it to be loaded before the page can render), that sort of stuff.
Easy way to do this: one of your test machines runs Windows XP on hardware with a 500MHz CPU, 256MB of RAM, an unaccelerated graphics card with 2MB of video memory and a 56K modem (or 115200bps serial link) for network connectivity. If your site performs decently on that, it'll be good on any mobile device.
I'd like it if, rather than the merchant charging me and the bank having to figure out if it's legitimate or fraudulent, I send a message to my bank/card-issuer saying "Pay this merchant this much, here's their reference number and here's my TOTP authenticator code.". That should reduce the problem dramatically, and turn the physical card and/or knowledge of the account number into a last-ditch resort when I can't get a data connection, can't get a text message out, can't get a voice call out or don't have my phone with me and the store doesn't have a phone line I can use.
Slashdot Mirror
USB's been the connector of choice for most of my peripherals. It replaced the floppy drive connector for portable media. It replaced dedicated connectors for keyboards, mice, tablets and the like. My headsets are almost always USB, whether they're wired or wireless. Webcams. The only things I don't use it for are primary networking (hardwired Ethernet there), non-portable mass storage (hard drives and optical drives), and video. Sometimes I still use the PS/2 keyboard connector for non-Windows UEFI systems where a USB keyboard won't get initialized during POST. It's fast enough, there's typically more than enough connectors (especially with a hub for non-latency-sensitive devices), and it's almost universally present and usable.
The EMV chips have been compromised for years. Typically it only takes a couple of weeks to break the latest version. The reason chip-and-PIN sounds so good is the European rules changes that accompanied it: if the transaction was done using chip-and-PIN then it's presumed valid and it's up to the cardholder to prove otherwise which is extremely difficult short of having absolute undeniable proof that you were physically at a different location at the time of the transaction (eg. timestamped video showing you at that other location at that time). So if the EMV chip in your card is compromised and cloned, the fraudulent transactions run up on the fake card are presumed not fraudulent and attempts to dispute them as fraudulent will be denied absent you having extraordinary proof. That skews the fraud statistics considerably.
The reason European cardholders don't raise a fuss about this is that 95+% of card fraud these days is done online using card-not-present transactions where chip-and-PIN isn't a factor. That won't change whether the US adopts chipped cards or not.
This isn't exactly an amazing product. The way Amex generates replacement card numbers is utterly trivial, the hardest part of it's calculating the new check digit. There's really no excuse for that kind of triviality, a replacement card should have a complete new number unrelated to the old one.
Having been on the permanent-staff team dealing with contract workers, I can't see permanent staff ever being replaced by "gig" developers. A lot of things depend on having not just skill in programming but familiarity with the business and prior decisions about the system's design and architecture. You can hire short-term people for specific tasks, but you need people who've been there long-term to work out how to fit new requirements into the system as it exists. Then there's maintenance. Bugs that make it into production tend to be obscure and hard to trace, and someone new who isn't intimately familiar with how things fit together's going to be completely lost trying to troubleshoot a bug that's not in any component but in the interaction between 3 different components (or worse, a bug caused by all 3 components being absolutely correct and bug-free but that particular account's so old it has a combination of settings on it that isn't currently legal and that the documentation doesn't mention).
The permanent staff won't be the cheapest in absolute terms, but they'll be the cheapest in terms of dollars spent for results produced. This isn't a guess, it's a prediction based on the outcome of the vast majority of attempts to replace permanent development teams with contract workers and consulting firms.
G+ has always had little of the Facebook-style indiscriminate "let the world see everything" of most social media, users have focused more on specific groups or communities with the conversations going on within that group and not in public view. The changes seem to make sense in focusing in on that rather than trying to be another Facebook or Twitter or SnapChat. It makes the pundits feel left out because they're outside those groups and not seeing the interactions, but that's easy enough to solve if they want to. If they don't... Not My Problem, Man.
Why would any sane terrorist use any sort of service run by someone else? That just makes them vulnerable. Any sort of PC, install Linux and set up their own private XMPP server, instant fully-encrypted communications without leaving any logs or other traces on anyone else's systems where the authorities could get access to them. And with the authorities' current focus on social media it adds the additional layer of security of not being where anyone's looking for them to be. Geesh, I think government officials have been reading too many best-seller spy novels and listening to too few tech geeks.
IMO it's: //
s/US Government
I haven't seen an outsourcing project yet that's been well-managed. Usually it's because management sees the development teams as interchangeable, so they go about managing the outsourced project like they would've their in-house devs. Problem is that your in-house devs you can call into the office and threaten with loss of bonuses and/or job if they aren't getting things done right. You can't do that with the contractors though since they don't work for you and likely aren't even on the same continent and the contract with the outsourcing firm's usually written without any provision for penalties for failure to deliver a product that works correctly and to spec, leaving you with no leverage.
The problem is that management's been taught to look at efficiency over effectiveness. The two aren't the same thing.
Yes, but if you're dealing with a situation where they'll hold and interrogate you for an extended period even if they find absolutely no evidence at all then you have bigger problems than how to keep them from finding anything. In that situation the only way to avoid this is to not go there in the first place and if you have to go there the question's more along the lines of how do you get in and out without them finding out you're you along the way. And that frankly is seriously out-of-scope for this kind of forum.
Best bet is simply not to have anything for them to find. Store your data on a thumb drive (that you'll carry or ship separately) or upload it to your own server or a service like Google Drive or Dropbox, encrypting it or not first, all depending on how sensitive the information is. Delete it or secure-wipe it or wipe the whole drive and do a complete factory restore on your laptop depending on how invasive you think the search might be. Then let the cops search all they want, they won't find what isn't there.
NB: Linux makes a better platform for this than Windows. On Windows bits of your files can end up in the oddest places to be found during a scan of the drive. On Linux it's easy to set up a separate partition where all your data will go and be certain it didn't leave traces anywhere else, and that partition can be secure-wiped and reformatted without messing up the OS installation in the process. Plus the cops are less likely to be familiar with Linux, and you can play the dumb-non-techie card of "I dunno, it's whatever the guys in IT put on it. I just follow the instructions to run my programs and everything works.".
Yep, and I agree with .local, .test and bare names and stuff like localhost not being allowed for commercial CAs. If I used them locally it'd be with my own internal CA for certificates (I have one set up, but that hodge-podge of shell scripts would make you cry).
@sigh Dammit, "The Marching Morons" was supposed to be a satire, not a bloody policy document.
As someone who's written that code, the problem doesn't lie in the timezone code. It lies in the Posix definition of the time() function, requiring it to return GMT/UTC which has leap seconds in it. Programmers too often treat that as if it were TAI which does not include leap seconds, and bugs pop up when leap seconds make UTC jump relative to TAI. If time() returned TAI directly and the timezone code handled leap seconds everything would be a lot better. I find it amusing that that change wouldn't break much Unix code and would in fact probably fix a lot of subtle bugs by bringing time()'s results into alignment with the assumptions of the code using it. And NTP wouldn't be a problem, conversion from NTP's time back to TAI isn't that difficult. But no, we still have to deal with UTC.
True, but at the time that RFC didn't exist. And a lot of software had a hard-coded rule about TLDs: ccTLDs were 2 characters, the generic TLDs were 3 characters and only a few were valid. Trying to use a TLD with more than 3 characters would make some software reject it as invalid, but it was easy to pick a 3-character TLD that was guaranteed not to exist in the global DNS.
Thankfully we've moved past that stage. Though I would like to see a special-use domain "local" defined for names that aren't for testing but are restricted to the organization's network.
I'd wonder why they needed test certificates at all? For any testing of their systems and software they could use fake domains and organizations located under a domain they own and use just for that purpose (I used the .ttk TLD for that sort of thing for years, back before the gTLD flood). If they were testing issuing of certificates to specific organizations, there wouldn't be any need for them to ever get to servers. I can think of no good reason Symantec would need to have certificates issued to Google, and several bad reasons why an antivirus product would want a certificate that'd be accepted as a genuine certificate for a Web site.
No. It means every CA has to have a log of every EV certificate it's issued, and Chrome is checking any purported-EV certificate it sees against the issuing CA's list. If the certificate really is a valid EV certificate, it'll be in the list. I presume that if the certificate isn't a valid EV certificate (ie. it's not found in the list) and you've got the "Automatically report details of possible security incidents to Google" setting turned on (the default) it sends the error report back to Google for analysis. All of that's perfectly reasonable, and Google only sees information about certificates that're lying about their EV status.
I hope they've taken SIM cloning into account. Myself, I prefer TOTP authentication using software like Google Authenticator or a hardware dongle (downside: finding hardware that supports multiple accounts on multiple services).
Then point 3 applies, one browser extension to automatically strip the DRM off and it's done.
It won't stop uploading. Tools like wput and Curl don't read the contents of files before uploading, and wouldn't be modified to support one closed-source feature for one specific file format.
It won't affect Web sites. Web servers don't read the contents of files before serving them, files are just blobs of bytes to the server. The sites of interest to the DRM people are running open-source Web server software too, and I seriously doubt Apache or nginx are going to add closed-source code for one specific file format. IIS would, but it's at best the third-place player in the large-volume-site space.
And finally, it'll be cracked. My bet is that before it becomes widely implemented someone'll crack the system and there'll be browser extensions easily available that simply strip the DRM off the JPEG before uploading, displaying or saving it. Those extensions'll be widely used too, it won't be long before anyone having problems viewing images on Pinterest/Tumblr/Twitter/etc. will just get told to install the extension and it'll fix the problem. Users won't know or care how it fixed it, just that it fixes it.
I'd go with Subversion. It's older and has a centralized repository rather than Git's distributed-repositories approach, but that won't be a problem for your team since they aren't spread out across multiple locations. It's got better support for running on Windows (CollabNet sells a supported commercial Windows-based server plus the whole TeamForge line), has Windows clients (both integrated into Explorer and stand-alone) and has supported integration with Visual Studio. Older means that almost every development tool out there for Windows understands how to interact with it. It's also easier for people who aren't familiar with version control to grasp SVN's model and how you interact with it (a commit is a commit, they don't have to understand the differences between their local copy of the repository and the origin copy on the Git server). Finally, SVN offers a degree of centralized control that makes management happy (eg. mandating commit comments in a certain form, controlling individual access to different parts of the directory tree).
The kind of document Gartner's talking about isn't the kind that's written, it's the kind that's transcribed from facts with some formatting applied. As the article says, it's sports scores and budget reports and such. It's the kind of stuff I call "boilerplate" and write scripts to handle, eg. to take a small input file with the information defining a C++ class ("This is the class name, these are the data members and their types.") and spit out a properly-formatted C++ class definition complete with all the constructors, assignment operator and standard methods needed (which is oftentimes 2 orders of magnitude bigger than the input file). Actual creative writing, the kind that requires coming up with the information to put into the document, is in no danger of being replaced any time soon.
At that point I'd actively avoid a pat on the back from him, I couldn't be sure if it were holding a knife or not. As for the pay raise, yes it did. The only problem he had was that the offer from his company to try and convince me to change my mind about my resignation letter was only about half the raise I'd been offered elsewhere. Not that it mattered at that point, there isn't a raise big enough to keep me at a company where that kind of behavior's acceptable in a senior executive.
It was also amusing on my last day watching HR's reactions as I forced them to go through the process of deactivating and securing all of my accounts and access so that I provably wouldn't have access to anything of theirs after that point. They didn't think that was necessary. I... disagreed. :)
If a manager gives me a verbal instruction and won't put it in writing/email, I simply follow up with an email to him saying "Here's what I understood you to be verbally instructing me to do at such-and-such a date and time. Please confirm whether my understanding is correct, and please clarify any points where it's incorrect. Thank you.". The boss trying to avoid a paper trail is a big red flag to me saying that I'm going to need that paper trail at some point.
Had the CTO claim he ordered one thing when he actually ordered exactly the opposite. He was counting on the "document retention" system to have long since deleted any emails documenting his original order. Pity that, as a properly paranoid software engineer, I had archive folders with retention settings of "retain forever" with copies of all relevant emails for any project I worked on (so I wouldn't lose the context of technical decisions or relevant requirement/spec changes) and could produce copies of his own emails with his actual instructions in them.
I hope the VW engineers had the foresight to do something similar, because this smells to me of management looking to find a scapegoat so they don't have to face the consequences of their decisions.
No, in point #2 I'm not talking about placeholders. I'm talking about eg. using an image for a header so you can put the site's name in it's brand-specific font as opposed to simple setting the background color and using text for the name. Or using images to create a separator between headline and content so you can have one that looks exactly like what you use on your TV shows or in print.
As for the third point, it only breaks things if you set the size to something other than the image size (which your server ought to know since it's the one sending the image). And if you're doing dynamic resizing to fit screens, you're probably one of the people I hate when I start scrolling to see the text on your website and suddenly everything jumps around as your page finishes loading and your JS starts resizing images causing reflows and rerendering of the page. It's not so obvious on a desktop system because things tend to load fast, but on mobile devices it makes people tear their hair out. Which is why I said to test your site on a machine with a deliberately-choked-off network connection: to see how it'll render as it loads through a relatively slow, heavily congested link. I suspect a lot of designers test mobile sites on either emulators or using devices connected through fast WiFi links to fast local servers and never test what happens when it takes 30+ seconds to get all the content through the pipe.
This'll be great for individuals, but companies won't accept it. The first problem is that ad networks won't accept the limitation, so any site that shows advertising will have to eschew AMP. The second problem is that companies use Javascript frameworks so heavily in their Web design that they won't be able to just drop it and go back to static HTML/CSS for their sites. If they were willing to, after all, Google wouldn't've seen such a need AMP in the first place.
I think the same results can be achieved by three things:>
1. Strip advertising down. Ads are the biggest things I find slowing mobile Web pages down as the ads do so many things to keep content from being accessed until the ad's been seen and dealt with and fetch so much stuff from so many remote servers. Minimize the number of ads and make them as simple as possible.
2. Stop using images for layout and convert to using CSS instead. Yes you lose the ability to do fancy brand-specific artwork on headers and separators and such, but you know what? Most users don't care about those things.
3. Stop using dynamic layouts that load the entire page and then make changes to it that alter it to it's final layout. Just lay things straight out so the browser can render stuff as it's loaded. Specify sizes for images, drop the "Tap to read the rest" buttons that hide the bulk of the content (but still require it to be loaded before the page can render), that sort of stuff.
Easy way to do this: one of your test machines runs Windows XP on hardware with a 500MHz CPU, 256MB of RAM, an unaccelerated graphics card with 2MB of video memory and a 56K modem (or 115200bps serial link) for network connectivity. If your site performs decently on that, it'll be good on any mobile device.
I'd like it if, rather than the merchant charging me and the bank having to figure out if it's legitimate or fraudulent, I send a message to my bank/card-issuer saying "Pay this merchant this much, here's their reference number and here's my TOTP authenticator code.". That should reduce the problem dramatically, and turn the physical card and/or knowledge of the account number into a last-ditch resort when I can't get a data connection, can't get a text message out, can't get a voice call out or don't have my phone with me and the store doesn't have a phone line I can use.