181 karma · joined June 9, 2014
I couldn’t tell from a quick Google if the modern VUDU service still does anything P2P, but the service is still around running on all sorts of platforms.
> For economical home use, the best solution to the chiller overhead would seem to be in altering the commercial design by refrigerating the pressure vessel. This should be possible by separating the pressure vessel from the rest of the carbonation unit and installing the vessel in the household refrigerator. The unit could then be operated at lower CO2 pressures. This would require adapting the liquid and gas plumbing on the unit, and the electrical controls, to make them longer and to pass them through the walls of the refrigerator.
I ended up doing something similar - I found a large commercial kegerator cheap on Craigslist and stuck a McCann carbonator entirely inside it. Then I just had to run power and water to it, which is simpler than splitting the carbonator itself into two components. It works surprisingly well (after replacing a bad check valve on my eBay-sourced model).
I sourced a post-mix bar gun from eBay to dispense it, which also lives entirely in the fridge with the carbonator. After learning about how soda systems work, it was also easy to add a bag-in-box soda system. The pumps are cheap used and are powered by CO2, so you need an extra regulator per syrup you want to add, and then run a line for it to the bar gun. The syrup box lives in the fridge with everything else, so it all stays cold (and the fridge is large enough that we use it for extra fridge space and for beer kegs).
The only downsides are that it’s loud (both the fridge compressor and the carbonator) so it lives on the back porch, and the fridge uses more electricity than I’d like (because it’s commercial). If you were willing to spend more money on a similar set up though, you could fix those issues.
"5 Americans are retiring to Vietnam, for cheap healthcare and a decent standard of living" doesn't have quite the same ring to it.
[0]: https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
A while ago, I wondered if there were such a thing as a microwave + toaster oven combo (there are several convection oven + microwave combos on the market, but none can toast like a toaster oven).
Here's the top non-sponsered result: https://www.chefspencil.com/10-best-microwave-toaster-oven-c...
And the second result: https://thebrilliantkitchen.com/best-microwave-toaster-oven-...
Sure sounds like there's at least 10 of these items in existence for me to choose from - but none of the items in these lists are actually both microwaves and toaster ovens.
I've been playing with some different ways of using CUE:
- https://github.com/cuebernetes/cuebectl (declarative, continuous syncing with a kube cluster)
- https://github.com/ecordell/cuezel (bazel/make but with CUE)
both have some overlap philosophically with the "command" subsystem in CUE, but it's been fun to play with different approaches to the same problems.
How is revocation handled? Will a proxy using sharewith as an oidc provider hit the authz graph on every request?
Fully disassembling (essentially uninstalling), cleaning, and sanitizing everything that touches water seems to fix it for a few cycles, but it slowly comes back over time.
The problem has followed me across states, houses, and dishwashers. I’m assuming it’s modern enzymatic detergent like you suggest.
Slightly more frustrating is that not everyone seems to smell it, or not as strongly as I seem to. It’s like dishwashers everywhere are gaslighting me.
> When major, minor, and patch are equal, a pre-release version has lower precedence than a normal version:
> Example: 1.0.0-alpha < 1.0.0.
They asked for my account number, name, and address for verification. When they got to the point that they sent me a code over SMS and wanted me to tell it to them over the phone, I stopped them and explained that this is also the exact set of steps required to reset my account and that I wouldn’t do it.
I went to a branch in person to unlock my account and the person helping me asked me to enter my password on their terminal so that they could “see the error message”.
I’m still not sure if some parts of this were a more advanced phishing scheme than I had thought was possible, even though it does just seem like a set of confusing practices by the bank.
Because it's just debian, I also run homeassistant in a docker container started with systemd.
I like this because:
- OSMC ensures it boots into kodi and keeps kodi up to date
- systemd/docker makes it very easy to manage my homeassistant config by scp'ing a new image over to the pi.
Nothing out of the ordinary given the other responses here, but thought I'd share because it's been an especially stable setup for me.
It attempts to address a similar problem (comparing json or subsets of json), but I wanted the structure of what was being compared to be more readable (compared to jq), so I went with graphql syntax. Doubt it would do great on larger datasets though.
The signals are flawless and continue to work even if there are otherwise problems with my raspi. ClearConnect (the wireless protocol) has its own spectrum and doesn’t interfere with anything else in my house that I have found, which sets it apart from all other wireless switch ecosystems that I know of. There is a wide range of dimmers for all types of loads (even very small led loads and fan loads) and physical remote controls. The pylutron library that homeassistant uses is solid - there’s room for improvement, but that just makes it more interesting from a hobby perspective. I also like that there’s no visual difference between wireless and “normal” maestro switches, so everything will look consistent even if you don’t go all in on wireless.
It took a few hours of my life to get certified and access the configuration software for radiora2, but I think it was worth it.
Lutron doesn’t pay me :) I’ve just found it to be a great platform to hack on. It is expensive but it’s a bit cheaper second hand.
(A quick search couldn’t tell me the integration status or if there are still plans to do so, but I’m familiar with the pypi plans from the TUF side)
(docs are sparse, I wrote an accompanying doc that might help: https://docs.google.com/document/d/1AU9bwpMYlnWBlwSIiwNyse0N...)
The basic idea is what you described: append only asymmetrically verifiable signatures.
As with most things Macaroons, the harder part is developing a caveat language and verifiers that actually meet your needs. And convincing people that they're a good idea.
It may be sufficiently half-baked (not because I'm unfamiliar with the material but because I'm not sure I wrote it for the right audience).
If it wouldn't doom them to obscurity, I'd personally like to see a set of vocabularies that macaroon users can use (a la semantic web). This is probably as simple as namespacing caveats with globally unique identifiers to indicate the vocabulary.
I've used macaroons in several settings and highly recommend them. The only thing really missing for "wider" adoption is something like a standard caveat language, the lack of which keeps macaroon use pretty localized to your specific deployment.
A couple things you pointed out are definitely hard with TUF right now:
> For instance, administrator approving registration is not a single person, but group of administrators, each with different permissions on streams
TUF is being actively developed and this type of approval pattern is planned: https://github.com/theupdateframework/tuf/issues/346
> Client cannot download stream of some other client, and cannot get any information on overlays used by other clients, etc.
This is currently a limitation of TUF, but it is known and there are some tentative plans to address it. If you have specific use cases you'd like to contribute to the discussion, there are GitHub issues and the mailing list.
I think it's worth pointing out that even if you don't use TUF, you need to be thinking about the vulnerabilities it's designed to protect against. Once you start doing that you'll probably end up with something similar modulo formats and transport.
I.e. there are multiple time-based controls in place
[0]: https://www.cl.cam.ac.uk/research/security/capsicum/
Most of what this article is about concerns first-party caveats only, because (for better or worse) I was trying to keep the discussion fairly basic. I'm glad it piqued your interest enough to read the macaroon paper!
> Instead, the server should HMAC the full set of its own constraints with its own key, and then a single delimiter should be added.
This basically describes a JWT, and there's nothing wrong with doing things that way; it clearly works well for a lot of cases. Macaroons provide flexibility by allowing attenuation and delegation. Hyperdex[0] and this video[1] both discuss cases where those properties may be more desirable, which may serve as clarifying examples.
> I would propose sets of constraints be added atomically with some delimiter to reduce the number of wasted HMAC cycles.
That's perfectly valid, it's also a suggestion from the macaroon paper:
> Macaroons permit many optimizations, in both their primitives and applications. For example, a reduced number of operations can be used for chained-MACs, if caveats are combined as in Figure 9.
Where figure 9 just shows including multiple "caveat assertions" in a single "caveat".
> This exposes 'TS' to potential DoS attacks where anyone can add potentially expensive-to-verify first-party constraints which there server could be tricked into thinking that it had actually added itself.
It's good to point out that this is a vector, but practically it's very easy to mitigate this sort of attack. The entire verification process is controlled by TS, so in the first place any caveats it doesn't understand will be ignored (and verification will fail because not all constraints were met). I strongly prefer failing macaroon verification as soon as possible (even if it opens up the possibility of certain timing attacks; which could at best only reveal supported caveat types and never any secrets). This alone limits the attack surface only to specific caveat formats that TS understands. From there it's easy to add other safeguards if necessary. Verification could limit the number of caveats allowed (the macaroon paper even suggests these limits could be encoded in the macaroon as "structural caveats", although currently no implementations support them), or simply fail if it takes too long to verify. As with all DoS attack prevention the goal is to mitigate as much as possible; simply rate limiting could be effective.
> I guess if you trust your link to the 3rd party, and you trust they will add the proper constraints, the only benefit is you know once they are added they cannot be removed.
When you use "third-party" you seem to be referring to attenuating the macaroon with additional "first-party" caveats. Actual "third-party" caveats can be used to verify context in a third-party system. First-party caveats confirm the context of the target service, but consider that first-party caveats could be added by other components of TS (e.g. in a service-oriented architecture) or by local client software (e.g. a browser extension), not just "third parties."
> We do now actually know which caveats were added by TS versus which were added by FS.
This is not quite true - without storing information about the originally constructed macaroon, TS has no way of knowing which caveats it issued originally and which caveats were appended later by someone else.
[0]: http://hyperdex.org/doc/latest/Authorization/#x11-630002 [1]: https://air.mozilla.org/macaroons-cookies-with-contextual-ca...
Here's a good discussion on the differences between macaroons and capabilities: http://www.eros-os.org/pipermail/cap-talk/2014-December/0163... (see the "Macaroons: Capabilities vs Credentials).