А я и сейчас время от времени Jescola Buzz запускаю. Причем плагины продолжают появляться, а комьюнити развиваться. Тоже весьма интересная программка. Модульность, куча всевозможных генераторов и фильтров, которые можно соединить между собой практически как угодно… Как для бесплатной программы — вполне даже неплохо.
Это они ПОКА бесплатно регистрируются.
Опять же — дополнительный «источник дохода» для проверяющих органов, учитывая широту трактовки понятия «персональные данные» и необходимости регистрации соответствующей БД.
А потом еще можно будет брать деньги за сертификацию по охране этих самых персональных данных в БД, а не сертифицированным запретить обрабатывать ПД без установки (с предварительным приобретением у «правильных поставщиков») комплексной системы защиты разработчиков из рекомендованного списка…
В общем, Остап Бендер от зависти может съесть свой дивный, в серых яблоках, костюм без гарнира.
Поддерживаю.
Где-то еще слышал выражение «увы, даже разработчики абсолютно надежных систем часто недооценивают изобретательность клинических идиотов».
Текущая проблема в организации безопасности в том, что либо на нее кладут большой и толстый, либо «закручивают гайки» на столько, что даже свои прямые обязанности выполнять сложно (на согласование действия с отделом безопасности уходит половина или больше рабочего времени).
Система безопасности должны быть сбалансированной и адекватной защищаемому объекту.
Потому что компьютер неуязвимый к компьютерным атакам — это компьютер выдернутый из сети и запечатанный в сейф. И то — сейф могут украсть, а здание разрушить. :)
Первое — все перечисленные выше протоколы — протоколы связи. Они обеспечивают взаимодействие девайсов на сетевом уровне, но они ничего не знают о исполнительных командах, которые может принимать и обрабатывать каждый из модулей. Это привилегия командных протоколов.
Кроме того, все перечисленные протоколы — беспроводные. А как быть. если хочется на проводах построить? Там и дешевле, и надежность повыше.
Насчет «домик спалить» — замыкания и неполадки бывают и в сертифицированных устройствах.
Из-за того, что можно порезаться ножами пользоваться не перестают. Так же как и зная о взрывоопасности природного газа он остается одним из главных источников энергии. В том числе в бытовой газовой плите. Потому что соблюдаются определенные правила и техника безопасности.
Если человек в состоянии самостоятельно спаять и запрограммировать микропроцессорное устройство, я думаю ему хватит ума рассчитать цепь нагрузки конечного устройства. Иначе он сам себе злобный буратин, так как в конце концов сами детали, из которых будет состоять плата, имеют свои технические (паспортные и сертифицированные) характеристики. А из-за того, что народ по недоумию вешает несколько электрических обогревателей на 10А удлинитель, который от такого обращения может загореться вполне себе реально (особенно если не будет перегруза по автоматам защиты), производителя удлинителей не посадят.
Да чего уж огорчать, наоборот, порадовали. :)
Собственно ранее искал, но как-то на глаза не попадалось. Хотя, может быть искал плохо.
По связным протоколам — да, по управлению — нет.
Тогда, действительно слабо представлю, что именно хотят в заголовке. Так как достаточно реализовать контроллер и набор управляющих модулей и датчиков, а там уже сами пользователи, что захотят, то и соберут.
Применительно к тому же управлению аквариумом: датчик температуры + исполнительные модули на включение подсветки и аэрации (и/или фильтра) — вот и готова система. Контроллер, пара датчиков и пара исполнителей.
Аналогично управление вентиляцией, отоплением и т.п.
То есть контроллер, выносные датчики, и управляющие платы (самое простое — релюхи; если поставить с перекидной группой, можно включать по желанию либо на замыкание либо на размыкание).
Протокол взаимодействия тогда действительно лучше взять что-то из существующих (быстрым взглядом, тот же VSCP вполне себе вариант) и делать просто модули (учитывая то, что есть вариант с CAN-шиной, а VSCP с CAN должен дружить «по-умолчанию»).
> Вообще-то когда я говорю про ZigBee, Z-wave и тд — совершенно логично что к ним существует (и уже большое количество) и модулей управления и прочего
— Я ничего логичного не вижу. Ибо, я повторяю, перечисленные стандарты всего лишь протоколы связи между устройствами. Управление же устройствами умного дома (без разницы как они соединены) формат проприетарный, завязанный на конкретного производителя и исключающий подключение сторонних устройств.
Ну, я рад за Lightwave, что они смогли «пробиться».
Почему бы не «изобрести свой велосипед» и не пробиться с ним?
Опять же, открытая спецификация, которая позволить избежать VendorLock и привлечь к взаимодействию разных производителей — тоже вполне неплохая цель.
А изготовление сертифицированных устройств с поддержкой такого протокола — лишь дело времени.
Что касается электрооборудования, то давайте не путать исполняющее устройство и устройство управления. Никто в здравом уме блок управления, например, газовым котлом заменять не будет. А вот подать удаленно сигнал этому устройству включиться на поддержание заданной температуры — почему нет?
На сколько я знаю, системы «умных домов» разных производителей как правило между собой не совместимы. Именно как раз в плане взаимодействия сейчас есть большая проблема.
LWRF еще не смотрел, что это такое.
(быстро глянул по сайту — детального описания технологии не нашел, тем более как сделать самому).
ZigBee, Z-wave, X10 — это протокол и технология взаимодействия, но не управления. Это все равно что сказать «давайте Ethernet-ом управлять свичами».
Кроме того беспроводные модули и ZigBee и прочие стоят заметных денег. По малопроводным шинам соединять устройства дешевле и проще для DIY — модули под шину данных при наличии определенного скилла сделать проще, в отличие от сертифицированных беспроводных модулей, которые однозначно стоят денег, даже сами контроллеры, без обвязки или готовой распайки, и далеко не мизерных.
О системе «умного дома» задумываюсь давно. Вопрос свободного подключения устройства и легкой конфигурации — один из самых мною обдумываемых.
Все зависит от архитектуры. Дело в том, что полностью «умный» модуль собирать и несколько накладно, и программировать много надо. Как по мне то архитектура должна быть построена по принципу «master-slave». Есть один центральный контроллер (или несколько, либо для отказоустойчивости, либо параллельного управления из разный мест; хотя тут есть свои и преимущества и грабли). Есть туча модульных датчиков и исполнительных устройств (модули могут быть объединены один мультимодуль).
Теперь, что касается управления. Модуль подключается к системе (шину сейчас в рассмотрение не берем). Нажимается кнопка «зарегистрировать в сети». Мастер и модуль находят друг друга и запоминают — мастер, что такой модуль есть, модуль — кто у него управляющий. Это позволить даже в пределах одной среды передачи данных организовывать несколько независимых сетей управления (опять же, от шины передачи пока абстрагируемся, тем более, что их можно организовать несколько).
После регистрации в сети модуль отсылает мастеру параметры. Причем — человекочитаемые. XML либо JSON, или еще что-от подобное, где передается следующая информация:
— название модуля (потом в мастере можно присвоить ему кастомное название, но у модуля должно быть «заводское». чтобы понимать с каким устройством работаем, например это датчик температуры, влажности, или вообще реле времени)
— потом список параметров и их типы, с которыми может работать модуль
— значения — могут быть только прочитаны (например температура с цифрового градусника или значение давления с манометра)
— команды — название и возможные принимаемые состояния (например, «шторы закрыть», «шторы закрыть»)
у каждого параметра есть его ID и текстовый параметр (можно сделать несколько языков, для интернационализации).
Контроллер запоминает данные и может с ними работать.
Что это дает?
Первый плюс — не надо иметь «драйвера» и базу данных описания каждого контроллера или датчика. Собственно описание параметров и возможных действия с модулем сообщает сам модуль.
Также это дает возможность строить на мастер-контроллере сценарии даже неподготовленному пользователю.
То есть, например, создание сценария «утро»:
— создать новый сценарий, дать ему название
— выбрать из списка имеющихся датчиков датчик освещенности «гостинная»
— добавить условие, что если значение «уровень освещенности» больше определенного уровня (границы значений также можно передавать в параметрах синхронизации), то
— отправить модулю «шторы гостинная» «команду „открыть“
— отправить команду „чайник“ команду „включить“
Естественно по шине данных гоняются только биты ID команд (или значений) и данные. Информация от модуля о конфигурации приходит один раз — при регистрации. Далее девайсы общаются двоичными командами „девайсу с ID 987 выполнить команду 2 с параметром 1“ и т.п.
Причем все это в визуальном виде, на основании информации полученной от модулей (я имею в виду построение скриптов). Можно как через спецПО, которое общается с модулем контроля, так и дополнительный модуль конфигурирования, где с использованием относительно недорогих экранов можно построить меню управления (которое динамически собирается контроллером, на основании информации полученной от исходных модулей).
С точки зрения разработчика модуля ему достаточно реализовать
— соединение по физической шине
— протокол регистрации в сети (нужно разработать что-то наподобие DHCP)
— описать в виде параметров и списка команд, что модуль может, а дальше дело за мастер-контроллером и пользователем системы.
В таком случае не нужны виртуальные машины. PlugAndPlay почти в чистом виде с человекочтаемой скриптовкой.
Да, от исполнительного модуля при этом понадобится какая-то минимальная логика, но микроконтроллеры нынче недороги и компактны. Тем более, что со стороны именно модулей особой „умности“ и не нужно — достаточно уметь общаться с мастер-контроллером да выполнять полученные от него команды.
»Навороченность" же мастер-контроллера в таком случае тоже не требуется — ему нужно будет только хранить таблицы значений «модуль»-«параметр»-«команда», скриптовку в двоичном виде и знать как адресовать модуль — по какой шине он подключен и куда отправлять команду на управление или считывание значения.
Основная его задача — регулярно мониторить показания датчиков и проверять условия срабатывания скриптов (да выполнять скрипт по срабатыванию триггера).
Определенная «моща» все же нужна будет — память, чтобы хранить скриптовку и данные о системе в целом, обрабатывать сигналы по шинам данных и т.д. Но двухъядерный гигагерцовый процессор там не нужен.
Для удешевления, сначала можно настройку организовывать с компьютера. Кому хочется «навороченности» и автономности — разработать модуль управления и редактирования скриптов с экраном, который будет подключаться к мастер-контроллеру.
Оформить протокол взаимодействия под каким-нить названием типа OHCP — Open Home Control Protocol — и продвигать.
Перепайка на не совсем.
Реболлинг — это отпайка микросхем и контроллеров в BGA (Ball Grid Array) корпусе (можно погуглить что это такое), новая «накатка» этих самых ball-контактов припоем (обычно через специальный трафарет) и повторная запайка на плату.
В указанном случае — видимо контроллер нагревается выше температуры плавления припоя и «съезжает» с посадочного места или просто отходит часть контактов.
В таком случае реболлинг может пофиксить проблему — отпаять микруху, восстановить контакты, запаять обратно и организовать нормальный теплоотвод, чтобы ситуация не повторилась. Но скилл в пайке нужно иметь нехилый (плюс оборудование, обычно специальный термо-фен; не промышленный :) ).
Вполне себе нормальное решение. Главное емкость подобрать.
А с учетом наличия SMD-кондеров это сэкономит память и такты внутри контроллера и не займет много места на плате.
Фишка в том, что для конечного пользователя ресурса(ов) на данном IP сайты выглядят как лежащие в дауне. ТО есть просто не ходит пинг и отсутствует доступ на сетевом уровне.
Хотя, казалось бы, на сколько сложно при доступе по данному IP сделать редирект на страничку с уведомлением «доступ к данному ресурсу заблокирован согласно постановлению суда» или что-то подобное.
Так пользователь был бы хотя бы в курсе, в дауне сайт или просто кому-то в голову желтая жидкость стукнула в голову и на сетевом уровне забанили IP на котором нашли запрещенный «1.wmv».
Женат. Счастливо. Есть ребенок.
Порнуху в Гугле не искал — и так знаю где брать, если надо. :)
История запросов — более чем богатая (и сексуальный контент там практически отсутствует), так что замечание не по адресу. :)
Просто такова суть интернетов — «киска» нынче ассоциируется не только (не столько) с котиками, а по запросу «пилотка» только на половине (в лучшем случае) картинок будет головной убор.
Много чего поменялось с не таких уж давних пор. Ведь и голубой ведь раньше был просто красивым цветом…
А каким боком SOPA к платежным сервисам и системам?
Если примут проект, то блокировать будут пути РАСПРОСТРАНЕНИЯ, а не оплаты «незаконного» «товара».
Но тут вопрос или полной халявы — торренты, файлообменники и прочие p2p-системы, или реально-нелегального распространения «запрещенного» товара, где пока самые стойкие позиции у наличных банкнот. Так как наличная бумага имеет свои преимущества в качестве средства платежа.
Хмммм… Хитроумно… Но зачем?
Все что попадает на сторону пользователя можно перехватить. От банального Printscreen, но копания в кеше браузера (последнее врядли можно как-то обойти).
Я уж не говорю о разного рода «грабилках», который вполне себе замечательно детектят поток по content-type и позволяют выгрести графику «на лету».
ООО «Кактус» судя по всему — провайдер. Также, скорее всего, поставили точку (возможно повышенной мощности) для предоставления беспроводного интернета клиентам. А вот для такого как раз нужна лицензия и разрешение Частотнадзора с согласованием места установки и ТТХ оборудования.
Тот же D-Link тоже разным бывает. У них есть и промышленные точки для организации WiFi-мостов (а при превышении определенной мощности излучения точку уже можно считать базовой станцией, на которую требуется разрешение).
Ну, даже у нас в стране право не прецедентное. Но в случае толкования спорных и неоднозначных моментов законодательства судья может руководствоваться результатами аналогичных завершенных дел. Так что прецедент в любом случае играет роль (хотя в конечном итоге на решение судьи это может и не повлиять, все же реакция и огласка результатов предыдущих аналогичных процессов часто принимается во внимание, с учетом текущей ситуации).
Оргстекло и прочий акрил — да.
Тут прокатит разве что поликарбонат — он более стоит. Но монолитный поликарбонат стоит очень приличных денег. Судя по всему, оракал рулит. :)
Опять же — дополнительный «источник дохода» для проверяющих органов, учитывая широту трактовки понятия «персональные данные» и необходимости регистрации соответствующей БД.
А потом еще можно будет брать деньги за сертификацию по охране этих самых персональных данных в БД, а не сертифицированным запретить обрабатывать ПД без установки (с предварительным приобретением у «правильных поставщиков») комплексной системы защиты разработчиков из рекомендованного списка…
В общем, Остап Бендер от зависти может съесть свой дивный, в серых яблоках, костюм без гарнира.
Где-то еще слышал выражение «увы, даже разработчики абсолютно надежных систем часто недооценивают изобретательность клинических идиотов».
Текущая проблема в организации безопасности в том, что либо на нее кладут большой и толстый, либо «закручивают гайки» на столько, что даже свои прямые обязанности выполнять сложно (на согласование действия с отделом безопасности уходит половина или больше рабочего времени).
Система безопасности должны быть сбалансированной и адекватной защищаемому объекту.
Потому что компьютер неуязвимый к компьютерным атакам — это компьютер выдернутый из сети и запечатанный в сейф. И то — сейф могут украсть, а здание разрушить. :)
Кроме того, все перечисленные протоколы — беспроводные. А как быть. если хочется на проводах построить? Там и дешевле, и надежность повыше.
Насчет «домик спалить» — замыкания и неполадки бывают и в сертифицированных устройствах.
Из-за того, что можно порезаться ножами пользоваться не перестают. Так же как и зная о взрывоопасности природного газа он остается одним из главных источников энергии. В том числе в бытовой газовой плите. Потому что соблюдаются определенные правила и техника безопасности.
Если человек в состоянии самостоятельно спаять и запрограммировать микропроцессорное устройство, я думаю ему хватит ума рассчитать цепь нагрузки конечного устройства. Иначе он сам себе злобный буратин, так как в конце концов сами детали, из которых будет состоять плата, имеют свои технические (паспортные и сертифицированные) характеристики. А из-за того, что народ по недоумию вешает несколько электрических обогревателей на 10А удлинитель, который от такого обращения может загореться вполне себе реально (особенно если не будет перегруза по автоматам защиты), производителя удлинителей не посадят.
Собственно ранее искал, но как-то на глаза не попадалось. Хотя, может быть искал плохо.
По связным протоколам — да, по управлению — нет.
Тогда, действительно слабо представлю, что именно хотят в заголовке. Так как достаточно реализовать контроллер и набор управляющих модулей и датчиков, а там уже сами пользователи, что захотят, то и соберут.
Применительно к тому же управлению аквариумом: датчик температуры + исполнительные модули на включение подсветки и аэрации (и/или фильтра) — вот и готова система. Контроллер, пара датчиков и пара исполнителей.
Аналогично управление вентиляцией, отоплением и т.п.
То есть контроллер, выносные датчики, и управляющие платы (самое простое — релюхи; если поставить с перекидной группой, можно включать по желанию либо на замыкание либо на размыкание).
Протокол взаимодействия тогда действительно лучше взять что-то из существующих (быстрым взглядом, тот же VSCP вполне себе вариант) и делать просто модули (учитывая то, что есть вариант с CAN-шиной, а VSCP с CAN должен дружить «по-умолчанию»).
— Я ничего логичного не вижу. Ибо, я повторяю, перечисленные стандарты всего лишь протоколы связи между устройствами. Управление же устройствами умного дома (без разницы как они соединены) формат проприетарный, завязанный на конкретного производителя и исключающий подключение сторонних устройств.
Ну, я рад за Lightwave, что они смогли «пробиться».
Почему бы не «изобрести свой велосипед» и не пробиться с ним?
Опять же, открытая спецификация, которая позволить избежать VendorLock и привлечь к взаимодействию разных производителей — тоже вполне неплохая цель.
А изготовление сертифицированных устройств с поддержкой такого протокола — лишь дело времени.
Что касается электрооборудования, то давайте не путать исполняющее устройство и устройство управления. Никто в здравом уме блок управления, например, газовым котлом заменять не будет. А вот подать удаленно сигнал этому устройству включиться на поддержание заданной температуры — почему нет?
LWRF еще не смотрел, что это такое.
(быстро глянул по сайту — детального описания технологии не нашел, тем более как сделать самому).
ZigBee, Z-wave, X10 — это протокол и технология взаимодействия, но не управления. Это все равно что сказать «давайте Ethernet-ом управлять свичами».
Кроме того беспроводные модули и ZigBee и прочие стоят заметных денег. По малопроводным шинам соединять устройства дешевле и проще для DIY — модули под шину данных при наличии определенного скилла сделать проще, в отличие от сертифицированных беспроводных модулей, которые однозначно стоят денег, даже сами контроллеры, без обвязки или готовой распайки, и далеко не мизерных.
Все зависит от архитектуры. Дело в том, что полностью «умный» модуль собирать и несколько накладно, и программировать много надо. Как по мне то архитектура должна быть построена по принципу «master-slave». Есть один центральный контроллер (или несколько, либо для отказоустойчивости, либо параллельного управления из разный мест; хотя тут есть свои и преимущества и грабли). Есть туча модульных датчиков и исполнительных устройств (модули могут быть объединены один мультимодуль).
Теперь, что касается управления. Модуль подключается к системе (шину сейчас в рассмотрение не берем). Нажимается кнопка «зарегистрировать в сети». Мастер и модуль находят друг друга и запоминают — мастер, что такой модуль есть, модуль — кто у него управляющий. Это позволить даже в пределах одной среды передачи данных организовывать несколько независимых сетей управления (опять же, от шины передачи пока абстрагируемся, тем более, что их можно организовать несколько).
После регистрации в сети модуль отсылает мастеру параметры. Причем — человекочитаемые. XML либо JSON, или еще что-от подобное, где передается следующая информация:
— название модуля (потом в мастере можно присвоить ему кастомное название, но у модуля должно быть «заводское». чтобы понимать с каким устройством работаем, например это датчик температуры, влажности, или вообще реле времени)
— потом список параметров и их типы, с которыми может работать модуль
— значения — могут быть только прочитаны (например температура с цифрового градусника или значение давления с манометра)
— команды — название и возможные принимаемые состояния (например, «шторы закрыть», «шторы закрыть»)
у каждого параметра есть его ID и текстовый параметр (можно сделать несколько языков, для интернационализации).
Контроллер запоминает данные и может с ними работать.
Что это дает?
Первый плюс — не надо иметь «драйвера» и базу данных описания каждого контроллера или датчика. Собственно описание параметров и возможных действия с модулем сообщает сам модуль.
Также это дает возможность строить на мастер-контроллере сценарии даже неподготовленному пользователю.
То есть, например, создание сценария «утро»:
— создать новый сценарий, дать ему название
— выбрать из списка имеющихся датчиков датчик освещенности «гостинная»
— добавить условие, что если значение «уровень освещенности» больше определенного уровня (границы значений также можно передавать в параметрах синхронизации), то
— отправить модулю «шторы гостинная» «команду „открыть“
— отправить команду „чайник“ команду „включить“
Естественно по шине данных гоняются только биты ID команд (или значений) и данные. Информация от модуля о конфигурации приходит один раз — при регистрации. Далее девайсы общаются двоичными командами „девайсу с ID 987 выполнить команду 2 с параметром 1“ и т.п.
Причем все это в визуальном виде, на основании информации полученной от модулей (я имею в виду построение скриптов). Можно как через спецПО, которое общается с модулем контроля, так и дополнительный модуль конфигурирования, где с использованием относительно недорогих экранов можно построить меню управления (которое динамически собирается контроллером, на основании информации полученной от исходных модулей).
С точки зрения разработчика модуля ему достаточно реализовать
— соединение по физической шине
— протокол регистрации в сети (нужно разработать что-то наподобие DHCP)
— описать в виде параметров и списка команд, что модуль может, а дальше дело за мастер-контроллером и пользователем системы.
В таком случае не нужны виртуальные машины. PlugAndPlay почти в чистом виде с человекочтаемой скриптовкой.
Да, от исполнительного модуля при этом понадобится какая-то минимальная логика, но микроконтроллеры нынче недороги и компактны. Тем более, что со стороны именно модулей особой „умности“ и не нужно — достаточно уметь общаться с мастер-контроллером да выполнять полученные от него команды.
»Навороченность" же мастер-контроллера в таком случае тоже не требуется — ему нужно будет только хранить таблицы значений «модуль»-«параметр»-«команда», скриптовку в двоичном виде и знать как адресовать модуль — по какой шине он подключен и куда отправлять команду на управление или считывание значения.
Основная его задача — регулярно мониторить показания датчиков и проверять условия срабатывания скриптов (да выполнять скрипт по срабатыванию триггера).
Определенная «моща» все же нужна будет — память, чтобы хранить скриптовку и данные о системе в целом, обрабатывать сигналы по шинам данных и т.д. Но двухъядерный гигагерцовый процессор там не нужен.
Для удешевления, сначала можно настройку организовывать с компьютера. Кому хочется «навороченности» и автономности — разработать модуль управления и редактирования скриптов с экраном, который будет подключаться к мастер-контроллеру.
Оформить протокол взаимодействия под каким-нить названием типа OHCP — Open Home Control Protocol — и продвигать.
Реболлинг — это отпайка микросхем и контроллеров в BGA (Ball Grid Array) корпусе (можно погуглить что это такое), новая «накатка» этих самых ball-контактов припоем (обычно через специальный трафарет) и повторная запайка на плату.
В указанном случае — видимо контроллер нагревается выше температуры плавления припоя и «съезжает» с посадочного места или просто отходит часть контактов.
В таком случае реболлинг может пофиксить проблему — отпаять микруху, восстановить контакты, запаять обратно и организовать нормальный теплоотвод, чтобы ситуация не повторилась. Но скилл в пайке нужно иметь нехилый (плюс оборудование, обычно специальный термо-фен; не промышленный :) ).
А с учетом наличия SMD-кондеров это сэкономит память и такты внутри контроллера и не займет много места на плате.
Хотя, казалось бы, на сколько сложно при доступе по данному IP сделать редирект на страничку с уведомлением «доступ к данному ресурсу заблокирован согласно постановлению суда» или что-то подобное.
Так пользователь был бы хотя бы в курсе, в дауне сайт или просто кому-то в голову желтая жидкость стукнула в голову и на сетевом уровне забанили IP на котором нашли запрещенный «1.wmv».
Порнуху в Гугле не искал — и так знаю где брать, если надо. :)
История запросов — более чем богатая (и сексуальный контент там практически отсутствует), так что замечание не по адресу. :)
Просто такова суть интернетов — «киска» нынче ассоциируется не только (не столько) с котиками, а по запросу «пилотка» только на половине (в лучшем случае) картинок будет головной убор.
Много чего поменялось с не таких уж давних пор. Ведь и голубой ведь раньше был просто красивым цветом…
Если примут проект, то блокировать будут пути РАСПРОСТРАНЕНИЯ, а не оплаты «незаконного» «товара».
Но тут вопрос или полной халявы — торренты, файлообменники и прочие p2p-системы, или реально-нелегального распространения «запрещенного» товара, где пока самые стойкие позиции у наличных банкнот. Так как наличная бумага имеет свои преимущества в качестве средства платежа.
Все что попадает на сторону пользователя можно перехватить. От банального Printscreen, но копания в кеше браузера (последнее врядли можно как-то обойти).
Я уж не говорю о разного рода «грабилках», который вполне себе замечательно детектят поток по content-type и позволяют выгрести графику «на лету».
А от неопытных картинку зачем защищать?
Тот же D-Link тоже разным бывает. У них есть и промышленные точки для организации WiFi-мостов (а при превышении определенной мощности излучения точку уже можно считать базовой станцией, на которую требуется разрешение).
Как-то все реально желтизной попахивает…
Тут прокатит разве что поликарбонат — он более стоит. Но монолитный поликарбонат стоит очень приличных денег. Судя по всему, оракал рулит. :)