As someone who has spent a good time of time working on trusted compute (in the crypto domain) I'll say this is generally pretty well thought out, doesn't get us to an entirely 0-trust e2e solution, but is still very good.
Inevitably, the TEE hardware vendor must be trusted. I don't think this is a bad assumption in today's world, but this is still a fairly new domain and longer term it becomes increasingly likely TEE compromises like design flaws, microcode bugs, key compromises, etc. are discovered (if they haven't already been!) Then we'd need to consider how Confer would handle these and what sort of "break glass" protocols are in place.
This also requires a non-trivial amount of client side coordination and guards against any supply chain attacks. Setting aside the details of how this is done, even with a transparency log, the client must trust something about “who is allowed to publish acceptable releases”. If the client trusts “anything in the log,” an attacker could publish their own signed artifacts, So the client must effectively trust a specific publisher identity/key, plus the log’s append-only/auditable property to prevent silent targeted swaps.
The net result is a need to trust Confer's identity and published releases, at least in the short term as 3rd party auditors could flag any issues in reproducible builds. As I see it, the game theory would suggest Confer remains honest, Moxie's reputation plays are fairly large role in this.
I found the reddit ManyBaggers recently and there is a cottage industry of high-end bags that seem incredibly made for the price that are in no way luxury products.
To contrast, in my early days of options trading with Interactive Brokers, they had closed a spread ~10 minutes before expiry at a loss, which turned profitable 8 minutes later.
Contacted support, and they responded within 2 minutes explaining exactly why this had been done (risk profile at the time, and insufficient margin to cover). They answered all my questions and even explained what I should do to mitigate this issue going forward.
Used to have IB: that broker is no joke. I would see ads on TV of $7 a trade while I was paying their crazy .001 cents per share or whatever their price was. Great paper trading account, and a Java/C++ API for everything. Plus level-2 data.
But essentially if you are using their “pro” service, which charges commissions then no. If you are using their “lite” service with zero-commission then maybe.
> Electron 9 stable will target Chromium M83 and be released on May 19, 2020, in response to Chromium's announcement of skipping the M82 stable date and adjusting the M83 stable date.
This is turning out to be a bad decision because there's been 5 major version bumps in the past year, yet the functionality in Electron hasn't materially changed very much, mostly bug fixes and minor changes.
Interested in why you think this was a bad decision. For a multitude of reasons surrounding security, performance and wanting the Latest And Greatest JS features we want to stay as close to upstream Chromium as possible. Curious what you feel the negative impact of major-versioning is?
The Electron version numbers are essentially meaningless now. I have no idea what even changed between Electron 4 and 8, the changelogs are all just bug fixes that didn't necessitate so many major version releases.
Also there are some NPM packages that have to create builds for specific versions of Electron, and those builds come out after Electron does, so I'm always 1 or 2 versions behind on Electron which leads into dependency hell situations.
We use JIRA to track our product development with a fairly large team (including 17 engineers) and while JIRA has its pain points, it does have integrations with development workflow.
In our setup, after a PR is merged in Github, the ticket automatically moves to the next “step”, in our case “Ready for QA”.
Beyond that there are automation workflows that accomplish much of what you are asking for here, the issue is that these are complex tools/flows that require a lot of up-front work and continuous maintenance which might not be worthwhile for all teams.
So internally, we're calling it the "task lifecycle". It's going to be a big feature, and the idea is to figure out the true development workflow (that works for 80% of users) and have statuses that update automatically based on Git. We're working on figuring out how to do this well enough, where the user doesn't have to go through complex configuration.
Also IANAL, but its my understanding (at least under common law here in Canada) that the doctrine of privity of contract should apply here. Since the ticket purchaser only has a contract with Ticketmaster/Live Nation they should not be able to sue the 3rd party event provider, and rather are only left with the option to sue Live Nation.
They are on top of that. The purchaser does agree a contract with Ticketmaster as outlined in the "Terms of Use". It even has a Who You are Buying From section. So there are at least two contracts. One with the broker to provide the tickets, and another between the organizer and the customers as embodied in the "admit one" physical/electronic ticket. A Canadian court isn't going to destroy one agreed contract and ball it up under another.
"Who You Are Buying From:
Ticketmaster acts as the agent to those who provide events, such as venues, teams, artist representatives and fan clubs, promoters and leagues ("Event Providers"). We generally sell tickets on behalf of our clients including artists, teams, venues, and promoters, though in some rare instances we may own a small number of tickets as part of our services contract with the individual client."
Had no idea they also owned Newton. Going to use this as yet another reminder not to invest in new email clients, they all seem to get shut down within a few years of launch.
Newton Mail’s send later’s “don’t send if recipient emails me before sending” feature looks really nice. Aside from that I can’t tell why I’d use Newton over Apple Mail.
I mean outside of any specialized features that the email client hosts, the majority of the functionality is local, no? So even if the email client is no longer developed, it'll keep working as long as your email service works.
Inevitably, the TEE hardware vendor must be trusted. I don't think this is a bad assumption in today's world, but this is still a fairly new domain and longer term it becomes increasingly likely TEE compromises like design flaws, microcode bugs, key compromises, etc. are discovered (if they haven't already been!) Then we'd need to consider how Confer would handle these and what sort of "break glass" protocols are in place.
This also requires a non-trivial amount of client side coordination and guards against any supply chain attacks. Setting aside the details of how this is done, even with a transparency log, the client must trust something about “who is allowed to publish acceptable releases”. If the client trusts “anything in the log,” an attacker could publish their own signed artifacts, So the client must effectively trust a specific publisher identity/key, plus the log’s append-only/auditable property to prevent silent targeted swaps.
The net result is a need to trust Confer's identity and published releases, at least in the short term as 3rd party auditors could flag any issues in reproducible builds. As I see it, the game theory would suggest Confer remains honest, Moxie's reputation plays are fairly large role in this.
reply