Google projekt zero website is the ONLY website which frequently get featured on HN that I cannot read on my iphone. Safari, Firefox or Edge are all rendering the page with horizontal scrollbars. I can use 2 finger zoom in and then a third finger to move the content around. At that point I cannot see the screen for my fingers and have problems holding my phone in my hands.
Do they have a bounty program for HTML where one can submit a fix? /s
This is not a new issue. Been like that for a long time
I'm on Android so I don't have any trouble, but keep in mind that all "browsers" on iOS are just Safari with a skin and a few features bolted onto it. Apple doesn't allow different browser engines on their platform because of various reasons.
It seems to be using the default simple blogger theme so there's probably no point of contact for the website, it's Google after all. The best chance you have is to submit a bug report with Apple about Safari not rendering the page right.
I just read both parts without even noticing but you’re right it does. I guess you have a different device/screen size as the position and scale is correct for me. It’s a bug in blogspot itself so far as I can tell.
All web browsers in iOS run the same engine (Safari). So while Google should fix their layout, this is a very good example on why Apple should allow alternative web engines in their OS.
You might think so but you would be wrong. For example, try making a link to add a calendar event from Safari vs. Chrome vs. Facebook in-app browser, etc.
UPDATE: This issues appears to have been fixed now and the page renders as it should. Everything is now fine. Assuming that is this thread that caused someone to to take a look at the UI. Thank you very much Google project Zero :)
Ps: The down votes on my original rant can stop now, I hope. Thx ;)
> We have positions available for a Principal Software Engineer and Senior Software Engineer. We are looking for engineers who have production compiler development experience and who value shipping software.
For new projects, sure. For existing projects, it's not trivial to convert them and anyone working on something significant is going to need time to do a migration during which additional new C code will almost certainly need to be written.
“semi-” is not a synonym for “easily done with production-ready results”. Until that changes, people are going to need to write new C code even if they're working to refactor their code into a better language.
> At this point, we were questioning our decision-making process more thoroughly, and immediately tried reproducing with the same version on a Linux build. I think you, the reader, can imagine how we felt when the issue also reproduced locally with an ASAN Linux build…
This was my very first thought when I read that it occurred on Android, so I know it had to be someone’s first thought working on this. Very unfortunate, but I’m pretty sure we’ve all been there, with a gut feeling we either ignored or outright doubted that could’ve potentially saved months at minimal risk.
I don't really understand this level of memory manipulation and exploit construction very well right now. But I notice that the usual Rust advocates are big on boosting how the language restrictions and constructs block these sorts of things. Can anybody comment on how many of the steps they used could actually be prevented by using Rust for this module?
27 comments
[ 2.7 ms ] story [ 71.7 ms ] threadDo they have a bounty program for HTML where one can submit a fix? /s
This is not a new issue. Been like that for a long time
Try the non-mobile version: https://googleprojectzero.blogspot.com/2020/02/several-month...
It seems to be using the default simple blogger theme so there's probably no point of contact for the website, it's Google after all. The best chance you have is to submit a bug report with Apple about Safari not rendering the page right.
Ps: The down votes on my original rant can stop now, I hope. Thx ;)
This the main take away. Even when writing C, just prefer safe libraries to default strings and arrays, when possible.
By the way, MSR is hiring for Checked C.
Only internships ATM according to their web page
At least that's what I understood from your original comment.
> We have positions available for a Principal Software Engineer and Senior Software Engineer. We are looking for engineers who have production compiler development experience and who value shipping software.
And even then, many of those interfaces are based in C semantics anyway.
So anything that helps to reduce the amount of possible security exploits per line of C code is welcomed.
[1] https://github.com/immunant/c2rust
This was my very first thought when I read that it occurred on Android, so I know it had to be someone’s first thought working on this. Very unfortunate, but I’m pretty sure we’ve all been there, with a gut feeling we either ignored or outright doubted that could’ve potentially saved months at minimal risk.
> C-style programming in C++ is also a bad sign; the IOBuffer design pattern with separate storage of buffers and their sizes is inherently dangerous.
Rust has "slices", which store a pointer and a length together, so they cannot get out of sync like this.