All of the videos I have seen of the summon feature have been pretty bad. A lot of time the vehicle can't seem to figure out what to do. I imagine that will get better with time, but if I had a Tesla I wouldn't be using it now.
> Obviously it is also a good fit for low scale use cases.
Is this a given? Just because something is necessary at scale doesn't mean it is a good fit for low scale use cases. I would expect the opposite is actually true.
I have long thought that there is an opening for local grocery stores to take a lot of this market. Many of my local supermarkets (HyVee, Walmart) allow for online ordering, but they all require the user to input items one-by-one. If they added a feature to add entire recipes in a single click, I think they would do very well for themselves. The additional cost of adding a recipe card would be negligible.
The customer's cost isn't increased over regular online ordering, and there isn't the issue of increased packaging. The food is fresh from the local supermarket and doesn't have to be shipped, beyond at most a local delivery.
Does the group of people who meal prep line up with those that don't want to think about meal prep? One of the benefits of these meal prep kits is that you end up with a freshly cooked meal. If you are going to be eating a prepared meal, why not just let the service send it fully ready to go?
Remember that many services are running in a cloud computing environment. Attackers can spin up machines right next to those that they are attacking and bypass much of the network related variables.
Timing attacks aren't as simple as often presented. Writers often give a set time for checking each character and ignore all other operations in order to make the issue easy to understand, but most people use this to write off the attack altogether. Surely it can't be that simple.
It isn't trivial to take advantage of timing attacks remotely, but researchers have shown that they are definitely exploitable. [1][2]
You can run into issues with headerless JWTs when you can't (or don't) guarantee the order of the header. Since the header is included in the signature of JWS objects, you must reattach a header that is exactly the same, and not just equivalent.
For example, both of these decoded headers are equivalent:
{
"alg": "HS256",
"typ": "JWT"
}
{
"typ": "JWT",
"alg": "HS256"
}
Obviously, these encode to two different values. If you reattach the wrong one, signature verification will fail.
Disclaimer: I maintain a Python JOSE library and have had to answer questions related to this on more than one occasion.
It's a good thing everyone's actions take place in a bubble and have no effect on others.