But if you change the firmware, it won't receive anything anymore since it wouldn't know what to listen to(?)
A subscription works like a prefix filter. If you subscribe to "foo",
you will receive any event whose name begins with "foo", including
"foo", "fool", "foobar", and "food/indian/sweet-curry-beans".
So its not that hard to find out what data is being received, but finding out what is send is granted a lot harder.
How is this different from if it were a product, seems to me that USB uploading would still be possible? Honest question, I donât know.
There is a slight safety check in that firmware for products must have the product ID builtin.
Although there is no check if the developer is the one that owns the ID, but the customer would need to find this somewhere, I dont think its treated as a secret though, so its likely possible to findâŚ
I think the device will be isolated if the firmware is not the correct product, not sure though.
If a unknown device loads your product firmware, its isolated untill you allow it inside on the console.
So not sure theres much difference actually 
Never forget that physical access will always be total access, no matter what route you take. This is why Particle recommends that you disable access to Serial and JTAG pins (breakaway post manufacturing). In any system be it Console or DIY all input should be verified and malformed/erroneous inputs should be rejected completely. Letâs say you use webhooks and have an instance of Redis inserting published data, can you be sure that malformed data wouldnât cause an issue, are you prepared to watch all CVS traffic related to the full stack and it goes on and on. This isnât an easy thing to do and in my mind part of the value is that I have Particle engineers working on my behalf and helping (not completely) identify potential attack vectors and mitigating them. Particle has handled so much of the low level stuff that is absolutely needed but not directly part of the âthingsâ built on their system. Always think through any potential attack vector then mitigate, log, continually review and improve.
No device in the hands of a skilled and determined adversary is totally safe so do what you can to deter (make it harder) but focus the majority of your efforts on the side of the equation you are in control of and they canât get to (the cloud side), Particleâs offering is what the industry calls Opioniated which is absolutely the direction most things are headed. Take advantage of their engineering, experience and skill or suffer the potential perils of bricking all your customers (hello to Wink again), a major outage, reputation loss or worst of all a very public and consumer confidence destroying breach that is likely to destroy your business/product.
3 Likes
Hi Luke, in my earlier post I laid out no need for particle services aside from firmware updates. Being able to send my Webhooks directly to AWS is all I need.
Your points re build vs rent are accurate if you believe as an user that theyâve hit critical mass where building doesnât make sense. Rolling my own automatic update took an afternoon to write, test and perfect.
4 Likes
Can we get an update on this? I still want to see if Particle is or plans to implement a feature that only charges for "active" devices within a given month. I would define active as pings the server even once. If a device is not active for 12 months but sits in a customers closet. Why am I paying continued device fees for that?
Let's say that I have 10,000 devices in the field of which, 5,000 customers decide not to use their product anymore. In perpetuity in order to support those never used customers anymore I would need to pay $1,450 a month.
2 Likes
Hey there @incorvia â wanted to provide some responses to your questions. Your OP was back in 2016 and some things have changed, so will address comments in both your linked post as well as your most recent one.
There are two models for transacting with Particle.
The first is our "self-service" model, where customers have transparent visibility into hardware and Device Cloud pricing on our pricing page. Discounts on hardware and Device Cloud are provided at pre-set volume discount tiers.
The second is our "enterprise" model, where customers make hardware and Device Cloud volume commitments in exchange for deeper discounts and additional platform features. These commitments help make our business more predictable (good for Particle) and provides more value to our customers for lower per-device costs (good for customers).
More detail on enterprise "commitments"
I spoke with a customer service representative and specifically asked what to do with devices that are thrown away after 2 years but we have to keep registered for 5 - 10 years paying fees for a machine that is technically no longer being used.
To be clear â there are no Device Cloud commitments for our self-service model. Our enterprise commitments typically span 2-3 years (term length is negotiable), not 5-10 years, and do not apply to any individual device, but rather a minimum number of devices.
So, in either plan, if a particular device is no longer in use, you can un-claim that device from your account or pause the cellular data services associated with that device and it will no longer be counted as billable. If you're on a self-service plan, you'll no longer pay for it. If you're on an enterprise plan, you're still accountable to the device minimums that you've committed to, but won't be charged for the device if you've already covered your minimums.
Billing for "active" devices
I still want to see if Particle is or plans to implement a feature that only charges for âactiveâ devices within a given month. I would define active as pings the server even once.
Thank you for your feedback. What I hear you saying is that it would be easier if Particle automatically removed even devices that are claimed and "active" from your bill if they aren't being used, versus requiring customers to un-claim or pause connectivity manually to remove them. I agree that this would make life easier for product creators, and will pass on your feedback to the team responsible for implementing our Device Cloud billing. I can share that we have plans to simplify the model for "active" and "inactive" devices on the platform to make billing more straightforward, I can't provide a timeline around this feature.
Let me know if you have any more follow-up questions! Hopefully my response was helpful to you.
4 Likes
Thank you Will for your very thoughtful and direct response. The end of your email is exactly what I was referencing and it is great to hear that Particle is not only receptive to the idea but is making plans to address some of these concerns directly. As you guessed, adjusting billing makes more sense in many ways than manually unclaiming or deregistering a device. If a user pulls a device out of the closet after 2 years of inactivity it would be good for it to âworkâ but we cannot foresee this and would be unaware of whether it was in a landfill or actually going to turn back on again some day.
As for your Enterprise points, this is something Iâm aware of but will reach out in a PM to more directly ask about these plans.
Thank you again!
2 Likes
Has there been any update on the idea of active vs inactive pricing?
2 Likes
If anyone is familiar with the minimum commitment needed to get extended Carrier per country support for Gen3 cellular, please send me a direct message about what the commitment and pricing is. Thanks.
From decades of experience, multiple carriers per country is necessary for all cellular products, at least here in Europe.
1 Like
I was never able to get this pricing but just want to voice the wish for the future that multiple carriers per country was available from the start instead of after a âcontact salesâ number of units and pricing.