Would it be correct for iOS Safari to quietly reencode to jpeg when a HEIC file is uploaded via a webform? How would Safari know that the site's backend didn't
want an HEIC file?
I agree the HEIC thing is very confusing (having set up my parents' phones recently), but I can't see how Apple is to blame. For starters, the College Board could've done a much better job emphasizing this step for iOS users in its instructions page. But for me, the overriding factor that places blame squarely on the College Board is this from the article:
> Senior Dave Spencer took a demo test before his Calculus AB exam to make sure he understood the process for uploading photos. He Airdropped an iPhone image of his responses to his Mac and tried to convert it by renaming the HEIC file to PNG. Changing a file’s extension does not guarantee that it will be converted, but Spencer was still able to submit the demo test with no problem.
> Spencer used the same process on the real exam and thought it went through, but he received an email the next day saying the files were corrupted and that he needed to retake the test.
So it seems that students had access to a demo before test day. If I'm reading the story right:
- During the demo, Dave's phone produced a HEIC file
- The demo upload initially failed. So Dave renamed the file extension to PNG.
- Dave uploaded the PNG (in name only), and the demo did not return an error.
- Dave assumed, quite understandably, that the renaming trick would work on test day too.
So the onus in the College Board here: they provided a demo in which the photo upload function appears to have been stubbed (e.g. "if 'PNG|JPG|JPEG' is filename, print "Success"), giving students and teachers false assurance that photo uploads would work on test day.