igloohome Smart Mortise
8 days ago by jm
Now this is clever. A "smart lock" which doesn't require access to the internet; uses crypto to allow generation of transient time-limited access codes which you can give to other people, and a TOTP-style algorithm to generate one-time access codes. (via threeze)
via:threeze
smart-locks
locks
iot
crypto
igloohome
homes
8 days ago by jm
Security Things to Consider When Your Apartment Goes ‘Smart’
24 days ago by jm
Good advice, and I'd be pretty unhappy about this if it happened to me too.
locks
iot
security
internetofshit
tenancy
renting
smart-hubs
smart-homes
smart-locks
If you’re a tenant in the US, it’s very likely that a management-provided smart home system is headed your way in the near future. Carefully evaluate your family’s personal threat model, and consider the plausible digital ways which these systems could be exploited.
Spend some time reading into the vendor. Respectfully and courteously encourage your property management company and their smart system vendor to adopt industry best practices in securing smart hubs physically and digitally, the networks they are connected to, and and resident data at rest and in transit in their infrastructure. Request your property managers clearly and decisively address privacy concerns such as data ownership and resale in writing. If solid answers in writing don’t assuage legitimate concerns, consider politely seeking an option to opt-out – and make your threat model clear to them, if you’re in a sensitive situation.
24 days ago by jm
Breaking combination locks with false gates
august 2018 by jm
bookmarking for future reference
lockpicking
locks
combination-locks
august 2018 by jm
Locking, Little's Law, and the USL
september 2017 by jm
Excellent explanatory mailing list post by Martin Thompson to the mechanical-sympathy group, discussing Little's Law vs the USL:
usl
scaling
scalability
performance
locking
locks
java
jvm
amdahls-law
littles-law
system-dynamics
modelling
systems
caching
threads
schedulers
contention
Little's law can be used to describe a system in steady state from a queuing perspective, i.e. arrival and leaving rates are balanced. In this case it is a crude way of modelling a system with a contention percentage of 100% under Amdahl's law, in that throughput is one over latency.
However this is an inaccurate way to model a system with locks. Amdahl's law does not account for coherence costs. For example, if you wrote a microbenchmark with a single thread to measure the lock cost then it is much lower than in a multi-threaded environment where cache coherence, other OS costs such as scheduling, and lock implementations need to be considered.
Universal Scalability Law (USL) accounts for both the contention and the coherence costs.
http://www.perfdynamics.com/Manifesto/USLscalability.html
When modelling locks it is necessary to consider how contention and coherence costs vary given how they can be implemented. Consider in Java how we have biased locking, thin locks, fat locks, inflation, and revoking biases which can cause safe points that bring all threads in the JVM to a stop with a significant coherence component.
september 2017 by jm
Bike thief reveals tricks of the trade in this shockingly candid interview
may 2016 by jm
This is an eye-opener:
bikes
locks
bike-locks
security
london
theft
lockpicking
d-locks
A former bicycle thief has revealed the tricks of the trade in an interview, which clearly and shockingly shows the extent that thieves will go to in order to steal a bike. He talks about the motivations behind the theft, the tools used to crack locks and how the bikes were moved around and sold for a significant sum. He also gives tips on how to prevent your bike from being stolen.
[...]
'Don’t be fooled by Kryptonite locks, they’re not as tough as made out to be. Also D-bars with tubular locks, never use them, they’re the most easy to pick with a little tool. It’s small and discreet, no noise and it looks like you are just unlocking your bike. With the bolt cutters we would go out on high performance motorbikes, two men on a bike.'
may 2016 by jm
Biased Locking in HotSpot (David Dice's Weblog)
march 2015 by jm
This is pretty nuts. If biased locking in the HotSpot JVM is causing performance issues, it can be turned off:
hashcode
jvm
java
biased-locking
locking
mutex
synchronization
locks
performance
You can avoid biased locking on a per-object basis by calling System.identityHashCode(o). If the object is already biased, assigning an identity hashCode will result in revocation, otherwise, the assignment of a hashCode() will make the object ineligible for subsequent biased locking.
march 2015 by jm
"Taking the hotdog"
may 2014 by jm
aka. lock acquisition. ex-Amazon-Dublin lingo, observed in the wild ;)
language
hotdog
archie-mcphee
amazon
dublin
intercom
coding
locks
synchronization
may 2014 by jm
The Best Bike Lock
october 2013 by jm
Interviews with 2 New York bike thieves (one bottom feeder, one professional), reviewing the current batch of bicycle locks. Summary: U-locks are good, when used correctly, particularly the Kryptonite New York Lock ($80). On the other hand, Dublin's recent spate of thefts are largely driven by wide availability of battery-powered angle grinders (thanks Lidl!), which, according to this article, are relatively quiet and extremely fast. :(
bike
review
locks
cycling
u-locks
theft
security
october 2013 by jm
Locks & Condition Variables - Latency Impact
locking
concurrency
java
jvm
signalling
locks
linux
threading
september 2012 by jm
Firstly, this is 3 orders of magnitude greater latency than what I illustrated in the previous article using just memory barriers to signal between threads. This cost comes about because the kernel needs to get involved to arbitrate between the threads for the lock, and then manage the scheduling for the threads to awaken when the condition is signalled. The one-way latency to signal a change is pretty much the same as what is considered current state of the art for network hops between nodes via a switch. It is possible to get ~1µs latency with InfiniBand and less than 5µs with 10GigE and user-space IP stacks.
Secondly, the impact is clear when letting the OS choose what CPUs the threads get scheduled on rather than pinning them manually. I've observed this same issue across many use cases whereby Linux, in default configuration for its scheduler, will greatly impact the performance of a low-latency system by scheduling threads on different cores resulting in cache pollution. Windows by default seems to make a better job of this.
</blockqote>
september 2012 by jm
related tags
amazon ⊕ amdahls-law ⊕ archie-mcphee ⊕ biased-locking ⊕ bike ⊕ bike-locks ⊕ bikes ⊕ caching ⊕ coding ⊕ combination-locks ⊕ concurrency ⊕ contention ⊕ crypto ⊕ cycling ⊕ d-locks ⊕ dublin ⊕ hashcode ⊕ homes ⊕ hotdog ⊕ igloohome ⊕ intercom ⊕ internetofshit ⊕ iot ⊕ java ⊕ jvm ⊕ language ⊕ linux ⊕ littles-law ⊕ locking ⊕ lockpicking ⊕ locks ⊖ london ⊕ modelling ⊕ mutex ⊕ performance ⊕ renting ⊕ review ⊕ scalability ⊕ scaling ⊕ schedulers ⊕ security ⊕ signalling ⊕ smart-homes ⊕ smart-hubs ⊕ smart-locks ⊕ synchronization ⊕ system-dynamics ⊕ systems ⊕ tenancy ⊕ theft ⊕ threading ⊕ threads ⊕ u-locks ⊕ usl ⊕ via:threeze ⊕Copy this bookmark: