I can echo his experience reporting browser bugs and provide my own reviews:<p>Firefox - By far the best. Quick response, usually from engineers. If it's important the fix will be quick.<p>Edge - No reply for months / years. When I've gotten replies back it's been to ask me to try with the current version. When I do and the bug still exists it goes back at the bottom of the queue it seems.<p>Chrome - Somewhat of a mixed bag. Some times responses are quick, some times they are from engineers. But most often I get replies that convey the person I'm speaking too is a very green QA type. I've gotten replies that the test case I provided them doesn't reproduce the bug, because they had attempted loading it with the file:// protocol (of course hardly anything works with the file protocol). I'm not sure, do they expect me to include a web server for them?<p>Safari - Only tried a couple of times, never gotten a whisper back.<p>I would rate my experiences as:<p>Firefox - A+<p>Chrome - C<p>Edge - D<p>Safari - F
The Microsoft experience reminded me of the time when security@apple.com went to the building security office, who just quietly deleted bug reports. Poor processes amd communication is one of the worst classes of security problem.
It's quite incredible how the web managed to get along with such a janky sandbox model.<p>It's a very important thing that users trust their browser and won't hesitate a second to enter an unknown URL. They see "going to a webpage" as the equivalent to looking at a poster in the street, not eating candy provided by a random stranger.<p>Eroding this trust would ruin it for everyone, even well behaved static websites without javascript.<p>Maybe it's time to reconsider giving the same execution rights to gmail and unknown web pages ?
I, too, discovered a browser bug. Specifically with mutation observers in Safari (but not Chrome, or other WebKit-likes) in a particular DOM event scenario. Fully replicable. Not a word from any team at Apple, no acknowledgement of the bug, no acknowledgment of the issue.<p>The situation is a common one wrt SPAs, routing, and changing a tree based on history state. I'm sure other frameworks have run into it. My brief experience documenting the issue solidified the position that I will never do it again.
This is really nice research! Simple, effective, and brutal.<p>This reminds me of the research that went into finding issues in the media plugin models. Essentially, once the security community discovered that Java and Flash, etc, plugins didn't follow the same rules as the browser at all times - it became a free bug hunting exercise until the media plugin model just died.<p>I expect there are some "side channel" type ways to create high resolution timers in browsers which have removed built in support for them, for instance: WebAssembly? WebGL subroutines?<p>Anyway, congratulations.
This was such a nasty bug for Edge. Visiting any page means I could now read your private Messenger messages, or your email. You could even automate resetting the password to an account, and then automatically exfiltrating the URL!
I've found a couple of browser bugs in different browsers (but nothing security-related). Nothing I've reported to browser teams has ever been fixed, even with simple standalone test cases. It's definitely easier just to write a workaround and call it good.
This just happened to be two anecdotes with 2 browser dev teams that should not be generalized.<p>Everyone who has to deal with n-th layer tech support regularly (where n > 2) knows that even there it's hit or miss. Sometimes you file a bug report and get a "thanks, fixed!" an hour later. Sometimes you spend an hour to gather all the data upfront only to be painstakingly taken through the exact same data gathering process step by step. By email. Over days. On a "4h response" SLA (and they always just barely make it, not considering the value of the "response").<p>Randall Munroe has the best description: <a href="https://www.xkcd.com/806/" rel="nofollow">https://www.xkcd.com/806/</a>
I'm not familiar with the Web Audio APIs, was the Edge bug effectively interpreting the stream of bytes from the cross origin request as an 'audio stream', and then the OP just wrote a thing to convert it back so it could be converted into a string?
<p><pre><code> For example, the request may have the following header:
Range: bytes=50-100
…which is requesting bytes 50-100 (inclusive) of the resource.
</code></pre>
I haven't finished the article, but I've seen how this movie ends...