Not sure what you're getting at, apart from the loss the same disadvantages also apply if the cable is superconducting.
Even worse, maintenance and running costs of superconducting cables are likely much higher due to the cooling (high temperature superconductors are "high temperature" in comparison to other superconductors - there's still lots of cooling needed).
Obviously they're fucked. Luckily we are still in the hardware design phase, otherwise we'd be even more pissed.
I don't think anyone built a product with enough volume that Intel would reconsider the discontinuation.
Long-term component availability is a major issue for hardware products. Discontinuing a product basically over-night is not a nice move from Intel and I hope people will remember this when Intel launches their next IoT/robotics product.
You cannot skip FCC certification, you can just go through the "simpler" unintentional radiator testing when using pre-certified modules. That's still around 1.5k USD.
Also you can't use custom firmware on a pre-certified module, otherwise you'll still have to do the intentional radiator testing. You control those modules with an external MCU, which is cheap though.
TIs WiFi offering is horribly expensive compared to any ESP8266 based modules, still like 13$ @ 1k units on DigiKey. That's the main reason the latter got so famous.
You need to sell a few hundreds just to get those fixed costs down to a reasonable amount per unit. And then you still have to pay the engineers... Maybe 80-100$ per unit would be more appropriate, but then again I doubt they sell in huge numbers.
However don't forget that when selling a product, lots of other costs arise. E.g. you'd need FCC certification (around 10k USD for intentional radiators) and make sure that no other standards are violated (mainly regarding mains voltage). The plastic case mold is another 3-5k. Then some margin for returns, marketing, etc.. It's a niche product, so the fixed costs make up a big part.
If it's popular someone will sell a simple DIY kit for 20$ and an open-source server. But I doubt there's much demand.
I doubt their "signal processing" involves anything more than a microphone and a peak detector.
A more practical side channel attack would probably be through radiated emissions over the mains power. However if you're willing to go that far, a laser microphone is much more effective and simpler.
Just checked again, we're still seeing issues. I can reproduce, simply by using my personal account in a private window, it randomly fails in at least one of our environments (e.g. prod, staging, localhost).
Ah yes, of course. I did miss that. The implicit (client-side) auth flow gets the access token directly and doesn't need another request to the API, that's the whole point.
This is indeed rather unwanted, even more so
with the new more restrictive API usage policy and the sandbox.
Sorry, but this is definitely not a hardware, connection or session issue. Just check the rest of the thread. We're seeing issues over various links (broadband, mobile, datacenter) on different server locations (AWS vs. on dev machine) with or without private mode / logging out and then in.
I honestly wish it was something like this, at least then we could fix it.
The double POST requests you see is most probably because api.instagram.com returns a 302 response ("Found", i.e. redirect). This is a relatively recent change, but still weeks before those issues started.
By the way, your server refuses connection when you go to https://picodash.com directly (without www.). You might want to fix this.
Private mode wasn't enough to fix the error for us.
At least not in all cases, i.e. we tried production, staging and an instance running on localhost. Private mode usually changed in which places the login worked, but it never helped for all three.
Pretty much our experience. We didn't figure out what caused it, the same Instagram account sometimes works and sometimes doesn't without a change in code on different instances.
Apparently it happens from time to time, there are some posts about this problem on StackOverflow. No answers though.
We tried many things, including resetting our secret. It's working now, but it's hard to tell whether our actions had any effect.
Android and Linux use 64 by default - the block could be circumvented by setting the laptop to use 65 TTL.