Hacker Newsnew | past | comments | ask | show | jobs | submit | svens_'s commentslogin

This assumption has unfortunately led to countless security issues, at least in the past. The nosniff header (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...), was created because of this and should be added.

While this probably works, you should also add a restrictive CSP (using the sandbox directive).

Forcing the download (via Content-Disposition header) would likely be even better, but it is annoying for users.


Replying to this comment because though it's vague in specifics it reads as authoritative and knowledgeable. In reality, it confuses/conflates multiple things.

Serving HTML source as text/plain is safe. No browser capable of understanding CSP is going to be at risk of anything that CSP would actually protect against in this case.


It's still available, just hidden in the search tools.


Yea, you have to click "Tools" to see the number of search results and the time it took for Google to retrieve information. Again, idk why they hid that.


Those counts have always been wildly inaccurate, to the point that engineers on the team were embarrassed to be displaying them, but product people felt it was important to the user experience anyway so kept it. Nice to see the engineers finally getting a win there.

(I worked on Google search like 15 years ago. I'm assuming they haven't found a way to make the estimate any more accurate, since it was seen as intractable at the time.)


when i search Google for "facebook", i get less than 100 webpages.

Google says it processed "About 25,270,000,000 results (0.28 seconds)"

why can't i see those 25 billion results? what are "results"?


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).


That would be a best case scenario and I doubt that's what's happening.

And instead of bringing those services back locally, nearshoring will probably be considered first.


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.


There are virustotal clones that don't send back results to the vendors. This is specifically done to prevent that kind of problem.


Same here, no problems anymore for more than two weeks now.


Thank you guys! ;) We will disable the client side authentication. If we encounter problems again I will comment.


I agree it's overpriced.

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.


Since the WiFi is the only source of emissions, you can avoid FCC certification by using a pre-certified module like an ESP8266 or ESP32 or one of the many offerings from TI.


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.


Don't worry, they thought about that:

Guests' privacy is always protected. Our patent pending technology ensures that no content is recorded

It's patented, so it must be good.

Sarcasm aside, I really wonder what's in that patent... I mean it must (should) exist, otherwise it should be "pending".


Given that variable bit-rate VoIP can reveal words spoken from bitrate alone[1], I would be very cautious about their claims.

[1] https://www.schneier.com/blog/archives/2008/06/eavesdropping...


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.


Depending on how wide is the peak detection window, they might send enough data to detect how long consecutive words are. I have a vague impression that I've read once that this, together with a language model, can be used to guess what's being spoken ~10% of the time or so.


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).


It was working for us for the most of the day, but now acting up not working again...


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: