By "internal feedback" do you mean feedback when a user is logged into an account?
We allow you to do fine-grained censoring of any DOM element by adding class="do-not-track". So if there's a field, or an entire page, that you do not want captured, you can easily mask all of it.
Passwords fields are always censored, and there's no way to disable that.
We also have limited session lengths (up to 30 days), unless a user leaves feedback or a member of the team explicitly saves a moment.
What prevents somebody from scanning it and reconstructing the position of the metal pieces?
Perhaps a better solution is to create a small chip powered by electric induction. The chip would have an embedded private key and solve challenge-response queries issued by the scanning device.
I'm not sure how that compares in cost though.
Edit: it looks like these already exist and cost less than 10 cents a piece. They are called NFC tags.
It says in the article that the idea behind this implementation is that if the tag is swapped it breaks the authentication since the glue is involved in authenticating. NFC/RFID chips can just be swapped from a real product to a fake one as-is.
>What prevents somebody from scanning it and reconstructing the position of the metal pieces?
You're talking about very, very small pieces of metal whose position/orientation is not deterministic when laying the glue and that information is combined with the tag itself to present some kind of challenge response.
Yeah if I’m understanding the article correctly it’s not that the glue is pre-printed with a specific code but rather the glue has a bunch of particles suspended in it and take on an arbitrary pattern when used. Conceptually similar to https://trmm.net/Glitter/ but at a much smaller scale.
Why is it not possible to embed the NFC tag in a destructible medium? Like those annoying stickers that you cannot peel without ripping?
If you use that, then the only way to move the NFC tag to another item would be to cut it out of the original item (including the original adhesive). But this attack also works against the technique in the article.
Regarding the orientation, I understand that it is nondeterministic in the original, but what prevents an attacker from copying it deterministically? Is it just that technology is not good enough to manipulate such small pieces of metal? How long will this limitation persist?
Yes, like other similar tamperproofing options (glitter, vacuum-sealed colored beads, etc) it's trivial, cheap and fast to get a random pattern, but absolutely impractical to control the pieces to get any specific pattern - perhaps someone like a microsurgeon could manipulate them properly given enough time, but that would take an absurd time (since there are many tiny pieces which each need to be manipulated within a gooey substance where each movement disturbs previous ones as well) and be absurdly expensive, and nobody has a "printing" technology to do it in a cost-efficient way.
Perhaps in future someone could develop an advanced combination of 3d printer and pick&place machines that could do it, but such future potential doesn't disqualify this tech from currently detecting counterfeiting of fancy shoes or something.
Why would you need a 3D printer or pick&place machines? You can just do it photolithographically.
Coat a piece of glass with a thin layer of metal. Put a photoresist on top. Project the desired pattern onto it with UV light. Wash the unhardened photoresist away and etch the unnecessary metal.
Now you've got metal in exact the spots you'd like, of exactly the thickness you'd like. You can get the accuracy down to a few hundred micrometers for cheap today.
That would work only for a planar distribution of material. A 3D distribution would require multiple layers (I guess it might quickly become infeasible if it requires thousands of layers).
In the case of 3D arrangements, I think some substrate materials (and also some properties of the particles) would be very difficult to get using photolithography (or some kind of micro 3D printing).
In the case of 3D arrangements, you don't necessarily need to create all the layers photolithographically. You might be able to flatten N layers into 1 layer, then add a plastic coating equivalent to N-1 layers ontop, then repeat that. You'll have a very similar result to every layer being separate.
Imagine e.g. the "multiple layers of cardboard cutouts" scenery in theater vs it actually being 3D.
I don't know much about photolithography, but doesn't it rely on relatively expensive fixed masks prepared for each layer?
Assuming that doing the process you describe is sufficient, what's the ballpark of what "for cheap" means for you if you needed to print 1000 different fake tags, assuming many layers of "the desired pattern" to print the metal flakes?
> doesn't it rely on relatively expensive fixed masks prepared for each layer
If you need perfectly sharp edges and high precision, sure. But I'm sure in this case that'd be unnecessary.
> Assuming that doing the process you describe is sufficient, what's the ballpark of what "for cheap" means for you if you needed to print 1000 different fake tags, assuming many layers of "the desired pattern" to print the metal flakes?
I described in another comment an additional way to quantize the layers to reduce the repetition steps, which would reduce costs further.
Regarding costs, you could fake a THzID chip for about 500€ per fake. Not cheap enough to do it for household items, but if you're faking designer bags, clothing, sneakers, or electronics, it'd be absolutely worth it.
With the right techniques it's often possible to remove those annoying stickers without ripping them. Some of the techniques involve using a solvent or very thin and slippery blade. They are supposed to be resistant against that, but in practice a lot of time not enough.
NFC tag usually consists of two parts very tiny IC (small piece of silicon the size of sand grain) and antenna (a piece of metal foil in a fancy shape). You could make an NFC tag where attempting to remove it rips antenna, but that wouldn't destroy the IC. It's probably a matter of product price and quantities whether, counterfeiting it by reattaching the NFC chip to a new antenna is economically viable. As the process is not only possible it's performed at the NFC tag factory at very large quantities at very low cost. It might also be possible to repair parts of broken antenna assuming area around IC is undamaged.
So overall you get simplicity and cost of regular tamper resistance stickers, with better resistance against solvent and blade attacks, and security properties closer to what you get from secure NFC chip (except you can't perform more complicated cryptographic operations like signing arbitrary data).
> Is it just that technology is not good enough to manipulate such small pieces of metal? How long will this limitation persist?
I would expect that at any point in future, whatever the best controlled manufacturing technique invented are, it will be possible to create uncontrolled pattern at finer scale, or at least much cheaper. Unless we reach the point where maintaining stable state without deteriorating becomes a problem, or the quantity of data for storing and processing becomes impractical.
Though the re-construction of the pattern is effectively impossible, I think you raise a good point regarding the use of NFC. The article mentioning a cloud database was a red flag for me as it introduces another attack vector. Sure, it's not as simple as replacing the tag as you can with RFID, but we know the counterfeiters will go to impressive lengths to replicate the real deal. If verification can be all-local that's ideal, imo. The issue there, though, is that you then need to trust either the scanned or scanning device with a private key. A private key that, if obtained, could be used to create infinite counterfeits. Either way, I think this glue-based method is a great solution, even if it does rely on a cloud service which is dependent on the company that maintains it.
I don't know if I understood correctly. But it might be that the metal pieces in glues are pure random process, and there are no way to reproduce or re-print it again. The metal pieces are then recorded as a key in central database or some sort of AI, just like human fingerprint or retina how are collected and used for authentication???
We tried for years to do things like this, and in the end an approach using typescript is way, way better than anything else I've seen attempted.
In my latest project[1], we set up the types for the API. The server and client are both bound by those types, meaning that one cannot change without the other. This fixes an entire class of bugs where backend code gets updated without the corresponding front-end code changing or vice-versa. It also has the nice side-effect that all of the possible return values (including errors) are nicely documented in one file, and that the errors are very consistent. On the frontend we have a "typed fetch" which returns typed results from the API.
We are also using this for typed access to localStorage, another source of many bugs in past projects, where random keys end up being scattered and causing nondeterministic behavior on different devices.
You can see how our API type system is implemented here:
[1]: We are working on https://app.presupplied.com, a digital home-schooling curriculum to teach 3-year-olds to read. Planning to expand to math, writing, and programming.
Our approach doesn’t preclude TypeScript! In fact I think it would integrate well with it. If you’re interested in a TS approach could you email me at keith@instant.dev ?
I am skeptical of reports published by the cities. There is incentive for the reports to skew positive, since otherwise individuals can lose elections/jobs/contracts.
So I looked back at the 2014-2016 reports from Flint, Michigan to see if they correctly predicted the water crisis.
Also note that while in the US the lead concentration limit is 15 ppb, Canada has recently reduced its limit from 10 ppb to 5 ppb. Nearly every US city I've looked at exceeds 5 ppb.
Almost every date picker I've used is terrible. If you are reading this and are responsible for adding a datepicker, please, please, please do at least the following:
1. There should be a textbox allowing me to type a human-readable date/time (e.g. "monday 5pm" or "july 7, 2015").
2. The textbox should be selected and ready to type into as soon as the datepicker is opened
3. There should be a short list of previously-typed dates because often, for a given date in the UI, the same date is used multiple times in quick succession
4. There should be a typical month view with days of the week visible, in case I'm on mobile
5. The current date should be highlighted on the month view.
6. I should be able to pick the month and the year in at most two taps each (i.e. dropdown for each), no matter how far back in time I need to go.
Shameless plug: we recently implemented an exceptional date picker on momentcrm.com because of how frustrated we were with the default browser experience.
In my web apps, I make dates text boxes that can handle inputs like “next Thursday”, “Monday at 5p”, etc by running the inputs through https://github.com/mojombo/chronic
I like the idea of inputs being able to make sense of as wide of a variety or formats as possible.
For number inputs I’d like to build into Rails something that can handle basic math expressions. For example, a person can enter “120 / 2” in an input and get 60. This is useful for expense apps where you need to expense half of something.
If folks are interested, I can open source these bits. I’d like to expand them as much as possible to handle an even wider variety of inputs.
That's a cool library. I note that WolframAlpha handles this type of stuff readily. Does anyone ever bundle Wolfram products into theirs to handle natural language type things? I'm not immediately sure of the licensing framework, but it would seem nice to be able to do that.
Edit: It seems that WolframAlpha does have an HTTP API.
Embedding wolframalpha is probably overkill, when all you need is simply a small arithmetic expression parser and to understand expressions like "next month" or "2 days ago", which even tools like GNU date support.
I quite like the iOS time picker, but agree the analogue clock style that I think Android popularised is awful. The iOS one also gives a number keypad if you tap the wheels so you can enter that way if you prefer. It’s a shame they don’t do anything similar for dates.
I've never see the analog style clock one before, wow that is garbage. I'm not a fan of the iOS style time 'reels' either, but like you say, at least it opens a keypad if you click on them.
To break down why this picker is bad, here are several UX snags I immediately ran into.
1) It was not obvious how to set minutes, and I spent several seconds trying to get the hour hand to go in between hours.
2) When I let go and it snapped to minutes, it was not obvious to me how to go back and change the hour I had just input incorrectly. Then after I input minutes I expected it to jump back to hours but it didn’t. This is especially bad if your first interaction is a single touch rather than a press and hold, as it will jump with a wrong input and no obvious way to go back before you can even process how the interface works.
3) I have to look at different areas at the same time to select a time. My finger is trying to scroll a circle (where btw my finger covers the number), but I have to look above to see what the input is.
4) The above was even trickier in the minutes inputs, since there were not markings for sub-5 minutes.
5) It was not obvious that the top bar was clickable as an input area to select am/pm, especially since clicking the top bar would not otherwise allow you to input the time.
6) It’s not obvious with the switch to minutes / seconds that the units have switched. Need some representation of this on the clock face itself.
Some major ticks on all inputs and minor ticks that pop up on the minutes input would help a lot with 1, 4, and 6. Could be subtle markings, but would help quite a bit imo. But really this didn’t need to be anything other than a simple text input.
Those aren't so bad, they're reasonably intuitive to anyone who knows how to read an analog clock, and though they're easily fat fingered, you do one click for hour, one for minute and AM/PM in the non 24h versions. Imagine a scrolling time picker where you couldn't scroll the hours, only the minutes. That's what common date pickers are like.
I'm still perplexed that this isnt how every website works.
The absolute worst are date pickers that grey out unbookable dates to look like past dates and default to one week from now, leading me to believe, if I'm not careful, that Im booking a ticket for today.
Seemingly no website that lets you book things has sensible date UX.
Some of these are really great ideas! But I think they should be relegated to an external library or perhaps a web component. The issue here is this is the HTML datepicker. The picker itself isn't well-defined but things like being able to type in human-readable data/time and having it interpret that would likely conflict with the HTML standards already defined and be extremely difficult to define further. Not to mention you could only really do something like that on desktop and the issues pointed out in the post are dealing with mobile date pickers
Very nice site. I was clicking around trying to find a sample of your date-picker and noticed that the "Free Courses" link is not working properly. I believe it is treated as a relative link as it takes me to:
In my opinion the syntax of layerci is relatively simple as someone coming from docker, and does basically boil down to "give us the commands you use to deploy"
However they also have the advantage that they can run deployments on arbitrary runtimes. It looks like reploy only works if my app fits in the runtimes that were preconfigured by you. Because of that, I can run not just my dev deployment, but something very close to my prod deployment as well (we've had multiple bugs that only show up in prod due to our build process).
And finally, their aggressive docker-like layer caching allows very substantial speedups in not only builds, but tests as well. The speedups are typically in the triple digits compared to a reasonably well-optimized build.
I think the differences are major enough that I wouldn't exactly characterize the end results as similar.
> their aggressive docker-like layer caching allows very substantial speedups in not only builds, but tests as well
Makes sense; Reploy actually won't run your tests (or any other CI-esque things to that note). We're very much focused on only spinning up environments!
Overall, there is definitely overlap here. I'd argue that if someone wants to spin up a frontend, backend, db, etc., it makes a lot more sense to enumerate your `services` rather than try and serve them all in a single runtime (I think this is called a Layerfile?). I'm not sure how a use case like this would work with Layer, but that would be my hesitance in trying to set things up.
Layer seems like a great option for running long jobs to really take care of that speed up.
I think there are 3 things that contribute to this:
1. It is very easy to make a prototype that looks "magical" but very hard to build something that works in real applications. There are an enormous amount of quirks that a browser allows, and each site you encounter will use a different set of those quirks. Sites also tend to be unreliable, so whatever you build has to be very resistant to errors.
2. There is a technological wall that every company in this space reaches where it is not yet possible to mass-specialize for different websites. So even if you're able to build a tool that works very well on any individual website, the technology is not there yet to be able to generalize the instructions across websites in the same category. So if a customer wants to scrape 1000 websites, they still have to build custom instructions for each website (5-10x reduction in labor vs scripting) when what they really want/is economically viable for them is to build a single set of instructions that will work for all similar websites (10000x reduction in labor vs scripting). This is something that we're working on for the next version of parsehub, but is still a couple years away from launch.
3. Many of the YC startups you hear about have raised funding from investors and have short term pressures to exit.
The combination of the three makes it very tempting to give up and sell.
#2 is what would transform this from a nice niche tool, to something very valuable. In the ecommerce space, tracking competitor pricing is a great example of this type of thing. I can also see use casese for recipe's, finance, healthcare, you name it. Those b2b use cases are worth real money.
Just curious, in your experimentation, have you found it necessary to train a new model for each "category"? Or have you found a way to generalize it?
Training a new model for each category is already possible today, but doesn't achieve the goal (mass-specialization).
The problem is that when you pre-train a model, you can only solve for the lowest common denominator of what every customer might want.
In ecommerce, for example, you might pre-train to get price, product name, reviews, and a few other things that are general to all ecommerce. But you won't pre-train it to get the mAh rating of batteries, because that's not common to the vast majority of customers (even within ecommerce). It turns out that most customers need at least a few of these long-tail properties that are different than what almost every other customer wants, even if most of the properties they need are common.
And so the challenge is to dynamically train a model that generalizes to all "battery sites" based on the (very limited) input from a customer making a few clicks on a single "battery site".
1. it's possible to make it "easy to switch" by having common building blocks and only changing the "selector" across sites - lots of companies in the space do this
2. it's impossible to do "just DOM" or "just vision/text" if you want to be able to generalize "get the price of the items"
- DOM doesn't represent spacial positioning very well (see: fixed/absolute positioning, IDs and dom changing without the visuals changing, ...) so you'd need the equivalent of an entire browser rendering engine in your "model" anyways!
- vision/text is messed up by random marketing popups (see: medium, amazon, walmart, ...), it's significantly more computationally expensive to do, and can't currently get >95% accuracy (which makes it useless, scraping needs very close to 100% accuracy in most use cases)
> So if a customer wants to scrape 1000 websites, they still have to build custom instructions for each website...
Can't this be crowdsourced in some way? Having each individual entity reinvent the same wheel feels like the main problem to me. What if there was a marketplace? The ability to buy / trade / sell? Maybe subscription based in some way?
If I wanted to scrape 100 sites, it might be worth $1 per year per site. Those who put in the time make money. Those who don't have the time would pay.
This isn't a technology issue per se. It's scaling a solution to the final gap the technology can't cover. A different kind of mechanical turk?
Yes. But there might be some who would not be interested but still do it for minimal pay.
It would also lower the barrier to entry and thus increase the size of the market. Imagine if the first X sites I tired all needed more work. I'd likely quit. But if that didn't happen, I'd more likely continue.
Crowdsourcing isn't The Answer. But it's certainly a better step in the right direction.
We used to use Intercom and were frustrated that they charged us a random amount every month.
They also don't have tools for lead gen or making calls to customers. It was a big pain having our calls go through skype. We'd have to take manual notes on the call and there was no good way to schedule follow ups so we ended up using a mish-mash of systems to do this.
Shameless plug: In the end, we started a competing product, MomentCRM, which has simple, predictable pricing, and spans the entire lifecycle of your user. No more data silos or "integration engineers"! I'm one of the founders, and I will move mountains to make sure you're happy if you decide to try it :)
We're a small team from Toronto, Canada that's also behind ParseHub.
Our goal was to launch quickly and iterate, so the public-facing portion of the site is somewhat barebones at this stage. We'll be sure to add legal info shortly.
We allow you to do fine-grained censoring of any DOM element by adding class="do-not-track". So if there's a field, or an entire page, that you do not want captured, you can easily mask all of it.
Passwords fields are always censored, and there's no way to disable that.
We also have limited session lengths (up to 30 days), unless a user leaves feedback or a member of the team explicitly saves a moment.
You can learn more here: https://moment.help.guide/v1/user-manual/time-travel/privacy