Hacker Newsnew | past | comments | ask | show | jobs | submit | samblogs's commentslogin

I'm using Deviceplane for this right now - it's designed for embedded linux machines but could be used on any linux distro. Is anyone else using Deviceplane still? It seems the project has gone dead, though the website and github pages are still up.

I like it because of the easy web interface, and ability to tag / organize machines. Authentication is really simple.

https://deviceplane.com/


Regulations (https://www.investopedia.com/terms/r/regsho.asp) exist to prevent more shares being shorted than exist. However, those lending out shares to be used in a short can demand them back. Also, banks might demand you put up more capital as a stock you shorted increased in value. But I wanted to clarify that there are regulations such that you can't short a stock out of thin air, the stock you're shorting must be "located". Making shorting completely illegal would likely lead to irrationally high values in the market, creating more bubbles like this one.


I am very unfamiliar with electron and security in general. But generally I understand electron as a browser-like sandbox for desktop applications.

Can someone please explain how the "electronSafeIpc" might be implemented? Naively this functionality seems to be the very dangerous part of this exploit, and seems to be a workaround of electron's intent to sandbox your application?


Electron uses an IPC to communicate between processes. Each process is like a thread, but really it’s more like a chrome tab. Most apps have at least two processes, main and renderer. The IPC passes JSON events between them. “ElectronSafeIpc” appears to be a Microsoft implemented function that is wrapping up the native IPC functions and is assumingly providing some sort of safety checks. I gather the safety checks weren’t good enough, so once one process is taken over, the researcher has managed to use the IPC to access the main process. That’s still sandboxed usually but...


Does anyone have a good detailed article on the crypto behind iCVV/dynamic CVV? This article summarizes how it works, but I haven't found a good detailed article after much googling


I found this from a public FirstData document:

"Codes written on the track with equivalent data stored on the chip to prevent fraud. All chip cards are issued with the card security code on the track data stored on the magnetic stripe and chip card security code stored on the chip. Calculated with the same DES key but with a ‘999’ service code"

https://www.firstdata.com/downloads/marketing-merchant/EMV-A...


Thanks for your feedback! I have 0 experience with mapping so it was fun to see all the tools out there. There's much more out there than I expected. I did notice they had the API, but figured I would learn something a little more universally applicable by learning PostGIS. I should try that out though for a more lightweight and cheaper option next time


Absolutely and that's critical knowledge - PostGIS is super powerful and the experience with GDAL is definitely good to have (and to understand the transformations that are possible)

One of my favorite primers is by Robert Simmon who I had the pleasure of seeing at OpenVis: https://youtu.be/N_dmiQI1s24

RE mapping tools - I've been working a lot lately with Vector Tiles and their embedded props and from a web-mapping perspective it's nice to download the geometry once and then style many times in terms of over-the-wire efficiency.

Happy hunting and thanks for your post.


The vector file seems really useful. I ran a query that resulted in a 1.5 GB geojson file... much too big for Leaflet. Maybe the Vector tile would be compact enough? Thanks!



Yeah I know that pain.

You'll need the MapboxVectorTiles plugin for leaflet but you can definitely improve the sizes by a fair bit.


When you're doing tiles, you need to simplify to highest resolution actually discernible in that tile. So, for each zoom level, generate bbox tile bounds, and then simplify or cluster everything in each tile for the pixel resolution you want. That way you will never have 1.5GB tile. After all, all that data is wasted space if it can't be seen.

I've done this for GeoJSON tiles for a long time, before the MVT tiles. The MVT tiles pack way more data though, but are not a solution to the O(n2) problem.


Reduce the precision, 15 decimal places are useful for picometers, not a web map. Try 5-6.


It never seems worth the effort in my testing, as you have to come up with your own loop to do the truncating, and the benefit is marginal. In this case he’d have 1.2gb file, I doubt that fixes the problem.


for what it's worth, ST_AsGeoJSON lets you specify decimal precision as an optional argument, so you at least don't have to write a truncating loop.

Another good option with many polygon geometries is Base64 encoding the output of ST_AsGeobuf -- it is many times smaller than GeoJSON and still pretty easy to handle from Javascript. (Needs libprotobuf-c on the PostGIS side and geobuf.js+pbf.js on the JS side)


Thats cool, I should try AsGeobuf as a soft upgrade to one of the older tile GeoJSON site :)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: