<input type="file" accept="image/jpeg,image/png" />

Ten bucks says College Board programmer(s) failed to do the most basic and standard filtering.

Edit: Like a sibling comment said, the accept attribute actually isn't necessary; even PNG images (e.g. screenshots) from Photos are converted to JPEG automatically. This is true on both macOS and iOS Safari (latest). To be clear, on macOS you need to select from Photos instead of the filesystem for this to take effect.

In case anyone's interested, source code you can use to test for yourself (a Flask app):

app.py:

  import flask
  
  
  app = flask.Flask(__name__)
  
  
  @app.route("/", methods=["GET", "POST"])
  def index():
      if flask.request.method == "POST":
          image = flask.request.files["image"]
          return f"uploaded {image.filename!r} ({image.mimetype})"
      return flask.render_template("index.html")

  <html>
    <head>
      <meta charset="utf-8" />
      <meta name="viewport" content="width=device-width, initial-scale=1" />
    </head>
    <body>
      <form method="post" enctype="multipart/form-data">
        <input name="image" type="file" required />
        <input type="submit" />
      </form>
    </body>
  </html>

In any case, sounds like absolutely horrid QA and communications of what's accepted (and of course, very bad idea not supporting the format in the first place when half your test takers are taking pictures in that format).

(A bit more context on my original comment: I thought they had some working system where test takers could upload photos directly from their phones — e.g., scan a QR code to open a page with a unique ID with an image upload form. Turns out that's too much to ask; their process is "get the image from your camera to your test-taking device whichever way you can think of, not our problem." Not surprisingly that's not a very foolproof process.)

However, taking a step back, you should have enough representative test cases (QA snaps a photo with iPhones, tries to upload) that whether assumptions are reasonable doesn't enter into it because you aren't making them.

Why is it a failure of the college board to put "accept="image/jpeg"", instead of iOS which failed to default to the more standardized jpeg format when HEIC was not specified?

HEIC is a newer format which fewer systems support. iOS / Safari should default to JPEG in this case.

Which, in turn, means that the form isn't putting any constraint on what's being uploaded at all, and so there's no reason to think that the form is asking for an image in the first place. At that point, it's asking for a file. Any file. And so it has the semantics of taking whatever file you provide it as-is, with no transformation necessary. Just like when a client requests `Cache-Control: no-transform` from a server. It wants the thing on the other side sent to it as-is.

And, it's important to support those semantics (and that particular implicit meaning for leaving out the `accept` attribute), because such "as-is" uploads have many use-cases. The form might be e.g. a computer-forensics or antivirus-signature portal, that wants an evidence file; or the interface to a hex editor or decompiler, that expects a raw binary with arbitrary extension in unknown format; or the SCP component of an old web SSH terminal emulator. All these existed on the web, and used <input type="form">, before the `accept` attribute was introduced. So "not using the `accept` attribute" has to retain semantics that are backward-compatible with that legacy.

1. Correctly label their expected stream types. 2. Test all of the most popular devices before having something this broken in production.

What about a kid that's using a cheap android tablet from aliexpress? Are you arguing that the company nobody's ever heard of is at fault for not programming their tablet to use the correct image format? I agree that they should probably be using JPEG but that doesn't mean College Board is off the hook for making it easy for a user to not be able to use their product for something this important.

It really bothers me when programmers make excuses for laziness or shoddy work that results in user's being harmed. Start caring about your users.

The iPhone is the most popular phone model in the United States. This is on the College Board. It takes very little work to make this work properly, which ANY BASIC QA PROCESS WOULD HAVE CAUGHT.

I don't think the failure is with the accept type. I think the failure is with the bespoke JavaScript checking the filenames. That puts the failure on the College Board, not Apple.

But even if it did send HEIC, if you're going to fail to handle "any" format, then you better specify the one you can handle. By the same token, why shouldn't my computer convert every .docx to PDF, or some other "more universal" format?

Instead of specifying the requirement programmatically, they spent their time sending out tweets and writing help docs.

Point of order: separate people, with separate/independent/concurrent job responsibilities. It very likely wasn't the programmers tweeting and writing docs. (Heck, I expect that the College Board doesn't even retain any full-time programmers, only contracts with firms for projects.)

It's the same as if Apple shipped me an empty box instead of my iPad Pro. Of course I can't blame the customer support person who takes my call, and I shouldn't be rude to them. But I would still blame Apple the corporation for such a thing, had it happened.

2. Please try to read the entire comment. iOS does default to JPEG when uploading, the accept attribute isn't needed.

And if they really needed to control the file formats this much, they should have written this functionality into an app (for iOS and Android) and handled taking the picture themselves.

They really screwed things up for a bunch of kids here.

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.

I don't think it was exactly that it was stubbed out, per se; I would guess it was that the whole "backend" process involved either a human or an async batch process opening the file; and so in both the demo and prod environments, the upload of a file can succeed while the parsing of said file can fail (much later on, after the test is completed, during the grading phase.)

And now that I reread the passage about Dave, I realize it's not necessarily true that Dave tried to upload HEIC, then got an error message, which led him to then rename the file. But he may have actually read the instructions about PNG/JPG being required, then thought he could just rename his file, then uploaded it as his first and only upload to the demo app. And whether the demo app actually did the upload, it apparently didn't do the parsing (I still think that was stubbed out; I can imagine an engineer thinking it'd save a headache if they disabled the parsing module for the demo server)

The demo is still up and you can still look at it

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

AIUI, Mobile Safari always re-encodes the image. However, if you transfer the image to a device that supports HEIC (e.g., recent macOS) then you'll find out that (desktop) Safari never re-encodes an image when uploading a file.

Not really: https://news.ycombinator.com/item?id=23261216

Images are converted if you select from Photos (instead of the filesystem).

As soon as I stray from golden path - text using anything but Apple MEssages, email using anything but apple mail, post using anything but safari, use/process with anything but Apple Photos - HEIC has been an absolute positive pain in my keister ;-(

Other people may have more luck; note that my work iPhone is an isolated island - my other devices are either Android, or Windows/Linux - which probably explains my troubles to a large degree. Apple's selling point has always been the well-integrated ecosystem so I understand I'm an outlier.

One can moan about the test site not being more robust/careful but it is Apple/Samsung that are using the new, non-standard format and expecting others to accomodate in short order.

Also you don't need an external tool -- Preview will convert HEIC to JPEG for you relatively instantly, even in batch. (Though I really do wish the phone would ask first if you want to convert, when Airdropping.)

If you don't care for apps to remember their previous windows and ui state, you can disable this mechanism in the settings app: https://support.apple.com/en-ca/HT204005#appresume

My guess is that the JavaScript manually checking the filename's extension is screwing up the automatic conversion.

What if it can't because the format is proprietary and Apple wants to charge for its use? As I understand it, MS and Google have to pay licensing fees to enable support for it in Windows 10 and Android.

HEIC (image encoding) is available without royalties: https://en.wikipedia.org/wiki/High_Efficiency_Image_File_For...

Regardless, in this case, as others noted, iOS would have just converted to jpg if College Board was using a standard image upload form.

As stated by that Wikipedia article, HEIF is the royalty-free container. HEIC means the content is encoded with HEVC, which makes it not free.

Ah, ok, thanks!