theicfire
Joined 15 years ago
Joined 15 years ago
Users can check their own email/phone/etc to verify that the attacker has the data, without the attacker revealing the data.
I'm surprised this doesn't happen more.
* Pivoting towards enterprise. Not with speed in mind, but instead security/control/compliance.
We didn’t spend too much time here, so I can’t definitively say this wouldn’t have worked. Cloudflare had (has?) just this vision when they bought S2: https://blog.cloudflare.com/cloudflare-and-remote-browser-is.... There is at least one critical roadblock that I see: wifi and networks can be spotty. If only 80% of a company’s employees have good enough internet, what do you do as an administrator? Force them to figure out notoriously difficult wifi problems? If you don’t, those that don’t like the browser will simply not use it because they’re not required to. Given this, I always thought of this as a secondary market. First, make something great, independent of being required to use the product. Then start building out other tools that make businesses more enticed. We did sell to companies in multi-seat deals, and were eager to keep pushing in this direction. Note the tag line: “A new browser to work faster”.
* CAD/Rendering/Simulation/etc instead of a Browser
The trend is that all of these are moving to the browser. However, maybe not fast enough and Mighty was too early. It’s also a more crowded market (Citrix, Teradici, now Parsec, etc) and yet smaller than the browser market (well, by users at least).
* Powering browsers inside of mobile VR/AR
We never tried this. My sense is we’d be too early (at least 2+ years?).
* Accessibility, e.g. for screen readers
This was never a big enough priority but yeah, it seems solvable. It’s more or less another API to implement.
* Loading web pages faster is not going to make you more productive
As I see it, there are two buckets of speed. The first is to make fast things faster. The second is to make slow things faster. The two can work together. The real value prop is the second, but the first is where you can bring lots of delight. But I think there is some truth to this. Of the loyal paying users that we had, they felt substantially more productive. But could this benefit offset the price + downsides? Knowing what I know now, I don’t think so. But there’s a lot of context about what’s actually possible, what a wide spectrum of people value, etc that gets me to that conclusion.
* Who really, really, has a slow browser that’s willing to pay $35/month due to it?
This was my first thought when we starting working on a Browser. One thing I learned was to hold back my gut instinct and prove the answer, instead of guessing it. The empirical answer: thousands of people that we could find through minimal marketing (just Twitter, basically). Does that mean there are a million+ people out there that also have it? Maybe.. it’s hard to tell. But my personal hope was that this quantity generalized somewhat to the 2B users of Chrome so that we could at least make a profitable business. If we got there, we could move into areas where we were solving more problems.
So to directly answer the question: I’m pretty confident this market exists. But not if Mighty also has the downsides it did (doesn’t work well in cafes, a variety of bugs, etc.)
Here's a video from Intel chatting with the researchers: https://community.intel.com/t5/Blogs/Products-and-Solutions/...
The questions are incredibly weak from the interviewers. They first state that it's not practical because the attack could take many hours, even days. But they don't describe why a day-long attack is not practical.
They then bring the researchers and ask them the same question. The researchers say that the attack is very practical because it only takes.. a few hours or days to execute the attack. Here's the specific part: https://youtu.be/BiRPr839dSU?t=1476
Instead of chatting more about this discrepancy they just ignore it and ask the researches how they feel about their new popularity.
From what I can tell from the advisory from Intel, it's simply that people should understand the attack and mitigate it in software. It's very vague. The specifics (i.e. a list of example popular programs that are vulnerable) seem entirely missing.
Yes, that's double quotes at the end. Weird.
I'm not sure how common of a problem this is for people, but I figured I'd try to build something to see if my solution even made sense. It turns out it works quite well.
Have you heard of problems this could solve, or projects like this? Please let me know! I put some decent effort into documenting the tool, but tell me if it's unclear.
Thanks!