List view
Sales from an EU company to an EU customer (business or otherwise) involve [VAT](https://en.wikipedia.org/wiki/European_Union_value_added_tax). The VAT rate _may_ be determined by the country of the exporter (below a certain threshold) or it may be necessary to use the VAT rules from the country of the importer (customer). See [Distance Sales](https://en.wikipedia.org/wiki/European_Union_value_added_tax#Distance_sales) for details. The remainder of this issue assumes it is necessary to use the country of the importer for VAT rate determination. When collecting billing information for the creation of a new subscription, we will need to determine if the customer resides in the EU and if so then in which specific country. This will allow us to determine the VAT rate to apply to the subscription. Once this is determined, we can [create the subscription with a tax rate](https://stripe.com/docs/subscriptions/taxes) matching the VAT rate to cause charges of the correct amount (including our fee and the additional VAT amount). (Stripe has [first-class VAT support](https://stripe.com/docs/orders/tax-integration) for _Orders_ / _Products_, apparently; but not for Subscriptions - unless I am misunderstanding something in the documentation.) The tax rate becomes a persistent part of the Stripe Subscription object and so is available for our later inspection but the physical location is not preserved anywhere. It may be possible to reverse a VAT rate to an EU country (perhaps not unambiguously but it seems to narrow down the possibilities a lot). This is desirable from a personal information standpoint (ie, LeastAuthority is happy to know as little about the customer as possible) but it may be problematic in other ways. For example, VAT rates do change over time. So, for example, the UK VAT rate changed from 17.5% to 20% in January 2011. If LeastAuthority had been EU-based at that time, it would have been necessary to replace all existing UK-customer subscriptions (which would have had a 17.5% tax rate applied) with new subscriptions identical except having a 20% tax rate applied instead. This is only possible if we can identify a Subscription as UK-based or not. Another possible event is that a customer could move to a new country with a different VAT rate. It seems likely that this would also necessitate a subscription change. Thus, we likely also need to extend our model to track the import country for each subscription. This will also be necessary if we want to apply "distance sales treatment" and use country of export to determine VAT rate, this requires accounting for sales to each different EU country and so also requires this additional subscription information. Therefore, we must update the signup form so that it collects the import country. We must use this information to create the subscription with the correct tax rate based on the import country's VAT rate. And we must persist the import country into the subscription (probably the one in our database, not Stripe's Subscription object). All existing subscriptions are billed in USD. This may give us leeway to assume all existing subscriptions belong to customers in non-EU countries and therefore VAT does not apply.
No due date•4/4 issues closed- No due date•3/3 issues closed
!Dependent on landing cloud backend branch in Tahoe-LAFS! Add Magic Folders (experimental) to the S4 service (dependent on Tahoe-LAFS work).
Due by March 31, 2017Identify necessary logging and monitoring, build reports to show information.
Due by February 28, 2017•14/14 issues closedComplete internal improvements to the way the S4 deployment is managed to reduce complexity, improve reliability, and streamline the development process.
Due by January 8, 2017•45/45 issues closed- Due by August 31, 2016•7/10 issues closed
- No due date•6/6 issues closed
- Due by September 4, 2014•3/3 issues closed
S4 Iteration Plan top priorities: * fix the spam problem on Zendesk (1 day) * complimentary service { Jeremy Benisek, Tor/Tails, Jean Lorchat, JoeyH } * tweak settings on kernel and rlimits (1 day) * blog post about breach (2 days of blogger team time, 1 day of DevOps team time) Not in this milestone, but potential future goals: things to make future iterations easier: * simplify the interface, factor out tools, for deployment tools * train other employees to learn the existing deployment tools possible improvements for future iterations: * new lower-priced plan(s) * improve monitoring to detect discrepancy between email/cc submission and successful deployment. * improve monitoring to notice when simple GET requests to our website fails. * having a control panel where customers can see their status (Nathan wishes stripe would do this for us.) * PGP automation * load testing on the webserver and/or signups (how many concurrent visits/signups trigger resource bottlenecks? Which ones?)
Due by July 29, 2014•8/8 issues closedOur public "maximum impact" release is set to coincide with (be a part of) ResetTheNet day on June 5. https://www.resetthenet.org/ Anything which should be fixed before then should be a part of this milestone.
Due by June 5, 2015•17/17 issues closed