I'm curious to understand which part you think is particularly interesting. The compiler clearly knows which variables are declared in what scope, so what's mysterious about figuring out which values need to be captured?
Haha this is bizzarely specific to my back-of-the woods brain. Feels like something that would be super relevant to someone in San Francisco but not as much to me
I'm currently residing in Mexico City and Apple Wallet passes are ubiquitous here for any type of event purchased online... pretty much all the major bus lines use them, all the theater chains, museums, etc.
There are many events you can't get into now without a smartphone. Unfortunately on-phone digital tickets are far too common and far too commonly mandatory. There's a huge audience of people who are required to use them. It may be specific, but it's also what we're stuck with.
> There are many events you can't get into now without a smartphone.
Yeah, it's pretty bad.
At least Apple's Wallet app works offline. There is nothing worse than having to use a dogshit proprietary app, waiting for it to handshake with four thousand data collection services before you can reach your My Tickets page, in a location where cell service is shit because thousands of other people are trying to do the same thing.
At least you can still almost always get a normal old PDF that you can print or open on your phone. Somehow these methods even work without sending gigabytes of data to 300 random services, requiring access to every sensor and going through the most botched workflows and UX choices you can imagine. A technological miracle if you ask me.
I'm enjoying the time before it gets really bad, because so far it's usually just the extremely large and centralized companies who let themselves engage this kind of abuse. Small venues, movie theaters, rewards programs or hotel reservations still find complex digital tickets to be too weird, and let us do things the boring old way.
I don't go to many events, but the last one I went to was a concert, and the tickets required the app and could not be screenshotted or PDFed because there was some motion thing on the QR code to ensure that it wasn't a screenshot. It really pissed me off, but there's not much I can do about it other than boycott the show.
Someday, I'd like to try capturing an animated gif or short MP4 or something of the motion, and see if that works, but the pragmatic part of me overwhelmed the hacker side of me. I would hate to lose my money on the ticket and not be able to see the show because I tried to hack the process
I'm wondering what the motion thing is even meant to address. Either a ticket is valid and used / not used or it's not a valid ticket. What about that requires a real-time motion thing?
Human beings are checking those tickets, and movement is proof of liveness (and not a screenshot you and 25 friends are sharing). Many ticket checking systems are not connected to the internet and cannot/will not check if it's already been used. Many of the motion enabled codes are also basically working in the same way as 2FA codes: your ticket is given with a public key, usually unique to your device, and rotates every minute. Allows them to ensure that the ticket is up to date, not forged and signed properly.
I wonder if they want to prevent reselling or at least require that it goes through their app? (I think this is a bad thing for them to do, just trying to think of the motivation).
You do understand it there because people have been trying to pass of screenshots as the app right? This happened during Covid as well. The Danish Covid passport initially just had QR code, then people started selling screenshots on Facebook. Same with the drivers license, people tried to pass off screenshots as the actual drivers license app.
It's not hard to imagine that people would sell screenshots of QR code ticket online. So rather than accepting that we've created a system that is fundamentally flawed, companies try to pave over it with more and more features, instead of just providing physical tickets.
> [...] there was some motion thing on the QR code
Yep, same happened to me with some baseball game tickets. So incredibly dumb.
Even worse, we split into two groups and I had to ask the other group to download the app... create an account... and finally be able to "transfer" the tickets to them. It took like ten minutes, and thank god we weren't at the park yet trying to do all that. Ugh.
Haha. I bought tickets to an event at the ticket window. They required sending it to my phone and wouldn’t print me a ticket! (They used ticket master). I have heard if you complain enough, they’ll have a security person escort you, but they will not just print you tickets!
It’s bad. I used to have a 6s which doesn’t have some nfc thing so most of the ticketmaster readers didn’t work and i had to go lookup how to get a barcode to appear..
I went a baseball playoff game this week with my father-in-law, and he sent me the ticket from TicketMaster in advance (not blaming him of course). I downloaded the app and logged in, and the first thing it prompted me was to select what type of events I was interested in...just to view the ticket that I already had on my account. It was skippable with some small, not-obviously-button-looking text at the bottom, so I did that, but it sucks that even when I do genuinely find digital tickets convenient, the experience is still horrible. (There was an option for exporting to Google Wallet but it kept failing, which unfortunately did not surprise me)
I found out the expensive way this year that you cannot even give someone a TicketMaster ticket. A ticket is app-based, and bound to your TicketMaster account and the only conceivable way to share it would be to give someone else your account credentials, which is stymied by the app's SMS based 2FA.
I will never give that company another dime, I don't care if John Lennon is reanimated and launches a comedy tour.
Oh yeah? I’m absolutely against Ticketmaster and their whole monopoly and the whole platform sucks with all the scalpers, but, for this specific case I never had any issues and it works well for me.
I’ve bought 2 tickets multiple times on Ticketmaster, and then ‘transferred’ one of them from the Ticketmaster UI to my partner, and then they ‘accept’ it on their account and the ticket appears there. This transfer is thankfully free.
I think the parent poster was asking how consistent that is across geographic divides. I notice the same effect: I live part of the year in a city where public transport requires either a smartphone or tap-to-pay, and the rest of the year in a rural area where nobody assumes you're carrying a smartphone. It seems to me at least that urban areas are standardizing on requiring people to carry a smartphone for tickets, passes, even menus in some places; while this hasn't caught on in rural areas. I would bet that people in rural areas will regard Apple's event ticket maker as alien to their lives and a sign of some sort of urban folly. I wonder if there's a similar urban/rural division on users of Apple's Invites app.
Most of the dev conferences around the Midwest have both the QR ticket code and then you can print a physical ticket as well - just in case. Speaking with people who work at the events, physical tickets are a life saver in conference halls where wifi/cell coverage is awful.
Nobody volunteering wants to be the bad guy and tell someone they can't enter the event because they don't have a digital ticket.
Of course a dev conference can be lenient. A Red Hot Chili Peppers concert? Probably not so much.
Not really. When I spend time in rural areas I see bar codes and QR codes are used everywhere. All this does is allow for the option for a business to put their barcode into your phone rather than having to carry around a paper copy. It doesn't preclude the use of paper. Your posting is a false dichotomy. The gap between urban and rural isn't that large.
It integrates with Apple's pass system and the app they have to let users collect their cards, passes and tickets in one place (whatever it's called), it's not about creating a PNG.
In some cases, yes, but I've used a digital ticketing system (Ticketmaster) where the barcode changes about every 20 seconds. Short of reproducing that barcode generation algorithm, Claude or Codex wouldn't help.
This has been a sore point in a lot of discussions regarding compiler optimizations and cryptographic code, how compilers and compiler engineers are sabotaging the efforts of cryptographers in making sure there are no side-channels in their code. The issue has never been the compiler, and has always been the language: there was never a way to express the right intention from within C (or most other languages, really).
This primitive we're trying to introduce is meant to make up for this shortcoming without having to introduce additional rules in the standard.
There really ought to be a subset of C that lets you write portable assembly. One where only a defined set of optimisations are allowed and required to be performed, "inline" means always inline, the "register" and "auto" keywords have their original meanings, every stack variable is allocated unless otherwise indicated, every expression has defined evaluation order, every read/write from/to an address is carried out, nothing is ever reordered, and undefined behaviour is switched to machine-specific behaviour. Currently if you need that level of control, your only option is writing it in assembly, which gets painful when you need to support multiple architectures, or want fancy features like autocomplete or structs and functions.
> want fancy features like autocomplete or structs and functions
I would argue that given a certain ISA, it's probably easier to write an autocomplete extension for assembly targeting that ISA, rather than autocomplete for C, or goodness forbid, C++.
Likewise for structs, functions, jump targets, etc. One could probably set up snippets corresponding to different sorts of conditional execution—loops, if/else/while, switch, etc.
Because for timing-sensitive code, those are important. If a variable is really a register, cache-based timing attacks just don't happen, because there is no cache in between.
>how compilers and compiler engineers are sabotaging the efforts of cryptographers
I'm not exposed to this space very often, so maybe you or someone else could give me some context. "Sabotage" is a deliberate effort to ruin/hinder something. Are compiler engineers deliberately hindering the efforts of cryptographers? If yes... is there a reason why? Some long-running feud or something?
Or, through the course of their efforts to make compilers faster/etc, are cryptographers just getting the "short end of the stick" so to speak? Perhaps forgotten about because the number of cryptographers is dwarfed by the number of non-cryptographers? (Or any other explanation that I'm unaware of?)
It's more a viewpoint thing. Any construct cryptographers find that runs in constant time is something that could be optimized to run faster for non-cryptographic code. Constant-time constructs essentially are optimizer bug reports. There is always the danger that by popularizing a technique you are drawing the attention of a compiler contributor who wants to speed up a benchmark of that same construct in non-cryptographic code. So maybe it's not intended as sabotage, but it can sure feel that way when everything you do is explicitly targeted to be changed after you do it.
It’s not intentional. The motivations of CPU designers, compiler writers, and optimizers are at odds with those of cryptographers. The former want to use every trick possible to squeeze out additional performance in the most common cases, while the latter absolutely require indistinguishable performance across all possibilities.
CPUs love to do branch prediction to have computation already performed in the case where it guesses the branch correctly, but cryptographic code needs equal performance no matter the input.
When a programmer asks for some register or memory location to be zeroed, they generally just want to be able to use a zero in some later operation and so it doesn’t really matter that a previous value was really overwritten. When a cryptographer does, they generally are trying to make it impossible to read the previous value. And they want to be able to have some guarantee that it wasn’t implicitly copied somewhere else in the interim.
Since the sibling comment is dead and thus I can’t reply to it: Search for “unintentional sabotage”, which should illustrate the usage. Despite appearances, it isn’t an oxymoron. See also meaning 3a on https://www.merriam-webster.com/dictionary/sabotage.
Every dictionary I've looked at, wikipedia, etc. all immediately and prominently highlight the intent part. It really seems like the defining characteristic of "sabotage" vs. other similar verbs. But, language is weird, so, ¯\_(ツ)_/¯.
As compiler have become more sophisticated, and hardware architecture more complicated, there are been a growing sentiment that some of the code transformation done by modern compiler make the code hard to reason about and to predict.
A lot of software engineer are seeing this as compiler engineer only caring about performance as opposed to other aspect such as debuggability, safety, compile time and productivity etc... I think that's where the "sabotage" comes from. Basically the focus on performance at the detriment of other things.
My 2 cents : The core problem is programmers expecting invariant and properties not defined in the languange standard. The compiler only garanty things as defined in the standard, expecting anything else is problematic.
I don't think it's nefarious but it is sabotage. There's long been an implicit assumption that optimization should be more important than safety.
Yes, languages do lack good mechanisms to mark variables or sections as needing constant-time operation ... but compiler maintainers could have taken the view that that means all code should be compiled that way. Now instead we're marking data and section as "secret" so that they can be left unoptimized. But why not the other way around?
I understand how we get here; speed and size are trivial to measure and they each result in real-world cost savings. I don't think any maintainer could withstand this pressure. But it's still deliberate.
> Now instead we're marking data and section as "secret" so that they can be left unoptimized. But why not the other way around?
Worse cost-benefit tradeoff, perhaps? I'd imagine the amount of code that cares more about size/speed than constant-time operation far outnumbers the amount of code which prioritizes the opposite, and given the real-world benefits you mention and the relative newness of concerns about timing attacks I think it makes sense that compiler writers have defaulted to performance over constant-time performance.
In addition, I think a complicating factor is that compilers can't infer intent from code. The exact same pattern may be used in both performance- and timing-sensitive code, so absent some external signal the compiler has to choose whether it prioritizes speed or timing. If you think more code will benefit from speed than timing, then that is a reasonable default to go with.
