
I discovered a browser bug - cgtyoder
https://jakearchibald.com/2018/i-discovered-a-browser-bug/
======
MatthewPhillips
I can echo his experience reporting browser bugs and provide my own reviews:

Firefox - By far the best. Quick response, usually from engineers. If it's
important the fix will be quick.

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.

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?

Safari - Only tried a couple of times, never gotten a whisper back.

I would rate my experiences as:

Firefox - A+

Chrome - C

Edge - D

Safari - F

~~~
jaffathecake
Yeah that Chrome experience doesn't sound great. Fwiw I tend to put my test
cases on jsbin or Glitch, but yeah, a Chrome engineer should know to put the
page on a basic web server.

If anyone runs into problems like this, feel free to bug one of the Chrome dev
rel folks, such as me.

~~~
reitanqild
> If anyone runs into problems like this, feel free to bug one of the Chrome
> dev rel folks, such as me.

Hi, and thanks for being part of creating Chrome && reaching out here.

Now that I have a Chrome guy here maybe you can help with another annoying
issues:

-QC internally at Google seems to be blissfully unaware of the fact that other browsers exists.

Examples:

\- one glaring issue I'm running into in core Angular on a daily basis.

\- Google Calendar performance is sometimes unreasonably slow in Firefox

\- For weeks or months Google search results would drive once CPU core to 100%
twice a minute.

~~~
notatoad
none of those are something a chrome dev rel person can help you with.

People like you are the reason we have to deal with three layers of low-level
tech support before we can actually talk to somebody who knows what they're
doing - please don't just spray your random complaints at anybody who happens
to be related to google in any way.

~~~
gsnedders
And it's not like the Chrome dev rel team doesn't fight for these things, but
ultimately the Chrome team doesn't have any control of prioritisation of bugs
in other products (like Calendar).

The only way we're going to see a significant change is when those high up in
the Google org chart start caring about products working well in other
browsers; as long as it's up to each individual product we'll continue to see
products prioritising time-to-market and targeting only the browser with the
majority of the market.

~~~
reitanqild
That's the second reason to post it here: because if you see one googler there
are hundreds nearby, and some of them might be at the relevant team.

(And if I point out often enough what happened last time a mega corp abused
their position to market their browser then maybe some of them starts talking
about it internally?)

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

~~~
chrisfinazzo
product-security@apple.com is the real one these days.

Of course, this gets me thinking, what kind of super powers do these addresses
have that allows people to send potentially malicious things there to be
disassembled and analyzed? I suspect they are quarantined in some way, but it
would be interesting to hear from the ops sec crowd how this gets handled.

~~~
acdha
Yes – I even got a nice email from someone apologizing about that and
explaining that they were trying to get the security@apple.com people to at
least forward messages when I did a full disclosure release after not
receiving a response.

~~~
philipodonnell
> they were trying to get the security@apple.com people to at least forward
> messages when I did a full disclosure release after not receiving a response

That sounds a bit dysfunctional on Apple's part that they can't exert that
kind of control over their own employees for an issue with potentially
enormously negative consequences.

~~~
reaperducer
_That sounds a bit dysfunctional on Apple 's part that they can't exert that
kind of control over their own employees for an issue with potentially
enormously negative consequences._

I'm not saying it isn't dysfunctional, but it sounds like every single large
company I've ever worked with or for.

Especially when "security" is provided by a third-party security company.

------
obl
It's quite incredible how the web managed to get along with such a janky
sandbox model.

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.

Eroding this trust would ruin it for everyone, even well behaved static
websites without javascript.

Maybe it's time to reconsider giving the same execution rights to gmail and
unknown web pages ?

~~~
WorkLifeBalance
Do you want to reinforce established monopolies? Because I can't think of a
better way of doing that than having a technical difference between "trusted"
and "untrusted" sites.

~~~
obl
Well, I personally would be fine with the fair policy of disabling js
everywhere but I'm sure most would not agree, so what's the alternative ?

If anything, Spectre class attacks really showed how hard it is to properly
sandbox arbitrary programs.

Yes, the CPUs are complex, but the attacks happen on a high conceptual level,
level at which the CPU is fairly simple. It's not like they rely on an obscure
detail or bug.

No one (publicly) figured those out for 2 decades when the involved ideas
(speculation, cache timings) are well known, common and did not change.

This indicates that for something with such a large surface as the various web
standards, where both the spec and the implementations are changing all the
time, there is very little hope.

~~~
etatoby
I now use Brave browser exclusively, with JavaScript and other things turned
off by default.

Turning it on for trusted websites is one click away, once per domain, and it
could save me in the future.

------
Promarged
> Oh, I guess the vulnerability needs an extremely tenuous name and logo
> right? Here goes

I admire the extra touch here :)

~~~
kawsper
I enjoyed the WhatsApp-looking box that explained the server/client
conversation.

~~~
_trampeltier
The PDF was great too ;-)

~~~
forgot-my-pw
lol no

~~~
jjcm
For people downvoting forgot-my-pw, "lol no" was the complete content of the
pdf.

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

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.

------
notveryrational
This is really nice research! Simple, effective, and brutal.

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.

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?

Anyway, congratulations.

------
dannyw
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!

~~~
Avamander
superlogout.com v2.0

------
ariehkovler
That's a really well-explained and clearly presented writeup of the bug and
how it can be exploited as a vulnerability.

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

------
zegl
Microsoft claims to be developer friendly these days, but they are clearly not
white-hat friendly.

~~~
evfanknitram
My entirely anecdotal experience is that they are white-hat friendly some
time. My last experience was super good.

~~~
zamalek
I think it depends on the team.

------
amelius
Another symptom of browser specs getting too complicated.

~~~
jaffathecake
In this case it was a symptom of them being too simple. The use of range
requests wasn't specified.

------
jlg23
This just happened to be two anecdotes with 2 browser dev teams that should
not be generalized.

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

Randall Munroe has the best description:
[https://www.xkcd.com/806/](https://www.xkcd.com/806/)

------
djhworld
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?

~~~
masklinn
A stream of bytes is valid PCM (that's the point). The issue is that Edge
would first allow a redirect to a cross-origin _then_ would leak the entirety
of the cross-origin data by allowing it through the Web Audio API — an API for
low-level audio processing and synthesizing — ultimately allowing the attacker
to retrieve the cross-origin resource.

------
chrisfinazzo
> Lol no.

That hurts, Jake :(

~~~
jaffathecake
bwhahahaha

------
frandroid
Is it Tuesday?

------
westmeal
Nice one!

------
mito88
tip of the iceberg?

------
usermac
First paragraph made me chuckle.

------
_bxg1

      For example, the request may have the following header:
      Range: bytes=50-100
      …which is requesting bytes 50-100 (inclusive) of the resource.
    

I haven't finished the article, but I've seen how this movie ends...

------
con22
hn bet big money on firefox/mozilla? all news for other web browser is bad
except firefox. HN now is mozilla's Microphone

~~~
dang
HN doesn't bet any money on anything. Please don't post unsubstantive comments
here.

