This (the 403s) have been happening for the last week, since Friday 13 November. It's a bit of a heisenbug, so I hadn't reported it. In any case here's what I have figured out:
If you send any batch of requests ~>5 at a time, you will probably hit this. Single requests don't ever seem to hit it on first pull of a specific book. The bigger batch you send, the more you'll get: If you request 20 books at a time, in 3 batches, queued into the job manager, you'll probably get all or most of the books in the first batch, 10-12 in the second batch, and none by the third. At this point, all requests to GR fail for the next while - I didn't yet narrow down how long, but it's at least 15 minutes.
Once any specific book has failed, that book id will also pull a 403 in a browser. I've checked multiple browsers. Adding any character to the end of the url (a - will do, gr url's on the site usually include part of the title, but their webserver is actually only responding to the book id, so any text after the book id will work) and it'll work, so it's only the bare book id that fails, it's interpreting any variant as a separate, different request.
All this leads me to believe it's probably something to do with rate-limiting.
As I said, given enough time, any bare book ID url will work again too in the browser, and once it does, you can again pull that book from the plugin.
Just to be super clear what I mean here:
Bare book id url's, for books that were exhibiting this, but naturally aren't now:
http://www.goodreads.com/book/show/6902644
https://www.goodreads.com/book/show/45634
https://www.goodreads.com/book/show/553907
http vs https doesn't seem to matter, I specifically tried both. Once it's blocked it's apparently ip blocking me, because I actually tried one of those url's from my tablet on wifi behind the same router as this pc, so same external ip address) and at the same time from my phone via 3g. Tablet failed, phone worked. ETA: this is specific book id by book id. When one specific one starts failing with 403's, the rest of the site still works, but as I mentioned internal url's on GR are not bare id's, they always include some other text. The fact it starts to decline *all* metadata requests from the plugin after it's failed enough times, is interesting, again implying rate limiting, since it's affecting either only bare book id urls, or only api requests.
adding a - or any other character to those same url's, during the period they were blocked with a 403 response, and they worked fine.
This is really quite hard to debug, since it's so inconsistent, but at the same time it's also quite repeatable, if you throw enough books at GR.